In 2024, Intopia’s consultants audited almost 200 websites, spanning not-for-profits to Fortune 500s. This included static sites to complex web applications across a range of sectors such as government, finance, health and tech. Across them all, we’ve collated the top 5 web accessibility issues that kept showing up again and again.
These issues aren’t just technical bugs. They’re real barriers for users who rely on screen readers, keyboard navigation or visual contrast to access information. The good news? They’re all fixable.
Here are the top 5 web accessibility issues we found in 2024. We’ll cover why they matter, how to find them, and how to fix them.
#5 – Text that looks like a heading but isn’t properly marked up
A majority of surveyed screen reader users rely on headings to navigate web pages. Sighted users often scan the headings on a page to understand the content and decide where to focus their attention. They rely on visual cues, like large or bold text, to tell headings apart from the rest of the text.
But when text is styled to look like a heading without the proper heading markup (<h1> – <h6>), screen reader users can’t scan the page with the same ease.
Find it:
Browser extensions can help identify heading problems:
- Accessibility Insights for Web identifies all the headings on your page, helping you find content that looks like a heading but doesn’t use heading markup.
- HeadingsMap lets you see the heading structure at a glance and make sure it matches the structure of your content.
Fix it:
Always use heading markup (<h1> – <h6>) for headings. Learn more about headings from the W3C’s Headings tutorial.
#4 – Keyboard focus isn’t managed properly
Many people rely on a keyboard instead of a mouse to navigate websites. Usually, the order in which interactive elements receive keyboard focus is matched by the visual reading order on a page: left to right and top to bottom. But sometimes keyboard focus needs to be managed with scripting, so focus moves where the user needs it to be.
Modal dialogs are the most common source of focus management problems. When a user opens a modal dialog, focus should move into that dialog. When they close it, focus should move back to a logical place on the page. Without proper focus management, keyboard users may have to tab through irrelevant content or may not be able to reach the content they want to interact with.
Find it:
Test keyboard interactions whenever you’re testing mouse interactions. The W3C’s Easy Checks – A First Review of Web Accessibility has instructions to get you started.
Fix it:
Make sure focus is managed properly when new content (like a modal or dropdown) appears and return focus to a logical spot on the page when that content is dismissed. Check the ARIA Authoring Practices Guide for recommendations on focus management for many common custom components, including modal dialogs.
#3 – Interactive elements that aren’t keyboard accessible
All interactive elements (like buttons, links, and form inputs) need to be accessible with a keyboard alone. If an element only works with a mouse, it’s inaccessible to many users.
Find it:
Make keyboard testing a part of your definition of done to catch these issues. Use the Tab key to move from one interactive element to the next and the Enter, Space bar, and arrow keys to interact.
Fix it:
Stop keyboard bugs before they start by using native HTML elements wherever possible. A native HTML <button> is accessible by default, but a <div> that’s being made into a button isn’t.
When it’s not possible to use a native HTML element, developers need to do some extra work to make an element keyboard accessible:
- Make sure the element is focusable by adding tabindex=”0″.
- Use keyboard-specific event listeners along with any mouse or touch event listeners (See Using both keyboard and other device-specific functions for details).
- For more complex components, follow established keyboard interaction patterns, so keyboard users know what to expect.
Note: these recommendations only relate to keyboard interactivity. All custom interactive elements also require a role.
#2 – Graphical elements with low colour contrast
Non-text elements (like icons, charts, and input borders) need to be clearly visible against their background. Low colour contrast makes an element hard to see for everyone, especially people with low vision.
Find it:
Unfortunately, automated accessibility tools often miss contrast issues with graphical elements.
Instead, visually inspect your page, looking for all the graphical elements that convey information to the user.
Look for things like:
- Icon buttons
- Arrow icons on expandable content
- Borders on text inputs
- Charts and other data visualizations
Use a colour contrast tool like the WebAIM Contrast Checker to compare the colour of the element and the colour that surrounds it.
Fix it:
Catch contrast issues before they start by testing for colour contrast at the design stage. Make sure graphical elements have at least a 3:1 contrast ratio against their background. Once you’ve found a contrast issue, choose new colours with the help of a tool like the Tanaguru Contrast Finder.
#1 – Text with low colour contrast
The #1 issue identified in our audits in 2024 was text that didn’t provide enough colour contrast against its background. For people with low vision, low colour contrast can make it hard or impossible to read your text.
Find it:
Use an automated accessibility checker like the Accessibility Insights for Web Chrome extension.
Fix it:
Stop contrast issues before they start by testing colour contrast at the design stage. Make sure text has a 4.5:1 contrast ratio against its background. Remember to check contrast for hover and focus states as well. Use a tool like the Tanaguru Contrast Finder to help you find the colours that will be to see.
Takeaways
A few good habits can prevent these top 5 web accessibility issues from ever making it to production:
- Use proper heading markup that reflects the structure of your content
- Test colour contrast early in the design process
- Test for keyboard accessibility during development
- Use native HTML elements when possible
Want to prevent these top 5 web accessibility issues in your next project?
- Explore our Intopia Learn courses
- Book an accessibility audit
- Or chat to us about embedding an expert in your team