Return to News

4 most common accessibility errors made impacting your website

June 3, 2021

Authored By: Spencer Rhodes, Software Engineer

 

An area easily overlooked when building websites is ensuring they can be consumed by everyone. It’s easy to forget some of our users may be visually or hearing impaired, and require assistive technologies to interpret and interact with the website.

You’ve built an amazing website, you’re ready to launch, but have you considered 508 compliance?

  1. One in four adults in the U.S. (61 million) has some type of disability.
  2. Creating an accessible site improves your SEO due to its readability.
  3. In 1998 Congress amended the Rehabilitation Act to require Federal agencies to make their electronic technology accessible to people with disabilities.

Modern frameworks and libraries are making accessibility much less of a burden on developers and testers alike. At Carimus, we are huge advocates of the React.js framework for this reason.

Making a website accessible requires diligence to ensure the appropriate attributes are added to elements on the page so technologies, like screen readers, will recognize and announce them in a coherent and intuitive way.

At a more basic level, accessibility ends up as an afterthought. Resulting in a lot of work at the end of a project to make it section 508 compliant.

Here are a few common accessibility mistakes made, taken from our own experience and the React docs:

1. Using HTML elements where they don’t belong

  • Screen readers can get confused or miss things when you violate HTML semantics. Instead of putting a <div> inside a list or table, use React fragments instead.
  • You may have a custom element in a Navigation section.  While <nav> elements will automatically get picked up by most screen readers, <div> elements will not unless you add tabIndex=”0”.

2. Use of aria attributes

  • aria-label is the most commonly used aria attribute, which is what the screen reader will announce when focus is applied to an element.
  • When using components from a library or framework (e.g. Material UI), you may need to do more than add aria-label=”your label here” to a component.
    • For example, with the Select component in Material UI, you must pass the aria-label through inputProps so it is put on the <input> element.
  • Another useful attribute is aria-live. This attribute instructs a screen reader to announce a change within an element, regardless of where the focus is on the page. This immediately announces an error message, although it does not change the focus to the error itself.

3. Inaccessible error messages

  • Consider where errors will be displayed. WebAIM outlines 3 common approaches here. We prefer the inline error approach, where errors are displayed on the page closest to the error itself.
  • In a form with multiple errors, you should have the screen reader announce and set the focus to the first error in the form.
  • The aria-describedby attribute can be used to link an error message to the appropriate form element.
  • Make sure your errors are informative. Instead of displaying “There was an error” or “The field was invalid,” give more detail as to why the error happened that will help the user correct it or know to contact an admin.

4. Insufficient color contrast

  • Not having enough contrast between text or an element and the background. This happens more so on disabled elements, which are less opaque to indicate they are disabled, so you must balance visual indication of the disabled state with color contrast requirements.
  • Refer to the React documentation on color contrasting for details on the varying levels of contrast compliance.

If you are unsure if your website is 508 compliant there are some great tools listed below to test your site or you can contact us at connect@carimus.com for assistance.

Tools within React applications to test your site accessibility:

Code linting for accessibility

 

  1. eslint-plugin-jsx-a11y 
    • This plugin can be used in a pre-commit hook to ensure basic attributes are not being left out for accessibility
  1. In-browser accessibility testing
    1. React-axe
      • The react-axe tool runs with your React app and outputting warnings and errors about insufficient accessibility to the browser console.
    2. ANDI
      • The ANDI tool serves as a more visual way to inspect the elements in your application for sufficient accessibility descriptions.

Refer to the React screen reader documentation for a list of the screen readers offered in each popular browser.

Looking to make your website more accessible? We can help! Contact us at sales@carimus.com today to learn more.

Interested in reading more from the Carimus team?Here are some related stories

What should go into your media kit

Carimus develops ADA-compliant site for National Resource Network