Frontend checks for web accessibility
Testing for valid, semantic HTML is essential for the accessibility of your work. In this page we list some essential requirements and best resources. It gives you the minimum tests you need to do during development and before you commit your work.
While you develop, always check the following items while developing: keyboard navigation, W3C validation, WCAG 2 AA validation and then announcement of dynamic changes for screen readers.
Note: validators are not perfect, it’s new technology and work in progress. They miss issues and sometimes also can give false positive. Investigate if the issues found are valid.
Using semantic, meaningful, valid HTML5.
That way all devices, browsers and users can understand and interact with the functionality on a web page. The best resource for HTML5 are the MDN web docs.
For WordPress we aim to meet the WCAG accessibility guidelines at level AA and the W3C standards. In the WordPress Accessibility handbook section Best Practices you find examples and resources.
You need to do two different checks, one for keyboard navigation and one for DOM validation.
Top ↑
All functionality should work using a keyboard only. This essential for all assistive technology to work properly. The only way to test this, at the moment, is manually. The best time to test this is during development.
How to keyboard test:
Tab through your pages, links and forms to do the following tests:
- Confirm all links can be reached and activated via keyboard, including any in dropdown submenus.
- Confirm all links get a visible focus indicator (e.g., a border highlight).
- Confirm all visually hidden links (e.g. skip links) become visible when in focus.
- Confirm all form input fields and buttons can be accessed and used via keyboard.
- Confirm all interactions, buttons, and other controls can be triggered via keyboard — any action you can complete with a mouse must also be performable via keyboard.
Top ↑
Your code must parse, be error free.
Test tools:
Top ↑
The generated DOM, the frontend of your web project, must conform to WCAG 2 AA.
Recommended:
More tools:
Top ↑
The big difference between phpcs / js checks and accessibility checks is that the accessibility checks need to be performed on the generated DOM, not on the code base itself. So you need to check on a working frontend url (this also can be a url in your local install).
There are several command line tools for automated testing like aXe-cli and pa11y.
Note: automated accessibility testing doesn’t catch all the issues, maybe only 50%. Testing in the browser and manual keyboard testing still needs to be part of your workflow.
Top ↑
Install axe-core for CLI first:
npm install axe-cli -g
npm install chromedriver –g
Then run axe in the command line: axe url -b c
The url can be any url, also a local one. You get a report of the accessibility issues for that url. The -b stands for browser, c for chrome, as this browser gives the best results (better than the default PhantomJS). You will get the errors and warnings in your console.
You can provide more (space separated) urls to the command like
axe url url2 url3 -b c
or call a file with urls like:
axe $( cat list-of-urls.txt ) -b c
Note: You can run axe-cli on more then one url in one command, but axe-cli is not build to run on a large amount of urls or on a complete site, axe-cli is not a crawler. Deque Labs recommends to use the axe-webdriverjs, a chainable aXe API for Selenium’s WebDriverJS for testing on a large amounts of urls.
Top ↑
The setup for pa11y is well documented in the GitHub repository.
Top ↑
Content that changes dynamically during time, like JavaScript generated error messages or content, must also be announced for screen readers. The best way is to test this with a screen reader like Apple VoiceOver (for Mac) or NVDA (for Windows). Listen to your website!
Top ↑
Top ↑
- VoiceOver with Safari,
- NVDA with FireFox
- JAWS with Internet Explorer or FireFox (as from version 60)
- Windows Narrator with Edge
The screen readers ChromeVox and Orca don’t perform well enough as a screen reader, at this moment, to give representative test information.
Top ↑
Top ↑
