Add semantic markup wherever color carries meaning
Color is a fast cue for most readers and no cue at all for some. G138 says that wherever you use a color difference to mark something, mark it in the markup as well, using an element that means what the color means. Emphasis, strength, a state, a relationship. Assistive technology can then present it in its own way, and most browsers will show it visually too. W3C lists this as sufficient for 1.3.1 Info and Relationships at Level A, on the condition that it is used to make information and relationships that live in the presentation programmatically determinable. That is the whole job of the technique. It is worth knowing what it does not settle. W3C does not list G138 against 1.4.1 Use of Color, and files the answers to that rule separately, mostly as putting the information in text.
How we find it in an audit
Our reviewers find the color cues first, by reading the page for any legend that explains what a color means, then by looking at lists, tables and status displays where colored text is doing quiet work. For each one, we check the markup underneath. A colored span with no meaning attached is the failure. An element that carries the meaning, with the color applied on top of it, is the fix.
How affected users experience it
A syllabus that marks required readings in red is, in speech, a list of readings with nothing marked. The reader has no way to know a distinction was ever made, so they do not go looking for one. Semantic markup changes that, because a screen reader can announce emphasis or strength, and a reader using their own stylesheet still sees the distinction after the site's colors are gone.
Passes vs. fails
Passes
Required readings use <strong class="required"> and end with '(required)', so the cue exists in markup and in words as well as in color.Fails
A syllabus marks required readings with <span style="color:red"> and the color is the only thing distinguishing them.How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- ARIA attribute is defined in WAI-ARIAA tool can check this
- ARIA state or property has valid valueA tool can check this
- Element with role attribute has required states and propertiesA tool can check this
- Form field has non-empty accessible nameA tool can check this
- Headers attribute specified on a cell refers to cells in the same table elementA tool can check this
- Role attribute has valid valueA tool can check this
- ARIA global properties not used where prohibitedA tool can check this
- ARIA required context roleA tool can check this
- ARIA required owned elementsA tool can check this
- ARIA state or property is permittedA tool can check this
- Table header cell has assigned cellsA tool can check this
Other ways to satisfy this rule
52 guides on this site are filed under 1.3.1 Info and Relationships. W3C lists this one as sufficient for that rule when used for making information and relationships conveyed through presentation programmatically determinable, so the condition is part of the test rather than a footnote to it.
- ARIA11sufficientAdd landmarks so users can skip around
- ARIA12sufficientUse role=heading when h1-h6 is impossible
- ARIA13sufficientName repeated landmarks so they are distinguishable
- ARIA16sufficientName controls from visible text with aria-labelledby
- ARIA17sufficientGroup related form fields with ARIA roles
- ARIA20sufficientMark leftover page areas with role=region
This guide is our interpretation of W3C technique G138: Using semantic markup whenever color cues are used. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.