Repository navigation
Add route announcer as part of new app output #749
Description
This addon: https://github.com/ember-a11y/a11y-announcer
Now that we have page-title as part of new apps, this is the next step to have better accessibility with route changes.
Activity
knownasilya commentedon May 27, 2021
Looks like https://github.com/ember-a11y/ember-a11y-refocus is the better version of this. Thanks @MelSumner
In the past it might have been assumed that people already did this, but honestly until recently I didn't even know it was a problem and did not have any kind of solution. With page-title being part of new apps, I think this makes sense as part of new app output to complete that accessibility loop. If people have something they use, they can easily remove this addon in a new app.
knownasilya commentedon May 27, 2021
@MelSumner also pointed out that the new app history proposal might handle this https://github.com/WICG/app-history#accessibility-benefits-of-standardized-single-page-navigations
This is still in draft stage, and might not make into browsers for a few years. Then it would need to get into the router, which might take months once it's supported. There might be polyfils, but a solution now makes all new apps made now more accessible by default.
MelSumner commentedon May 28, 2021
So I have championed this idea before, but at the time we could not obtain consensus within the framework core team.
IIRC this was the outcome:
If there is appetite to re-consider this issue, I'm more than willing to champion it. 👍
michaelrkn commentedon May 31, 2021
What about providing it as an optional feature that is enabled by default on new apps, like optional jQuery was? And then, like optional jQuery, at some point in the 4.x series, deprecate having the announcer feature disabled.
MelSumner commentedon Sep 21, 2021
If anyone has interest in writing this RFC, please DM me on Discord!
sandstrom commentedon Oct 7, 2021
How about keeping it as an optional addon, just like it is today?
I.e. anyone who needs it can add it to their app. Just like e.g. i18n addons (the vast majority of the human population doesn't speak English, but we still don't have the i18n addon in the default template).
MelSumner commentedon Oct 12, 2021
@sandstrom good question! My goal is for Ember to be fully accessible out of the box; it should at least not immediately fail accessibility success criteria in a new app.
sandstrom commentedon Oct 13, 2021
I think it would make more sense to have a clear accessibility section on the website, where addons etc. are mentioned. So that those who need to build an accessible app know what tools and addons exist.
But in practice, 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 solutions. 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 90% 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.
knownasilya commentedon Oct 13, 2021
I'd disagree because of this exact reason. We want to have more accessible apps by default specifically because most people aren't concerned with it. So whatever we can do to make the app more accessible without the user's (dev) involvement the better.
MelSumner commentedon Dec 10, 2021
cc @wycats since we chatted about this a bit today.
[-]Add a11y route announcer as part of new app output[/-][+]Add route announcer as part of new app output[/+]wagenet commentedon Jul 23, 2022
@MelSumner @wycats any updates here? This seems important, but we definitely need an RFC to get it going anywhere.
wycats commentedon Jul 25, 2022
I think we should make sure to include this question into discussions about:
@domenic my understanding of the Navigation API is that it's intended to address this issue head on. Am I reading that correctly? How should we think about a path forward for Ember that is intended to intersect with the Nav API once it's ready (or at least stable enough to start shipping a polyfill).
domenic commentedon Jul 26, 2022
Yeah, that's right. You can test the result in Chrome 102+ today: for example, on demo sites like https://gigantic-honored-octagon.glitch.me/ or https://http203-playlist.netlify.app/ , SPA navs are announced the same as MPA navs. (Note: NVDA on Windows is currently not picking up the load-complete events that Chrome is sending; we are debugging with them. Orca on Linux, VoiceOver on macOS, and JAWS on Windows all work as expected.)
In terms of stability, we just shipped a couple of breaking changes (new API shipped/old API deprecated in Chrome 105; old API removed in Chrome 108):
transitionWhile()->intercept()andrestoreScroll()->scroll(). But now it should really be stable, and we're working to roll it out across various Google properties.So I'd suggest experimenting with a design that aligns with the navigation API, and takes advantage of it in Chrome 102+ (or maybe 105+ if you only want to support the post-breaking-changes version). Probably with some fallback best-effort using ARIA live regions in other browsers? The problem with the fallback, of course, being that it doesn't behave exactly like the user's screen reader, e.g. VoiceOver is much less verbose about navigations than Orca, but there's no way for your fallback to know which screen reader the user is using and thus what they expect.
knownasilya commentedon Oct 14, 2022
@wycats would something like https://github.com/ember-a11y/ember-a11y-refocus be a good stopgap, or should we wait for the new navigation apis to move forward?