4.1.2: Name, Role, Value [A]

Description Sufficient Techniques Advisory Techniques Failures Notes

Description

For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

Sufficient Techniques

Sufficient Techniques for Success Criterion 4.1.2

Note: Other techniques may also be sufficient if they meet the success criterion. See Understanding Techniques.

Situation A: If using a standard user interface component in a markup language (e.g., HTML):

• 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
• G108: Using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes
  • H91: Using HTML form controls and links
  • 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

Situation B: If using script or code to re-purpose a standard user interface component in a markup language:

• Exposing the names and roles, allowing user-settable properties to be directly set, and providing notification of changes using one of the following techniques:
  • ARIA16: Using aria-labelledby to provide a name for user interface controls

Situation C: If using a standard user interface component in a programming technology:

• G135: Using the accessibility API features of a technology to expose names and notification of changes
  • PDF10: Providing labels for interactive form controls in PDF documents
  • PDF12: Providing name, role, value information for form fields in PDF documents

Situation D: If creating your own user interface component in a programming language:

• G10: Creating components using a technology that supports the accessibility notification of changes
  • 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
  • ARIA16: Using aria-labelledby to provide a name for user interface controls

Advisory Techniques

Advisory Techniques for Success Criterion 4.1.3

• Using aria-live regions with chat clients (future link)
• Using role="marquee" (future link)
• Using role="timer" (future link)
• ARIA18: Using aria-alertdialog to Identify Errors
• SCR14: Using scripts to make nonessential alerts optional

Failures

Failures for Success Criterion 4.1.2

• 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
• 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
• 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

Notes