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.
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:
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.
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:
Rules for a correctly written alt attribute:
ℹ️ I definitely recommend checking out the article on WebAIM where they go into more detail about writing alt text along with examples.
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).
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.
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.
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.
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.
ℹ️ You can read more in the article Accessible icon links or in the documentation for Font Awesome icons.
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.
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.
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.
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.
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.
ℹ️ You can find well-done article on the accessibility of forms on WebAIM.
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.
If we use this attribute correctly, we will meet two WCAG success criteria:
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.