There are 3 types of relationships in a web page: explicit, implicit, and content-based relationships. Read this to see what they are and why they’re critical to ensure accessibility for everyone.
Last month (July 2014) I spoke at Open Web Camp to a wonderful group of designers and developers. My talk was “Accessible Design: Which everyone do you mean?” I talked about three types of relationships that are needed for accessibility: explicit, implicit and content-based relationships. Here’s what I mean.
Take a look at this form:
These are the strongest ties that elements on a web page can have. Think of the form
label with its
<label for="screenname">Screen name:</label> <input id="screenname" type="text">
That’s an explicit programmatic relationship. It is spelled out in the code. It is clear and easy to programmatically determine. These explicit relationships are critical for someone using assistive technology such as screen readers, magnifiers or voice recognition software.
These aren’t as strong as explicit, but they’re definitely there. In development terms, think of two nodes that are siblings. In our form above:
<label for="screenname">Screen name:</label> <input id="screenname" type="text" aria-describedby="screentip" > <span id="screentip" class="tip">Your nickname here. One word. Letters and numbers only. No spaces.</span>
The input and the span are related to one another because they have the same parent node. And yes, they can be programmatically determined too, but not in the same direct way as an explicit relationship.
In design terms, the label, the input field and the span with the extra tip are all visually close together on a page in a group. We create visual relationships between design elements all the time. Think of that same form field and label combination. The form label could technically be ANYWHERE on the screen and it would still pass programmatic accessibility checks. But we put it near the field because that’s where it belongs visually. The label and field are a grouping, along with any other instructions or error messages that go with the page. We visually group them to create an implied relationship.
These implied and visual relationships are critical to someone that has low-vision (that may or may not be using a magnifier or magnifier/reader combination). In other cases, they may be just as important for someone who uses a switch to access content or functionality, or someone using voice recognition software. Ease of use will often be dependent on the placement of those items on the screen.
Content-based relationships are the weakest of these ties, but nonetheless are still critical to overall accessibility. We use words as part of our practice all the time to create meaning on a web page. For instance, let’s look at our form example again and take a look at these error messages:
- Screen name: has already been taken.
- Email: has already been taken
Each one of these messages uses the field name in the error message itself. Why? It creates an important connection for users between elements, a connection that is based purely in the content on the page. Even if the error messages were programmatically tied to the fields themselves using
aria-describedby, they’re far away from the fields themselves. A low-vision user likely won’t see the error messages and the fields at the same time. Using the name of the field makes it easier to search for the field that has the error. The content reinforces the programmatic relationships we’ve created elsewhere.
How do you succeed with accessibility? Use all three
There’s a huge emphasis on programmatic accessibility on the web today. And for good reason—it’s critical for a lot of people with disabilities. But the other relationships are important too for creating an inclusive experience.
When you’re building and designing your next site or application, remember all three. Provide them all, and you’ll be going a long way to making your work accessible to more people.
You can watch this segment of the presentation below: