Developer A11Y Notes

developer a11y.md

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.

Community

• https://www.w3.org/WAI/IG/
• https://webaim.org/discussion/
• https://web-a11y.herokuapp.com/

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)

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 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
• 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!

Other Tools

• Browser extensions, like https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb and
• https://www.w3.org/WAI/ER/tools/

Testing custom ARIA attributes

• 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.

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.

• 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:

• https://developer.paciellogroup.com/blog/2015/01/the-browser-accessibility-tree/

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

Component Reuse

• 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.

Some of Our Resources at the IDRC

• 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

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

Regarding the heading "Automating Accessibility Testing", and, specifically, aXe, there are plugin versions to make it show up under the browsers development tools. The plugin for FireFox, which adds an "accessibility" tab in its Inspector, is:
https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/?src=api

Under "Understanding Accessibility APIs and the Accessibility Tree", there is the DOM Inspector plugin for FireFox that exposes FireFox's internal Accessibility API including the accessibility tree. It provides a quick-n-dirty check, since it doesn't look as deep as the platform AAPI ((e.g., Windows/IAccessible2), but it does give the developer an idea about what's going on.

Also, there is a cross-browser AAPI under development, that will provide a way to get at the underlying platform AAPI using the browser's DOM and JavaScript engine -- the AOM. But, maybe that's too alpha for this document.

Regarding the misuse of ARIA, there is guidance provided by the W3C's ARIA in HTML.