Last modified on Fri 17 Mar 2023

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:

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


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:

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:

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:

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

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.


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