Technical Accessibility Issues for New Ember Apps #595
Description
Technical A11y Issues in New Ember Apps
The goal of this issue is to provide a starting point for an accessibility-focused strike team to propose an overall accessibility approach for Ember.js, and specifically target at least these issues.
There are five technical issues that currently prevent new Ember apps from meeting the legal requirements for digital accessibility in countries that require it.
Severity Levels
All technical issues listed here would all require remediation during an accessibility audit done for legal purposes. However, it can be useful to consider the severity of the impact on the user for each issue while determining priority/urgency of work. With that in mind, the following severity levels show what kind of impact it has on the user:
- Severity Level 1 (S1): Not likely to prevent anyone from accessing content, but could affect the ability of some people to use a page.
- Severity Level 2 (S2): Medium Impact. Likely to make it difficult for some people to access content and use a page and/or could prevent some people from accessing or using page content.
- Severity Level 3 (S3): High Impact. Will prevent access to sections of the site or the ability to perform required functions.
1. Routing
Description of Issue
There is no event associated with pushState which means that when a user with a screen reader navigates to a new URL within an Ember app, no information is given to the user to let them know that the navigation was successful. This is problematic because it (the silence) is also what happens when navigation fails to occur at all.
Severity level 3.
WCAG Success Criteria Reference
4.1.3 - Status Messages - https://www.w3.org/WAI/WCAG21/Understanding/status-messages.html
Notes
- RFC #433 (now proposing a single solution)
- Working document: https://github.com/MelSumner/ember-a11y-roadmap/blob/master/rfc-research/router/describing-the-problem.md
2. Page Titles
Description of Issue
Ember provides the base HTML boilerplate that is needed for a valid web page in the index.html file.
However, the <title> element is missing, and there is no way to provide that content.
Severity level 1.
WCAG Success Criteria Reference
2.4.2 - Web pages have a title that describes topic or purpose. https://www.w3.org/WAI/WCAG21/Understanding/page-titled.html
Notes
This is why this is an issue:
- Users with assistive technology rely on this information being present so they know they are on the correct page of a website.
- It is also useful for sighted users, as this information is the text content for tabs in browsers.
3. Label support for Inputs
Description of Issue
The input component that is built into Ember supports 30 standard attributes but provides no way to ensure that the inputs have labels.
Severity level 3.
WCAG Success Criteria Reference
4.1.2 - Name, role, value - https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html
Read more: https://www.w3.org/TR/WCAG20-TECHS/H57.html
Notes
There are four technically valid ways to provide an accessible label to an input element:
- associate the
<input>element with the<label>element by using theforattribute (the label can be visible or hidden in an accessible way) - nest the
<input>element inside of the<label>element for automatic association - add the
aria-labelattribute to the<input>element - in special use cases (like the common search pattern): use the
aria-labelledbyattribute on the<input>element
4. Missing default language declaration
Description of Issue
There is no default language declaration on the <html> element in the index.html file.
Severity level 1.
WCAG Success Criteria Reference
3.1.1 - The default human language of each Web page can be programmatically determined. Read more: https://www.w3.org/WAI/WCAG21/Understanding/language-of-page.html
Notes
The data we already have gives us evidence that most Ember applications are:
- in English
- use internationalization if other languages are required
By applying the same "80% rule" that we generally seem to apply while designing solutions for the default Ember experience, we can see that there is already precedent for adding the lang attribute to the <html> with an English default.
There is a small sub-set of cases where this might be problematic, but there is such a small chance of this happening (given the available data) that it is likely to not come up; however it should be mentioned. Consider the following use case:
- the application developer is unaware that Ember now includes the
langattribute - the application does not require internationalization
- the application's content is in a language that is not English
- an end-user with a screen reader turned on, whose operating system (OS) is set to a different language, navigates to that page with their screen reader turned on
The screen reader would attempt to read the page in the language that is defined by the lang attribute on the page, but the supporting element information ("button", "link", etc) is read out in the language that is set by the operating system.
To see what happens when this information does not match, I created a new Ember application and created four buttons:
No Language Defined:
If no lang attribute is set for the page or the parts, the screen reader defaults to the operating system (OS) language. It reads Spanish in an English accent, and the button element was also still read in English. For the Chinese and Russian letters, it spelled out the letters (i.e., "Cyrillic Letter E")
Language Defined:
I then changed the lang attribute value and listened to these buttons in Chinese(zh), Spanish(es) and Russian(ru). Here's what happened:
- in each case, the announcer's voice changed for the content, but since my OS is set to English, the supporting element information that the assistive tech (AT) tells me was in my OS language (English).
- When set to Chinese, the AT read the English, Chinese and Spanish well enough to understand, but did not read out the Russian. Russian behaved similarly (read all of them except the Chinese).
I then tested what happens if I set language on each of the buttons with the app language set to English:
They were all read correctly in their respective languages, each followed with the word "button" in my OS language (English).
For the final test, I visited a page that was in Spanish, and it behaved similarly to my other tests. I then used the Google translate function to translate the page into German, and it translated the text on the page into German and then read it to me in German with my OS language for the elements.
Conclusion:
This research in a practical setting, when considered with other data, leads me to conclude that there is low risk in setting the lang attribute to a default value. We can include instructions and more information in the Ember documentation.
5. Splattributes
Right now, ...attributes do not have a guaranteed merge order. This is problematic in cases where some aria- attributes can have multiple values, and the order of those values matter. For apps whose components are contained in the same app, this is not so much of an issue; for apps that depend on accessible UI components in an addon, this is an issue.
This is not an issue for new Ember apps, but is an issue that should be addressed as part of an overall A11y focus/effort.
References & Supplementary Materials
- How to meet WCAG Success Criteria ←super useful reference that is filterable!