Read This First
No ARIA is better than Bad ARIA. Before using any ARIA, read this to understand why.
How to build accessibility semantics into web patterns and widgets
No ARIA is better than Bad ARIA. Before using any ARIA, read this to understand why.
A button is a widget that enables users to trigger an action or event, such as submitting a form, opening a dialog, canceling an action, or performing a delete operation. A common convention for informing users that a button launches a dialog is to append "…" (ellipsis) to the button label, e.g., "Save as…".
In addition to the ordinary button widget, WAI-ARIA supports 2 other types of buttons:
menu or true.
The types of actions performed by buttons are distinctly different from the function of a link (see link pattern).
It is important that both the appearance and role of a widget match the function it provides.
Nevertheless, elements occasionally have the visual style of a link but perform the action of a button.
In such cases, giving the element role button helps assistive technology users understand the function of the element.
However, a better solution is to adjust the visual design so it matches the function and ARIA role.
div and span elements made into accessible command and toggle buttons.div and span elements made into accessible command and toggle buttons.
This example uses the IDL Interface.
When the button has focus:
button has an accessible label.
By default, the accessible name is computed from any text content inside the button element.
However, it can also be provided with aria-labelledby or aria-label.
true.true, and when toggled off, the state is false.
This is an unpublished draft preview that might include content that is not yet approved. The published website is at w3.org/WAI/.