Meaningful text is pretty straight forward: when a user reads text or has it announced to them, they should be able to immediately understand what it means even without any surrounding context. A lack of meaningful text can affect all users, but especially those who rely on assistive technologies. In this lesson we’ll be going over a few instances where you should start making sure you provide meaningful text to users.
By the end of this lesson, you should be able to:
- Know how to provide meaningful links.
- Know how to provide meaningful text in forms.
- Know how to provide meaningful
altattributes for images.
Let’s take a look at two different examples of a link:
<!-- Example 1: Where's "here"? --> <a href='...'>Click here</a> to start your career in web development! <!-- Example 2: I love that place! --> Visit <a href='...'>The Odin Project</a> to start your career in web development!
To a sighted user, the link in Example 1 makes perfect sense. However, in addition to being able to navigate a page via landmarks and headings (as mentioned in the Semantic HTML lesson), a screen reader may be able to navigate between each element of a specific type, such as links. If a user were to navigate between all of the links on a page, the only thing that would get announced in Example 1 is, “Click here, link.” Where’s “here” exactly? Without any surrounding context, the link is meaningless. Not only that, but if you have multiple links on a page with that same text content, then users will be told to “click here” many times.
The link in Example 2, however, not only makes sense in context for all users, but it also makes sense out of context for screen reader users when it gets announced: “The Odin Project, link.”
When you add links to a page, there are a few rules you should be following:
- Make sure that the text content of the
<a>element somehow indicates where the link redirects to and that it’s brief (around 100 characters). So avoid using phrases like “click here” or “this page”.
- If a link would open or download a file, include text that tells the user what kind of file it is as well as the file size.
- If a link would automatically open in a new tab or window with the
target="_blank"attribute, you should indicate this to the user in some way.
<!-- Example 1: Now the user is aware that this link will open or download a PDF file. --> <a href='...'>2021 Sign Up Statistics (PDF, 1MB)</a> <!-- Example 2: And now the user knows this link opens in a new tab! --> <a href='...'>GitHub (opens in new tab)</a>
The next time you need to use links, try saying the contents of the element out loud to yourself. Does it reasonably indicate where that link would take you, such as the title of the page, article, or video? Are you aware whether it’ll open in a new tab automatically or not, or that it’ll open a download dialog? If you’ve been testing out using a screen reader up to this point, then an even better way to test whether a link has meaningful text is with the screen reader itself!
Providing meaningful errors to users when they are filling out or submitting a form can turn the experience from frustrating to… well, maybe not fun, but at the very least just a bit less frustrating. Let’s take a look at a few error examples, ranging from not helpful at all to very helpful:
<!-- Example 1: Huh? --> <div class='input-error'>Error: Invalid input.</div> <!-- Example 2: That makes more sense. --> <div class='input-error'>Error: Email is invalid.</div> <!-- Example 3: Even better! --> <div class='input-error'>Error: 'JohnSmith@@test.com' is not valid. Example of a valid email: email@example.com.</div>
Even if you could tell what input caused the error in Example 1, which may not always be the case, the error doesn’t provide any meaningful text. What input is invalid? Why is it invalid? How can you fix it? None of these questions are answered. Now imagine how meaningless this error must be to users of assistive technologies, who may not be able to see where an error is rendered on the page and may only have “invalid input” announced to them.
The error in Example 2 clearly tells you what input is invalid, so you now know exactly where to go. While this might be all a user needs to know, it’s worth keeping in mind that it is still a rather vague error. We don’t know why our email is invalid.
The error in Example 3 is even more meaningful. It not only tells you what input is invalid, but also how to fix the error. Generally when you inform a user of a form error, you should be informing them what input caused the error and, when possible, how to fix the error or why the error occurred in some way.
Another way to provide meaningful text in forms is with instructions, such as when a password input lists any characters that the password must contain (“Must include at least one uppercase letter and one number…”). For instructions that are unique to an input, they should be placed alongside the input itself. Instructions that are more global across the form, such as indicating which inputs are required, should either be placed at the top of the form (“* indicates a required field”), or placed alongside the input or its label (“Name (required)”).
At this point you should be pretty familiar with the
alt attribute on
img elements. Whether you are or not, let’s see if you can tell which of the following examples is valid:
<!-- Example 1 --> <img src='...' alt='' /> <!-- Example 2 --> <img src='...' alt='Odin' />
Believe it or not, both examples above are valid! While Example 1 doesn’t actually have any meaningful text (perhaps a meaningful lack of text), you should still understand its importance. When you’re using an image purely for decoration, or the image just isn’t really important for the user to be aware of, you generally don’t want users of assistive technologies to be made aware of it. In those cases, you should always use an empty string for the value of the
alt attribute, the presence of the image could still be announced, which may confuse the user (especially if the file name was a random string of letters and numbers).
For Example 2, the screen reader would announce, “Odin, graphic”, making the user aware that there’s an image and what it’s an image of. What the alternative text should be for an image will ultimately depend on various factors, though. Read Alternative Text - WebAIM to learn about when and how you should be adding alternative text for images based on the function of the image and the context surrounding it.
This section contains questions for you to check your understanding of this lesson. If you’re having trouble answering the questions below on your own, review the material above to find the answer.
This section contains helpful links to other content. It isn’t required, so consider it supplemental.
- Making Accessible Links: 15 Golden Rules For Developers is a little old, but is still a great list of 15 rules for creating, well, accessible links. Some of the rules the article goes over were mentioned in this lesson, but there are some other rules that can help make sure you’re creating a11y friendly links.
- Usable and Accessible Form Validation and Error Recovery goes over a few different ways you can provide errors to users (using the