Should ARIA provide better support for routing in single-page applications?

[MelSumner]

The Problem

Single page applications (SPAs) made our apps faster, because we no longer had to reload all of the content every time, thanks to pushState. However, pushState purposefully came with no event hook, and the thinking was that developers should manually manage focus (see the IRC logs from that time, and I’ve spoken with some of the folks who were involved with the decision when it was made).

We also respect the traditional URL, which made the experience feel like browsing on a static site- for all users except ones that need assistive technology.

There are well-known issues that users with assistive technology have when it comes to client-side routing:

• Because there is no full-page refresh, the user has no way of knowing that the page has changed at all.
• Because there is no focus management, the user’s focus remains where it is.
  • In cases where the item that had focus goes away, focus is lost.
  • In the cases where the item that has focus doesn’t go away, the focus simply remains where it is (and if you imagine the user interacting with a link in the footer, and then they experience silence- and their focus still stays on that link in the footer- well, that’s a bad experience. Makes it feel like something is broken.

So we have two distinct issues:

• Lack of focus management
• Lack of feedback that a page transition has occurred

Current Solutions

See: Solution Comparisons in JS Frameworks

From what I am aware of, current solutions use one or more methods to resolve the issue:

• Dynamically set the focus on a wrapper element
• Dynamically set focus on a heading element (h1-h6) to move focus to the new content
• Dynamically set focus to an interactive element such as a skip link
• Use an aria-live region announcement
• Imitate a traditional browser refresh by resetting focus

Thinking About A Permanent Solution

I wonder if ARIA could provide some type of support (a role, perhaps?) that authors could use to indicate "here's where the new content will be loaded when the route(URL) changes."

Another potential solution is some sort of new event hook- something that indicates that a semantic navigation event has occurred. (Vaguely, imagine something like pushState but also have a second parameter with a promise that resolves with a DOM node.) Both frameworks and assistive technology could use this event to indicate/recognize new content.

It's also possible that this is a problem for SPAs to solve on their own, without any other involvement from any spec.

Research

Here is some extra reading that might be useful; it's documentation of my own experiments to try to find a potential solution, with links to test apps that demonstrate some ideas - https://github.com/MelSumner/ember-a11y-roadmap/blob/master/rfc-research/router/ideas-and-experiments.md

[carmacleod]

Not sure whether this proposal for a new history event in the HTML spec is interesting: https://github.com/whatwg/html/issues/5562

[domenic]

Hey! In https://github.com/WICG/proposals/issues/20, we're working on a proposal for a new history API that, among other things, has a first-class notion of intercepting a cross-document navigation and replacing it with a single-page navigation. You can see more on that part of the proposal in the Navigation monitoring and interception section, as well as the subsequent subsection which talks about some of the benefits (mostly for metrics) of communicating such interceptions to the browser in a first-class way.

I'm hopeful that the proposal captures half of what you discuss here, around "Lack of feedback that a page transition has occurred"; it gives the browser, and thus (if we wire things up right) accessibility technology, clear feedback on when a single-page navigation starts and finishes.

The second half, around "Lack of focus management", is quite interesting. Although it's logically separable, I wonder if we can encourage web apps to do the right thing through some nudges in the API design, or by bundling some focus management in correctly. I'm unsure how far to go there, and would need advice from accessibility folk on what might work best. But the whole purpose of this app history API is to make it easy to do the right thing by default, unlike with window.history. So getting the right accessibility experience by default would be ideal, and I want to explore it.

[MelSumner]

@domenic I’m delighted to hear this & would be happy to help in any way I can. 👍

[scottaohara]

wicg proposal - https://github.com/WICG/app-history#customizations-and-consequences-of-navigation-interception

[aleventhal]

Sounds related to issues we've had with notifying ATs of a pseudo-page load when Chrome's bfcache is used to quicky load a page from history that's still in memory. NVDA doesn't actually listen to page load complete events, for one thing. We had some intermittent issues with getting the AT to refresh its virtual buffer, and instead reading the virtual buffer from a no-longer visible page. At the moment the bfcache is turned off in Chrome when AT use is detected.

Also related: @joanmarie is working with @domenic -- she has been adding code to fire the page load complete events in Chrome when the single page app changes in a way that is similar to a page load.

[domenic]

Thanks @scottaohara for pointing to the WICG proposal. I'm also scheduling some time with @cyns to chat about this in general.

For the group's attention, we're trying to tackle the two issues @MelSumner mentions head-on. (Namely, feedback and focus.) The section @scottaohara points to discusses our currently-proposed solutions, which we are implementing in Chromium behind a flag. Any feedback is super-welcome.

I'll note that we're especially struggling with the focus question. I just opened https://github.com/WICG/app-history/issues/202 on that.

We're hoping to have something finalized and ready to ship around end of Q1. Although we can always add or tweak things later, we want the result to be as accessible as possible by default, and changing defaults can be risky. So figuring out the right defaults is an area of particular concern right now.

[MelSumner]

Outcome of today's ARIA WG deep-dive:

1. broadly, we support a "everybody" solution that isn't ARIA specific
2. we encourage folks to read and weigh in on the proposed navigation API and on the follow-up issues shared
3. we think the next steps are to add author guidance to the authoring practices, and @MelSumner will do that work

[domenic]

Oh, thank you all for looking in to it! Let me know if it would be helpful for me to attend any calls.