Toggle button VS A11y
HCI Today summarized the key points
- •This article asks how to handle the accessibility (a11y) and WCAG interpretation of toggle buttons in an enterprise SaaS design system.
- •The author is confused about whether a design that changes the label based on state—like a mute button switching between Mute and Unmute—is allowed or should be prohibited.
- •One viewpoint explains that a true toggle button with aria-pressed should keep the label fixed, and that if the label changes, it should be treated as a regular button.
- •Another viewpoint, based on the quoted guidance’s ‘Alternatively’ wording, argues that label changes are possible, but in that case aria-pressed is not necessary.
- •Overall, the comments conclude that you should not confuse toggles with state indication, and that labels should reliably convey state or context rather than action wording.
This summary was generated by an AI editor based on HCI expert perspectives.
Why Read This from an HCI Perspective
This article is highly meaningful for HCI/UX practitioners because it shows how to separate label changes from state indication in toggle buttons (toggle button). In particular, it connects the confusion that arises when interpreting WCAG and ARIA—overlapping in practice—to real design decision-making. It helps you consider not only whether you comply with accessibility (a11y), but also the user’s cognitive load, predictability, and consistency of feedback. From a design system perspective, it also offers direct hints for defining reusable patterns.
CIT's Commentary
From a CIT perspective, this debate is not about whether ‘the label can change,’ but about whether you modeled it by separating ‘what is the name’ from ‘what is the state.’ A toggle is typically an interaction that reveals a single ongoing state. If you use action-centered wording like Mute/Unmute, it’s easy for state and action to get mixed together. So we recommend keeping the label as stable as possible and conveying the state through machine-readable information such as aria-pressed and supporting visual cues. That said, depending on the product context, it may be more appropriate to design it as a ‘state-transition button.’ In that case, you should verify explicit feedback and keyboard/screen reader consistency together. Ultimately, the role of a design system is not to force a single correct answer, but to document interpretation conditions and prohibited conditions for each pattern to reduce misunderstandings across the team.
Questions to Consider While Reading
- Q.In a design system, what criteria do you use to distinguish cases where a toggle button’s label is changed (state-like) versus kept as a fixed label?
- Q.What principles does your team use to choose state representation methods such as aria-pressed, checkboxes, and switches?
- Q.Have you actually observed confusion with this pattern in usability tests involving screen reader users and keyboard users?
This commentary was generated by an AI editor based on HCI expert perspectives.
Please refer to the original for accurate details.
Subscribe to Newsletter
Get the weekly HCI highlights delivered to your inbox every Friday.