Routing isn't screen-reader accessible? #7681

jhackett1 · 2019-06-26T20:30:43Z

Bug report

I was browsing my next.js app with voiceover on, and noticed that client-side route changes aren't announced or even noticed by the screen reader. This is kind of alarming, since I've been using it in production on the assumption that the routing was accessible (my bad, was confusing with gatsby's use of reach-router).

I don't see many other references to "accessible routing" or "screen readers" in the issue history or documentation.

To Reproduce

With voiceover (perhaps other screen readers too) on, click a next/link.

Expected behavior

Focus should move to the top of the new page, and the new page title should be announced by the screen reader, like with a server-side route change, when clicking a next/link.

I'm not a regular screen reader user, so it's possible I'm missing something and the current implementation is actually fine, but I think the point is that the server behaviour and client-rendered behaviours should be the same?

System information

macOS
Chrome and Firefox
Version of Next.js: 8.1

timneutkens · 2019-06-27T11:40:06Z

It should focus back on the body already: https://github.com/zeit/next.js/blob/canary/packages/next/client/link.tsx#L183

cc @connor-baer

connor-baer · 2019-06-27T14:01:39Z

I'll have a look later today. The focus behavior should work. The title announcement is new to me, but it sounds like a reasonable addition. I'll do a bit more research.

connor-baer · 2019-07-08T10:23:45Z

This issue should be reopened since #7693 was reverted by ##7753.

I've been doing some preliminary research on announcing client-side route transitions. Here's a good article that sums it up nicely: https://hiddedevries.nl/en/blog/2018-07-19-accessible-page-titles-in-a-single-page-app

My main takeaways:

The <title> element cannot be announced automatically, instead, an aria-live region can be used to achieve the same effect.
On a website, announcing the page title and reverting focus to the body makes sense. However, in an application (e.g. like a dashboard with an app shell), you might want to retain focus on the current section or announce an element title, while the page title remains the same.

IMO, Next.js should provide a reasonable default since many developers probably don't know or think about this. For advanced use cases, this behaviour should be customizable.

It would be super helpful to get an actual expert's opinion on this. I will also do more research and share my findings here.

timneutkens · 2019-07-08T10:39:22Z

We reverted the PR as it was merged right before Next.js 9 so it wasn't on canary long enough to be considered stable. @Timer is going to re-apply it later.

developit · 2019-07-11T17:55:53Z

My 2¢ here (I'm by no means an accessibility expert):

For arbitrary client-side navigation, it doesn't seem like it will be possible to know that a URL change indicates large content replacement, since that's highly application dependent.

As an example, imagine using a keyboard to navigate to a link in the header of a site. Would you expect focus to be redirected back to the full page? Going deeper, what if that link simply triggered a modal? Or more commonly, what if the link navigated to a page that was very similar to the current page, only changing a some small region of the screen contents?

Since this issue goes pretty deep on Accessibility concerns, I asked @robdodson. Rob wrote about similar things a couple years back, and I will try to paraphrase the suggestions he and I discussed:

Resetting focus back to starting point is desirable, but you need to have a logical starting point to focus. Just blurring elements won't cause screen readers to announce new content, and focussing <body> can be jarring for AT users.

So here's an alternative approach I'd like to float: give developers a convenient (and perhaps default) way of marking their focus root, then detect and focus it when performing client-side navigation. As a reference point, Gatsby appears to do this for their client-side navigation.

Here's a rough example of what might go on link.tsx line 183:

// move focus back to the focus root if one has been provided:
const focusRoot = document.querySelector('[next-focus-root]');
if (focusRoot) focusRoot.focus();

That selector could be pretty easily added by developers, and potentially part of the default _app.js:

/** @example
 *   const { Component, pageProps } = this.props
 *   <div id="app">
 *     <Header />
 *     <FocusRoot><Component {...pageProps} /></FocusRoot>
 *   </div>
 */
export function FocusRoot(props) {
  return <div next-focus-root style="outline:none" tabindex="-1" role="group" {...props}>;
}

... or developers could annotate their desired focus root with the next-focus-root attribute directly.

developit · 2019-07-12T16:49:55Z

Just an update, Marcy happened to publish a post about this yesterday! It's definitely worth a read, and there's a whole section on the above:
https://www.gatsbyjs.org/blog/2019-07-11-user-testing-accessible-client-routing/#common-accessibility-barriers-in-client-rendered-web-apps

falcon03 · 2019-11-20T16:45:17Z

Blind regular screen reader user here! :) I was comparing reactJS and other server side rendering solutions for a project I am working on. Focus handling is a critical accessibility issue in most of the server side rendering solutions I've tested until now. I think that nextJS should automatically move focus on the first accessible element of the newly appeared component (the route destination) after completing the route transition.

A mechanism should be also provided to allow developers to easily indicate where focus should be moved after navigating to a new route to handle edge cases and/or customize the default behavior (perhaps even opting out from it) wherever it makes sense to do so.

Finally, when going back to a previously visited route (for instance using the browser's back button) focus should be automatically restored to the point it was before navigating to a new route (I would suppose 99.9% of the times the Link element that triggered the navigation event).

Feel free to ask me any question if you need more details; I'd be happy to test eventual patches, but don't feel confident enough with the framework for a PR (yet).

sophiekoonin · 2020-02-12T15:48:03Z

Hi! I was wondering if there was any plan to reintroduce this back into Next? We're having problems with screen readers not recognising that routing has taken place :/

olpeh · 2020-03-24T05:56:27Z

After looking into this problem for a while, we noticed that next-routeralready moves the focus to the body on client side routing, but only if the body can be focused, ie. has the tabIndex attribute as -1.

However, having tabIndex -1 present on body is not recommended, because it breaks the click+tab interaction. This interaction means clicking close to a link anywhere on the page and then pressing tab -> the link will receive focus. If body has tabIndex -1, it will receive focus when clicking the body.

This can be worked around by adding the attribute on routeChangeComplete and then removing it on blur. Here's our solution to this:

This is in our componentDidMount in _app.tsx`:

    Router.events.on('routeChangeStart', () => {
      /*
       * This is needed for the focus to be moved back to the beginning of the page after
       * client-side routing by next-router, we'll set it programmatically and remove on blur
       * because we don't want to focus the body if the user clicks on some parts of the body
       * that are actually not clickable.
       *
       * This is useful for click+tab interaction, where you click close to a link + tab in order
       * to focus that link – a fast way for moving the focus exactly where you want it to be.
       */
      document.body.setAttribute('tabIndex', '-1');
    });

    document.body.addEventListener('blur', () => {
      // See the longer explanation above about why we remove this
      document.body.removeAttribute('tabIndex');
    });

timneutkens · 2020-03-24T08:35:26Z

Feel free to send a PR to improve this!

leerob · 2020-12-16T21:04:54Z

Related: Marcy has done some excellent research here on this topic!

- Update tables to add tbody (HTML validation issue) - Add lang to HTML - Focus on body when navving between pages - Add aria-describedby to charts Sources: - vercel/next.js#7681 - https://www.gatsbyjs.com/blog/2019-07-11-user-testing-accessible-client-routing/

@marcysutton

# Route Announcements ## Summary This PR improves the accessibility of NextJS's client-side navigation by announcing route changes to screen readers. ## Context When a user who is sighted clicks on a link, they can see the content change. It's an affirmation that what the user intended to do by clicking a link actually worked! Users navigating the page via a screen-reader will not get this feedback on NextJS sites (This is an issue on many SPA-like architectures). https://user-images.githubusercontent.com/4213649/103017382-63b02b00-44f8-11eb-9940-fb530d2d3018.mov ## Solution Whenever there is a route change, the new `<RouteAnnouncer />` will look for a name to give the new page and then announce it! The name is found by first looking for an `h1`, falling back to `document.title`, and lastly to `pathname`. `<RouteAnnouncer />` is a visually hidden component placed within the `<AppContainer />`. ## Demo https://user-images.githubusercontent.com/4213649/103017401-6ad73900-44f8-11eb-8050-b3e9a7e0c3f2.mov ## Inspiration First and foremost, this PR was inspired by @marcysutton's studies and writing, [What we learned from user testing of accessible client-side routing techniques with Fable Tech Labs ](https://www.gatsbyjs.com/blog/2019-07-11-user-testing-accessible-client-routing/) as well as @madalynrose's [Accessible Routing](gatsbyjs/gatsby#19290) PR for Gatsby. There were also learnings gleaned from the conversations within #7681. ### Related Issues & PRs - Resolves #7681 - Relates to #19963

kevinolivar · 2021-08-03T08:41:23Z

@olpeh I had to add the following,

document.body.focus();

in order to make it work. Without it, next/router does not focus on the body.

olpeh · 2021-08-03T18:16:54Z

@olpeh I had to add the following,

document.body.focus();

in order to make it work. Without it, next/router does not focus on the body.

I think my workaround only worked in an older version of next, where that body focusing happened in the next-router.

balazsorban44 · 2022-01-28T00:13:08Z

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

connor-baer mentioned this issue Jun 27, 2019

fix(Link): Set focus back to the body element #7693

Merged

Timer closed this as completed in #7693 Jul 4, 2019

timneutkens reopened this Jul 8, 2019

Timer added this to the 9.0.x milestone Jul 11, 2019

Timer modified the milestones: 9.0.x, backlog Aug 30, 2019

Timer mentioned this issue Sep 19, 2019

fix: Ensure <body> has tabindex attribute before calling .focus() #8493

Closed

lionelB mentioned this issue Jan 13, 2020

a11y: ajouter un mecanisme pour notifier le changement de page pour les lecteurs d'écran SocialGouv/code-du-travail-numerique#2227

Closed

This was referenced Jan 30, 2020

Reset focus after navigation EmilTholin/svelte-routing#25

Open

Remove Chrome special case oaf-project/oaf-routing#42

Closed

olpeh mentioned this issue Apr 17, 2020

Move focus to the beginning of body even if no tabindex -1 was set #11983

Closed

Timer added the kind: story label Sep 12, 2020

Timer modified the milestones: backlog, iteration 15 Dec 16, 2020

kyleboss mentioned this issue Dec 23, 2020

[a11y] Route Announcements #20428

Merged

Timer self-assigned this Dec 31, 2020

Timer modified the milestones: iteration 15, iteration 16 Jan 4, 2021

timneutkens removed this from the iteration 16 milestone Feb 19, 2021

timneutkens added this to the iteration 17 milestone Feb 19, 2021

shuding self-assigned this Mar 10, 2021

timneutkens modified the milestones: iteration 17, Iteration 18 Mar 15, 2021

kodiakhq bot closed this as completed in #20428 Mar 15, 2021

vercel locked as resolved and limited conversation to collaborators Jan 28, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Routing isn't screen-reader accessible? #7681

Routing isn't screen-reader accessible? #7681

jhackett1 commented Jun 26, 2019 •

edited

Loading

timneutkens commented Jun 27, 2019

connor-baer commented Jun 27, 2019

connor-baer commented Jul 8, 2019

timneutkens commented Jul 8, 2019 •

edited

Loading

developit commented Jul 11, 2019

developit commented Jul 12, 2019

falcon03 commented Nov 20, 2019

sophiekoonin commented Feb 12, 2020

olpeh commented Mar 24, 2020

timneutkens commented Mar 24, 2020

leerob commented Dec 16, 2020

kevinolivar commented Aug 3, 2021

olpeh commented Aug 3, 2021 •

edited

Loading

balazsorban44 commented Jan 28, 2022

Routing isn't screen-reader accessible? #7681

Routing isn't screen-reader accessible? #7681

Comments

jhackett1 commented Jun 26, 2019 • edited Loading

Bug report

To Reproduce

Expected behavior

System information

timneutkens commented Jun 27, 2019

connor-baer commented Jun 27, 2019

connor-baer commented Jul 8, 2019

timneutkens commented Jul 8, 2019 • edited Loading

developit commented Jul 11, 2019

developit commented Jul 12, 2019

falcon03 commented Nov 20, 2019

sophiekoonin commented Feb 12, 2020

olpeh commented Mar 24, 2020

timneutkens commented Mar 24, 2020

leerob commented Dec 16, 2020

kevinolivar commented Aug 3, 2021

olpeh commented Aug 3, 2021 • edited Loading

balazsorban44 commented Jan 28, 2022

jhackett1 commented Jun 26, 2019 •

edited

Loading

timneutkens commented Jul 8, 2019 •

edited

Loading

olpeh commented Aug 3, 2021 •

edited

Loading