Go to search page
A11ying with Sanna - I would if I could a guide to web accessibility

WCAG tips: Robust

The fourth principle of the Web Accessibility Guidelines is Robust. User agents, such as assistive technologies should be able to interpret content reliably. Use valid and semantic HTML. Ensure the implementation is compatible with different browsers and devices.

I won't go through every single criterion on this site. If you are curious about the more detailed contents of WCAG, hop over to my WCAG site!

Guideline 4.1 - Compatible

The criteria for compatibility aims to ensure services work when the technologies develop further.

4.1.1 Parsing

This criterion is now obsolete. But it doesn't reduce the importance of valid HTML and all functionality-related IDs being unique.

4.1.2 Name, Role, Value (Level AA)

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.

You can get warnings like this: "This select element does not have a value/name available to an accessibility API." Now, what does this mean exactly?

  • Name: What this input is called, for example, what piece of information the user is providing.
    • Using aria-label helps only screen reader users. If you use a visible label, all users benefit from it.
  • Value: It means the current value of the input so that users understand what they have chosen.
    • For a HTML <select>, this means adding a selected attribute to an <option> element. If you have an "all" option, you can mark that option as selected when the page is first shown to the user.

Most of the errors I've encountered for 1.3.1 and 4.1.2 regarding form element names can usually be fixed by using visible, correctly created labels.

Source material