Integrate successful accessibility features to be the default for new Ember apps about rfcs HOT 7 OPEN

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

from rfcs.

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.

from rfcs.

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

from rfcs.

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.

from rfcs.

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)

from rfcs.

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

from rfcs.

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

from rfcs.