In striving for WCAG 2.0 Compliance, I'm finding quite a bit of varied information regarding proper treatment of buttons, specifically what is required to consider the button accessible and compliant.
What is the appropriate way to mark-up a <button>? What attributes or combination do they need to have?
My buttons fall into three categories:
- Buttons that have text that describes their intended action. (e.g. "Learn More" to launch a modal with more product information)
- Buttons that have text that does not describe their action. (e.g. "X" or text that titles a section of accordion content)
- Buttons that do not have text that describes their intended action or otherwise. (e.g. An icon / image that switches the context of a carousel)
For instance, in the following simple example of 3 above: http://codepen.io/ga-joe/pen/ggeLeW
Is it acceptable to add only an aria-label attribute for a button with no text? Are name and / or value always required? Please send help! Thank you!
These seem to be the relevant WCAG Guidelines:
- https://www.w3.org/TR/WCAG20/#text-equiv-all
- https://www.w3.org/TR/WCAG20/#navigation-mechanisms-refs
- https://www.w3.org/TR/WCAG20/#ensure-compat-rsv
These kinds of questions always depend on context. Let me give it a shot sans context.
<button>Learn More</button> does the trick as long as contextually someone will understand what they will learn more about. Usually the button is preceded by some descriptive text. However, if it just brings someone to another page as opposed to firing a modal, I would use a link.
<button aria-label="Close">×</button> for a close button (I am using the character entity for ×, which is more symmetrical than x. Again, if the button is at the top of a modal (for example), perhaps adjacent to its heading, then that is probably adequate.
<button aria-label="Image 1">[icon]</button> can work for a carousel. Note that a font icon can be lost if the typeface does not download. A background image will disappear in Windows High Contrast Mode (WHCM) for IE11 and older versions of Edge. The aria-label will not help the WHCM users. Probably best to use an image (even an SVG) and its alt attribute instead, which means then you do not need aria-label.
You do not need a name attribute. It does nothing useful here.
Do not use a role="button" attribute. That role is automagically part of the <button> element. If you assign another role, then you have a big problem.
Definitely do not use a title attribute. That does more harm than good.
Buttons that have text that describes their intended action. (e.g. "Learn More" to launch a modal with more product information)
You can read the recommendations for WCAG 2.4.9 Link Purpose (Link Only) even if we're not talking about links. The text "Learn more" can be understood when in context, but for low vision users who require screen magnifier, for instance, it can be difficult to understand the action from the button text itself.
For instance the text Learn more about "Wheels on the bus" may seem more appropriate.
Buttons that have text that does not describe their action. (e.g. "X" or text that titles a section of accordion content)
I answered that subject in another post:
What is aria-label and how should I use it?
You have to use both aria-label (useful for screenreaders) and title attributes (for standard users using standard browsers which may need more support):
<button
aria-label="Back to the page"
title="Close" onclick="myDialog.close()">X</button>
Buttons that do not have text that describes their intended action or otherwise. (e.g. An icon / image that switches the context of a carousel)
The same reasoning can apply to this point. But for blind people, moving a carousel to the left or to the right is a different experience, sometimes useless. If they can ignore that what they see is a carousel, without losing any content, navigating with the keyboard or their assistive technology, then you are doing what is expected.
Also, you have to never forget that accessibility does not only target blind users, but also children, old people, people with cognitive or sensitive disabilities. For instance, the aria-label will never be sufficient enough to help those people when needed. They do not have a screen reader, and they do not read the HTML source code.
In the case of users using "speech-recognition software" (yep, they are not a lot but let's improve their life), not having any visible text can also lead to difficulties.
