For many people, technology serves an important role in improving the quality of their lives as it is used to work, communicate, play, and even navigate the physical world. This is just as true for users with disabilities, which is why it is important that these experiences are designed with accessibility in mind. Technology should be inclusive and accessibility guarantees that it can be enjoyed by as many people as possible.

PLUS QA’s work doing accessibility testing for web and mobile applications helps make this possible so, as part of this year’s Global Accessibility Awareness Day celebration, we decided to reach out to several members of our accessibility team to help answer one question – what are the most common accessibility violations we find when testing an accessibility project?

Here’s what they had to say:

Visibility & Contrast

According to the Web Content Accessibility Guidelines, in order for web content to be compliant as Perceivable, “information and user interface components must be presentable to users in ways they can perceive.”

One of the most common examples of this is when text appears on backgrounds that do not provide enough visual contrast in order for them to be distinguishable. In order for it to pass for contrast, the visual presentation of text and images of text must have a contrast ratio of at least 4.5:1, except for the following:

  • Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1
  • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
  • Logotypes: Text that is part of a logo or brand name has no contrast requirement.

Screenshot of WebAim's color contrast analyzer showing the contrast ratio between #ffffff and #ce4a35 as foreground and background colors, respectively.

 

With the exception of captions and images of text, text content must also be resizable by a user (up to 200 percent) without loss of content or functionality. Many users with low vision take advantage of this feature in order to help them read text content on the web.

 

Content is Unlabeled or Skipped by Screen Readers

For sighted users, it might be easy to navigate and understand the content of a website since there is visual reference for how it is structured and organized but for users of screen readers, they must rely on labels and having useful elements be readable to be able to understand what it is.

According to the Web Content Accessibility Guidelines, in order for web content to be compliant as 2.4: Navigable it must “provide ways to help users navigate, find content, and determine where they are.” This guideline shares a relationship with 1.3.1: Info and Relationships “which ensures that any structure in the content can be perceived.”

If a page component (for example a button or icon with some functionality) is unlabeled, a user of a screen reader might see it as a plain element and be unable to determine its purpose. Developers make use of labels (text or other components with a text alternative that is presented to a user) to help users of screen readers identify a component within Web content.

Users of screen readers also rely on having the content of a web page be presented to them in an order that is consistent with the meaning of the content. When components of a page are skipped by a screen reader, this interferes with the user’s ability to form a consistent mental model of the content and makes the experience of reading the web page confusing.

 

No Text Alternatives for Images or Media

Images and video are some of the most common forms of content that appear on a web page and their use can be helpful for communicating to both sighted, and even non-sighted users, so long as they’re accompanied by what is known as ‘alt-text’.

Text Alternatives (or Alt-Text) are used for any non-text content in order to allow it to be changed to suit the unique needs of a user. This can take many forms such as large print, braille, speech, symbols or simpler language.

All non-text content that is presented to a user should also have a text alternative that serves an equivalent purpose, with some exceptions like if the content is meant to be decorative, serves as visual formatting, or is meant to be invisible to the user. You can read up on more exceptions for using text alternatives here.

When the media content is time-based, such as audio-only, video-only, audio-video or some other combination of audio/video working in tandem, text alternatives can be used to help users be able to understand the content.

One common example of this is video captions which, according to the Web Content Accessibility Guidelines, should be “provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.” These not only benefit deaf and hard of hearing users to be able to understand audio or audio-video content but also users who might either experience a cognitive disability, like ADHD, or a situational disability, like being in an environment where it is difficult to listen to media at an audible volume.

Screenshot of a video from PLUS QA's YouTube channel where captions are visible.

 

Improper Heading Level Markup

Though sighted users may not see it when they browse a web page, users of a screen reader depend on the various HTML heading levels to understand what information is contained and how it is organized. For a lot of web projects, it is common to see headings that are styled as if they follow a heading level order but in the HTML markup, they are not marked as <H1>, <H2>, <H3>, etc.

A tester demonstrating a screen reader active on a web page about Accessibility Testing

 

It is expected that there will be only one unique <H1> tag used per page to (often used to describe what the purpose of that page is) and after that, the other heading levels will be used to describe the contents of that page. Heading levels should not be skipped from the top down (i.e not going from <H2> to <H4> without an <H3> in between.)

While the Web Content Accessibility Guidelines do not explicitly address this topic, they do offer some success criteria that address the use of headings to help users navigate and determine information, structure, and the relationships between web content programmatically such as 2.4.6: Headings and Labels, 3.2.3: Consistent Navigation Level, and 1.3.1: Info and Relationships.

 

Keyboard Operation and Focus Order

Many users with a variety of motor and visual disabilities rely on hardware or software keyboard devices in order to be able navigate the web, so it is important that they have access to the same functionality that users of other input devices do, wherever possible.

A user interacting with a keyboard device on a tabletop.

Keyboard users typically take advantage of the ‘tab’ and ‘shift + tab’ keystrokes to manipulate a ‘focus’ element which will navigate them either forward or backwards through a web page. For sighted users, this looks like a border that outlines the element that is currently ‘focused’ and as they move between various page elements, so too will their navigational position on the web page.

This is also why having a proper focus order is important – a keyboard user’s experience navigating through a web page should mirror the experience of a user with a non-keyboard input, meaning the order in which they receive focus should be logical and intuitive. For any page elements that would not normally be interactive for mouse or touch input, these should be made non-keyboard focusable so that it is not confusing for keyboard-only users.

 

Conclusion

These may just be a few of the most common accessibility violations we identify when conducting our accessibility testing services but there’s so much more to discover. In our more than 16 years of experience, we’ve tested hundreds of accessibility related projects and have filed thousands of accessibility violations for various project types.

If you’d like to learn more about how we can help test your application or website for accessibility, visit our accessibility testing services page or get in touch with us today!

A photo of Jesus's hands touching a pile of LEGO Braille Bricks. He spelled out #accessibility on the gray baseplate.