Robust

This section of WCAG is about ensuring that your website or product will work with browsers and assistive software both now and in the future.

4.1 Compatible

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

4.1.1 Parsing (Level A)

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.

Parsing was removed from WCAG 2.2 as it is now obsolete. This is because assistive technology no longer directly parses HTML. Personally though, I still think it is good practice to use valid code.

Learn how to meet 4.1.1 Parsing

4.1.2 Name, role, value (Level A)

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.

In theory, you should pass this criterion if you stick to standard HTML and keep to the specification. As I see regular fails in this, my first post will address these. Later, I may write some posts about custom widgets.

Learn how to pass Name, role, value, when using standard HTML.

4.1.3 Status messages (Level AA)

In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.