The results were devastating: the analyzed home sites averaged almost 60 errors each, and the percentage of clean sites was less than 3%. But, there was a silver lining: most of the errors could be grouped into just a handful of categories. Out of a total of 59.6 million errors, 52.1 million were caused by only five easy-to-prevent problems:
- 36 million were instances of text with insufficient contrast.
- 12.3 million were images without an alterntive text.
- 2 million were inputs without a corresponding label.
- 1.3 million were ambiguous or empty links.
- 0.5 million were unordered headings.
Correcting these five issue types would fix most of the Accessibility problems detected.
Poor text contrast was the most common mistake according to the WebAIM report. On average, the analyzed home pages contained 36 issues with insufficient contrast between text and its background.
For me, this may be the most limiting requirement (at least creativity-wise), as many times I find an interesting color palette that I end up discarding because it doesn't meet the WCAG specifications. One option is following the less restrictive Level AA level criteria as it is not possible to satisfy all Level AAA success criteria for some content anyway.
WebAIM has a really nice tool to check color contrast, and you can find many other tools online. Actually, it is really easy to implement your own one. It requires some math, but nothing fancy, and it can be a great learning experience. For example, I developed a contrast checker myself in order to test RGB colors since all the checkers I found online worked with HEX values only.
Adding alternative text to images is one of the main pillars and basic principles of Web Accessibility. Yet it is one of the most common problems in almost every website, even when the
alt attribute is required in images.
<img src="guernica.jpg" alt="Guernica painting by Pablo Picasso" />
Although it seems as simple as adding the
alt attribute with a description to the
<img> tag, the alternative text may require a little bit of thought. What is the role of the image? What is the text surrounding it? We may not want to ignore the image (adding an
alt=""), and we don't want to have screen readers repeating the same information twice.
alton the right could work for the image, it will depend on the context
And one more thing to consider: if the image is used as a CTA, the
alt should be a description of the action to be taken and not of the image! Users may want to know that the image is a printer, but what they really want to know is that if they click on it, the document will be printed.
Labels present many benefits such as: (1) they help identify & provide additional information about the field; (2) when clicked they will focus on the linked form element; and (3) they are simple to implement. You just need to wrap the text with a
<label> tag and use the
for attribute to point to the element's id:
<label for="username">Username:</label> <input id="username" type="text" name="user"> <label for="password">Password:</label> <input id="password" type="password" name="pass">
Sometimes there may be tricky situations in which inputs may not have a specific label for each of them (e.g. a table with rows that allow edition, or a label that should apply to multiple fields). In these cases, you may use the attribute
aria-labelledby to point to the element that will serve as a label:
<table> <thead> <tr> <th id="namelabel">Name</th> <th id="addresslabel">Address</th> <th id="agelabel">Age</th> </tr> </thead> <tbody> <tr> <td><input aria-labelledby="namelabel" name="name" /></td> <td><input aria-labelledby="addresslabel" name="address" /></td> <td><input aria-labelledby="agelabel" name="age" /></td> </tr> ... </tbody> </table>
If you have a form or a component that includes form elements such as input fields or radio buttons, don't forget to add a label for the different form elements or add a
How many times have you found a website or blog with summaries of the posts and links asking to "Read more"? While that is a description of the action that the user will perform, it doesn't really provide actual meaning to the link. Are we going to be reading more about elephants, web programming, or brain surgery? Read more about what?
Now some may say: "But having a long meaningful link breaks the way in which our site is presented! There's only space for a 'Read more' caption!" And for them there is an alternative: use
aria-label in your links:
<a href="#" aria-label="Read more about Web Accessibility"> Read more </a>
Modern screen readers will read the
aria-label instead of the anchor text, so you could potentially leave your short link caption while providing a meaningful and accessible text.
The content on each page should be structured semantically and organized correctly, using the right headings in an orderly way. This may sound like a no-brainer, but it is a really common mistake: over half of the analyzed home pages presented this issue.
Screen readers allow users to jump from heading to heading. A poorly organized document will resemble a Choose Your Own Adventure book for them! And the disorganization is also confusing for the rest of us as well as for website crawlers.
Also, don't forget to use the proper semantic tags; it is important to use headings (
<h2>, etc.) instead of styling other elements to look like a title. They may be similar visually, but not all users rely on their vision.
The fact that 87% of the Web Accessibility problems found on the WebAIM analysis were really low hanging fruit errors may seem like great news, but we need to take these results with a grain of salt: the analyzed pages were just home pages, which normally don't include complex components subject to more complex accessibility issues.
Also, claiming that 85% of all the accessibility issues could be fixed with the 5 steps above is a bit of a stretch. (Sorry for the click-baity title.) Although, chances are that the actual percentage is not that far off from reality (which would make good the old 80/20 rule in computing).
The main lesson to take away would be that improving Web Accessibility may be challenging, but it is not as complicated as it seems, and every improvement, even the tiniest one, counts.
Many times as a mobile developer I have to work on apps without the API ready that was crucial for the feature I was implementing. Either the backend was developed by another team that was not entirely in sync with us or our backend team had no chance to implement those endpoints earlier. For this reason, I was not able to satisfy the Definition of Done but it does not mean that I have implemented the UI only.