Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies. - WCAG2.2

Guideline 4.1 - Compatible

Maximize compatibility with current and future user agents, including assistive technologies. - WCAG2.2

Success Criterion 4.1.2 - Name, Role, Value

For all UI components - which includes, but isn't 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;
• notification of changes to these items is available to user agents, including assistive technologies.

Note that standard HTML controls, when used according to spec, are compliant with this success criterion out of the box, while custom UI components might not be.

Depending on the situation, you can use different techniques to comply with this success criterion.

If you're using a standard UI component in HTML:

• use aria-label to provide an invisible label where a visible one can not be used,
• use aria-labelledby to provide a name for UI controls,
• use markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes by:
  • using HTML form controls and links,
  • using <label> elements to associate text labels with form controls,
  • using the title attribute for frame and iframe,
  • using the title attribute to identify form controls when <label> can't be used,
  • using HTML according to spec.

Otherwise, use ARIA to provide accessibility support for your UI component by:

• using an ARIA role to expose the role of a UI component
• using ARIA state and property attributes to expose the state of a UI component

• using aria-labelledby to provide a name for UI controls Common failures of this success criterion include:

• using a script to make div, span or similar UI controls in HTML without providing an ARIA role for the control

• implementing custom controls that don't use an accessibility API (such as ARIA) or do so incompletely (e.g., set only the name, but not the role)

• not updating text alternatives when changes to non-text content happen

• controls not having a programmatically determined name

• the focus state of a UI component not being programmatically determinable, or no notification of change of focus state available

• not providing names for each part of a multi-part form field

• not providing an accessible name for an image which is the only content in a link

Note that in Firefox, ARIA attributes aren't properties of Element. Therefore, while they are readable from Element in some cases, they should be set using setAttribute and read using getAttribute

Note that using ARIA incorrectly can make websites unusable for users using assistive technologies - no ARIA is better than bad ARIA. Take a look at the section "ARIA and building accessible websites" for additional guidance on following this success criterion.