Team Intopia are wrapping up for the year and we’ve been reflecting on the year that has been. As the world becomes more aware of the importance of inclusive design and digital accessibility, we notice interesting trends in our audits year after year. We wanted to share some of our findings so that teams who are thinking about accessibility can check for these issues – and hopefully fix them!

At Intopia, we conduct audits a little differently. In our audits, we do more than just assess WCAG (Web Content Accessibility Guidelines) 2.1 conformance. Our design, development, accessibility and assistive technology specialists also check for usability and functional issues that will create an inaccessible user experience, but are not technically “WCAG failures”.

In this article, we list the top 5 WCAG-related failures and how to test for them (note that most of these issues cannot be found using automated testing tools). We then talk about why it matters, as well as how to fix them. If you’re interested in a more comprehensive checklist for accessibility, please also check out the Accessibility Not-Checklist!

If you find this article useful, please sign up to our newsletter, or follow us on LinkedIn or Twitter. We plan to share more practical tips throughout 2023 to help teams build more inclusive products. If you’d like to know more about Intopia’s accessibility testing service, please contact our friendly customer engagement team!

Top 5 critical WCAG 2.1 failures

Before we jump into the list, let’s talk about what we mean by “critical”. We categorise our accessibility issues by severity, and these are:

  • Critical – a critical issue that will stop a user from accessing content or completing a task.
  • High – a high-priority issue that is likely to cause serious problems or major inconvenience to users.
  • Moderate – a medium-priority issue that is likely to cause problems or frustrations for users.
  • Low – a low-priority issue that is likely to be an inconvenience or irritation to users.

Our top 5 failures are ordered by the percentage of audits with critical issues for that success criteria. If we included issues of all severities, the top 5 WCAG 2.1 failures below, appear in at least 85% of all audits.

1. Not accessible with a keyboard (critical failures in 61% of audits)

Related criteria: Success Criterion 2.1.1 Keyboard (Level A)

The most common critical issue we found is that interactive elements (for example buttons, links, or anything that could be activated with a mouse click) were missing keyboard behaviour. In other words, you couldn’t tab to it with a keyboard, and/or you couldn’t interact with the element using Enter, Spacebar or, in some cases, Arrow Keys. Most often the keyboard behaviour was missing due to developers not using native <button> or <a> elements which have keyboard behaviour built in by default, and using <span> or <div> instead (often because they are much easier to style with CSS).

Why it matters

Some users can only interact with their devices using a keyboard or similar input device (such as a switch control). On top of that, most screen reader users are also keyboard-only users.

How to test

For web browsers on laptops or personal computers, use only the Tab key (and occasionally arrow keys) to navigate between interactive elements. Make sure the element can be actioned by pressing Enter (and also the Spacebar, in the case of buttons).

Testing is easier if there is a visible focus outline styling on focused elements. This is often missing (see 2.4.7 Focus Visible (AA) critical failures at number 3 on this list) so you may need to add a focus outline first.

For smartphones or tablet devices, connect a Bluetooth keyboard to navigate the device and test in a similar fashion.

How to fix

When possible, use native interactive elements like <a>, <button> and <select> as they come with keyboard accessibility by default.

If you must build a custom element, like a <span> for example, you will need to add:

  • tabindex="0" to be able to focus on the element using the Tab key
  • the appropriate ARIA role, role="button" for example, so that screen readers know what type of interactive element it is
  • JavaScript onclick and onkeyup events to make sure that click, touch, Enter, and Spacebar are all handled correctly.

2. Content or functionality is lost when the viewport is 320px wide (critical failures in 17% of audits)

Related criteria: Success Criterion 1.4.10 Reflow (Level AA)

320px might not seem like a lot of space to work with. However, it’s the equivalent of someone with low vision using 400% zoom on their regular laptop or tablet device, or a smaller smartphone.

Why it matters

Users with low vision, the elderly, or people with dyslexia may need to zoom the page in order to use the site.

How to test

Ensure content can be resized to 400% when the viewport is set to 1280 x 1024px without any loss of content or functionality.

How to fix

Review the CSS for the positioning and size of elements that do not fit in the viewport. Declare content container dimensions in relative units (such as ems or rems) so they can stretch and scale along with changes to the layout. Use appropriate CSS media queries to support smaller screen widths and heights.

3. Interactive elements (button, link, input, etc) have no visual indicator when focused (critical failures in 15% of audits)

Related criteria: Success Criterion 2.4.7 Focus Visible (Level AA)

All native interactive elements have a default focus outline as it is a default browser style. Focus outlines go missing for several reasons:

  • developers use a “CSS reset” that removes default browser focus styles with something like outline: none;
  • designers don’t supply focus styles as part of their designs, so developers forget to add them in
  • developers forget to add focus styling to custom interactive elements (for example <span role="button" tabindex="0">).

Why it matters

Without a visible focus indicator, sighted keyboard users cannot tell which user interface (UI) component (e.g. link, button, form field) has keyboard focus.

This may mean sighted keyboard users do not know when interactive elements are in focus. So they cannot engage with them – such as triggering a button.

How to fix

Ensure that there is a clearly visible focus indicator such as an outline or a highlight, for all keyboard-operable UI components. We also recommend providing additional focus indicators for form fields.

Custom focus indicators must have a minimum contrast ratio of 3:1 against the background. Consider designing custom focus indicators down to the component level – one indicator may work in one place but not the other.

Related criteria: Success Criterion 1.3.1 Info and Relationships (Level A)

