[2.18.25] Accessible Routing triggers region a11y violation in axe

[wKovacs64]

Description

#19290 seems to have introduced an axe a11y violation, citing the new <div id="gatsby-announcer" ... /> element as not being contained within a landmark (the region rule). This only occurs after navigation has taken place and the element contains text. It does not trigger on initial page load, as there is no inner text yet.

Steps to reproduce

1. Navigate to a new page
2. Run axe accessibility tests (Chrome Devtools, cypress-axe, whatever)

Reproduction: https://github.com/wKovacs64/gatsby-announcer-region-test

You can check the GitHub Actions in the reproduction project to see a simple Cypress test fail after navigation has occurred, but running it locally will give you a lot more information (see screenshot below).

Expected result

No accessibility violations.

Actual result

Axe believes the region rule has been violated after navigation has occurred.

Environment

Run gatsby info --clipboard in your project directory and paste the output here.

  System:
    OS: Windows 10 10.0.18362
    CPU: (16) x64 Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
  Binaries:
    Node: 12.14.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.21.1 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.13.4 - C:\Program Files\nodejs\npm.CMD
  Languages:
    Python: 2.7.17 - /c/Python27/python
  Browsers:
    Edge: 44.18362.449.0
  npmPackages:
    gatsby: 2.18.25 => 2.18.25 
    gatsby-image: 2.2.39 => 2.2.39 
    gatsby-plugin-manifest: 2.2.37 => 2.2.37 
    gatsby-plugin-offline: 3.0.32 => 3.0.32 
    gatsby-plugin-react-helmet: 3.1.21 => 3.1.21 
    gatsby-plugin-sharp: 2.3.13 => 2.3.13 
    gatsby-source-filesystem: 2.1.46 => 2.1.46 
    gatsby-transformer-sharp: 2.3.13 => 2.3.13 

[madalynrose]

@wKovacs64 I've made an issue in the axe-core repo and it sounds like they'll tackle it on their end. I'll update when they address it.

[wKovacs64]

Cool, thanks @madalynrose!

[marcysutton]

To add some additional context here, too: this really shouldn't fail an accessibility audit for landmark roles, as the announcer element isn't something a user would interact with directly. Adding a landmark specifically for the announcer element wouldn't be recommended for the same reason; it could end up being empty, and therefore not be useful in landmark navigation. axe-core and other tools really should disregard these types of live regions, or provide a way to mark them as inapplicable (that could be done with the axe-core Exclude API, but not in the main Chrome extension).