When we develop a website, it’s essential to design and deploy the page’s features with a clear purpose: that of improving our users’ experience. This includes thinking about accessibility from the time that these features are conceived.
In February 2024, the homepages of one million websites were analyzed to troubleshoot the most common accessibility problems, per criteria of the Web Content Accessibility Guidelines (WCAG). These websites were chosen based on the Tranco ranking.
The analysis was done with Wave stand-alone API,
but with the warning that automated tools have some limitations, and cannot find all accessibility deficiencies. In other words, the fact that the tool cannot find any errors does not mean that the page complies with the WCAG, thus requiring a more thorough manual analysis with support technologies.
Following are the most common accessibility problems at homepages. We will then share several best practices for how to avoid them:
1. Text with low contrast
This is a problem found in 81% of homepages.
The page’s content must be clear and legible for everyone, including people with visual impairments. Compliance with the contrast ratio depends on the level of compliance you want to achieve:
- Level AA is the intermediate level, and requires a contrast ratio of at least 4.5:11 for normal text and 3.1 for large text (18pt or 14pt bold).
- Level AAA is the most advanced level, and requires large text and text images to have a contrast ratio of at least 4.5:1.
Note: Achieving level AA requires compliance with the criteria of level A, while achieving level AAA requires compliance with the criteria of A and AA.
2. Images without alt text
This problem is found in 54.5% of homepages.
Alt text is essential for people to use the screen reader, while, in general, it is also useful in the case of images that do not load on the page.
To choose an image’s alt text, it is important to consider its surrounding context, i.e., whether the image is decorative or functional.
- Functional images, with a button containing only a magnifying glass icon, should have alt text such as alt-text=”Search, so that the button’s action is clear to a person using the screen reader.
Decorative images, such as a picture of a person using a mobile phone, do not need to be read by the screen reader, since they add no additional useful information to the text. The image should have a null alt text (alt-text=””), or should be added as a background image in CSS.
If you have any questions about how to use alt text, please see W3C Alt Decision Tree.
3. Form fields without labels
This problem is found in 48.6% of homepages.
In addition to visually associating labels, error messages and instructions with their corresponding fields to be filled in, we must also do so from a programming standpoint, i.e., in the code itself.
In order to associate each label with its respective field, the for attribute value of the <label> and the id attribute of the <input> must be the same:
<for label=“name”> Full name</label>
<input id=“name” type=“text” autocomplete=“name”>
This makes it easier for those scrolling through the form with the screen reader, since it will communicate the label of each field.
Furthermore, when clicking on the label, the field receives the focus to be filled in, which expands the click area and facilitates the interaction for people with physical or visual impairments, above all with smaller screens.
4. Empty links
This problem is found in 44.6% of homepages.
The link should have a descriptive text that clearly specifies its purpose, together with an href attribute that specifies its destination. Otherwise, it will be an empty link.
We should avoid using vague expressions such as “Click here” or “See more” for the link’s descriptive text, since it is confusing to people who browse through the links with a screen reader or keyboard. If all of the links have the same name or a name that is vague, understanding each link’s destination can be difficult.
5. Empty buttons
This problem is found in 28.2% of homepages.
Links and buttons have different purposes, and should be structured according to their function. Normally, buttons execute actions on the page where they are found, such as sending a form, opening a menu or closing a pop-up.
To avoid empty buttons, including form buttons, they should have a clear text and a value that describes their function (e.g., form button with value=”submit)
For buttons whose content is only an image, as occurs with a button with a search icon, an alt text should be used (alt-text=”Search”) allowing the screen reader to also communicate the purpose, and not just say “Button”.
6. Document without language
This problem is found in 17.1% of homepages.
Determining the website’s primary language is important for people using a screen reader, braille translators or text-to-speech programs. When we specify the language that should appear by default, support technologies adjust the accent, pronunciation, and syntax specific to the language in question, making the content more accessible and understandable to a wide range of users.
To determine the document’s language, we can use the lang attribute at the start of the HTML: <html lang=”PT”></html>
For foreign words in the middle of the text, we recommend defining the language in which the screen reader should read them (e.g., English) when adding the lang attribute to these foreign words.
References
- The WebAIM Million – The 2024 report on the accessibility of the top 1,000,000 home pages
- W3C – Contrast (Minimum) (Level AA)
- W3C – Contrast (Enhanced) (Level AAA)
- W3C – Non-text Contrast (Level AA)
- W3C – An alt Decision Tree
- W3C – Labeling Controls
- WebAim- Links and Hypertext
- W3C – Button Pattern
- W3C – Language of page (A)
