Enhancement: Improve the accessibility of the site header

[awtj8o81ryywg793]

Description

Currently, the accessibility of the site header is lacking. For instance, users cannot navigate to the toggle button via the keyboard or change its state. Additionally, while the toggle uses a <label> element to allow toggling the drop-down without JavaScript, which is a commendable approach, the element is not marked as a button, despite functioning as one.

This Pull Request introduces a new file, header.js, which adds support for interacting with the drop-down toggle via the keyboard, as well as setting aria-pressed, aria-expanded, tabindex, and role attributes. Here's a breakdown for each attribute as to why they are added to the element via JavaScript:

• aria-pressed - Its value necessarily depends on being updated via JavaScript, which, without it, may lead to confusion for users, as the value of the attribute wouldn't match the toggled state of the drop-down.

• aria-expanded - Its value necessarily depends on being updated via JavaScript, which, without it, may lead to confusion for users, as the value of the attribute wouldn't match the toggled state of the drop-down.

• tabindex - Setting the attribute's value to 0 allows users to navigate via the keyboard to the drop-down toggle. However, without JavaScript, there is no means by which the user can toggle the visibility of the drop-down. As such, the attribute should only be added via JavaScript to avoid any confusion.

• role - Setting the attribute's value to "button" signals to assistive technology that the element is a button. However, on its own, such an attribute doesn't add any additional functionality to the <label> element that native <button> elements have since this functionality must be added manually via JavaScript. As such, the attribute should only be added via JavaScript to avoid any confusion.

For further reading regarding these attributes, I'd suggest checking out: https://www.a11y-collective.com/blog/aria-button/.

In addition to those changes, this pull request also changes the header's drop-down arrows to be <label> elements, rather than <div> elements, as well as adding cursor: pointer to the top-most toggle.

Related issues

Closes #3115.

Role

Individual not affiliated with any project relevant to this PR.

Timeline

There’s no immediate deadline, so feel free to review this PR whenever you can.

Signoff

Please sign off your individual commits or whole pull request.

[awtj8o81ryywg793]

Whilst I initially planned to just tackle accessibility issues in this PR, I moved to also refactor the header as a whole. However, I've now scaled back the scope of this PR to its original goal. A refactor will be made if (or when) we move to a more component/macro-based workflow, as suggested in this comment.

[awtj8o81ryywg793]

Given the introduction of header.js and the outcome of #3135, I'd like to include the required REUSE information. Before doing so, could it be clarified who the copyright holder is? Would it be permissible to use a GitHub username for either copyright holders or contributors?

[HarHarLinks]

Given the introduction of header.js and the outcome of #3135, I'd like to include the required REUSE information. Before doing so, could it be clarified who the copyright holder is? Would it be permissible to use a GitHub username for either copyright holders or contributors?

IANAL, but aiui yes:
https://reuse.software/faq/#copy-pseudonym
#2435 (comment)

[HarHarLinks]

For instance, users cannot navigate to the toggle button via the keyboard or change its state.

agreed. in terms of screen reader, would it be feasible/preferable to not have to toggle anything in the first place?

[awtj8o81ryywg793]

Quoted from a previous comment:

agreed. in terms of screen reader, would it be feasible/preferable to not have to toggle anything in the first place?

I'm not sure it would be, no. How would you see that working?