(Accessibility) SPA routing

[myasonik]

Because single page apps (SPA) never do a full page refresh, there's never anything for assistive technologies to hook onto to catch the route change. If we're going ahead with a SPA architecture, we need to fix that regression to ensure that routing, core to any web app, is accessible to all.

• Bypass Blocks - Level A (skip link from page chrome to main, where individual apps should render into)
• Page titled - Level A
• Focus Order - Level A (focus, ideally, set on h1 inside main on page load, or main if h1 is unavailable or infeasible)
• Location - Level AAA (aria-current=page on appropriate link)
  • We are already using aria-current=page in our breadcrumbs (tested 8.3)
• Headings and Labels Announce page is loaded - Level AA

References for more info:

• https://timwright.org/blog/2019/03/23/accessible-routing-in-react/
• https://www.gatsbyjs.org/blog/2019-07-11-user-testing-accessible-client-routing/ (also lists its own references)
• https://tink.uk/using-the-aria-current-attribute/
• https://hugogiraudel.com/2020/01/15/accessible-title-in-a-single-page-react-application/

[elasticmachine]

Pinging @elastic/kibana-platform

[elasticmachine]

Pinging @elastic/kibana-app-arch

[timroes]

@myasonik We had a discussion for the initial a11y effort around skip links. In summary, we decided to leave them out, since the WCAG 2.4.1 only requires the user to be able to skip repetitive parts of the content, and by using landmark elements (or roles) in Kibana, the user can simply use their landmark navigation in their screen reader to reach every part of the content more easily. I would consider aria-labels on the landmark elements (since they usually show in the landmark navigation) way more important. But I am happy to reopen the "skip button" discussion if you have the feeling, we should do more here.

Also see #11516 for more details.

[myasonik]

TL;DR I think we can do better than providing only landmarks... (And that skip links would help.)

---

Doing or not doing something for reasons of meeting a spec I think is a quickly bankrupt conversation. (Users don't care how spec compliant your app is, as long as it works for them.) So, let's say the skip links aren't a requirement to meet WCAG and move on to what might actually benefit users.

Though landmarks are super powerful, I'm not sure it's safe to soley rely on them. I repeatedly hear (mostly through Twitter) that heading navigation is still the defacto way to navigate pages and tabs are the fallback for when that doesn't work. Because we can't know or account for every way that someone might try to navigate Kibana, supporting the lowest common denominator I think is a good way to bring up our worst possible experience. And, looking beyond screen reader users, like you said in the old ticket about skip links, for sighted people navigating with a keyboard, skip links can really help cut down on the time to navigate a page.

Because I have it handy, I can also link to Gatsby's recent user testing, where users wanted more skip links than were already provided.

If it was something that was super difficult to create, maintain, or explain to users, then I might be more keen on skipping it. But, as it's a relatively easy thing to implement, seems to benefit many users, and is an increasingly common pattern across the web, I think it's something worthwhile to add and support.

I'd want us to do our own user testing before entertaining the idea of not providing skip links on Kibana.

And, to address your question from the previous ticket about what to do with pages that auto-focus on the most important part of the page already: I don't think a user has to start focused on a skip link.
A. It helps on all the other pages,
B. For the pages that do set focus on load, it can still help in cases where we forget to return focus to a proper element and a user starts over at the top of the page, a pretty common bug in my experience, or if a user navigates through the whole page and wraps back to the top.

[timroes]

Let me make clear: I think we should provide the best user experience here for users not follow the standard. I purely mentioned that standard conformity, because you put the level A behind it :-)

Thanks for linking to the Gatsby user testing here. I think that might show we want skip links in there. I actually did some quick questioning that time of the users using assistive technologies I commonly know and have contact with, and there the general consent was: We usually directly start using landmark navigation skipping to the important parts and don't even bother checking for "skip it links". To be fair that user group has around the same statistical relevance than the Gatsby user testing (which unfortunately also only had 5 users).

But as you mention since it seem to use both variations of navigation commonly I would say, let's add skip links, since we'll also not loose anything by adding them there (but nevertheless try to use good aria-labels for landmark elements, for the users rather using landmark navigation.

[1Copenut]

@timroes I'm picking this one back up while reviewing some feedback. I'd like to understand how the routes are derived in Kibana, and work together on possible ways to handle focus on route change and add a global skip link that doesn't interfere with routing.

[ppisljar]

Thank you for contributing to this issue, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this feature/bug should still be considered, please reopen with a comment.

[lukeelmers]

I believe we need to keep this issue open for tracking purposes, as it is blocking some potential users from moving to Kibana. I know the issue hasn't had activity recently, but we've had at least one internal discussion on this in the past few months cc @alexh97 @alexfrancoeur

[1Copenut]

@ppisljar && @lukeelmers We've (EUI team) tried to consolidate the open tasks in this issue related to bypass block, focus order, and accessible SPA routing in #135760. 135760 is a meta issue. It provides a unified pattern for client-side route change announcements, focus management at the top of the source order, and a skip link to target a default or user-provided ID.

The unified pattern has been road tested fairly exhaustively on the EUI docs pages, and been in production there for over a month.

[1Copenut]

All child issues have been remediated. Moving this issue to closed.