Lessons learnt making a website pass Level AA WCAG 2.0

Accessibility is a tricky subject for web developers. I think most developers would say they:

  • build accessible websites already or
  • would like to in theory

However, if you work for a digital agency it’s likely you simply do not have the time to perform accessibility testing and it’s likely you don’t have anyone above you to help you out when you hit a brick wall – which is often when you first get started with a11y.

If you work in an organisation that does have the time to make things accessible you may not have the budget to properly test e.g. do you have the budget to pay for several different versions Jaws (because people don’t update Jaws too often) or the patience to run the demo version for 30 minutes at a time or the budget to pay for a 3rd party testing company?

For a recent project, I was tasked with making the site accessible. As I said before, most developers and designers like to think that their code/designs are accessible already but, in my experience, few actually test and ensure that they truly are. However, on this project the end-client requested Level AA WCAG 2.0 compliance and the agency (my client) hired a 3rd party supplier to test.

Whenever an accessibility bug was found, a card was created in Trello and that card stayed there until it was fixed. That meant accountability and it meant accessibility bugs could not be ignored.

When we make something accessible… what exactly are we looking to achieve?

  • The site works with keyboard functionality (e.g. tabbing to links and form elements with a mouse)
  • The site works for colour blind people (e.g. not just conveying information with colour alone)
  • The site works for people will poor eyesight (who may zoom in or simply need a large enough font size and high contrast)
  • The site works for visually impaired (or blind) people who use a screen-reader
  • The site works for people who can see but not well and may use a screen-reader to assist them (e.g. what is read aloud to them should corresp0nd to what they see on screen)
  • The site works if/when JavaScript isn’t available/doesn’t load (rare as this is)
  • The site works for deaf/hard-of-hearing people (e.g. videos have captions)

Ok so that’s the basics. But the phrase ‘the site works’ doesn’t always cut it… because things can technically work, but they don’t always make sense e.g. a big thing when building for screen-readers is that we don’t always want the screen-reader to read out content that is hidden off screen – confusingly – sometimes we do want the screen-reader to read out content that is hidden off screen. See… I told you it was difficult :)

An example

Take an example of a hamburger menu that is hidden off-canvas when inactive and slides into view when its active.

  • We only want the content of that menu to be read out when it is visible and open because remember not all screen-reader users are blind so we don’t want content read to them which seems like it is coming from nowhere.
  • We also want the button (which the user clicks to show/hide that menu) to indicate to a screen-reader that the it toggles the hamburger menu and what state the hamburger menu is.
  • We don’t want keyboard users to be able to tab (or up/down arrow) out of the menu when it is active and start tabbing visually hidden links elsewhere on the screen.
  • We want people to be able to close the menu by pressing the Esc key on their keyboard and by clicking outside of the hamburger menu itself (that is, if there is any empty screenspace that the menu does not occupy)
  • We want users to be returned to the position they were at before they opened the hamburger menu so they don’t get lost/disorientated.
  • We want users to have their keyboard focus returned to their previous location before they activated the hamburger menu and we want their focus to go to the first item in the menu when they first activate it.
  • We want to make sure the buttons that show/hide the menu are <button>s and not <a> tags to avoid confusion.
  • We want the hamburger menu (in some cases) to display if JavaScript fails to load – otherwise it would always be hidden.
  • We want the hamburger (and the site in general) to be fully functional and legible if the user zooms in 200% in their browser

That’s a lot of criteria. Showing a hamburger menu can be a few lines of code with jQuery. A click event on a link that toggles a class on the <nav> element and job done; making an accessible hamburger menu is a lot more work.

I’d say the first time you write an accessible JavaScript component like this you are at least doubling the amount of time it would take you to write it.

Lesson 1: Third party testing helps

My client hired a testing (QA) company called ULTRA who were brilliant. They pointed out lots of issues with my build which I had not considered and/or I didn’t realise were issues. After working with ULTRA on this project and testing on my own on other projects, my main takeaway for building accessible sites is: get an expert to test it. Providing you can afford it – of course.

Going through your templates with a screen-reader is beyond tedious and very time consuming. For me personally, I missed a lot of issues because I am not a  regular screen-reader user and I found learning Jaws and VoiceOver very difficult. I have no doubt I was not necessarily using it as a real user would use it so my testing was not really that great.

Lesson 2: Designing for accessibility from the start helps

Most of the big issues in development revolved around:

  • colour contrast
  • lack of link/button focus

Designers love light grey copy and links that don’t look like links. They hate :focus styles. Real people need to know what part of the page can be clicked/tapped and they need to know which current form input/link/button is currently in focus.

If you can get designers onboard early who will use properly contrasted colours and who think of various link/button styles (and not just a hover state) then 50% of a11y problems go away immediately.

A big factor I employed was to use :focus-ring on this project and in particular the focus-ring polyfill script. Focus-ring can help you to only apply a focus style when it detects that the user navigatig the site with a keyboard – therefore you can style infocus links/buttons for these people and remove focus styles for non-keyboard users. This isn’t ideal but I am yet to meet a designer who *gets* focus styles, but I am also yet to meet a designer who users their keyboard to navigate a website so you can trick them and add in some accessible focus style this way while still making them happy :)

Lesson 3: Having time helps

As I stated earlier, coding accessible websites takes so much extra time. If your client/boss doesn’t give you the time – it isn’t going to happen.

Luckily, for this project, the end-client made everyone aware that this was critical feature so my client had to build the time into the schedule for it and the end-client had to pay for the time.


Building accessible websites can be difficult. The issues can be hard to see for a developer, time-consuming to fix and more often than not, nobody will thank you for this extra work. You are effective building a website in such a way that everyone can access it without problems or avoidable annoyances and people (usually) notice things that work . Something working is a pretty low barrier because all websites should be built so they are accessible to and work for everyone.

Although, it’s hard – it is very satisifying to create something that you know works for everyone.

For further reading and practical coding tips head to Inclusive Components.

Comments are closed.