- As with many web development topics, there is a lot of out of date, incorrect or debatable information on the web about what the correct approach is for accessible web development
- Like security, accessibility is a domain that has specialists, but every web developer should have:
- Familiarity with the basics of the topic
- Enough comfort with the terminology to do further research in specific scenarios
- Your goal should be a single code base that works well for different users - there are various approaches to this (progressive enhancement, etc). I don't recommend trying to maintain a parallel "accessible" version of a site.
- As the saying goes, "no silver bullets" in programming - same goes here. That said, knowledge of the fundamentals saves you time that can be used to work on the more complex issues when they arise.
Page markup validation will catch a number of issues.
- http://khan.github.io/tota11y/ (a11y visualizer bookmarklet)
- https://validator.w3.org/nu/about.html (HTML validator bookmarklet)
Common gotcha: because of modern front-end development relying on Javascript to manipulate the DOM, always make sure you are running any validation against the currently rendered state of the page.
Testing a page purely with keyboard interaction is a good technique for finding problems a screen reader user will encounter (users with mobility issues may also not be able to use a mouse). I also highly recommend it as an empathy exercise.
Fixing issues found in UX testing (too many clicks, confusing layouts, inconsistent behaviours, etc) will also help accessibility - UX problems with a page are typically magnified for users on the margins, and an irritating task for the "average" user may be next to impossible for someone with mobility or cognitive issues.
- aXe: https://github.com/dequelabs/axe-core
- pa11y: https://github.com/pa11y/pa11y
- https://github.com/paypal/AATT
A typical test suite or CI flow uses a combination of a web driver (PhantomJS, Selenium or similar) and an a11y validator to put a page or component into the required states, send the current markup to the validator, and generate reports of any issues.
Automation can help flag issues that are detectable via validation tools (this is not all of them).
If you are making the short-term investment for the long-term gain of CI, set aside time to make a11y testing a part of it!
- Browser extensions, like https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb and
- https://www.w3.org/WAI/ER/tools/
- Misuse of ARIA attributes to mark up custom behaviours driven by Javascript (drop down menus, carousels, etc) can actually make things worse.
- ARIA attributes change what the browser sends to the accessibility API; it's therefore possible to conceal or misrepresent component functionality from an AT
- If possible you should always study examples from WCAG or similar for the type of component.
- You should test custom behaviours with a screen reader.
The operating system accessibility APIs are (in almost all cases) the interface between a web browser and a particular AT. Each browser communicates with the accessibility API in different ways - this is why the same screen reader can behave differently with the same page or component in different browsers.
- https://www.smashingmagazine.com/2015/03/web-accessibility-with-accessibility-api/
- https://github.com/WICG/aom/blob/gh-pages/explainer.md
The browser generates and conveys an accessibility tree based on the DOM; this is what's actually used by a screen reader or other AT to supply information and support interaction:
The ability to inspect the accessibility API directly through a graphical tool can be helpful for diagnosing more complex issues, such as understanding what a custom component with ARIA is actually communicating to the accessibility API:
- OSX: Accessibility Inspector - https://developer.apple.com/library/content/documentation/Accessibility/Conceptual/AccessibilityMacOSX/OSXAXTestingApps.html#//apple_ref/doc/uid/TP40001078-CH210-SW1
- Windows: https://msdn.microsoft.com/en-us/library/windows/desktop/dd318521(v=vs.85).aspx
- Linux: https://github.com/GNOME/accerciser
- Supporting end user customization of the interface
- Explicitly, through components such as https://build.fluidproject.org/infusion/demos/prefsFramework/
- Implicitly, by avoiding CSS (such as fixed pixel sizes for fonts) that interferes with page adaptation / customization
- If you can achieve it with a native form element, consider doing that. Look into techniques for styling form elements while leaving their markup unchanged. Be aware of where the browser support sits for newer form elements like date pickers and sliders.
- Be careful that a reusable component's markup can be adapted to different places in the page hierarchy (customizable heading levels, etc).
- If using someone else's component library, read what they've written about the component library's consideration of accessibility; if they haven't written anything, be careful. Audit the component.
- Many popular tools (Slack is one example) have accessibility issues.
- As with components, read what they've written about accessibility.
- https://github.com/WICG/aom (spec for direct exploration and modification of the accessibility tree of an HTML page)
- https://spec-ops.github.io/atta-api/index.html (Accessible Technology Test Adapter API)
- "back end doesn't matter for accessibility" -> this is not always true. one example is the metadata delivered by back-end systems such as image delivery systems. It must be sufficient to allow good ALT text.
- Any system that delivers markup or content that will be used to construct markup can have implications for accessibility.
These pages on the wiki might be useful:
https://wiki.fluidproject.org/display/fluid/Quick-and-Dirty+Website+Accessibility+Tests+-+and+Fixes
https://wiki.fluidproject.org/display/fluid/Accessibility+Resources
https://wiki.fluidproject.org/display/fluid/Making+an+Inclusive+and+Accessible+Website