One Button to Rule Them All: Making Accessible Buttons

One button to rule them all!

There are many aspects of Web Accessibility, and it can get quite complex, and feel very overwhelming. I’m hoping to do a whole series of posts, but for today I’m going to focus on just one small element; buttons.

Why do we care?

When most people think about Web Accessibility, they are only thinking about standards and requirements. But let’s take one moment to think about why those standards exist.

In 2021 according to the census, nearly 42.5 million people (13% of the population) in the USA had a disability.

According to the CDC 2.17% of the population is experiencing vision loss.

I’ll admit, I tend to be the sentimental, idealistic type. I would love to live in a world where we are thinking of and considering all types of people when we build things.

But even if those ideals don’t concern you, imagine the prospect of up to 42.5 million people being unable to use your website? Purchase your product? Purchase your service? That should concern you. So how do we know if our websites/products/services are accessible?

We just ask our vision impaired friend to test it right? Wrong.

The Web Content Accessibility Guidelines (WCAG) are a series of web accessibility guidelines published by the Web Accessibility Initiative of the World Wide Web Consortium, which is the international standards organization for the internet. This means you don’t have to bother a friend to test for you. There are set standards and guidelines for what it means to be accessible. You can look through them here if you want to see them all. We’ll be using those as our guideline.

POUR me some accessibility!

According to WCAG standards, in order for a button to be accessible, it needs the following aspects.

• Perceivable: The button must have a clear label that describes its purpose, either as text or as an alternative text for an image. The button must also have a sufficient color contrast with the background, and be resizable without losing information or functionality.
• Operable: The button must be keyboard accessible, meaning that it can be focused and activated using the Tab and Enter keys. The button must also have a visible focus indicator, such as a border or a background color change, to show which element has keyboard focus. The button must also respond to touch and mouse events, and not rely on hover effects or double clicks.
• Understandable: The button must have a consistent and predictable behavior, meaning that it should perform the same action every time it is activated. The button must also provide feedback to the user, such as changing its appearance or displaying a message, to indicate the result of the action.
• Robust: The button must use standard HTML elements and attributes, such as <button> or <input type=“button”>, and avoid using <div> or <span> with role=“button”. The button must also use valid and semantic markup, and follow the best practices for writing HTML, CSS, and JavaScript.

So let’s look at how we make this happen. We’re going to start with the HTML, and we’ll just pretend this is a “send” button for a feedback form.

<!-- HTML -->
<button id="button">Send</button>

Let’s talk a little about some best practices here. Right off the bat we’re using the “button” html tag, so assistive technologies are aware this is a button. But we wouldn’t want to give a real functioning button an id like “button” because in all likelihood there will be multiple buttons on the page, and having multiple items with the same id is invalid html. (Which means it won’t find all the elements with the same id when they are needed and the things will break). So we’ll try this again.

<!-- HTML -->
<button id="send-feedback-btn" aria-label="Send">Send</button>

That’s better. If this was for a large company, we may even go a step further and specify the specific page/department. But for now this is fine. Let’s move on to the aria-label. But what is an aria-label? Should we ask Google?

Was this not the way you thought I was going to ask Google?

Aria labels are attributes we can add that give the user information about the element’s purpose, these attributes are used by assistive technologies like screen readers. So if a user were to focus on the “Images” link on google, it would be able to tell them it was a link (under “Role”), the name/text inside the link (“Images”), and the aria-label “Search for Images (opens a new tab)”. And now here’s a fun aside, because if I click that link it doesn’t open a new tab. So that just shows even the tech giants aren’t remembering to update their accessibility attributes when they work. (I reported the bug, I had no idea I’d be letting sending bug reports to Google when I started this article.) Back to the info though!

If we are pretending this is a send button for a feedback form, we want a user who is totally blind, using a screenreader to understand from the label what the button does when they click it. They will already get “Send” from the text inside the button. But send what? What if there’s another send on the page somewhere? One is to send a request to the chatbot for help and it’s on every page. The user needs to know which one does what so they can’t both just say “send”, they should be descriptive. “Send Feedback” is more appropriate. If it were going to take you off site, or open a new tab, like you saw in the Google example, that information would be helpful as well.

<!-- HTML -->
<button 
  id="send-feedback-btn" 
  aria-label="Send Feedback"
>
  Send
</button>

Let’s move on, what is tabindex, and do we need it?

I swear I just put them in the right order… what happened tabindex!?

<!-- HTML -->
<button 
  id="send-feedback-btn" 
  aria-label="Send feedback"
  tabindex="0" 
>
  Send
</button>

Setting the tabindex allows a developer to control if an element is keyboard focusable. But it is worth noting that by default most User Agents (the computer program that represents the person, often a Browser in this case) will automatically handle interactive elements like links and buttons by presuming they should be focusable. So you rarely need to set a tabindex manually unless you have an interactive element that should not be focusable, or you have a non-interactive element that should be focusable. A common mistake is manually attempting to order the tabindex, which can lead to confusing focus orders for the user and unmaintainable code. It’s considered a best practice to only use -1, or 0 as tab orders. You can read more here. In our case, we have a button, it’s already focusable, and we don’t really need to add the tabindex attribute. And now it’s time to discuss titles.

Any more questions?

<!-- HTML -->
<button 
  id="send-feedback-btn" 
  aria-label="Send feedback"
  title="Send"
>
  Send
</button>

