The 10 most common accessibility problems (Part 1)

I recommend that you also take a look at our article with an introduction to accessibility, where you can read everything you need to understand the basics.

1. Insufficient color contrast

This is a colored contrast between the text and its background. The greater the contrast, the easier the text is to read, for example for people with a visual handicap or when the sun shines directly on your screen.

According to the WCAG specification, the minimum color contrast between text and background is as follows:

AA rating:

• Normal text – 4.5 : 1
• Large text – 3 : 1

AAA rating:

• Normal text – 7 : 1
• Large text – 4.5 : 1

Large text in the case of CSS pixels means at least 24px or bold text at least 18.5px. An exception applies to decorative texts or brand logos. In the new WCAG 3 specification, there will be a new and more intelligent algorithm for calculating contrast, which will also take into account the font or the specific colors used.

Color contrast can be verified directly in the browser's DevTools or with any automated test. Only texts that are in front of the image background can be a problem, where you have to be more careful.

ℹ️ You can find more useful information about colors and contrast on the WebAIM website.

2. Missing alt text

The non-text content of the page must contain alternative text. The best example is images, but it also applies to other elements such as videos, charts... Alternative text fulfills several functions:

• For the visually impaired, the screen reader reads the alternative text, so they know what information is important in the image.
• If the image fails to download, at least the alternative text is displayed
• Search engines use the alternative text to better recognize the content of the page

Rules for a correctly written alt attribute:

• The alt attribute should be short and concise (usually a few words are enough)
• It should not be redundant. This means that it should not contain information that is available from the text next to the image.
• Words such as image, image of... we do not include the in the alt attribute, because screen readers will already do it for us. It would be unnecessary to read the word image twice.
• Every image must contain an alt attribute. If the image is purely decorative and does not carry any important information, then we only include an empty attribute: alt="".

Example: <img src="image.jpg" alt="A guy presenting about accessibility to his colleagues">

ℹ️ I definitely recommend checking out the article on WebAIM where they go into more detail about writing alt text along with examples.

3. Blank links and buttons

Each interactive element on the page, e.g. buttons or links must have an understandable name. It often happens that e.g. the links have only an icon in them, but no text. The screen reader cannot read what the link is for blind users.

There are two ways we can provide a name for purely icon buttons or links. The first is using the ARIA attribute aria-label, which can only be used for interactive elements (eg. buttons, links).

<a aria-label="Twitter" href="https://twitter.com">
    <svg aria-hidden="true" ...></svg>
</a>

The second method is using the <span> tag, which we hide with CSS, but this text remains visible for screen readers (you can find more about the method for hiding visual content on the WebAIM website). We can also use this method on non-interactive elements.

// CSS
.sr-only {
  position: absolute;
  left: -10000px;
  top: auto;
  width: 1px;
  height: 1px;
  overflow: hidden;
}

// HTML
<a href="https://twitter.com">
  <svg aria-hidden="true" ...></svg>
  <span class="sr-only">Twitter</span>
</a>

In both examples, we also used the aria-hidden="true" attribute on the svg element, which is used to hide content for assistive technologies such as e.g. screen readers.

Inappropriate link descriptions

Another common problem is links that have no informative value. For example click here, read more, etc... Screen readers can read a list of all the links on a page to the user so they can navigate faster. However, if the reader tells him the read more link 5 times in a row, the user has no idea where the link is going.

// Bad examples
<a href="https://www.goodrequest.com/blog">Click here</a>
<a href="https://www.goodrequest.com/blog">Learn more</a>

The ideal solution is to provide meaningful text for this link. If we cannot avoid it, we can use aria-label. The screen reader will ignore the link text and use the text from the aria-label attribute instead.

<a href="https://www.goodrequest.com/blog" aria-label="Read full article about accessibility">Read more</a>

ℹ️ You can read more in the article Accessible icon links or in the documentation for Font Awesome icons.

4. Insufficient accessibility of forms

Keyboard control

Forms on the web, like other interactive elements, should be accessible using the keyboard. For example, we can move between inputs using the Tab key, select should be selected using the up/down arrows or mark the checkbox with a space.

Naming of inputs

Each input must have an associated <label> element. We can use two notations using the for attribute in combination with id or by wrapping the input in a <label> element.

<label for="name">Name:</label>
<input id="name" type="text" autocomplete="name">

<!-- or -->

<label>Name: <input type="text" autocomplete="name"></label>

Grouping

We can group checkboxes or radio inputs with <fieldset> elements and assign a description using the <legend> element. Just visual grouping of inputs is not enough for people who use a screen reader.

<fieldset>
  <legend>Select your pizza toppings:</legend>
  <input id="ham" type="checkbox" name="toppings" value="ham">
  <label for="ham">Ham</label><br>
  <input id="mushrooms" type="checkbox" name="toppings" value="mushrooms">
  <label for="mushrooms">Mushrooms</label><br>
  <input id="olives" type="checkbox" name="toppings" value="olives">
  <label for="olives">Olives</label>
</fieldset>

Important attributes

If we want to mark the input as mandatory, we can add the attribute required or aria-required="true". Marking it with a star is not enough, because not all screen readers will recognize that it is a mandatory input.

<input id="name" type="text" required>

<!-- or -->

<input id="name" type="text" aria-required="true">

For the visually impaired, it is not enough to highlight invalid input visually, e.g. red color. The aria-invalid="true" attribute is used for this, thanks to which the screen reader will notify the user of an erroneous state.

<input id="name" type="text" aria-invalid="true">

ℹ️ You can find well-done article on the accessibility of forms on WebAIM.

5. Missing lang attribute

The language of the page should be defined using the lang attribute. Thanks to this, the screen reader can use the correct pronunciation and inflection or the browser can offer a translation of the page. We can define the lang attribute for the entire page in the <html> tag. If there is a part of the page in another language on the website, then we should use the lang attribute for a specific part of the page. You can find the list of country codes at this link.

<html lang="en">
  <p>This paragraph is English</p>
  <p lang="fr">Ce paragraphe est défini en français.</p>
</html>

If we use this attribute correctly, we will meet two WCAG success criteria:

1. Success Criterion 3.1.1 Language of Page (Level A)
2. Success Criterion 3.1.2 Language of Parts (Level AA)

Conclusion

These few tips are very easy to implement and can significantly improve web accessibility. You can easily detect these errors through automated testing and quickly correct them. We also covered automated testing in our article on the introduction to accessibility.

We are also preparing a continuation of the article where we will review 5 more common problems with accessibility. If you don't want to miss this article, you can subscribe to our newsletter.