Web accessibility isn’t just about aesthetics (though design certainly plays an important role). As a developer, you have a responsibility to think about users with disabilities — and by considering those users, you can build much better websites, apps, and other digital products.
To start building an accessible mindset, it’s helpful to learn about some of the common mistakes that create barriers for people with disabilities. Here’s an overview of four common errors (and what to do instead).
1. Overusing <div> and <span>
The <div> and <span> elements are frequently used to control the visual presentation of content. They’re generic elements: They group HTML together, but they are not semantic identifiers.
Of course, generic HTML elements can be quite useful, and when used correctly, they’re not bad for accessibility. The problem occurs when you use <div> or <span> for content that has an associated semantic HTML element.
For example, if you’re surrounding standard hyperlinks or images in <div> and <span>, you’re probably overusing those tools. That could prevent assistive technologies (such as screen readers) from presenting your content to users.
The Web Content Accessibility Guidelines (WCAG) are the international standards for digital accessibility. Eight WCAG criteria require content to have “programmatically determinable" names, roles, and relationships. A clear semantic structure makes content “programmatically determinable” and ensures that assistive tech works well with your website or mobile app.
When in doubt, try to use plain old semantic HTML. If you must use <div> or <span>, make sure you’re using WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) where appropriate.
For additional guidance, read: Accessibility Tips: Using the DIV and SPAN Elements.
2. Failing to build responsive content
In 2024, responsive design is the standard. Nevertheless, developers sometimes hold misconceptions about what “responsive" really means. If your website’s functionality changes significantly when the viewport is resized — for example, if buttons disappear or navigation becomes more difficult — that’s a problem.
WCAG requires that content reflows, which essentially means that it must be responsive. It must be able to be presented on different types of screens without loss of information or functionality, and without requiring scrolling in two dimensions. Following that guideline helps to ensure that content works for a wide range of people, including those who use their browsers to magnify content.
For a quick accessibility test, try zooming your website by 200% or more. Ask questions: Does everything still work? Do you need to scroll horizontally to read all of the text? Do images retain their orientation, and do other elements appear in a way that makes sense?
For additional guidance, read: Give Yourself an Accessibility Test: Zoom Your Page to 200%.
3. Failing to support keyboard accessibility
Many people use a keyboard alone (with no mouse) to browse the internet. If your website isn’t fully operable with a keyboard alone, that’s a problem — and if you don’t test for keyboard accessibility, you’re asking for trouble.
In severe cases, web content can prevent keyboard users from controlling their devices. Issues with JavaScript and third-party plugins can cause keyboard traps, which are exactly what they sound like: The user gets stuck on a focusable element and cannot use standard keyboard commands to regain control.
You can perform basic keyboard accessibility tests by using shortcuts and hotkeys to navigate your website. Pay special attention to forms, JavaScript menus, and other interactive elements.
For additional guidance, read: Give Yourself an Accessibility Test: Don't Use a Mouse.
4. Overusing WAI-ARIA
WAI-ARIA (or ARIA, for short) provides crucial semantic information for screen readers and other assistive tech, and when used thoughtfully, it’s an important tool for accessibility.
But ARIA is not intended as a replacement for semantic HTML. It’s not as widely supported, and assistive tools may interpret ARIA markup in very different ways. That’s why the first rule of ARIA is so important: Wherever possible, use semantic HTML instead.
If you do use ARIA markup, you’ll need to test your markup to ensure that it works predictably for assistive technology users. We strongly recommend working with an accessibility partner when utilizing ARIA, particularly if your website has a lot of dynamic content.
For additional guidance, read: Introduction to ARIA for Web Accessibility.
Start thinking about accessibility from the first stages of development
Digital accessibility is much easier when it’s a consistent priority. Developers can avoid lengthy remediation processes — and a hefty technical debt — by thinking about users with disabilities from day one.
That means building user experience (UX) personas with disabilities, testing new content against WCAG, and publishing an accessibility statement that outlines your commitment to your users.
If you’re building a strategy for long-term digital compliance, the Bureau of Internet Accessibility is ready to help. We provide a range of services including expert-led audits, 24/7 accessibility support, and onsite and self-paced training courses.
To get started, schedule a free consultation or test your website with a free WCAG accessibility analysis.
