Name, Role, Value

Understanding WCAG2.0

Elements to be operated by the user need to be interpreted by the program if they have names, roles and values. When describing elements as usual in HTML, this is rarely a problem. However, even if you are describing HTML as usual, it is important to note that if span etc. receives focus and implements such as JavaScript that causes some change in content.

Principle	Robust	Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
Guideline	Compatible	Maximize compatibility with current and future user agents, including assistive technologies.
Criterion	Name, Role, Value (4.1.2 A)	For all user interface components (elements that make up the form, links, script-generated components, etc.), names and roles can be interpreted programmatically. In addition, the status, properties, and values that can be set by the user can be set by the program. Then, user agents including assistive technology can use change notifications for these items.

URL of Techniques for WCAG 2.0

• G10: Creating components using a technology that supports the accessibility API features of the platforms on which the user agents will be run to expose the names and roles, allow user-settable properties to be directly set, and provide notification of changes
• G108: Using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes
• G135: Using the accessibility API features of a technology to expose names and roles, to allow user-settable properties to be directly set, and to provide notification of changes
• H44: Using label elements to associate text labels with form controls
• H64: Using the title attribute of the frame and iframe elements
• H65: Using the title attribute to identify form controls when the label element cannot be used
• H88: Using HTML according to spec
• H91: Using HTML form controls and links
• ARIA4: Using a WAI-ARIA role to expose the role of a user interface component
• ARIA5: Using WAI-ARIA state and property attributes to expose the state of a user interface component
• ARIA14: Using aria-label to provide an invisible label where a visible label cannot be used
• ARIA16: Using aria-labelledby to provide a name for user interface controls
• PDF10: Providing labels for interactive form controls in PDF documents
• PDF12: Providing name, role, value information for form fields in PDF documents
• F15: Failure of Success Criterion 4.1.2 due to implementing custom controls that do not use an accessibility API for the technology, or do so incompletely
• F20: Failure of Success Criterion 1.1.1 and 4.1.2 due to not updating text alternatives when changes to non-text content occur
• F42: Failure of Success Criteria 1.3.1, 2.1.1, 2.1.3, or 4.1.2 when emulating links
• F59: Failure of Success Criterion 4.1.2 due to using script to make div or span a user interface control in HTML without providing a role for the control
• F68: Failure of Success Criterion 4.1.2 due to a user interface control not having a programmatically determined name
• F79: Failure of Success Criterion 4.1.2 due to the focus state of a user interface component not being programmatically determinable or no notification of change of focus state available
• F86: Failure of Success Criterion 4.1.2 due to not providing names for each part of a multi-part form field, such as a US telephone number
• F89: Failure of Success Criteria 2.4.4, 2.4.9 and 4.1.2 due to not providing an accessible name for an image which is the only content in a link