Router: WAI-ARIA group is missing a name

[spiritcapsule]

I understand from reading https://reach.tech/router/accessibility that the intention of the line of code below is to manage focus for accessibility. Thank you for your effort toward better accessibility. Unfortunately, that line of code generates an accessibility error when testing in Siteimprove.

<div style="outline:none" tabindex="-1" role="group"></div>

The issue is that when applying a WAI-ARIA landmark with the role="group", a name must also be provided. The element can be named by applying the WAI-ARIA aria-label attribute or aria-labelledby in conjunction with visible text.

https://www.w3.org/TR/WCAG20-TECHS/ARIA17
https://www.w3.org/TR/wai-aria-practices-1.1/#carousel

[wittjeff]

Also, the role="group" is a bit cumbersome or irregular if it is wrapping, for example, a page <header>, <main>, and <footer>. I was going to suggest adding a Note at the top of the page like so:

<div style="outline: none; clip: rect(1px, 1px, 1px, 1px);
clip-path: inset(50%); height: 1px; width: 1px; margin: -1px; overflow: hidden; padding: 0; position: absolute;" tabindex="-1" role="note" aria-live="polite">Focus is now at a point just before new content.</div>

but that doesn't really work, either, if the note is wrapping the rest of the contents of the page. So we'd like the focus target to be closed before the next contents start.

Regarding appropriate /ideal semantics, you could alternately just use an anchor without an href, since they are intended to be in-page markers. Like so:

<a style="outline: none; clip: rect(1px, 1px, 1px, 1px);
clip-path: inset(50%); height: 1px; width: 1px; margin: -1px; overflow: hidden; padding: 0; position: absolute;" tabindex="-1">Focus is now at a point just before new content.</a>

That screen-reader-only text technique is from https://webaim.org/techniques/css/invisiblecontent/ and has best cross-browser compatibility.

[spiritcapsule]

focus must work for sighted keyboard only users as well, not just screen reader users. but visual focus indication combined with the screen-reader only technique may work.

[wittjeff]

Yeah I was just thinking about that. Also I expect that some automated testing suites may soon check for visible focus indicators having the newly-required minimum 3:1 luminance contrast ratio (https://knowbility.org/blog/2018/WCAG21-1411Contrast/). Frequently I have encountered some friction with designers regarding the presence of any focus indicators on non-interactive elements in these usage scenarios. Also I think setting focus on an invisible target when new content is drawn is low-risk if pressing tab is the safest and most likely outcome, though it might not be super-friendly. But for a minimalist conformant approach you could do something like this:

<a href="javascript:void(0)" tabindex="-1" style="outline: transparent; color: #66666600" onfocus = "this.style.color = '#66666ff'"
   onblur  = "this.style.color = '66666600'">.<span> style="clip: rect(1px, 1px, 1px, 1px);
clip-path: inset(50%); height: 1px; width: 1px; margin: -1px; overflow: hidden; padding: 0; position: absolute;" >Focus is now at a point just before new content.</span></a>

So that's a period that turns grey on focus and invisible on blur.

I just remembered that using outline: transparent will ensure that an outline is visible in Windows High Contrast mode. Also the href="javascript:void(0)" will avoid a different automated testing warning.

[wittjeff]

If there is any concern about using the phrase I have suggested above, I'd suggest a simple "Ready." as an alternative. But a blank target (depending on the role) may not tell a screen reader user that anything has changed vs. when the router was triggered. In other contexts we have used "Ready." to indicate when a full-pay loading indicator is removed and the user again has interactive control. I think this is analogous.

[joeleisner]

Any updates on this? I started a Gatsby project today and was disappointed to see that a). this is the only a11y error I have on this project, and b). this issue is still open with no response from the developers.

[fymmot]

Perhaps this article by @marcysutton can be useful: https://www.gatsbyjs.org/blog/2019-07-11-user-testing-accessible-client-routing/

She's done user research on accessible routing with screen reader users, low vision-, keyboard-, voice control- and switch users