Integrate successful accessibility features to be the default for new Ember apps

[MelSumner]

I'd like to see us integrate some of the successful accessibility improvements we implemented as addons so we can move to the next iteration of improving accessibility in Ember.

We set a goal: "No new Ember app should fail accessibility success criteria" and we have made improvements to this goal, such as integration of page titles and unique-id helpers for template-only components, but I think we have a few polish items left.

1. set lang="en" by default, and not a flag that the developer has to remember when creating a new app. Rationale:
   • Our survey data and community feedback says that not only are most Ember apps in English, apps in a different language do not mind having English set to the default.
   • The only objection I have heard is from a few devs in the US that do not want to assume these things. I think that is considerate, but I also think in this one instance, it's okay to do this.
   • Developers could still set it differently via flags (eg, you can use --lang today) when creating a new app.
   • I am not suggesting that our data is perfect, only that it is the data that we currently have.
   • We can work on improving our data (e.g., try to find community members or sponsors who are willing to help with survey translations) and periodically re-visit to ensure that the defaults are aligned with our community's use.
   • When the RFC for interactive new Ember app creation is implemented, lang could be one of the options that developers are given.
2. accessible routing and skip links: integrate ember-a11y-refocus, which gives us accessible routing by default in an Ember app.

I think there are some new approaches to accessibility in JS apps that Ember could demonstrate, and there's a lot of room for growth. First, however, I would like to see us really get these things over the finish line.

[wagenet]

This is very important. What will it take to get RFCs for these?

[sandstrom]

I'd argue that it doesn't matter if the Hello World! Ember app is accessible or not.

Any semi-advanced app will need a lot of customization and work to be accessible. For example, any custom components need to be accessible. Any other software components (may be written in other languages or frameworks) that may interact with the Ember sub-system also needs to be considered.

Accessibility is also a vague term. Is that people who are color blind? Handicapped? Deaf? Elderly with Alzheimers? Those are different handicaps, that require very different remedies.

For example, someone with short-term memory problems need other adjustments in their software, compared to someone with only one arm [typing difficulties].

All in all, my guess is that a majority of Ember users don't strive to build accessible apps. Which is why I think it's better to keep the tools separate.

Don't get me wrong, I'm not against the addons themselves, I just don't think it's good to prioritize getting them all into core (or ember-cli defaults), I think it's better if they exist as opt-in addons.

Also, I think there is a tendency to think that anything that isn't part of core Ember is less important. An advocate of Server Side Rendering wants Fastboot into core, and someone who's worked on accessibility want their work into core.

But that's not the yardstick I'd use. I'd say it's more about what's a natural fit for a particular piece of logic, sometimes an addon makes more sense. That doesn't make it less valuable or useful.

[wagenet]

I think there may be some misalignment about what it means for something to be in "core". Ember has historically been monolithic, but we're working to make things more modular. In a modular context you pick and choose only the things you need. So the only real significance to something being "core" is who maintains it. Relatedly, there's also the question of the default recommended configuration. However, this does not depend on something being core as we have many addons in the recommended setup.

So then the question is really whether we should 1) have a default solution for accessibility and 2) should the Ember core team maintain it?

My answer to the first question is 100%. It's not a good thing that many apps forgo accessibility concerns and we should do what we can to encourage out of the box accessibility. Of course we cannot cover every case, (indeed many cases are a matter of good interface design, not actual code), however just because we can't do something perfectly hardly means that we should do nothing at all. Furthermore, many accessibility concerns actually are related to the internals of Ember itself (e.g. routing).

So this leads into the answer to the second question: it depends. Ember should make sure to provide the primitives necessary to work with tools like screen readers and we should make sure out core functionality can be configured in accessible ways. However, as you rightly note, there will be more niche cases and we probably would not want to be responsible for maintaining all of them. These would be ideal candidates for add-ons.

Ultimately, it's not all-or-nothing here. We can and should improve Ember's accessibility story but that doesn't mean that we have to be responsible for every possible accessibility concern.

[sandstrom]

My answer to the first question is 100%. It's not a good thing that many apps forgo accessibility concerns and we should do what we can to encourage out of the box accessibility.

This is often stated as a indisputable fact. But why is this important? And where does it rank among other important things?

To give two examples:

• Is it more important than Ember continuing to exist as a front-end framework?
• Is it more important than localization? (there are far more people that don't speak English, than there are handicapped people)

[wagenet]

I'm not sure why you're painting this as a zero-sum game. We can be concerned with all of those things.

[sandstrom]

@wagenet Because attention and technical bandwidth [people writing code, mostly] is finite?

Any technical product or project is an exercise in priorities. Both implementation and continued maintenance thereafter requires resources. Anytime you move something up in priority, everything else is implicitly moved down.

[webark]

Any technical product or project is an exercise in priorities.

Agree with this statement completely. All the more reason to prioritize accessibility. It's something that is too quickly overlooked or put off, and one that is imperative and has always been a core principle of the web.

https://www.w3.org/standards/webdesign/accessibility