1.3.1 Info and Relationships failures were the most common accessibility issues. They were found in 93% of audits and made up 14% of all accessibility issues in 2022.

Make sure content read by a screen reader or other assistive technology has the same meaning as what is presented visually.

The most common mistakes that led to critical accessibility issues were:

  • Using only CSS to style <span>s, <div>s, or <p>s to look like headings.
  • Form inputs not programmatically linked to labels.
  • Related checkboxes are not grouped programmatically.
  • Error messages are not linked to their related inputs programmatically.
  • Tables are not marked up correctly.

Why it matters

To achieve an equal user experience for all, developers must understand how to build UI components using semantic HTML. The HTML must combine with the correct ARIA attributes in order to convey the same information programmatically, not just visually.

An example is using CSS to style “headings” to be different font sizes. This conveys heading structure to sighted users while using <h1> to <h6> conveys the same information programmatically to screen reader users.

How to fix

“1.3.1 Info and Relationships” failures are our broadest and most varied category, which is probably why they make up most of the issues we find in our audits.

We recommend developers and designers look at how and when to use semantic HTML and native elements. These are better than just using the div and span elements. We also recommend developers and designers look at testing with a keyboard or a screen reader.

For screen-reader-friendly tables, we recommend W3C’s Tables Tutorial.

5. A component’s name, role, state or values are not conveyed to assistive technology (critical failures in 9% of audits)

Related criteria: Success Criterion 4.1.2 Name, Role, Value (Level A)

All UI components must visually and programmatically communicate their name, their role, their value, and their current state. For example, an accordion header must communicate its accessible name (the text in the header), its role (a button) and its current state (whether it’s expanded or collapsed).

These are usually done visually, but not programmatically. Native interactive elements have a role, and state or value by default. For example, a checkbox has a role of “checkbox” and a value of “checked” or “not checked”, without requiring any extra attributes or programming. When a developer creates a custom UI component (like using a span for a button), or a complex UI component (like a dropdown menu), they need to add extra attributes to make it accessible.

The most common mistakes that led to critical accessibility issues were:

  • Buttons that do not have an accessible name, in other words, the buttons contain images with no text description or aria-label.
  • A <div> or <span> has been styled to look like a button with an onclick behaviour but is missing tabindex="0" to make it keyboard accessible. It is also missing role="button" to tell screen readers that this is a button. In most cases, developers should use a <button> element.
  • A tooltip programmed using <span> that trigger only on mouse-hover. These are inaccessible to keyboard and screen reader users, and sometimes do not even work with touch.
  • Complex components, such as date pickers, often have compounding accessibility issues. They are usually not keyboard accessible, and many sub-components require a name, role and value to allow a screen reader user to use them effectively. Other problematic components include accordions, combo boxes, autosuggests, tab navigation and hamburger menus.

Why it matters

If a UI element does not have an appropriate name or role, screen reader users will not know how to interact with it. If an element changes state visually and the change is not conveyed programmatically, screen reader users will not know that something has happened.

How to fix it

It’s difficult to know what the correct name, role, or value attributes are to add to an HTML element if you haven’t seen it before. We recommend checking out the W3C’s ARIA Authoring Practices Guide (APG). We have included below some accessible patterns to follow for the complex components mentioned in this section.

Bonus: Tab or focus order does not follow logical visual order (8.7% of all accessibility issues)

Related criteria: Success Criterion 2.4.3 Focus Order (Level A)

Most applications we test generally follow a logical focus order for all on-screen interactive elements however, things get tricker when there are hidden page elements!

The most common mistakes that led to critical accessibility issues were:

  • Visually hidden elements can still be navigated via keyboard, and screen reader.
  • Focus is not managed when a modal is opened or dismissed.
  • Items within combo boxes, popups, or menus do not receive focus when opened. So are not navigable using a keyboard or screen reader.

Why it matters

Mobile-first and increasingly feature-rich applications mean we need to hide away elements inside hamburger menus, dropdowns, modals, and more. We often find these elements are only hidden away visually, but not programmatically. Meaning that screen reader users and keyboard users can access hidden elements when we might not want them to!

Worse still, when we toggle things open and closed (like a modal), developers often don’t manage the focus. Our keyboard and screen reader users are left behind on the toggle, when we could have sent them to the newly-revealed content.

How to fix it

Hide invisible elements using aria-hidden or display:none in CSS. This will make sure no one can access them. Developers, check out Inclusively Hidden | CSS-Tricks for an in-depth guide to inclusively hiding UI elements.

Focus management is a little harder. You cannot create an accessible show/hide component without adding some extra JavaScript to manage focus. Here are some great examples that you can use as a reference from the ARIA Authoring Practices Guide (APG).

That’s a wrap!

In 2022, the most critical accessibility issues were: keyboard accessibility, supporting smaller viewports/zoom, using semantic markup and ARIA attributes correctly, and managing focus visually and programmatically. Our team uses the latest automated accessibility checking software to support our auditing work and help us find many accessibility problems, however, almost critical issues listed here are not able to be found with automated checking tools. In 2023, we hope teams prioritise keyboard-only testing, screen reader testing, and considering zoom and focus management while creating UI designs (like using accessibility annotations in Figma).

Wishing everyone a safe and merry holidays!

If you found this article useful, please sign up to our newsletter, or follow us on LinkedIn or Twitter. We plan to share more practical tips throughout 2023 to help teams build more inclusive products. If you’re interested in a more comprehensive checklist for accessibility, please also check out the Accessibility Not-Checklist! If you’d like to know more about Intopia’s accessibility testing service, please contact our friendly customer engagement team!