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

Accessible Routing #433

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
6 participants
@MelSumner
Copy link
Contributor

MelSumner commented Jan 18, 2019

Rendered

Create 0000-a11y-routing.md
RFC to help routes be accessible in Ember

@MelSumner MelSumner changed the title Create 0000-a11y-routing.md Accessible Routing Jan 18, 2019

@Robdel12
Copy link

Robdel12 left a comment

I am so so so so so so so so excited for this


## Alternatives
1. We could try to implement something like Apple’s first responder pattern: https://developer.apple.com/documentation/uikit/uiresponder/1621113-becomefirstresponder
2. Wait for a SPA solution to be implemented in assistive technology. I would note that this option seems less than ideal, since this specific issue has been reported to the different assistive technologies available, and has been an on-going issue for many years now.

This comment has been minimized.

@Robdel12

Robdel12 Jan 18, 2019

This, and I bet AT vendors will try and push the burden onto the browsers since AT operates at the OS level.

This comment has been minimized.

@drewlee

## How we teach this

For phase one, the guides should include information about skip links, since the application author will need to add those in themselves (just as they would for a static site). For phase two, we would explain that skip links are no longer needed because we have integrated that functionality in a more machine intelligent way.

This comment has been minimized.

@Robdel12

Robdel12 Jan 18, 2019

For phase two, we would explain that skip links are no longer needed because we have integrated that functionality in a more machine intelligent way.

Is this true? I usually still keep nav skip links in my SPAs because it's helpful to move past the giant headers / nav bars web apps have.

This comment has been minimized.

@MelSumner

MelSumner Jan 18, 2019

Author Contributor

@Robdel12 the idea for phase 2 is that we'd make it so AT would automatically implement skip link functionality so it was a cohesive experience- I think of it as an upgrade to skip links.

This comment has been minimized.

@drewlee

drewlee Feb 12, 2019

Skip links are also readily utilized by keyboard-only users, so it would still be a concern outside of ATs. Additionally, as an author, I would expect a means of disabling the generated skip link in case where we want to implement something much more custom and robust.

So we have a puzzle to figure out: why don't screen readers read out the new content or appropriately move focus when the user navigates to a new route within an Ember application. In researching the issue more thoroughly, we discovered that NVDA doesn't seem to have a way to handle the history API. (Which makes sense- screen readers were released before the history API was released.)

One of the challenges is that screen reader technology is all closed-source except for [NVDA](https://www.nvaccess.org/), the open source screen reader for Windows (and typically used with Firefox). The source code for NVDA is available on [GitHub](https://github.com/nvaccess/nvda/) and is written in Python. It seems useful, at least initially, to try to solve for SPAs + NVDA, since both can be done in open source. (Related: [NVDA Issue #6606](https://github.com/nvaccess/nvda/issues/6606))

This comment has been minimized.

@Robdel12

Robdel12 Jan 18, 2019

I've long had a dream to take NVDA (since it's OSS) and turn make a "headless" screen reader version of it. Just like we have a headless Chrome we push around in tests, I'd like a headless AT to send commands to and asset the right thing has happened. Like "press enter on this link, now assert the spoken output of the AT is correct & it focuses the correct element in the DOM"

It's a neat idea, but I have no idea if its even possible.

@locks locks added the T-framework label Jan 19, 2019

@jessica-jordan jessica-jordan referenced this pull request Jan 23, 2019

Merged

Ember Times No. 82 - Jan 25th 2019 #3773

9 of 13 tasks complete
@sandstrom

This comment has been minimized.

Copy link

sandstrom commented Jan 24, 2019

This is probably an unpopular point of view, but I think there are other areas that should be prioritized over accessibility. Here are three examples:

  1. Any of the many things that the community is already eagerly waiting for.

  2. Better localization support. There are ~6.5 billion non-native english speakers, and better support for handling multiple languages, currency formatting, etc. would be better in terms of "accessibility" (billions of additional people that would "get access").

  3. Things that makes it easier to run Ember on low-cpu devices, such as phone (i.e. performance improvements). Again, billions of people don't have desktop computers with Intel chips. Would "enable access" for a lot more people than improved screenreader support will ever do.

Obviously one thing doesn't prohibit another, one can work on both screen reader support and localization functionality at the same time. But in a world of limited resources, I think efforts should be concentrated on other things.

Show resolved Hide resolved text/0000-a11y-routing.md Outdated
Update text/0000-a11y-routing.md
Co-Authored-By: MelSumner <melaniersumner@gmail.com>
@MelSumner

This comment has been minimized.

Copy link
Contributor Author

MelSumner commented Jan 24, 2019

This is probably an unpopular point of view, but I think there are other areas that should be prioritized over accessibility.

Thankfully, it's not a zero sum game! Since my primary area of expertise is accessibility, this is where I can propose specific improvements to Ember.

If your area of expertise is in any of the things you suggested, please do feel free to write RFCs to address those issues- there's room here for everyone! 👍

@Robdel12

This comment has been minimized.

Copy link

Robdel12 commented Jan 24, 2019

@sandstrom I have to wholly disagree with that statement based on one thing: every single new ember app out there right now is broken to AT. There's nothing the user can do to try and work around or fix it. I know it's not ideal, but if you need to translate something to a different language, you have the ability to. AT users are simply stuck high and dry. If they're an advanced AT user they might be able to figure out what's going on in a SPA, but probably won't bother.

I think every SPA framework / lib needs to take accessibility seriously & prioritize the work now that everyone is building SPAs. Until those framework / lib authors take it seriously, all SPAs will be broken to AT.

And, as @MelSumner said, it's not zero sum. You can get the ball rolling on first class i18n support if you'd like. Maybe learn some lessons from Angular when they took on that effort.

Lastly, this work might save everyone's companies from being sued for not being accessible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment