Top 8
Minor Accessibility Issues

Whether native HTML or a custom widget, user input elements need to play the right roles in order to make their meaning clear to screen reader users when they are focused on and landed on. If a custom widget, the element’s function must be correctly exposed by using appropriate ARIA role values rather than abstract roles.

When button and link text in an alt property value repeats, screen reader users hear the same information twice, rendering the alt text worthless and confusing.

WAI-ARIA role attribute values must be correct. This means that values must be written correctly, correlate to existing ARIArole values, and not be abstract roles in order to properly display the element’s purpose.

It is a best practice to make sure each heading element, denoted by the tags <h1> through <h6>, contains text.

Users of screen readers are informed when a heading tag is present. Users may become confused or even unable to access information on the page’s structure if the headline is blank or the text cannot be accessible.

The user-scalable="no" parameter in the <meta name="viewport"> element must not be used since it prevents text scaling and zooming, which are necessary for individuals with impaired vision.

Checks to make sure elements selected for removal from the accessibility tree are really deleted.

The text in table header components should be visible. Make sure screen reader users can access the table header. It is preferable to mark up an element with a td if it is not a header.

Markup for data tables can be tedious and complex. Make sure the summary table’s properties and the caption don’t match. There are several capabilities in screen readers that help with table navigation, but for these features to function properly, the tables must be accurately marked up.