8000 Change aria-pressed into aria-expanded for buttons connected to expandable content by rianrietveld · Pull Request #1679 · just-the-docs/just-the-docs · GitHub
[go: up one dir, main page]

Skip to content

Conversation

@rianrietveld
Copy link
@rianrietveld rianrietveld commented Jul 8, 2025

This PR changes aria-pressed to aria-expanded on buttons toggling expandable content.

Related issue: #1680.

aria-pressed is used for e.g. switch buttons, a screen reader will announce "on" or "off" with the button. MDN on aria-pressed.

For expandable content like menus the correct attribute is aria-expanded. The screen reader will announce the accessible name (the aria-label in this case) of the button adding the state expanded or collapsed when the button gets focus. MDN on aria-expanded.

This PR also simplifies aria-label for buttons with aria-expanded: when aria-expanded is used there is no need to add to the aria-label the text “toggle", because the aria-expanded already gives that info plus the state of the toggle.

So: “Menu”, instead of “Toggle menu”.
The screen reader will announce the info as:

Button Menu collapsed

and

Button Menu expanded

Also it is for voice recognition software advisable to start the aria-label with the text a user may guess what the button stands for, to focus it.

This PR changes aria-pressed to aria-expanded on buttons toggeling expanable content.

Aria-pressed is used for e.g. switch buttons, a screen reader will announce "on" or "off" with the button.

For expandable content like menus the correct attribute is aria-expanded. The screen reader will announce the accessible name if the button adding the state expanded or collapsed when the button gets forcus.
When aria-expanded is used there is no need to add to the aria-label the text “toggle", because the aria-expanded already gives that info and the state of the toggle.
So: “Menu”, instead of “Toggle menu”.
The screen reader will announce the info as:
Button Menu collapsed
and
Button Menu expanded

Also it is for voice recognition software advisable to start the aria-label with the text a user may guess the button stands for. (This is best practice, not WCAG)
@mattxwang
Copy link
Member

Hi @rianrietveld,

Thank you for submitting a pull request as well as filing #1680! I apologize for the late response - it's been a challenging past few months for me. I also appreciate you giving back after using our theme!

I think you are completely correct here that aria-pressed is the incorrect ARIA role in each of the cases that you've noted. I also agree that the existing accessible text is not ideal!

After looking into things a bit more carefully, I'm wondering if we should pair these aria-expanded roles with aria-controls, since each of these buttons directly controls the visibility of its associated submenu/item. What do you think? (this is hopefully not too challenging of an addition - I am happy to help dig into this more if this suggestion makes sense)

@rianrietveld
Copy link
Author
rianrietveld commented Jul 24, 2025

Hi @mattxwang,

Thank you for your comment. I completely understand that life happens :-)

aria-controles is not needed in this case because the expanded content is right below the toggle, so the tab- and reading order is logical as is.

Also aria-controles is poorly supported by most screen readers.
See aria-controls attribute (aria).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

0