This content originally appeared on 24 Accessibility and was authored by David Kennedy
You’ve heard of this inclusive design thing, and know that a11y is a numeronym for accessibility. It matters to you, and you try to make the people and projects around you better for it. But you’ve conquered the basics. Now what?
I have good news to share: going beyond the basics isn’t as hard as you might think. Why? Well, because doing deeper in this case means looking at what you already know, just through a different lens.
That thing you already know? HTML. The different lens you can look at it through? How HTML, or markup, needs to change based on the content of a site or application, and the different abilities of those using it.
Yes, I’m going to talk about HTML a lot in this post. I’m also unlikely to cover anything new for you on that front. However, the concept I want to stick is how understanding accessibility becomes easier once you grasp how it intersects with nearly every part of your work. In the case of this post, I’ll discuss markup, content and assistive technology users, how they intersect to create accessibility needs. Once you learn to spot those intersections, you can pick one, go deeper and get a sense of why it’s that way. Then you’re on your way to making better decisions around accessibility.
What will give you a deeper understanding of accessibility?
Web accessibility may be one of the most nuanced topics when it comes to designing, building and testing for the web. You can get to know it from many entry points, each of which allows you to gain extensive knowledge. Though, when I conduct accessibility reviews of designs and interface builds, I find myself highlighting the same three topics. They are:
- How HTML structure needs to be approached
- How to create and label the controls of an interface (its form fields, buttons, etc.)
- How to effectively write plain-language content that reads well
- How each of these factors impact people who use assistive technology
Let’s talk about HTML
First, let’s start with the one true requirement for putting anything on the web: HTML. When a browser renders a web page, it forms what’s called the Accessibility Tree. That tree, as it’s called, provides an API to describe the content and structure of a web page. So many HTML elements, but not all come with certain semantics that surface in that API. So don’t think of HTML as just HTML – it’s really a powerful API. You create that API with many of the elements you place on the page. That’s why HTML isn’t really “basic” at all.
Let’s look at a few examples of how HTML needs to be different, depending on the content of the page and people that might be using it.
The classic example here would be alternative text. Let’s say that you have this image:
Imagine this dog has gained some notoriety, thanks to a meme we’ll call “Grumpy dog.”
For example, you have this photo of the dog, followed by this content:
“Grumpy dog became a popular Internet meme in 2019, when a photo of the black pug wearing a denim jacket was shared widely on social media sites.”
Based on that, the alternative text for this image might be “Toshi, the grumpy dog.”
Now, what if there was a caption under the photo that said, “Toshi, the grumpy dog?” If so the alternative text for this image would be different. The alt attribute could be “Pug wearing a jean jacket.” The accompanying markup might be:
<figure>
<img src=... alt="Pug wearing a jean jacket">
<figcaption>Toshi, the grumpy dog</figcaption>
</figure>The dog’s name becomes repetitive in the alt attribute because of the caption. With the markup, screen reader users would know there was a photo and what it looks like. Everyone would get the information that isn’t readily apparent via the photo itself in the figcaption.
That’s a good example of how, depending on the content, the markup and context needed for the screen reader experience can change. It also shows how it’s a good idea to let the content do most of the work so you don’t create something unneeded for screen readers. Your content, markup and context will almost always be intertwined.
Another example would be the use of fieldsets. Fieldsets are a structural element that group related form controls. For example, you have a question in a form with three radio buttons:
Have you filed taxes in 2018?
- Yes
- No
- I have filed an extension
The labels for each radio button are the answers to the question. Many people mark up the labels properly, but they fail to connect the question, “Have you filed taxes in 2018?” to the radio buttons via HTML. They place the question in a <p> element, heading element or something similar. For a sighted user, it’s easy to see that the question relates to the choices because of the proximity of them. However, for a screen reader user with vision impairments, that association may be harder to make.
The <fieldset> and <legend> elements should be our go-to elements. By placing those radio buttons in one, we get the necessary semantics and exposure to the accessibility tree:
<fieldset>
<legend>Have you filed taxes in 2018?</legend>
… radio buttons ...
</fieldset>
Adding the question to a legend element means that when a screen reader user navigates via form fields alone they’ll hear what question goes with the associated answers . This allows all users easy scanning of the page, and creates a more optimal experience.
Focus on your interactive elements
To go further into HTML, let’s move to links and controls. That’s your links, plus buttons and inputs used in forms – elements that drive interaction.
The classic example here would be choosing between a link or button. When you make a `<button>` element, it comes with a certain semantics, again informing the browser’s accessibility tree. A screen reader user knows that it’s a button and knows what keys activate it. If a keyboard user tabs to it, it’ll work like a button. However, it you used a <div> or <span> to make that faux button, you won’t get all of those benefits out of the box.
Another example, continuing to focus on the <button> element, are labels. Often, in an interface, you may design button labels that are one or two words. Let’s say you have a button that edits your page, opening it in a content editor. The button’s label may say: “Edit.” The label works because sighted users can see the proximity between the page title and edit button, recognizing the two go together. However, for low vision users, they can’t see that proximity. So having more context matters. Screen reader users can navigate by forms controls alone, skipping around from button to form field. So if they land on a button that says, “Edit,” how would they know what the button would edit unless they pressed that button? Adding “Edit page title” to the button helps people know they’ll edit the page.
Labels and instructions
HTML opens up a lot of possibilities for useful, built-in context that can come with the web pages and web apps you create. Despite that, many who build for the web make the most basic mistake with labels – leaving them out. Fifty nine percent of the 3.4 million form inputs identified were unlabeled in the recent WebAIM Million report.
When you label your form fields, what do you get when you do that? Most obvious, they give the user instructions either visually or auditorily (with screen readers). Beyond that, a label properly associated with a form field means that not only will screen readers read it, but users with motor impairments can click or tap on the label, and focus on the right field. You can use that to your advantage.
In many cases, you may need to pair your form labels with instructions, especially if the information needed is tricky. Placing any instructions in the label element means you get all the previously mentioned benefits. Of course, your design may call for something different location-wise, and ARIA can assist you there, but this way gives you the widest browser and assistive technology compatibility. You can also do this with error messages, putting all the relevant context in one spot for users to digest and interact with as they use what you’ve created.
Wrapping up
We’ve covered a lot of basics, but we’ve also looked at the context behind how accessibility intersects with markup and context. With that, you can start to reframe your thinking around accessibility to learn more about and grow beyond the basics.
Some of my favorite “beyond the basics” include:
- A11y Weekly: a weekly newsletter run by yours truly, full of links both about the basics and beyond.
- What is This Thing, and What Does It Do?: This talk by Karl Groves expands on the importance of how markup and decisions impact accessibility.
- Developer’s Guide to Accessibility Mechanics: Leonie Watson shares in-depth information on how the browser works and what it gives you when it comes to accessibility.
- A11y Wins: A site that curates good examples of accessibility, from Marcy Sutton.
- Form design: From zero to hero all in one blog post: Adam Silver covers all the basic form design patterns (and more) in one post.
The post The intersection of markup, content and context in accessibility appeared first on 24 Accessibility.
This content originally appeared on 24 Accessibility and was authored by David Kennedy
David Kennedy | Sciencx (2019-12-05T00:20:05+00:00) The intersection of markup, content and context in accessibility. Retrieved from https://www.scien.cx/2019/12/05/the-intersection-of-markup-content-and-context-in-accessibility/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.