Whenever I come across a a violation of 1.3.1, I have a primal need to look deeper. I investigate because I believe if something falls under this success criterion, it is most likely improperly classified. It is extremely important that we understand the relevant context, information and relationships of content. Frequently, I observe that this particular success criterion is misused. It often serves as a catch-all for “Where does this go?”
So then what does go here?
Per WCAG, 1.3.1 Info and Relationships is:
Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
Cool. We used the original words to define it. I didn’t like third grade English when I was in third grade.
Let’s look at the intent:
The intent of this Success Criterion is to ensure that information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes. For example, the presentation format changes when the content is read by a screen reader or when a user style sheet is substituted for the style sheet provided by the author.
Now this is better. We’re given a breakdown and example. The intent is to ensure that what is visually indicated as structural, explanatory, and informational is available to everyone. This includes people using different presentation formats.
Structural
When talking about structure, it is crucial to distinguish between visual structure and code structure. We need to consider both.
When we look at our mock-up of a page, we want to absorb it visually. Is the most important item in the page grabbing the eye? Does the way it is designed lead you to the next thing you want to say or a primary CTA
(Call to Action)? Take it all in, then we start deciding what HTML elements best represent all those pieces of the page. We begin to think of how we order them. Should it be in a landmark like header, aside, footer, main, or nav? Or is does it need a textual element like headings, anchors, paragraphs, lists, or quotes?
Information
We need to ensure that any information expressed visually is communicated non-visually. If a button is disabled, how do we inform a screen reader user it is disabled? How does a screen reader user know if a Menu is opened? This is the information we should be looking for. In many cases ARIA attributes will be the answers to provide this information.
Relationships
Under relationships we find little programmatic lines connecting the page together. We might specify via aria-label that the first navigation is the “Primary navigation.” Forms point to a more direct relationship in how we set up labels, inputs, and error messages. Using the label’s “for” attribute we build a relationship of the name and input. Aria-describedby with the ID of an error message is another bridge creating a relationship.
Here’s my problem
Much of the time these are not errors of information or relationships. They’re a failure of properly using HTML or ARIA. Sometimes both.
In my example of using the landmarks to construct the basic layout, it isn’t a violation. But we didn’t provide an accessible name. That’s a violation of 4.1.2, so why dump it here?
My disabled button? Case of missing aria-disabled, a 4.1.2 issue.
Headings used out of order? Not a WCAG SC.
Headings not sized to their importance? Now you have a 1.3.1 violation! The visual size provides a hierarchy of importance. On the code side we do this with heading elements H1 – H6.
The Fix
Info and relationships are important on the web. They provide context and details that may not be picked up right away. Anything we do on this account visually needs to be conveyed programmatically too. But that doesn’t mean everything that falls into this bucket belongs. Dumping things in here can harm your clients. You might not provide them enough context to resolve their issues.
Look deeper at the issue. Is it a matter of a screen reader not announcing something? Look at the code, is it missing ARIA? Does it apply to another criteria? Make sure you flag it the right way. And don’t flag it twice, once here and once under the other SC. If it fits under another SC, then fixing it under that criteria will fix it for 1.3.1 as well.
Have a thought, feedback or concern about this article, let’s discuss it on BlueSky or LinkedIn.