Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Technical Accessibility Issues for New Ember Apps #595

Open
MelSumner opened this issue Feb 21, 2020 · 21 comments
Open

Technical Accessibility Issues for New Ember Apps #595

MelSumner opened this issue Feb 21, 2020 · 21 comments
Assignees
@MelSumner
Labels
T-ember-cli RFCs that impact the ember-cli library T-framework RFCs that impact the ember.js library T-learning

Comments

@MelSumner
Copy link
Contributor

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

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:

  1. Users with assistive technology rely on this information being present so they know they are on the correct page of a website.
  2. 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:

  1. associate the <input> element with the <label> element by using the for attribute (the label can be visible or hidden in an accessible way)
  2. nest the <input> element inside of the <label> element for automatic association
  3. add the aria-label attribute to the <input> element
  4. in special use cases (like the common search pattern): use the aria-labelledby attribute 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 lang attribute
  • 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:

image

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:

  1. 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).
  2. 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:

image

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

  1. How to meet WCAG Success Criteria ←super useful reference that is filterable!
@MelSumner MelSumner self-assigned this Feb 21, 2020
@MelSumner
Copy link
Contributor Author

Community members who wish to be a part of this strike team should please indicate interest in the #st-a11y channel on the Ember Community Discord Chat or DM @Melanie#1618 (melsumner).

Thank you!

@rwjblue
Copy link
Member

rwjblue commented Feb 21, 2020

Thanks for putting this together, please count me in on the team to dig into these topics....

@shadow-chunli
Copy link

shadow-chunli commented Feb 21, 2020 •
edited
Loading

Which screen reader did you use for your lang testing? In my experience, they all seem to have different implementation for interpreting lang. By the way, the lang attribute also affect braille readers. I am not sure how that would impact the severity level.

@gossi
Copy link

gossi commented Feb 22, 2020 •
edited
Loading

Thank you @MelSumner for putting this together. This is related to problem (2): https://gist.github.com/gossi/c3d6fded03be001d8b9763a8219b0a5e - hope that is a valuable input.

@kenigbolo
Copy link

Thank you so much for this @MelSumner

@rajasegar-c
Copy link

For the lang problem, we already had a discussion here
ember-cli/ember-cli#8599
I am glad finally we had consensus on the default value to "en"
@MelSumner We also need your input here
https://github.com/kellyselden/ember-a11y-blueprint/issues

@rajasegar-c
Copy link

I can raise a PR in ember-cli for the default lang to update the blueprints for app.
@MelSumner @rwjblue Your thoughts?

@MelSumner
Copy link
Contributor Author

Which screen reader did you use for your lang testing? In my experience, they all seem to have different implementation for interpreting lang. By the way, the lang attribute also affect braille readers. I am not sure how that would impact the severity level.

For MacOS I used Safari + VoiceOver, and on Windows, Firefox + NVDA.

@rwjblue
Copy link
Member

rwjblue commented Feb 23, 2020

I am glad finally we had consensus on the default value to "en"

This is incorrect. There is no consensus on a specific solution, only that the problem needs to be addressed.

@rajasegar
Copy link

So which means, we still have some disagreements regarding the default value with "en" ? But what about the "80% rule" @MelSumner was talking about designing solutions for the default Ember experience. I thought we had an agreement. My personal preference is with the default value "en", because half a loaf is better than no loaf.

@Willibaur
Copy link

Which screen reader did you use for your lang testing? In my experience, they all seem to have different implementation for interpreting lang. By the way, the lang attribute also affects braille readers. I am not sure how that would impact the severity level.

For MacOS I used Safari + VoiceOver, and on Windows, Firefox + NVDA.

is there any chance we could include one SR for Linux users?

@nightire
Copy link

My personal preference is with the default value "en" because half a loaf is better than no loaf.

Why not have an interactive development experience instead? I remember there's a blueprint or whatever will prompt you to choose an option when installing so that you can have your loaf and others can have their soup.

@rajasegar
Copy link

@nightire I think that beats the purpose of having a conventional framework like Ember. If we keep saying that you need to configure your app to have a default language while creating it every time, it means that the very base of CoC on which Ember is betting on is missing something. Instead it would be better to document (or call it out) it somewhere more clearly that the default blueprint supports "en" as the language, and if you want to change it you can go change it in the index.html.
Again I think we are disagreeing here for the same issue like earlier instead of moving forward...
I just wanted to put forward my best intentions in terms of sensible defaults. If that doesn't sound right, that's fine, let's just agree to disagree...

