The purpose of this (gist) is to break down what steps Ember.js would need to take, in order to be considered accessible by default. The goal is to identify what is - and what is not - possible to do "by default".
This document should neither be be considered a criticism of any previous effort nor a dictation of how things must be, but rather a starting point for conversation for where we (as a community) could go.
This document assumes that the reader is at least minimally familiar with what digital accessibility is and the existence of the WCAG Guidelines. This proposal uses WCAG 2.1 documentation.
The layers of guidance include:
- 4 Principles
- 13 Guidelines
- Success Criteria
- Sufficient and Advisory Techniques
The Sufficient and Advisory Techniques are sub-divided into the following categories:
- General Techniques (206)
- HTML Techniques (97)
- CSS Techniques (30)
- Client-side Scripting Techniques (38)
- Server-side Scripting Techniques (5)
- SMIL Techniques (14)
- Plain Text Techniques (3)
- ARIA Techniques (21)
- Flash Techniques (36)*
- Silverlight Techniques (35)*
- PDF Techniques (23)
- Common Failures (93)
*I do not think it would be necessary to use solutions that we've identified as out-of-date practices, so these could likely be ignored
- routers and assistive technology
- modals
- automatic updates that change context
- ensuring that aria and html properties are added at the right place and time
- prevention of common failures when possible and reasonable
The issue with all SPA routers is that the entire page is not reloaded when a link is clicked and you navigate to a new route. This is good for navigation in general, but assistive technology can no longer tell when a route transition has happened, so it doesn't alert the user that something has changed. The user then leaves the site because it thinks the site is broken.
We need a machine-readable way to determine that a route transition has occurred, in the same way that assistive technology can currently tell you that you have moved to a new URL.
Current solutions to this problem sort of exist in various forms, mostly in Ember and React:
- ember-a11y
- ember-self-focused (by Sarbbottam Bandyopadhyay here at LI)
- reach router (by Ryan Florence)
- stripes-components
- Vue's router has a beforeEach in transitions, so before each route transition you can run some code. Seems logical that someone could figure out where you're transitioning from (and to) and put something in there for machines to read.
There are some stretch goals. It would be good to light the path for the other JS frameworks here too, if we were able. Everyone needs a machine-readable way to
- represent application state
- represent transitions between those states
It seems possible that the existence of a popup window could be detected and prevention of interaction with anything except the popup window could be enforced automatically.
(include screenshots for illustration)
If an action would cause an automatic change in content and is not an interactive element marked as such, it seems reasonable that a warning should be given about labeling these interactions to prevent loss of context by the user.
(include examples of what this would look like)
Develop method(s) to prevent incorrect use of properties based on rules in specifications for each. (this section will need a bit of a deep-dive into each)
At a minimum, it seems realistic that the list of common failures should be evaluated to see which are reasonable to add warnings about, and/or outright prevent.
(deep-dive list here)
Author's note: I've started an in-depth analysis of every single technique. Ask me for access to the Airtable if you would like to see it before I'm finished.