TOOLS AND APPROACHES FOR ACCESSIBLE WEB DEVELOPMENT
Some General Statements
- 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.
Checking for Basic Problems
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)
Testing with the Keyboard
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.
Fix UX Issues
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.
Automating Accessibility Testing
- aXe: https://github.com/dequelabs/axe-core
- pa11y: https://github.com/pa11y/pa11y
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
Testing custom ARIA attributes
- 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.
Understanding Accessibility APIs and the Accessibility Tree
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.
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
Additional Support for Accessibility
- 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.
SaaS and External Platforms
- Many popular tools (Slack is one example) have accessibility issues.
- As with components, read what they've written about accessibility.
Looking to the Future
- 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)
Accessibility Implications of Back-End Systems
- "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.