3

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:

  1. Buttons that have text that describes their intended action. (e.g. "Learn More" to launch a modal with more product information)
  2. Buttons that have text that does not describe their action. (e.g. "X" or text that titles a section of accordion content)
  3. 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:

josephjbliss
  • 113
  • 1
  • 6

2 Answers2

8

These kinds of questions always depend on context. Let me give it a shot sans context.

  1. <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.

  2. <button aria-label="Close">&#215;</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.

  3. <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.

aardrian
  • 8,581
  • 30
  • 40
  • Regarding #1, I agree it should be a link if it truly is a 'learn more' type button that will display more info, unless that more info is contained within a modal dialog, in which case a button is appropriate. However, even having contextual text before the button isn't always sufficient. I like to lean towards WCAG 2.4.9 even though that's a AAA requirement. If I were to bring up a list of buttons on the page (eg, from JAWS, ctrl+ins+b), the button list would show "learn more" and I wouldn't have any context. It's always best to have an aria-label on the button with a little more context. – slugolicious Feb 01 '17 at 21:22
  • Regarding `name`, this is an unfortunate confusion between WCAG 4.1.2 (name, role, value) and the `name` attribute. They are unrelated to each other and it's too bad WCAG uses 'name' in the name of this success criteria. The name of an object with respect to WCAG can be thought of as the object's label. That is, what will the screen reader call that object. In the button case, the 'name' of the object is the text between the ` – slugolicious Feb 01 '17 at 21:27
  • To @slugolicious' first point, remember that `aria-label` only benefits screen readers. Since the suggestion for more verbosity is generally good for cognitive issues, take a look at how to make that available to both mouse and keyboard users: http://adrianroselli.com/2016/12/accessible-emoji-tweaked.html – aardrian Feb 01 '17 at 21:38
  • This is super helpful! Thank you for the clarification and advice. – josephjbliss Feb 01 '17 at 22:29
  • Yes, `aria-label` benefits assistive technology users (not just screen reader users, it's also handy for braille devices), as do all the aria attributes. That's the whole point of aria, right? Cognitive issues are trickier. Sometimes more verbosity is worse for some cognitive issues, and tooltips can be distracting. My point was that if you have contextual info, as you mentioned, hopefully that's sufficient for the cognitive person. The addition of `aria-label` to a 'learn more' button or link is tremendously beneficial to AT. – slugolicious Feb 02 '17 at 13:34
  • @slugolicious Can you tell me what Braille devices? I am not aware of their level of support, and I know too few people who can give me input. At the very least, if a vendor is at CSUN next month I can go do some guerrilla testing. – aardrian Feb 02 '17 at 13:42
1

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.

Community
  • 1
  • 1
Adam
  • 17,838
  • 32
  • 54