Add route announcer as part of new app output

[knownasilya]

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.

[knownasilya]

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]

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

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 we add a route announcer to the default blueprint, it could break people's apps when they upgrade, if they already have this sort of solution in place.
• instead, info should be added to the guides (outcome: https://guides.emberjs.com/release/accessibility/page-template-considerations/#toc_focus-management)
• also, we should try to contribute to getting a web-wide solution in place (outcome: see Include accessibility in the spec WICG/navigation-api#25 and Should ARIA provide better support for routing in single-page applications? w3c/aria#1353 and https://github.com/MelSumner/ember-a11y-roadmap/blob/master/rfc-research/router/solution-comparisons.md)

If there is appetite to re-consider this issue, I'm more than willing to champion it. 👍

[michaelrkn]

if we add a route announcer to the default blueprint, it could break people's apps when they upgrade, if they already have this sort of solution in place.

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]

If anyone has interest in writing this RFC, please DM me on Discord!

[sandstrom]

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]

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

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]

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.

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]

cc @wycats since we chatted about this a bit today.

[wagenet]

@MelSumner @wycats any updates here? This seems important, but we definitely need an RFC to get it going anywhere.

[wycats]

I think we should make sure to include this question into discussions about:

1. the Polaris routing API
2. discussions about how to integrate our routing story with the draft navigation API.

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

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() and restoreScroll() -> 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]

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