Writing code with two hats (and building accessibility from day one)

woman coding in office
By Luke Harby, Senior Front-End Engineer

For me, writing Front End code is a spectrum. At one end, it should be fun and experimental, and at the other, professional and conscientious with a focus on accessibility. There might also be a happy middle ground. Another way to look at this is that writing code means wearing different hats. 

The fun stuff

What happens if I stack 3 images on top of each other and pass them different css mix blend modes? Can you make a small witches head and animate it along a randomised path and when the user hovers on it the head fades out only to appear somewhere else on the page? (I was asked to make this). What if I invert this element? I probably shouldn’t but I want to see what happens. Let’s try and break something!

Photograph of a young girl grinning in front of an open laptop. The laptop is covered in stickers.
Image: PTBOCANADA. Creative Commons License

The serious stuff

Historically, accessibility issues were fixed on websites retrospectively. Perhaps after an organisational audit or after receiving input from canvassing users of assistive technologies. Accessibility issues might be addressed; they would generally be fixed after some intervention and sometimes begrudgingly. It doesn’t have to be like that. 

OK, but now we’re working on a large-scale website. It’s public facing and has a lot of daily visitors. People are accessing it from all over. We need to try and do the best to meet their needs. There are accreditations on the site from partner organisations. We have to be thorough and robust. Now we have to put on the professional hat. This brings me nicely on to accessibility.

Even if you are in this position of having to fix an existing code base, if you are using a modern JavaScript framework (at Amiqus we use Vue) then no doubt you will have created functional, reusable logic as components. If so, fixing any accessibility issues at the component level will cascade across the entire application once implemented. It doesn’t have to be super unwieldy. 

Going forwards, it’s better and easier to bake accessibility into your application when building new components. So getting it right early on will pay dividends. 

New browser features are being added all the time. We now have a native details element (similar to an accordion), date and colour pickers, modals, and some exciting stuff in the pipeline (a dropdown element)! At Amiqus we have started using Primevue for some of our base components. The nice thing about this is there are accessibility features built into Primevue, but we create a wrapper for the component and are then able to pass through additional attributes and properties and add additional accessibility features if required.

In the past making a date picker would involve using a third-party library which would have pasted a ton of HTML markup over your existing elements. There would be a Git issues list as long as your arm and tons of configuration you might never need, and you would have to deal with a plugin that handles dates and times properly. Accessibility in these libraries also varied enormously – well, from none to slim. 

The W3C have always been mindful about developing elements with accessibility built in, and I think it’s better now than it has ever been. These new native elements have accessibility at the forefront, they will work cross-browser and are much simpler, lighter and easier to maintain. You can keep them as native inputs and in some cases even style them.

Image: Meme generated by Will Boyd from an original comic strip by Joshua Barkman.

In addition, there are now way more tools to help developers in tracking down accessibility issues. There are probably more than I can go into here but I am going to list a few of my favourites and ones that I think are useful. 

  • Chrome Lighthouse – Open the inspector in Chrome on any web page and run a report. It will highlight issues in sections with accessibility being its own section. This is a good starting point. 
  • Chrome Accessibility Tree view – Chrome also has an inbuilt viewer that displays a full-page accessibility tree and helps to show what users with assistive technologies might experience.

    Screenshot from the Chrome Internet Browser. It shows a console which is open using the Accessibility panel.
  • IBM Equal Access Toolkit – This is my favourite tool to use. There is the chrome extension that will generate page reports, has links to specific issues, and also allows you to pinpoint in the code and in the browser where the problem lies. 
  • h123 Accessibility HTML5 Outliner – Useful for testing headings which are important.
  • Vue eslint a11y plugin – Do you use a compiler? Of course you do. Why not add this to your repo and get some real time accessibility reporting in your tooling. This is specific to our business use case but there are plugins for other languages.
  • Better mobile inputs – Make forms easier to interact with for mobile users.
  • Storybook – I love this tool but it’s been a while since I have used it, we are implementing a new version at Amiqus and there are some really nice Accessibility tools built in. 

Legality

Even if you have read the above and are skeptical or worried about the resources needed to implement accessibility on your site, you must still address any issues. The European accessibility act is a directive which came into effect in June 2025. It aims to provide equal access to digital services for all users but especially those with additional needs. And it gives those users the power to report organisations which fail to provide such services. This could lead to fines and/or legal action. Even if you don’t find accessibility issues on your site, your customers and clients surely will. And now they have the power to do something about it. 

Caveat

I am absolutely NOT an expert in the area of website accessibility. To my mind, website accessibility is a spectrum, and there are always ways to make sites more accessible. It is not simply a case of pass or fail. It’s a journey, and it is ongoing. I still feel like I am at the very start of this journey. 

I am extremely proud to be working in a company where we try to champion accessibility and make it at the forefront of everything we build. If you make your sites as accessible as possible, you make it better for everyone. 

Finally I would like to leave you with this quote I often think of. 

“We’re all just temporarily abled”
– Cindy Li 

See the latest blogs & articles from our team

candidate shaking hands with an employer
Staff Vetting

3 practical steps to digital DBS compliance

man using laptop
Staff Vetting

Avoiding delays in BPSS screening: the four pillars HR teams must get right

photo-id-verification
AML

Digital identity: The new standard in Scottish property transactions