Many years ago when we created our Accessibility Management Platform (AMP) we decided it was best to remove the need for testers to choose which Section 508 standard paragraph or WCAG success criteria (SC) applied to a violation. Instead we created best practices in AMP that were very clear explicit tests that mapped back to the accessibility standard paragraph or WCAG SC, allowing the system to then automatically generate a level of support to the correct accessibility standards. Fairly often I see people in our community incorrectly applying a WCAG 2 SC. This post will cover some of the commonly confused WCAG 2 Level A and AA success criteria and elucidate on how they should be correctly flagged.
SC 3.3.2 Labels and Instructions
SC Requirement: “Labels or instructions be provided when content requires user input” (Refer to understanding SC 3.3.2).
This SC requires that labels and instructions be visible to all users, not just users of screen readers. It doesn’t require that labels be associated with user input controls — that is covered under SC 1.3.1 Information and Relationships. Most often I see developers provide input without a visual label because there is an accessible label such as aria-label or a title attribute — so they don’t think a visual label is needed. Similarly, I see testers flagging this criteria when an explicit label or aria-labelledby attribute is missing. Keep in mind that many of these success criteria are aimed had making web content accessible to all users — this includes people with cognitive disabilities who may not be using assistive technology. Remembers, labels are available to everyone while names may only be available programmatically, e.g. to assistive technology.
SC 2.4.6 headings and labels
SC Requirement: “Headings and labels describe topic or purpose.”. (Refer to Understanding SC 2.4.6)
This success criteria requires that only when a heading or label is present that it describe the topic or purpose. It does NOT require that headings or labels be added. Adding labels is covered under SC 3.3.2, adding headings is covered under SC 2.4.10, a Level AAA success criteria. It also does NOT require that headings be marked up correctly with HTML heading elements, e.g. h1, h2, h3, etc. Proper heading markup when headings are present is covered under SC 1.3.1 Info and Relationships. As you may have noticed, SC 1.3.1 Info and Relationships is a very broad success criteria that covers many common accessibility issues.
SC 4.1.2 Name, Role, and State
SC Requirement: “For all user interface components … 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…” (Refer to Understanding SC 4.1.2).
First, the aim of this SC is for interactive elements with a focus on custom controls. Thus, standard text input controls without an accessible label should be flagged under SC 1.3.1 Info and Relationships and not this SC. There are three primary areas where this SC should be flagged:
- when custom controls, e.g. those that may use ARIA roles, states, and properties are used and need to correctly expose this information.
- when custom controls use scripts for operation and the scripts are not implemented in a way that is accessibility supported with user agents and assistive technology, e.g. the screen reader user is unable to activate an item that is keyboard accessible because the click event is not supported
- when notifications such as changes in focus or dynamically changing content are not indicated using accessible methods, e.g. ARIA live regions.
SC 4.1.1 Parsing
This SC requires “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.” (Refer to SC 4.1.1 Parsing)
Simply put, this SC does not require that a web page validate to the HTML specification. This SC should not be flagged if a page simply fails the HTML validator, for example, if a required HTML attribute is not set. What it does require is that when a markup language is used such as HTML that a very specific set of criteria are met as defined above. The purpose of this SC is to allow flexibility for authors while failing the most egregious issues that are likely to cause problems for assistive technology or cause the accessibility API to not be created correctly in the user agent.
SC 1.3.3 Sensory Characteristics
This SC requires “Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation, or sound.” (Refer to Understanding 1.3.3)
This SC applies to instructions for understanding and operating content. There may be other situations where non-text elements such as color, spacing, audio, etc. are used to convey meaning for a control but are not part of the instructions. For non-instructions, the appropriate SC should be indicated, for example, use of color to communicate a state can be flagged under SC 1.4.1. Use Color, use of an audio alert could be flagged under SC 1.1.1 Non-text Content or SC 1.3.1 Info and Relationships could be flagged when presentation is used to convey meaning or relationship.
SC 1.1.1 Non-text content
This SC requires “All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.” (Refer to Understanding SC 1.1.1)
This SC applies to more than just images. There are many types of non-text content including audio alerts, objects, etc. that are covered by this SC. Also, leetspeak or other glyph characters that may not be recognized as human language by users of assistive technology need a textual equivalent. Note while audio alerts are covered under this SC, pre-recorded video and audio are covered under SC 1.2.1 Audio-only and Video-only (prerecorded). Examples of controls that need accessible names under the SC include image buttons and embedded objects on web pages. Also included under this SC are decorative images and formatting that is not properly obscured from assistive technology.
It is important for testers, developers, and those creating accessibility requirements understand what is covered by WCAG 2 success criteria. This is not only important in reporting the correct results of an accessibility audit but also to ensure that requirements and implementation efforts correctly meet the WCAG SC. Testers should use a platform such as AMP to ensure that correct SC are automatically flagged and accurate WCAG support and conformance documents can be created.