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.

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

Add route announcer as part of new app output #749

Open
knownasilya opened this issue May 20, 2021 · 14 comments
Open

Add route announcer as part of new app output #749

knownasilya opened this issue May 20, 2021 · 14 comments

Comments

@knownasilya
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

@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
Copy link
Contributor

MelSumner commented 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
Copy link

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
Copy link
Contributor

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

@sandstrom
Copy link
Contributor

sandstrom commented 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
Copy link
Contributor

@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
Copy link
Contributor

sandstrom commented 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
Copy link
Contributor Author

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
Copy link
Contributor

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

@MelSumner MelSumner changed the title Add a11y route announcer as part of new app output Add route announcer as part of new app output May 19, 2022
@wagenet
Copy link
Member

wagenet commented Jul 23, 2022

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

@wycats
Copy link
Member

wycats commented Jul 25, 2022

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
Copy link

domenic commented 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() 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
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants