For everything you need to know about accessibility, check out Web accessibility – Everything you need to know, on Programming Duck.
Disclaimer: I’m not a lawyer. This article only represents my personal opinion and current understanding. It is not legal advice. Please consult a lawyer for information on the legal aspects of accessibility.
Ensuring that your website is accessible shouldn’t be difficult. A little bit of effort can take you a long way in your day-to-day work.
To start with, if you’re completely new to accessibility, learning some of the basics will be very helpful. Please see how to learn accessibility for some useful resources to start with.
Afterwards, here is a simple process you can use to apply accessibility as you work:
- Learn about your legal accessibility requirements
- Use semantic HTML
- Check accessibility checklists frequently to ensure you’ve applied accessibility correctly in your work
- Test your website’s accessibility to ensure you’re doing it correctly
Optionally, you can also:
- Make accessibility part of the standards and the development process
- Educate people about accessibility
- Hire specialists if you need more help
Here are more details on each part of the process.
Legal requirements
Before starting, you should know about your legal requirements.
In general, for most companies, you should meet the WCAG 2.1 (or more likely, the latest published version) level AA accessibility standards. Level A is probably not sufficient. Level AA is the standard. Level AAA is "aspirational". It’s generally not a legal requirement to meet it, however it’s great if you can.
Additionally, you may need an accessibility statement depending on your country’s laws. Even if you don’t, WCAG mentions that there are many good reasons to have one. For information on accessibility statements, please see the WCAG article on developing an accessibility statement.
Use semantic HTML
Using semantic HTML is the most important thing you can do for accessibility. An easy way to do this is to scan through the HTML element reference on MDN. It lists all of the HTML elements and says what they should be used for. You can also visit a dedicated page for every element for much more information about it.
Use useful checklists
As you work, keep referring to these useful checklists:
WebAIM WCAG checklist
The WebAIM WCAG checklist provides great recommendations on the most important things you can do for accessibility. It’s one of the simpler checklists in this section. As a result, it’s great to refer to frequently and for the majority of your work.
WAI-ARIA authoring practices
The WAI-ARIA authoring practices provide guidelines for custom widgets created with JavaScript (things like accordions, custom dropdowns, etc.). Following these guidelines is very important for the accessibility of these widgets. Therefore, I recommend always referring to this resource whenever you’re working on something like that.
Additionally, this resource provides guidance on naming for particular elements. Some elements require a name, while for others a name is recommended, but not required. Thankfully, if you use semantic HTLM, the majority (if not all) of the elements that require a name will automatically get one associated to them from their content. In other words, you shouldn’t need to check this section very often.
However, the naming section provides additional recommendations for naming elements. If you want to improve the experience of screen reader users even further, feel free to check this section once in a while and apply some of its recommendations.
WCAG
WCAG includes the official specification that’s mentioned in the legal requirements. To be 100% compliant, you have to check against that.
However, this resource seems more difficult to work from than the others. For this reason, you may find it easier to work from the WebAIM resource in your day-to-day work. Then, you can check this resource when you want to do a more comprehensive accessibility audit.
Frequency of using the checklists
As for the frequency of using these checklists, you have different options. You can:
- Refer to them every time you’re working on something relevant and want additional information
- Scan over the documents every once in a while, perhaps once a week or so. That way, you can recall the work you did that week and make sure that you haven’t missed any accessibility requirements.
Test
To really be sure that your website is accessible, you need to test it.
There are different kinds of accessibility tests that you can do. They vary in complexity and time required. They can also be manual or automated.
Manual tests
Here are some things that you should consider testing manually.
Zoom
Test how your website looks when you use browser zoom. The WCAG standard currently requires your page to be readable and functional at 200% zoom. However, feel free to test higher than that.
Consider also testing your website with OS-level zoom (a zoom setting applied in your operating system settings).
Consider also testing your website with an application such as ZoomText.
Screen readers
Test your website with a screen reader.
For more thorough testing, consider testing your website with different common combinations of operating systems, screen readers and browsers:
- Mac or iOS with Voiceover and Safari
- Windows with Jaws or NVDA
- ChromeOS with ChromeVox and Chrome
- Android with accessibility options enabled and Chrome
- Linux with Orca
Keyboard navigation and interactivity
Test the keyboard navigation and interactivity of your website. Pay particular attention to things that work with JavaScript, such as custom widgets, modals, etc.
Ensure that keyboard navigation is sensible, easy and clear. The user should know exactly where the focus is every time.
Also ensure that the entire website can be operated using just the keyboard. The only exception to this rule is if that’s practically impossible, for example if you have functionality for free-hand drawing.
Vision deficiencies
Some browsers have a vision deficiency simulator. If you’re using Chrome, here’s Andy Osmani’s tutorial on the vision deficiencies simulator in Chrome. Here’s an article for using color vision simulator in Firefox.
Alternatively you can use a browser extension like NoCoffee vision simulator.
Document outline
The document outline refers to the headings of a webpage. Specifically, it refers to their heading level and their order.
Heading levels should descend in order, without jumps.
For example, this is fine:
<h1>h1</h1>
<h2>h2</h2>
<h2>h2</h2>
<h3>h3</h3>However, the following is not fine, because it skips / jumps from an h2 to an h4:
<h1>h1</h1>
<h2>h2</h2>
<h4>h4</h4>
<h2>h2</h4>An easy way to test these is to install a browser extension like WAVE or Outliner. They can show you the document outline very clearly, without you having to look at the source code of the page.
Accessibility testing tools
Here are some tools that you can consider using for accessibility testing.
Third-party services / analysers:
Page testing tools:
- Chrome developer tools:
- Accessibility tab
- Rendering tab -> Vision deficiencies simulator
- Lighthouse
- Browser extensions:
Build tools:
Also consider accessibility code linters for the technologies you work with. One example is the eslint-plugin-jsx-a11y for JSX.
Unit, integration and end-to-end tests for accessibility
In rare cases, you may want to write unit, integration or end-to-end tests for accessibility.
For example, consider that you’ve created a custom widget. You may want to have an end-to-end test for it to make sure that the widget can receive focus when the user presses TAB on their keyboard.
Recommendations for getting started with accessibility testing
When it comes to accessibility testing, there are many things you could test and many tools you could use.
To keep things simple, consider starting with the following:
- Use lighthouse to run audits on pages on your website. Then fix any errors it mentions.
- Do some manual testing for keyboard navigation, screen readers, the document outline and zoom.
As you get more comfortable, you can try out additional tools. For example:
- Try installing the WAVE browser extension or an alternative.
- Try setting up some automated accessibility testing with Lighthouse, axe-core or an alternative.
- Try installing some relevant code linters, such as eslint-plugin-jsx-a11y.
- And so on.
Alternatively, if you have the budget, you can also use a service like Tenon or even hire an accessibility consultant.
Make accessibility a standard and part of the development process
It’s useful to make accessibility an official part of your standards and development process. That way, it won’t be neglected.
This is similar to how you would make anything a standard in your codebase.
You may declare in your standards documents that accessibility is important and that all work is expected to meet the WCAG 2.1 AA specification, or at least the WebAIM recommendations and ARIA authoring practices recommendations.
You could also make it part of your development process:
- You could set up automated accessibility tests to be run on the pull request for every story.
- You could require developers to test the accessibility of their work before they submit a new feature.
- You could run a small accessibility audit once a month, or maybe a comprehensive audit once a year.
- And so on.
Educate people whose work ends up on the front end
As explained in Accessibility – Everything you need to know, front end developers need to know more about accessibility than anyone else.
However, all work that ends up on the front end can affect accessibility. This includes work done by designers, content creators and other job roles. Therefore, it’s useful for them to know about accessibility too.
For this reason, it may be good for front end developers to educate them.
Additionally, developers can collaborate with them or advise them on creating standards that ensures their work is accessible. For example, they may advise copywriters (people who write text on the website) that their work needs to follow a reasonable document outline.
Hire third-party accessibility consultants
Even if the developers in the company know about accessibility, they’re not specialists. They could be missing things that only a specialist may know of. Even if they’re not missing any legal requirements, a specialist may be able to enhance accessibility in ways that the developers may not think of.
So, if you want to be extremely thorough with accessibility, you may have to hire a third-party accessibility consultant or a specialist.
Summary
Accessibility work doesn’t have to be difficult.
Here is a simple process you can use:
- Learn about your legal accessibility requirements
- Use semantic HTML
- Check accessibility checklists frequently to ensure you’ve applied accessibility correctly in your work
- Test your website’s accessibility to ensure you’re doing it correctly
Optionally, you can also:
- Make accessibility part of the standards and the development process
- Educate and advise people on accessibility
- Hire specialists if you need more help
Final notes
That’s it for this article.
Please leave a comment if you have any feedback, anything I missed that might help others, or even anything you disagree with.
Next, if you want to know more about accessibility, please see the article Web accessibility – Everything you need to know.