I know what you’re thinking, the aria-label is announcing “Send feedback” to the screen readers, and the text inside the button announced “Send” so why would the title have to do it? And you are totally correct. But what if the text inside the button was an icon? **An additional note on icon usage can be found at the bottom of the article.

We don’t need it to announce “Send” because aria-label has our back for that. But what if the user hovers over the button? If I hovered over a bell icon, I’d normally see the word “notifications” or “alerts”. If we had an icon stand-in for our send button, we would want “send” as our hover. In our current case we don’t have an icon so we don’t need it, but it was worth taking a minute to discuss when we might. So lets move on and talk about focus styling.

<!-- HTML -->
<button 
  id="send-feedback-btn" 
  aria-label="Send feedback"
>
  Send
</button>

#send-feedback-btn:focus {
  outline: 2px solid #0000ff;
  /* Add custom focus styles */
}

Focus styling is what the element looks like when your keyboard has focus. If you hit the “tab” key inside your browser multiple times, you’ll normally see a highlighted or outlined area, representing the active focused area. According to Yale.edu

Developers and designers are encouraged to design their own focus styles, including custom focus styles for particular elements.

It’s a magic trick.

Play with this on your own, you’ll find numerous sites where the focus works, but sometimes elements don’t highlight. I was recently on a page where the main menu elements highlighted nicely, then everything else on the page included no indication of where the active focus was. It made it impossible to navigate. I was guessing, and eventually had to write down the order. That’s a very difficult experience if it’s your only way to navigate a website.

Those are the basics for making a *basic* button accessible, but every button is different. Different functions, and different styling, will impact this, and may have new requirements. It’s always a good idea to put your computer into voiceover and test how it’s working, or tab through it on your keyboard. Here are a few more accessibility notes for styling that apply to, not just buttons. We’ll start with color contrast.

There’s nothing hidden in this colorblind test. I thought you should know what it feels like.

When styling buttons (or any element), you should ensure your color contrast meets certain standards. This is for people with visual impairments and color blindness. The best way I know to ensure you are meeting these standards is to visit accessibleweb and use the free website scan tool, or the free chrome extension.

Ever had a button you just can’t press!?

Accessibility issues for dexterity have become so prevalent, we have a new word in the dictionary for them.

That’s an official Oxford Language definition.

And while we may make jokes about having sent messages “Love you” to our co-worker “Dax”, instead of “Dad”, for many people dexterity accessibility is a real challenge in day to day life.

We can help ensure our websites are as accessible as possible by:

• Ensuring on computer screens buttons are at least 44x44px (or 7x7mm).
• 44x44px for touchscreens.
• Ensuring there is enough spacing around clickable/touchable elements to prevent accidental activation. (The only thing more frustrating than not being able to hit a button, is accidentally hitting one your didn’t want to), and keeping that spacing consistent so the user it better able to understand the structure.
• Making your designs responsive so buttons can display larger on smaller touchscreens where they may prove more difficult to target.
• And as a stretch goal, letting users customize the size of buttons, so those with more dexterity challenges may be able to make the buttons larger and easier to touch. (For example Samsung phones have, or at least used to have, a fantastic mode called ‘Easy Mode’ which I have set up for many friend’s parents. The buttons are larger, the text is larger, and the interface is simpler. It makes using their phones far more comfortable for them. Good job Samsung.)

And I use an iphone.

**An addition note on icon usage:

Icons can be great for accessibility. When used properly, icons can transcend language or cognitive barriers (after all, you don’t need to be able to read, or read English to understand a save icon, or a back icon). But what counts as proper usage? Using established, known, intuitive, and commonly understood icons.

In 1972 iconic designer Massimo Vignelli redesigned the New York subway map in a way meant to be more user friendly, and that has influenced subway map designs to this day. The issue was, the map was so far removed from what users expected and understood, it caused confusion even in its simplicity. Even when a design is in every way better, if it’s too far removed from what a user understands, it will fail in its purpose.

One of the best icons I can think of is a back arrow, which toddlers who aren’t yet verbal have proven to comprehend. The back arrow is established, known, intuitive, and commonly understood.

An established, known, commonly understood, but not intuitive icon would be a floppy disk as a save icon. We haven’t widely used floppy disks in over 20 years and younger generations may not know the object is, but it’s still widely recognized as meaning “save.”

The hamburger menu icon is a point of controversy within the design community. Despite being established, it’s not always known, it’s unintuitive, and often hard to notice. But having become standard makes it hard to replace. People don’t always look at a hamburger menu icon and immediately know what it will do, and this is why you see different solutions for this icon on different websites. Some may simply write “Menu.”

Bad icon usage would be using an unrecognized icon with no label. If you put a sad face icon in a menu, what does that mean? Is this icon for feedback? Support? A wall of shame? We can add a label and titles, but if it’s not generally understood, and intuitive, it may be best to re-think the icon.

I know this was a really long article to tell you to add just a few lines, because accessibility changes when our elements and components change, so I wanted to discuss what some of those changes involve. If you stuck with it to the end, an learned how to make a super simple button accessible, I encourage anybody who potentially read this far to try to remember that accessibility is not a frustrating extra step. It’s something we should all be thinking about, because if I walk to another level in a building, a person in a wheelchair should have a way to also access that level. If I navigate an online store to buy some new clothes, a visually impaired person should also be able to navigate that website to buy some new clothes. If I’m cruising through your website, somebody with tremors in their hands should be able to manage it as well.

And now that I made a strong closing statement I’m going to end this with a High School Musical meme.

I know Troy & Gabriella are still together in the High School Musical world, and living happily ever after.