Accessible Routing

[MelSumner]

Rendered

Updated on Jan 12, 2020 to reflect conversations during framework f2f weekend.

[sandstrom]

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 phones (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.

[MelSumner]

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! :+1:

[Robdel12]

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

[nathanhammond]

This is roughly a duplicate of #66. Having already gone through the process I believe that Ember should be a thin core with extension points for the functionality that we need for accessibility which would then be provided by an addon. If (and only if) we can't implement things in user space we should figure out how to enable those things by way of changing core. Those changes should still be minimal and not focused on accessibility so much as exposing the internal Ember.js state required to accomplish the goal.

Benefits to being external:

• Enables backwards compatibility. If you bundle something into Ember.js itself the user cannot get that functionality prior to that version of Ember. If distributed as an addon it can easily work all the way back to Ember 1.10, like ember-a11y.
• Enables configuration by way of interactions between multiple addons and their build steps and ordering. This allows integration and coordination between multiple addons who may care about using a single extension point.
• Enables shipping independently from Ember. This alone is a big enough reason for me to encourage never including accessibility-related functionality in core. We used jQuery in the early days of Ember to wallpaper over browser differences. AT is a massive target and not something consistent enough to address once and walk away from. For example: https://github.com/ember-a11y/ember-a11y/issues/72

My proposed path forward:

• Implement the set of things that you would like to have default-enabled in Ember in one or more addons.
• Once those addons are considered "done" open an RFC to have those be included in the default Ember blueprint.
• Document their use in the Ember Guides.

This will be far less painful for maintenance over a longer time scale, allow us to better serve AT users, and enable more people to contribute to the success of the effort.

As a person who is incredibly familiar with this space (and the author of one of the referenced examples) I am strongly opposed to landing this RFC.

[MelSumner]

@nathanhammond I believe I have attempted to address your concerns with the updates I have made to this RFC.

[chadhietala]

@MelSumner thanks for taking the time doing the investigation and providing paths forward. I think I would prefer that we do something with {{outlet}}s, either making an {{application-outlet}} or just making outlet smarter.

What I mean by making outlets smarter is that RFC#93 talked about exposing the {{get-route-info}} which is the data structure that knows what the logical hierarchy of the routes is. We would also like for this to be the data structure that is used for setting outlets as we have something that is similar today for setting the outlets. Another aspect this system is that we compute a from and to version of the RouteInfos, so technically we know the pivot point of the UI that we would need to focus.

I'm a bit cautious about exposing ember specific IDs that we use to bring focus to elements. The reason is that those IDs effectively become public API, but public API with no transition path if we decided to change the name or remove it. We have seen this with .ember-transitioning-in, .ember-view etc. Instead I think we could use a weakmap to look up the element that needs focus().

Overall though I think this is heading in the right direction.

[wagenet]

This still seems very important. I'm curious whether the routing spikes around Polaris would address this.

[MelSumner]

👋 The Ember Framework Core team recognizes accessible routing as an integral part of the future router work that is now being designed and planned for the Polaris edition of Ember. We are also excited about the Navigation API work in progress that will lend itself to this work.

As such, I'm going to close this RFC.

For the time being, I encourage developers to check out ember-a11y-refocus, an addon that provides accessible routing for Ember apps.