Clickable and Inclusive: Designing Accessible Buttons
#accessibility #WCAG #userexperience
Buttons might be one of the smaller elements on your website, but they’re also what encourage visitors to take action on your site.
Have you ever asked yourself whether all users can engage with the buttons on your website though? Even visitors who rely on assistive technology.
No matter the size of your site, button accessibility is an important consideration.
Button accessibility means designing and coding buttons so that all users, including those with disabilities, can easily perceive, understand, and interact with them.
This includes ensuring buttons are compatible with assistive technologies such as screen readers and are keyboard navigable.
Your buttons also need to meet specific requirements as outlined in the Web Content Accessibility Guidelines (WCAG) if you want to enhance the overall user experience for everyone who visits your website.
WCAG and other global disability acts such as the ADA and AODA require websites to be accessible to all, regardless of their abilities. Buttons may serve a simple function on your website, but all website visitors still need to be able to access and engage with them.
Failure to provide access to basic functionality can render your website non-compliant, which puts you at risk of costly penalties or even lawsuits.
Over and above this, your overall user experience is impacted too. Imagine how many potential customers you are driving away because they cannot access important information or perform certain actions.
Ensuring your buttons are accessible is a quick but worthwhile exercise in creating a more inclusive online experience.
Let’s get into some of the primary requirements that your buttons need to meet in alignment with WCAG.
Buttons need to be fully operable using a keyboard alone to cater to users who cannot operate a mouse. A website visitor should be able to use the Tab key to navigate to the button and the Enter or Space key to activate it.
Every button on your site needs meaningful, descriptive text. They can’t be vague such as “Click Here” or “Submit Form”. Without the text being descriptive, a screen reader would not be able to accurately relay the function of the button to a user.
Buttons should be large enough to be easily clickable (at least 44×44 pixels) and spaced apart to prevent accidental clicks.
People with limited dexterity who struggle with precise movements will find it very difficult to interact with buttons that are too small or poorly spaced. Visitors who rely on screen magnifiers would also struggle to distinguish small or closely packed buttons.
WCAG states that button text should contrast well with the background. The color contrast of your buttons should be at least a 4.5:1 ratio for normal text and 3:1 for large text. Without this contrast, visitors with visual impairments such as colorblindness would not be able to see your buttons correctly.
To ensure that all the buttons on your website are fully functional and accessible, here are some best practices to keep in mind.
When adding buttons to your site, rather use the <button> element instead of <div> or <span>.
The <button> element inherently supports keyboard interactions and is recognized by screen readers without the need for additional ARIA attributes. Non-semantic HTML elements like <div> or <span> require extra effort to make them accessible and may still not provide the same level of usability.
Buttons should have a visible focus state such as an outline or highlight.
This ensures that users who rely on keyboard navigation can identify which button is currently selected. You should also avoid removing default focus styles without providing a clear alternative, as this can make navigation difficult for some users.
Provide clear visual and/or auditory feedback when a button is hovered over, focused, or clicked. This can include changes in color, size, or adding an animation to indicate interactivity.
For users with visual impairments, screen readers should also announce relevant state changes, such as when a button becomes disabled or when an action has been successfully completed.
ARIA labels also really come in handy. Use aria-label, aria-labelledby, or aria-disabled when needed to provide screen readers with additional context.
For example, if a button only has an icon, an aria-label can provide a descriptive text alternative (e.g., aria-label=”Search” for a magnifying glass icon). Similarly, aria-disabled=”true” ensures that users of assistive technology understand that a button is unavailable, even if it appears visually disabled.
Use text, icons, or patterns along with color to indicate different button states (e.g., active, disabled, or error states).
This benefits users with color blindness, who may not perceive differences between red and green or other common status colors. For example, instead of using red alone to indicate an error, you can include an error icon or text like “Invalid input” to make the issue clearer.
Buttons should behave predictably across different devices and browsers. It’s important to maintain standard interactions, such as ensuring buttons always trigger on Enter or Space. It’s also best to avoid unexpected behaviors like requiring a double click when a single click is expected.
Make a point of testing your buttons across various screen sizes, browsers, and assistive technologies to maintain consistency and usability.
Once you’ve made sure the buttons on your website are accessible, make sure you’re staying up to date with any WCAG updates. It’s not impossible for requirements to change, so further updates may be required.
Lastly, if you make any major updates to your site such as adding new functionality or pages, don’t forget to check any new buttons for accessibility too.