Using aria-label to provide an invisible label where a visible label cannot be used

From WCAG WG


Status

Editorial note

The title of this technique might be changed to "Using aria-label to provide an invisible label when there is no visible label but the context and visual appearance of the control make its purpose clear" (Loretta) or "Using aria-label to provide a programmatically determinable label" (Adam)

Update 28. August 2013 (Detlev)

Addressing survey results: https://www.w3.org/2002/09/wbs/35422/htmltfJun182012/results

  • I changed the name from "Using aria-label to provide an invisible label" to "Using aria-label to provide an invisible label where a visible label cannot be used" to address Loretta's concern that the old name might imply that it's generally acceptable to use invisible labels on form controls.
  • I changed the text of the test procedure to reflect Adams suggestion
    • WAS: "Check that the value of the aria-label attribute properly describes the purpose of the focusable element."
    • CHANGED TO: "Check that the value of the aria-label attribute properly describes the purpose of an element where user input is required"
  • Regarding James' caution as to using the div with contentEditable, I would propose to assess that again, more than a year after the technique was surveyed. I have moved the Example into third place but left it in, for now. Many authors use HTML5 ansd many like to rely on placeholder text only for labelling their inputs (native and div) so perhaps the example is relevant after all? Not sure...

I still feel uneasy about the other two examples for the reasons I have set out in the survey liked to above - they are far from typical designed web content, so I welcome any idea to replace them with something better.

User Agent Notes [To be published separately]

Screen reader support varies depending on browser:

  • System Access To Go (IE8) does not recognise aria-label
  • Using NVDA with Firefox (FF), aria-label is only spoken on custom controls
  • Using NVDA with Internet Explorer (IE), aria-label is only spoken on native controls
  • JAWS has the best support of aria-label

Here are the results of some detailed testing:

  • JAWS 13 (WIN7, FF13)
    • Example 1: JAWS speaks aria-label of div set to contentEditable but not the content of the div (the word to be corrected)
    • Example 2: JAWS speaks aria-label: "close button"
    • Example 3: JAWS does not speak the aria-label, just says "button"
  • JAWS 13 (WIN7, IE9)
    • Example 1: JAWS speaks aria-label, but the content of div boxes is only spoken in Virtual PC cursor mode, not when tabbing to the divs
    • Example 2: JAWS speaks content of div box (focus is being moved to its beginning through the skip link) followed by aria-label: "close button"
    • Example 3: JAWS speaks the aria-label
  • NVDA 2011.3 (XP, FF13)
    • Example 1: NVDA speaks specified aria-label of div set to contentEditable, followed by announcing "section editable" and, for mis-spelled words, "spelling error"
    • Example 2: NVDA does not speak the aria-label, just "X button"
    • Example 3: NVDA does not speak the aria-label, just "button" (- and + are dropped, but this may be customizable in screen reader settings)
  • NVDA 2011.3 (XP, IE8)
    • Example 1: Browser focuses div contentEditable but apparently does not expose them to the accessibility API so NVDA does not speak associated contents of aria-label
    • Example 2: NVDA speaks the aria-label content, "button close", instead of the text included in the button (X)
    • Example 3: NVDA speaks the aria-label content
  • NVDA 2012.2.1 (WIN7, IE9)
    • Example 1: Same as under (XP, IE8): div contentEditable received focus but aria-label is not exposed to accessibilty API
    • Example 2: NVDA speaks aria-label "This is a div box button close" in browse mode and "close button" in focus mode
    • Example 3: Content of aria-label spoken
  • NVDA 2012.2.1 (WIN7, FF13)
    • Example 1: NVDA speaks specified aria-label for custom div set to contentEditable, followed by announcing "section editable" (but no announcement of mis-spelled words here)
    • Example:2 Does not speak aria-label of X-button
    • Example 3: NVDA does not speak aria-label for + and - button (- and + are dropped, but this may be customizable in screen reader settings)
  • System Access To Go (XP, IE8): In all three examples, SAToGo does not recognise aria-label
    • Example 1: SAToGo speaks "editable text" followed by the text in div contentEditable
    • Example 2: After activating Link, SAToGo speaks content of the pop-up div followed by "button X
    • Example 3: By default, SAToGo speaks "plus button" and "hyphen button" - not the content of aria-label

Applicability

This technique applies to technologies that support WAI-ARIA, such as HTML.

This technique relates to:

Description

For sighted users, the context and visual appearance of an element can provide sufficient cues to determine the purpose. An example is the 'X' often used in the top right corner of pop-up divs (light boxes) to indicate the control for closing the div.

In some situations, elements can be given the attribute aria-label to provide an accessible name for situations when there is no visible label due to a chosen design approach or layout but the context and visual appearance of the control make its purpose clear.

In other situations, elements can be given the attribute aria-label to provide an accessible name when the native HTML labeling element is not supported by the control - for example, when a div set to contentEditable is used instead of native form elements such as input type="text" or textarea in order to provide a richer text editing experience.

Examples

Example 1: A close button (X) in a pop-up box

On a page, a link displays a pop-up box (a div) with additional information. The 'close' element is implemented as a button containing merely the letter 'x'. The property aria-label="close" is used to provide an accessible name to the button. 

    

<div id="box">
   This is a pop-up box.
   <button aria-label="Close" onclick="document.getElementById('box').style.display='none';" class="close-button">X</button>				
</div>



Look at Example close button

Example 2: A phone number with multiple fields

<div role="group" aria-labelledby="groupLabel">
  <span id="groupLabel>Work Phone</span>
  +<input type="number" aria-label="country code">
  <input type="number" aria-label="area code">
  <input type="number" aria-label="subscriber number">
</div>

Resources

Related Techniques

Tests

Procedure

For elements that use aria-label

  1. Check that the value of the aria-label attribute properly describes the purpose of an element where user input is required

Expected Results

  • Test #1 is true.

If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.

Retrieved from "https://www.w3.org/WAI/GL/wiki/index.php?title=Using_aria-label_to_provide_an_invisible_label_where_a_visible_label_cannot_be_used&oldid=3731"