Review: 4.1.2 Name, Role, Value (A)

[qbalsdon]

Task: Edit MCAG section 4.1.2 considering the mobile research questions (to be completed)

---

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.

Note 1: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

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 ](https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA16.html)

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 ](https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA16.html)

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