Bug: Menu and content containers use aria-label incorrectly

[andrewhick]

In repositories with a table of contents such as the WCAG Primer, both the left hand menu and content window are contained in <div> elements which have aria-label attributes but no role. This causes inconsistent behaviour across screen readers and browsers.

When viewing on 1280x1021 screen size:

• VoiceOver reads labels out in Chrome and Safari but on Chrome they are being mis-identified as form controls (they do not have any form functionality at this screen size; when text size is increased, page zoomed or mobile view then table of contents is a button).
• JAWS does not read the labels
• NVDA read the "content" label only

Note, if zooming in/out and opening/closing table of contents modal, aria-hidden is set in some scenarios. This state should be consistently maintained so that confusion is not caused.

Code for the menu container:

<div class="toc" data-module="table-of-contents" tabindex="-1" aria-label="Table of contents" aria-hidden="false">

Code for the content container:

<div class="app-pane__content toc-open-disabled" aria-label="Content" tabindex="0">

Strangely this is not detected by Axe (which normally picks these issues up) but it does look like incorrect ARIA usage, as a <div> has a default role of generic and so aria-label is not allowed.

We believe this fails WCAG 4.1.2 Name, Role, Value.

This was originally raised as WCAG Primer issue 133.