@nightire
Copy link

nightire commented Feb 24, 2020 •
edited
Loading

@rajasegar I understand your concerns, but I just can't see how an interactive UI could break the base of CoC. ember new can have flags like ember new my-app --skip-git --blueprint="path/to/my/favourite", does it beats the purpose of CoC? IMO, no. And I'd love that if ember new can show me a menu to choose them all to what I prefer, but I can stick with flags as well because half a loaf is better than no loaf.

So what's the fundamental difference to add another "flag"? Like ember new my-app --a11y-lang ="zh", not so bad right? ember new my-app just apply all defaults like it uses to be.

Besides, it doesn't only for convenience but also shows how much ember.js valued A11y, it encourages users to think about it from the very beginning. If we only put it somewhere else, it means been buried for many people, especially those who don't speak English natively or don't know about A11y much.

It's just my feelings, I really believe "don't make me think (or find it somewhere)" is more valuable than CoC, especially for the beginners.

IMO, CoC means "best practices", means the "big picture", the "architecture design", "technique decisions of the critical path", not the things that users can choose whatever it makes sense to them.

@rajasegar
Copy link

rajasegar commented Feb 24, 2020 •
edited
Loading

@nightire You know what, that's actually a great idea to have in ember cli. I mean to choose or enter a default language for your app or choose a blueprint, etc., It gives a more engaging and intuitive experience for the developers and also tells that Ember as a framework really cares about a11y without compromising DX.

Just playing with the idea using inquirer.js

render1582542029481

@nightire
Copy link

@rajasegar A nice demonstration, it's exactly what I described above.

Actually we use this technique internally in our team. We have a "foundation" add-on which will be installed in all of our add-ons and/or apps, and we use Vorpal to build an interactive ui, thus we can make decisions easier for our developers.

Although it can be done by creating addons based on the great ember-cli framework, something still needed by default, like the basic A11y configurations. I don't want to do too much manually because as a small team, we prefer to spend the majority of time on the business, not to build or maintain the basic infrastructure.

@Gaurav0
Copy link
Contributor

Gaurav0 commented Feb 26, 2020 •
edited
Loading

Can we all agree then that the generated index page will always have lang="xx", and that xx will be specified by an option in ember-cli, and that it will default to "en" if not specified. Users can add a different default to their .ember-cli.js in their home directory to always default to another specific language. Users can also edit their index.html after the fact. I like the idea of an interactive ember new (so long as there is a non-interactive override option) but can we punt on that for another RFC?

@nightire
Copy link

nightire commented Feb 26, 2020 •
edited
Loading

I like the idea of an interactive ember new (so long as there is a non-interactive override option) but can we punt on that for another RFC?

Sure. Let's make simple progress first.

@hergaiety
Copy link
Contributor

hergaiety commented Mar 29, 2020 •
edited
Loading

Some rough thoughts on page titles.

  • Ember Addons that have approached this in the past seem to take a bubbling approach where nested routes/components/etc specify a title that gets split by an optional separator {title} | {subtitle} | {subtitle 2}. Though this may be overly complicated for a first pass.

  • One concern is coming up with a solution that will work for Fastboot. While not a part of Ember officially, I feel that affects enough users that it'd be important to consider something that fastboot could potentially handle to serve a page with titles.

@MelSumner
Copy link
Contributor Author

  • One concern is coming up with a solution that will work for Fastboot. While not a part of Ember officially, I feel that affects enough users that it'd be important to consider something that fastboot could potentially handle to serve a page with titles.

@sharpshark28 that's a good point!

@steveszc steveszc mentioned this issue Apr 3, 2020
Closed
@MelSumner MelSumner added T-ember-cli RFCs that impact the ember-cli library T-framework RFCs that impact the ember.js library T-learning labels May 28, 2020
@wagenet
Copy link
Member

wagenet commented Jul 23, 2022

This seems pretty high priority. We should spend some time figuring out how to make actual RFCs for these things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@MelSumner MelSumner

Labels
T-ember-cli RFCs that impact the ember-cli library T-framework RFCs that impact the ember.js library T-learning
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests