Accessible Routing

[MelSumner]

Rendered

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

[Robdel12]

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

[Robdel12]

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

[drewlee]

+1

[Robdel12]

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.

[MelSumner]

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

[drewlee]

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.

[fuzzbomb]

Indeed, AT is a red herring as far as skip-links are concerned. The main group who rely on skip links are keyboard users without AT. Screen reader users have a variety of alternative navigation mechanisms available.

Skip-links will still be necessary, until browsers provide at least one built-in mechanism for reaching the main content (e.g. heading navigation, landmark navigation, or spatial navigation).

[Robdel12]

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.

[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! 👍

[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: Refocus after load completes failing. ember-a11y/ember-a11y#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.

[nathanhammond]

This design should be explicit. As it stands this is not a concrete proposal; it cannot be implemented using the RFC as a guide.

[nathanhammond]

This doesn't account for modals as well as non-body-hosted applications.

[nathanhammond]

It is possible to implement this, but it's a really wonky experience on the Web. To do it right you would likely need inert.

[nathanhammond]

ember-a11y works with loading states out of the box with exactly one caveat: when the loading state is below the pivot route.

[nathanhammond]

This is likely just an implementation detail and doesn't really need to be addressed in this RFC. This would clean up maybe a dozen lines of code in ember-a11y except that I want for ember-a11y to remain backwards compatible, so it won't adopt those until the old APIs are removed.

Given that, ideally any solution would not leverage those helpers unless it had to.

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

[nathanhammond]

The rest of your description doesn't specify position by location, but instead by DOM hierarchy. This one slipped through.

[nathanhammond]

One thing that I've experimented with is an off screen "page change" log inside of an aria-live component. Every element in that log would provide information about what is happening, and the ability to jump to the section flagged by it. This has numerous problems:

• It's a new paradigm.
• It can't be done in a fully-automated way (the description for each page change area must be manually specified).
• It doesn't support all AT use cases.

[nathanhammond]

• How should this handle partial renders? /foo/loading => /foo/bar/loading => /foo/bar/baz
• How do you prevent this from being read at other times?
  • If you remove it, how do you prevent this from disappearing before AT has a chance to communicate it to the user?
  • If left in the page, stale information in this component could in theory be read during a transition to something new (especially if a large portion of content gets popped out of the page). This could make it seem as if you have landed on the previous state while the next state is still transitioning in.
• How do you provide a human-understandable page name?
  • If it requires configuration, how do you ensure that users properly configure it?
• Ember doesn't support localization out of the box, how do you localize the message?

[nathanhammond]

• Can we make this use a reference from inside of Ember?
• How does this support Ember being used in a place where it is not in control of the entire application? The idea here seems to be to focus the "first" thing, similar to default AT behavior. However, if rootElement is set this doesn't play quite as nicely.

[nathanhammond]

This element should probably provide a jump link back to the section of the page that changed.

[nathanhammond]

I much prefer having a single outlet type. @ef4 and I have created a few over time:

• liquid-outlet ... from liquid-fire.
• focusing-outlet ... from ember-a11y which lifts the outlet stuff from liquid-fire.
• animated-outlet ... in Apple Music which is a few dozen lines of code for hardcoded CSS fade transitions.

The problem with this strategy is that none of those solutions by default play nicely together: they're fighting over the same extension point. To wire them together you have to make one dependent upon another and wrap things. You end up (approximately) with:

{{! custom-outlet.hbs }}
{{#animated-outlet}}
  {{#focusing-outlet}}
    {{outlet}}
  {{/focusing-outlet}}
{{/animated-outlet}}

I feel like the API for the outlet itself should be extensible instead of needing to wrap it. I'm thinking something like element modifiers. It's a little hard to figure out what it should do since and outlet doesn't exactly have the same lifecycle hooks that a component has.

[nathanhammond]

I feel like the behavior in this scenario should be opt out, not opt in. Start with outlet that does the accessible thing, opting out requires changing things in the application. Presumably the person who knows how to opt out will also be more familiar with what they're doing.

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