fix: focus on the root div after navigation

[jlengstorf]

This fix applies focus to the main app div after page navigation, which triggers screen readers and other assistive tech to announce the new page. Thanks to @NickColley for initially pointing this out, and to @LJWatson for jumping in with a fix!

fix #5581

[jlengstorf]

@calcsam Can you restart this build? It said "gatsby is not found", which makes me thing something hiccupped. https://app.netlify.com/sites/eloquent-golick-4ddc79/deploys/5b0db4f0b13fb1339e945589

[gatsbybot]

Deploy preview for using-drupal ready!

Built with commit 648ce92

https://deploy-preview-5593--using-drupal.netlify.com

[gatsbybot]

Deploy preview for gatsbygram ready!

Built with commit 648ce92

https://deploy-preview-5593--gatsbygram.netlify.com

[NickColley]

Nice work, I think we need to test in the following assistive technologies to know this has got us good coverage: https://www.gov.uk/service-manual/technology/testing-with-assistive-technologies#what-to-test

Happy to do this for you :)

[NickColley]

I believe you'll need to add a tabindex="-1" to the element, otherwise you cannot trigger programmatic focus.

This'll then likely show a focus outline that is not useful for most users, so you'd want to add some styles to remove this outline.

[NickColley]

Just tested with NVDA, Firefox, Windows 10 and there's no response, I believe this is because of what I've noted inline. Can test again, or make this update for you if you fancy.

Also, when pressing 'Down' the read the next item, it starts at 'Category: Salads' rather than the top of the page.

[pieh]

I don't think adding this to gatsby-link cover all grounds here - for example using history.back() will not trigger it.

I think we should create internal plugin that will use gatsby-browser.js onRouteUpdate that is called on all client navigation. Worth noting that this is also called on initial render, so this potentially might cause problem with screen readers - in that case we would have to skip refocusing app div on first route update.

[jlengstorf]

Good points, @NickColley and @pieh.

@NickColley, if you want to take this PR and run with it, I'd be happy to hand over the reins.

@pieh I don't have much experience with internal plugins. Any good places to start learning about that?

[pieh]

@jlengstorf There is not much to learn really about internal plugins:

• they live here: https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby/src/internal-plugins
• and you add them to plugin list here:

  gatsby/packages/gatsby/src/bootstrap/load-plugins/load.js

  Lines 131 to 138 in c5ed4ae

  	const internalPlugins = [
  	`../../internal-plugins/dev-404-page`,
  	`../../internal-plugins/component-page-creator`,
  	`../../internal-plugins/component-layout-creator`,
  	`../../internal-plugins/internal-data-bridge`,
  	`../../internal-plugins/prod-404`,
  	`../../internal-plugins/query-runner`,
  	]

• they are regular plugins (query-runner is only exception - this one is more tightly coupled with gatsby core). They are just shipped with gatsby package and don't have to be explicitly declared in gatsby-config.js. You will need package.json, no-op index.js (both of which you can copy from existing internal plugins and adjust where needed) and for purpose of this feature gatsby-browser.js

[NickColley]

Would love to run with this, to avoid bugging you with back and forth. Appreciate all the time you've put in so far!

[benrobertsonio]

I tested the Drupal demo on JAWS 2018 on Windows 10 in Chrome and IE11.

Chrome does not read the page title aloud on page change.

IE11 does read the title (twice), although I'm thinking this is because IE11 doesn't support service workers and so is not getting the SPA experience and is actually just loading the page.

I'm happy to test again with JAWS once we have an updated PR.

[benrobertsonio]

Also just wanted to note that since Gatsbygram doesn't have unique page titles I don't think it will be that helpful to test there.

[NickColley]

Of note: https://reach.tech/router

[m-allanson]

Of note: https://reach.tech/router

See also: #5656

[pieh]

quick update:
I did implement changes I suggested here - pieh/gatsby@master...pieh:fix/link-a11y

and it does focus app container on navigation (app container is visibly outlined), but this doesn't seem to trigger screen reader I used for test (NVDA) to read out new page title/headings. Disabling js (so doing fallback to default browser navigation) does make NVDA to read out new page title/headings

so not sure if focus trick will do good job with this :/

[LJWatson]

@pieh as noted in my comment in 5581, the screen reader behaviour can't be entirely faked, but it's ok because focus is in the expected part of the page to enable the user to explore/discover the information they need.

[NickColley]

@LJWatson https://reach.tech/router has managed to solve this issue so I'm not sure we have to compromise on that.

[pieh]

@NickColley because changing router component that is deeply embeded into gatsby might not be feasible (breaking change, because it seems like it has different API than react-router from). Even if we switch to it in future, we should still explore possible solutions for this problem short-term when we are using react-router.

[NickColley]

I meant more, we can copy the approach, not that we should integrate that project.

[KyleAMathews]

I'm going to attempt moving us to reach-router for v2. It's both smaller (33kb -> 18kb) and ready for async React and it fixes this issue. My understanding are that the API changes are minimal and most sites shouldn't have to do anything to upgrade.

[KyleAMathews]

FYI, my PR adding @reach/router is about ready to go in #6918