Understanding the Button Role in ARIA
Buttons are the primary interaction points on any digital interface. They enable users to submit forms, trigger actions, navigate between pages, and complete transactions. Yet despite their fundamental importance, buttons remain one of the most commonly mishandled elements in web development. When buttons aren't properly implemented, users with disabilities encounter barriers that prevent them from completing essential tasks--everything from submitting contact forms to completing purchases.
Screen reader users rely on clear button semantics to understand what actions are available and what will happen when they activate each element. Keyboard users need reliable Enter and Space key support to trigger button actions without using a mouse. Users with motor impairments depend on adequately sized touch targets to activate buttons accurately. Each of these requirements represents a dimension of accessibility that, when overlooked, excludes users from completing critical tasks on your interface.
For a broader understanding of how accessibility integrates into web development, consider exploring our guide on accessibility audits to ensure your interfaces meet comprehensive accessibility standards.
Key concepts for implementing accessible buttons
Button Role Fundamentals
Understand the button ARIA role and when to use native HTML elements versus custom implementations.
ARIA Attributes
Master aria-pressed, aria-expanded, aria-haspopup, and aria-disabled for comprehensive button states.
Keyboard Support
Implement proper Enter and Space key activation for full keyboard accessibility.
Testing Strategies
Validate buttons with automated tools and manual testing using assistive technologies.
What Is the Button Role?
The button role is an ARIA (Accessible Rich Internet Applications) attribute that identifies an element as a button to assistive technologies such as screen readers. When you add role="button" to an element, you communicate to assistive technology that the element represents a button widget used to perform actions such as submitting forms, opening dialogs, canceling operations, or triggering scripted functions according to MDN's ARIA button documentation.
However, the button role alone provides no inherent functionality. It serves purely as a semantic marker for assistive technologies. The actual button behavior--including keyboard activation, focus management, and click handling--must be implemented through JavaScript and CSS. This distinction is critical: role="button" tells assistive technologies what an element is, but it doesn't make the element behave like a button. You must implement all the expected behaviors yourself as recommended by The A11Y Collective.
Native HTML Buttons: The First Choice
The first rule of ARIA states that if a native HTML element or attribute provides the required semantics and behavior, use that instead of adding ARIA. Native <button> elements and <input type="button"> elements include all the accessibility features you need without any additional work according to MDN's ARIA button documentation.
Native buttons are natively focusable, fully keyboard-operable, and automatically convey meaningful information to screen readers. They respond to both mouse clicks and keyboard activation (Enter and Space keys) without any JavaScript intervention. The browser and assistive technologies understand exactly what a native button is and how it should behave. When developers rely on non-semantic elements like <div> or <span> to create buttons, they often introduce complexity that leads to broken interactions, poor accessibility, or inconsistent behavior across different screen readers and browsers as recommended by The A11Y Collective.
When Custom ARIA Buttons Are Necessary
Despite the preference for native elements, custom ARIA buttons serve legitimate purposes in specific scenarios. You might need a custom ARIA button when creating components with specialized behaviors not available in native elements, when working with third-party UI libraries that require non-standard markup, or when implementing design systems with unique interaction patterns that can't be achieved with standard elements as recommended by The A11Y Collective.
If styling is your primary concern, try using CSS to style native <button> elements before resorting to custom implementations. Modern CSS provides extensive styling capabilities for buttons, including custom appearance, hover states, focus indicators, and disabled styling.
Understanding when to apply ARIA roles correctly is essential for building inclusive web experiences. Our comprehensive guide on using ARIA for accessibility provides additional context on applying ARIA attributes correctly across your projects.
Essential ARIA Attributes for Buttons
aria-pressed: Creating Toggle Buttons
The aria-pressed attribute transforms a standard button into a toggle button--a two-state control that indicates whether a setting is active or inactive. This attribute is essential for buttons that switch between two states, such as mute/unmute, play/pause, or like buttons according to MDN's ARIA button documentation.
The aria-pressed attribute accepts three values. A value of false indicates the button is not currently pressed. A value of true indicates the button is currently pressed. A value of mixed indicates the button is partially pressed, which applies to split buttons or tri-state checkboxes according to MDN's ARIA button documentation. When implementing toggle buttons, the accessible name should remain consistent regardless of state. A mute button should always be labeled "Mute," with the pressed state communicated through aria-pressed. Screen readers will announce "Mute button, pressed" or "Mute button, not pressed" depending on the current state.
aria-expanded: Indicating Collapsible Content
The aria-expanded attribute indicates whether a button's associated content is currently expanded or collapsed. This attribute is essential for buttons that control collapsible regions, accordion sections, dropdown menus, or expandable navigation elements as recommended by The A11Y Collective.
When aria-expanded is set to false, the controlled content is collapsed or hidden. When set to true, the controlled content is expanded or visible. If the attribute is omitted or set to undefined, the element is not expandable. Dynamic updates to aria-expanded are critical--as users interact with the button, you must update the attribute value to reflect the current state. Users of assistive technologies rely on these state changes to understand the interface's response to their actions as recommended by The A11Y Collective.
aria-haspopup: Signaling Menu Buttons
The aria-haspopup attribute indicates that activating the button will open a menu, pop-up dialog, or other interactive element. This attribute helps screen reader users anticipate what will happen when they activate the button according to MDN's ARIA button documentation.
The attribute accepts several values. A value of true or "menu" indicates the button opens a menu. A value of "dialog" indicates the button opens a dialog. A value of "listbox", "grid", or "tree" indicates the button opens a corresponding widget type. However, aria-haspopup alone doesn't make a component accessible--after opening, the menu or dialog must be focusable, users must be able to navigate through it with the keyboard, and focus must be properly managed throughout the interaction as recommended by The A11Y Collective.
aria-disabled: Communicating Disabled State
The aria-disabled attribute indicates that a button is in a disabled state--visually present but not interactive. Unlike the HTML disabled attribute, aria-disabled doesn't prevent focus or interaction by default, so you must implement additional logic to prevent activation as recommended by The A11Y Collective.
When aria-disabled is set to true, assistive technologies communicate that the button is disabled, but users can still tab to it. You must ensure that click handlers and keyboard event handlers check this state and prevent activation when appropriate. Visual disabled states are equally important--disabled buttons should have reduced opacity, changed colors, or other visual indicators that communicate their non-interactive state to sighted users.
1<!-- Toggle button with aria-pressed -->2<button id="favButton" aria-pressed="false" aria-label="Add to favourites">3 <svg aria-hidden="true"><use href="#heart-icon"></use></svg>4</button>5 6<!-- Menu button with aria-expanded and aria-haspopup -->7<button id="menuButton" aria-haspopup="true" aria-expanded="false" aria-controls="mainMenu">8 Menu9</button>10 11<!-- Disabled button with aria-disabled -->12<div id="submitBtn" role="button" aria-disabled="true" tabindex="0">13 Submit14</div>Keyboard Interactions and Event Handling
Required Keyboard Support
Buttons must be fully operable through keyboard input. Users who cannot use a mouse rely on keyboard navigation to interact with all interface elements. For buttons, this means supporting both the Enter key and Space key for activation according to MDN's ARIA button documentation.
Native <button> elements automatically respond to both keys. When implementing custom ARIA buttons, you must handle both keydown events manually. Pressing Enter or Space while a button has focus should trigger the button's action. The distinction between native and custom buttons is significant--native <button> elements fire their click event for both mouse clicks and keyboard activation, while custom elements with role="button" only fire click events for mouse clicks, requiring separate keydown handlers for keyboard activation according to MDN's ARIA button documentation.
JavaScript Event Requirements
Custom ARIA buttons require two essential event handlers. The onclick handler processes mouse clicks and touch events. The onkeydown handler processes keyboard activation by monitoring for Enter and Space key presses according to MDN's ARIA button documentation.
When implementing onkeydown handlers, check for both Enter (key code 13) and Space (key code 32). Prevent default behavior for Space key to avoid page scrolling when activating buttons. The handler should call the same action function as the onclick handler to ensure consistent behavior across input methods. Focus management after activation depends on the button's function--if clicking a button opens a dialog, focus should move to the dialog; if clicking a button closes a dialog, focus should return to the button that opened it; if the button alters the current context without changing focus context (like a mute button), focus typically remains on the button.
Focus Management Best Practices
Every interactive button must be focusable. Use tabindex="0" to make custom ARIA buttons part of the natural tab order. Elements with tabindex="0" receive focus in the order they appear in the document, matching the behavior of native interactive elements as recommended by The A11Y Collective.
Avoid tabindex values greater than zero, as they disrupt the natural tab order and create confusing navigation for keyboard users. Reserve positive tabindex values for elements that should appear out of document order, and even then, consider whether the design might be improved by rearranging the source order. For complex interfaces with modals or dropdowns, focus must be managed throughout the interaction--when a modal opens, focus should move to the first focusable element within it; while the modal is open, focus should be trapped within the modal; when the modal closes, focus should return to the triggering element as recommended by The A11Y Collective.
Proper focus management ties directly into overall usability and accessibility. Techniques like programmatically scrolling elements into view when they receive focus are covered in our guide on scrollIntoView for accessibility.
1// Get the button element2const saveButton = document.getElementById('saveButton');3 4// Click handler5saveButton.addEventListener('click', function() {6 saveChanges();7});8 9// Keyboard handler for Enter and Space10saveButton.addEventListener('keydown', function(event) {11 if (event.key === 'Enter' || event.key === ' ') {12 event.preventDefault(); // Prevent scrolling on Space13 saveChanges();14 }15});16 17// Toggle button example18favButton.addEventListener('click', function() {19 const isPressed = this.getAttribute('aria-pressed') === 'true';20 this.setAttribute('aria-pressed', !isPressed);21 // Update visual class22 this.classList.toggle('pressed', !isPressed);23});Accessible Naming and Labelling
Providing Accessible Names
Every button requires an accessible name that clearly communicates its purpose. For most buttons, this is simply the text content between the opening and closing tags. Screen readers announce this text when users navigate to or activate the button according to MDN's ARIA button documentation.
Icon buttons without text content require explicit labelling. Use aria-label to provide a text alternative, or aria-labelledby to reference existing text in the document. The accessible name should clearly describe the button's action, such as "Close dialog" or "Submit form" rather than vague labels like "Click here" as recommended by The A11Y Collective.
Visually hidden text is another option for icon buttons. Add a <span class="visually-hidden">Submit form</span> inside the button element. This text is available to assistive technologies but invisible to sighted users, providing an accessible name without affecting the visual design.
Avoiding Common Labelling Mistakes
Label changes based on state can confuse assistive technology users. If a button label changes from "Show more" to "Show less" when expanded, screen reader users might not understand the context. Instead, keep the label consistent and use aria-expanded to communicate state changes according to MDN's ARIA button documentation.
Empty buttons without labels create significant accessibility barriers. A button containing only an icon must have an aria-label or visually hidden text providing its purpose. Without this, screen reader users encounter "button" with no indication of its function as recommended by The A11Y Collective. Button labels should be action-focused and specific--"Submit" is better than "Go," and "Save changes" is better than "Save." Clear, descriptive labels help all users understand what will happen when they activate a button.
Visual Design Requirements for Accessibility
Touch Target Size
Buttons must have a minimum touch target of 44 by 44 CSS pixels, as recommended by WCAG 2.1 success criterion 2.5.5 (Target Size). This ensures users with motor impairments can accurately activate buttons without accidentally triggering adjacent elements as recommended by The A11Y Collective.
Even when visual design calls for smaller buttons, you can maintain the 44x44 minimum touch target by adding padding while keeping the visual appearance smaller. CSS techniques like padding, background spread, or hit area extension can achieve adequate touch targets without changing the visible button size. Touch targets should also have adequate spacing between them--overlapping or closely positioned buttons increase the likelihood of accidental activation, frustrating users who rely on precise touch input.
Colour Contrast Requirements
Button text must maintain a colour contrast ratio of at least 4.5:1 against the button background for normal text, or 3:1 for large text (18px bold or larger). This ensures readability for users with low vision or colour blindness as recommended by The A11Y Collective.
Focus indicators are equally important. Buttons must have a visible focus state that meets contrast requirements. Remove default browser focus outlines only when providing an equally visible alternative. A 2px solid outline in a high-contrast colour is typically sufficient. Disabled buttons should maintain sufficient contrast for their disabled state--while reduced opacity can communicate disabled status, it shouldn't drop below the minimum contrast requirements. Consider using colour changes or pattern overlays in addition to opacity reduction.
Button Accessibility by the Numbers
44px
Minimum touch target size
4.5:1
Minimum contrast ratio
2 keys
Required keyboard activation
4
Key ARIA attributes to master
Testing and Validation
Automated Testing Tools
Validate custom buttons against WCAG 2.2 criteria, particularly success criterion 4.1.2 (Name, Role, Value) which requires that user interface components expose their name, role, and value to assistive technologies as recommended by The A11Y Collective.
Automated accessibility testing tools like aXe, WAVE, and the W3C HTML Validator can identify common issues such as missing roles, incorrect ARIA attribute usage, and insufficient colour contrast. However, automated tools can't evaluate all aspects of button accessibility--manual testing remains essential. Lighthouse accessibility audits provide quick feedback during development, identifying issues like missing labels, low contrast, and improper ARIA usage. Run audits regularly throughout development rather than waiting until completion.
For comprehensive testing workflows, learn how to integrate accessibility validation into your development process with our detailed guide on accessibility audits.
Manual Testing with Assistive Technologies
Test buttons using screen readers including NVDA (Windows), VoiceOver (macOS/iOS), and JAWS (Windows). Navigate to each button using keyboard-only controls (Tab and Shift+Tab), and activate buttons using both Enter and Space keys. Verify that screen readers announce the correct name, role, and state information as recommended by The A11Y Collective.
Keyboard-only testing reveals focus order issues, missing keyboard support, and inadequate focus indicators. Tab through the entire interface without using a mouse, activating every button using only the keyboard. Note any buttons that can't receive focus, can't be activated, or trap focus unexpectedly. Testing with actual assistive technology users provides the most valuable feedback--their real-world experience reveals issues that developer testing might miss, including confusing announcements, unexpected behaviors, and usability challenges.
Common Questions About Button Accessibility
Common Mistakes and How to Avoid Them
Using role="button" on Native Elements
Never add role="button" to native <button> or <input type="button"> elements. Native buttons already have the correct role, and adding ARIA roles to native elements can create redundant announcements or unexpected behavior in screen readers according to MDN's ARIA button documentation. If you need additional button-like behavior, implement it using JavaScript on the native element--native buttons provide all the accessibility infrastructure you need.
Forgetting Keyboard Activation
Implementing click handlers without keyboard handlers is one of the most common button accessibility failures. Users who rely on keyboards can tab to the button but cannot activate it because Enter and Space key presses do nothing according to MDN's ARIA button documentation. Always test buttons using only the keyboard--if you can't activate a button with Enter or Space, add the missing keyboard event handlers.
Incomplete State Communication
Toggle buttons that update visually without updating ARIA attributes create confusion for screen reader users. If a button appears pressed but aria-pressed remains false, screen reader users receive incorrect information about the interface state according to MDN's ARIA button documentation. Whenever a button's visual state changes, update the corresponding ARIA attribute in the same operation. Test with screen readers to verify that state changes are announced correctly.