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

Guideline 4.1 - Compatible

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

Success Criterion 4.1.1 - Parsing

In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.

For HTML, you can use these techniques:

• validate web pages using the W3C validator
• fully conform to HTML specifications
• ensure that web pages can be parsed using one of the following techniques:
  • ensuring that opening and closing tags are used according to specification, id attributes are unique on a web page, and elements do not contain duplicate attributes
  • ensuring web pages are well-formed

Note that any of these techniques is sufficient to comply with this success criterion.

WordPress

The WordPress admin panel is neither HTML specification compliant, nor is the admin bar. If you're validating this success criterion while logged in and the admin bar is present, you will probably fail this success criterion. This may present additional challenges in using ARIA properly, as you'll have a nav with the ARIA role navigation without a label. Furthermore, the admin bar's search element has a screen reader-only <label> after the element itself, which might cause challenges in the logical order of labels on your page.

You can fail this success criterion by:

• incorrectly using start and end tags or attribute markup
• duplicate id attribute values, which includes id=""

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.

WordPress

The blocks implemented in Eightshift Frontend Libs are designed to be Level AA compliant.