As developers and content creators, you can always do better to improve the accessibility of our applications and websites. Here are 5 of the top accessibility mistakes you’re making.
Not adding enough contrast between text and the background
This ensures that there is sufficient contrast between text and the background color to ensure that the text can be easily read by the user. There are levels of compliance you can achieve, depending if your organization is aiming for the standard AA minimum compliance level or not.
| Text Size | Contrast Ratio |
|---|---|
| < 18 point (not bold) or < 14 point (bold) | AA: 4.5 to 1 AAA: 7 to 1 |
| ≥ 18 point (not bold) or ≥ 14 point (bold) | AA: 3 to 1 AAA: 4.5 to 1 |
You can use the WAVE accessibility tool to detect contrast errors on your webpage or use the individual foreground and background color contrast checker to help you calculate the contrast ratio.
Only using colors to convey meaning
Note that although GitHub uses a lot of red to indicate that there is an error with the new password, those who are color-blind would still be able to identify the error state from the error text, highlighted border, and exclamation icon. If required form fields require an asterisk (*), indicate that in the instructions as users may have trouble seeing the symbol.
Not providing error suggestions to the user
Form fields should have error messages either next, below, or above the form field or at the top of the form to indicate that an error has occurred in that field so that users do not have to scroll to the top or bottom of the page to find the error. From an accessibility standpoint, this may be done using either client-side validation or server-side validation. Instead of creating generic error messages, indicate to the user what they have done incorrectly or offer suggestions. Some examples include “No results found. Did you mean ‘City Center’?” or “Incorrect format detected. Username must not contain symbols”.
The app should also leave an error message or alert so that the user is aware that an error has occurred. Use the ARIA attribute role="alert" to indicate that the area contains alerts for the user and is “live”.
Not using role to indicate a custom component’s purpose
As developers, you develop custom components for your applications all the time. From calendar widgets to custom searches, these components are usually a set of DIV elements nested together and styled to create a usable interface to the user, but does not have any semantic meaning by itself. You can change that by specifying a role.
Refer to the list of ARIA roles that are available but remember – don’t use them unless it’s necessary such as when you’re creating a custom component that does not utilize a native DOM element.
Using sticky elements that do not unstick on different device orientations
Sticky elements such as headers and footers have always been popular, but you should ensure that when a user rotates their device to the landscape orientation, or when a user zooms in, that the sticky region does not cover up the content. Another accessibility problem comes from tabbing backwards where the tabbed area ends up behind the sticky region. Use a media query to alleviate this problem using the orientation: landscape property and change the position to position: static.
Until next time! 🎉