Accessibility Techniques WCAG

Issues that don’t fail 4.1.2 Name, Role, Value

I run across a lot (and when I say a lot… I mean A LOT) of 4.1.2 bugs that have an inaccurate understanding of the success criterion. Here are some common bugs and some clarification. This is a living document and will be updated periodically.

Some things to remember about this is that 4.1.2 Name, Role, Value requires that user agents “can” get or set this information. It does not require the information provided to be accurate. We’ll cover this more in the following examples.

  1. Element has the role defined in content.
    1. This is somewhat of a grey area. However, if you read the definition for “programmatically determined”, then you will notice this line, “can extract and present this information to users in different modalities”. If the role is defined with a hidden span of text or some other method, then it would fail. The reason for this is that a user agent cannot extract this information to present in different modalities. It can only be presented as plain text. If it were a custom created link with JavaScript, then it could not be presented in the modality of a link list.
  2. A text document viewed on the web has no aria roles defined.
    1. Since the underlying technology for a text document does not have the ability to add these properties, then using consistent formatting of content is sufficient. Without any formatting, this may be considered a fail.
  3. Accessible name is not clear.
    1. Accuracy of the accessible name is not a requirement of 4.1.2.
    2. If the element is a form element, this is covered in 2.4.6 Headings and Labels which requires the label to describe the topic or purpose.
    3. If the element is an anchor element (link), this is covered in 2.4.4 Link Purpose (in context).
    4. If the element is a landmark or other element, then 2.4.6 would apply. Whether the label is visible or not, it must be sufficiently descriptive.
  4. Form labels are missing.
    1. If there is no visible label or element with a text alternative, then this is a failure of 3.3.2 Labels or instructions.
    2. If there is a visible label or element with a text alternative, then this is likely a failure of 1.3.1 Information and Relationships. The reason for this is there is no programmatic relationship between the visible label and the input.
  5. Screen reader does not report role.
    1. If there is an accurate role on an element, then this success criterion is met (at least for roles). The accuracy in reporting the role is considered a bug with the User Agent or Screen Reader.
  6. The status update is not automatically reported to the user.
    1. “Notification of changes” is often misunderstood as “Informing the user that a change has occurred.” These are two very different things. The only requirement from this is that the User Agent must be kept up to date. It does not require the end user to be informed about every change.
    2. Example: This would require the use of aria-expanded when content is shown/hidden. When the value of the aria-expanded is updated from true to false, that is all that is required. If the screen reader does nothing with that information, that is not a failure.

Leave a Reply