Last updated:

Created by:

Success Criterion:

Description

Interactive elements labelled through their content must have their visible label as part of their accessible name

Accessibility Requirements

This conformance rule relates to:

Test procedure

Applicability

This rule applies to any element that has:

Note: widget roles that supports name from content are: button, checkbox, gridcell, link, menuitem, menuitemcheckbox, menuitemradio, option, radio, searchbox, switch, tab, treeitem.

Expectation

The complete visible text content of the target element either matches or is contained within its accessible name.

Note: Leading and trailing whitespace and difference in case sensitivity should be ignored.

Assumptions

There are currently no assumptions

Accessibility Support

There are no major accessibility support issues known for this rule.

Background

Test cases

Passed

Passed example 1

Visible label and accessible name matches when trailing white spaces are removed.

Code Snippet:
 <div role="link" aria-label="next page ">next page</div>
 
Example Output: Open in a new tab/ window

Passed example 2

Character insensitivity between visible label and accessible name.

Code Snippet:
 <div role="link" aria-label="Next Page">next page</div>
 
Example Output: Open in a new tab/ window

Passed example 3

Full visible label is contained in the accessible name.

Code Snippet:
 <button name="link" aria-label="Next Page in the list">Next Page</button>
 
Example Output: Open in a new tab/ window

Failed

Failed example 1

Visible label doesn’t match accessible name.

Code Snippet:
 <div role="link" aria-label="OK">Next</div>
 
Example Output: Open in a new tab/ window

Failed example 2

Not all of visible label is included in accessible name.

Code Snippet:
 <button name="link" aria-label="the full">The full label</button>
 
Example Output: Open in a new tab/ window

Inapplicable

Inapplicable example 1

Not a widget role.

Code Snippet:
 <a aria-label="OK">Next</a>
 
Example Output: Open in a new tab/ window

Inapplicable example 2

Widget role that does not support name from content.

Code Snippet:
 <input type="email" aria-label="E-mail" value='Contact'>
 
Example Output: Open in a new tab/ window

Inapplicable example 3

Non-widget role that supports name from content.

Code Snippet:
 <div role="tooltip" aria-label="OK">Next</div>
 
Example Output: Open in a new tab/ window

Inapplicable example 4

No rendered text in name from content.

Code Snippet:
 <div role="tooltip" aria-label="OK"></div>
 
Example Output: Open in a new tab/ window

Inapplicable example 5

Non-text content.

Code Snippet:
 <button aria-label="close">X</button>
 
Example Output: Open in a new tab/ window

Glossary

Semantic Role

A semantic role is a semantic association that indicates an object’s type. This allows tools to present and support interaction with the object in a manner that is consistent with user expectations about other objects of that type.

Roles can be implicit through the element type or explicit through the role attribute.

The role attribute takes a list of tokens. The semantic role is the first valid role in this list. If none of the tokens are valid, the implicit role will be used instead.

Non-abstract roles defined in the following specifications are considered valid:

Other roles may be added as they become available. Not all roles will be supported in all assistive technologies. Testers are encouraged to adjust which roles are allowed according to the accessibility support base line. For the purposes of executing test cases in all rules, it should be assumed that all roles are supported by assistive technologies so that none of the roles fail due to lack of accessibility support.

Note: For HTML elements the implicit roles are documented in ARIA in HTML.

Visible Text Content

Elements that are visible on the page, that are of type text, excluding text content in title or alt attributes, and are not categorised as non text content.

Note: These elements should also be ensured to meet the color contrast and visibility requirements.

Visible

Content perceivable through sight.

Content is considered visible if making it fully transparent would result in a difference in the pixels rendered for any part of the document that is currently within the viewport or can be brought into the viewport via scrolling.

Content is defined in WCAG.

Accessible Name

The programatically determined name of a user interface element that is included in the accessibility tree.

The accessible name is calculated using the accessible name and description computation.

For native markup languages, such as HTML and SVG, additional information on how to calculate the accessible name can be found in HTML Accessibility API Mappings 1.0, Accessible Name and Description Computation and SVG Accessibility API Mappings, Name and Description.

Test Aspects

Test aspects are defined as part of the ACT Rules format 1.0.
  • DOM Tree

  • CSS Styling

Contribute






GitHub

Contributing is open to anyone. We welcome any new issues or pull requests for changes. Auto WCAG Rules has conference calls every 4 weeks. If you are interested in becoming an active contributor or reviewer, we ask that you join the Auto WCAG Rules community group through the W3C Website. This requires setting up a W3C account, may require approval by the organization you work for if they are a W3C member.

Learn more about contributing to Auto WCAG Rules Join the Auto WCAG Rules community group now!