Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ToggleButton: refactor to use correct semantic elements to enhnace screen reader UX #3241

Open
tujoworker opened this issue Jan 18, 2024 · 0 comments
Labels
discussion Good for discussion

Comments

@tujoworker
Copy link
Member

tujoworker commented Jan 18, 2024

Our ToggleButtons can be used in various variants. And the screen reader support is fine as well.

  • Its read out as a toggle button by e.g. VO (by using aria-pressed).
  • Also the "state" is read out correctly (by using aria-checked).
  • And they are accessible with the tab key. Which is debatable if that is wanted or not.

But there are some issues that can be solved with a refactor:

  • Semantically, we can't use e.g. aria-required, which is only allowed on type="input" elements. So axe tests do fail. Even e.g. VO does read them out correctly.
  • When only one ToggleButton can be selected at a time type="radio", maybe, it should also behave like a radio button group? So a arrow key would be used to change the value, instead focus and enter/space.

I think, the last point is highly debatable, because, we should probably not change the user input behavior for when the component "looks" the same.

Also, it looks more like a button, so I would argue, that a user wants to use the tab key to access these buttons, instead of a arrow key.

A quick solution, to make aria-required be acceptable, is to change:

  • aria-pressed to aria-checked
  • and add these three attributes to the button component:
<Button
  role="checkbox"
  type="checkbox"
  element="span"
  ...
/>

This makes aria-required to be accepted by axe. But now VO reads the "toggle button" out as a checkbox. Which is in my opinion not a good move. But again, debatable.

@tujoworker tujoworker added the discussion Good for discussion label Jan 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Good for discussion
Development

No branches or pull requests

1 participant