10 Common Accessibility Mistakes Frontend Developers Make

Accessibility is often an afterthought in frontend development, but it shouldn’t be. Many developers unknowingly introduce barriers for users with disabilities. The good news? Most common accessibility mistakes are easy to fix once you know what to look for. This article covers the top 10 mistakes and how to avoid them.

1. Insufficient Color Contrast

Color contrast is one of the most frequent accessibility issues. Text with low contrast against its background is hard to read, especially for users with low vision or color blindness. The Web Content Accessibility Guidelines (WCAG) require a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text.

To fix this, use a contrast checking tool during design. Avoid light gray text on white backgrounds. Stick to dark text on light backgrounds or vice versa. If you use brand colors, verify they meet the ratio. Tools like the WebAIM Contrast Checker can help you test combinations.

A common mistake is relying on color alone to convey information, like indicating required fields with only red text. Always supplement color with icons, patterns, or text labels. When designing, consider users with color blindness by checking your palette in a simulator. Also, ensure that hover and focus states maintain sufficient contrast — a subtle change may not be noticeable enough.

2. Missing Form Labels

Forms without proper labels are a nightmare for screen reader users. Never rely solely on placeholder text as a label. Placeholders disappear when users start typing, and they often have insufficient contrast.

Every input should have an explicit <label> element with a for attribute matching the input’s id. Alternatively, you can use aria-label or aria-labelledby. Group related checkboxes and radio buttons with a <fieldset> and <legend>. For example:

<label for="email">Email Address</label>
<input type="email" id="email" name="email">

If you cannot use a visible label for design reasons, still provide an accessible label with aria-label. But remember, visible labels help all users, not just those using screen readers. Also, ensure that error messages are associated with inputs using aria-describedby, so screen readers announce them.

3. Non-Semantic HTML

Using <div> and <span> for everything is common but harmful. These elements provide no semantic meaning to assistive technologies. Instead, use native HTML elements that carry built-in roles and behaviors.

• Use <nav> for navigation
• Use <main> for primary content
• Use <button> for clickable actions
• Use <heading> elements (h1-h6) for headings

Semantic HTML is the foundation of accessible web development. It reduces the need for ARIA and makes your code more maintainable. For more on optimizing your frontend, check out React vs Next.js: Choosing the Right Framework for Your Project.

A common misstep is using a <div> with an onclick for a button. While you can add ARIA roles and keyboard listeners, a native <button> is easier and more reliable. Similarly, using <h1> for branding instead of the page title misleads screen reader users. Ensure your heading hierarchy is logical and each page has exactly one <h1> that describes the page content.

4. Poor Keyboard Navigation

Not all users can use a mouse. Some rely on keyboard navigation. Common mistakes include missing focus indicators, incorrect tab order, and interactive elements that are not keyboard accessible.

Always provide a visible focus outline (never use outline: none without a replacement). Ensure the tab order follows the visual order of the page. All interactive elements like links, buttons, and form controls should be reachable and operable via keyboard. Test your site by tabbing through every element.

Also, avoid setting tabindex greater than 0, as it disrupts the natural focus order. Instead, organize your DOM flow to match visual order. For custom components like dropdowns or modals, trap focus within the modal when open and return focus to the trigger element on close. Use JavaScript to manage focus, but test thoroughly.

5. Images Without Alt Text

If an image has no alt text, screen readers may read the file name, which is useless. Informative images need descriptive alt text. Decorative images should have alt="" (empty alt) to be ignored by assistive technology.

Write alt text that conveys the purpose of the image. For example, “A dog playing fetch in a park” is good for a photo of a dog. Don’t say “Image of a dog” — that’s redundant. Avoid keyword stuffing. If the image is a link, describe the destination. For complex images like charts, provide a text alternative nearby.

A common mistake is writing overly long alt text. Keep it concise but informative. For SVG icons used as buttons, give them role="img" and aria-label. For background images in CSS, ensure the content is decorative, or include equivalent text in the HTML.

6. Improper Use of ARIA

ARIA (Accessible Rich Internet Applications) can enhance accessibility, but misuse can make things worse. A common mistake is adding role="button" to a <div> without adding keyboard support. Another is overusing ARIA attributes where native HTML would suffice.

Follow the first rule of ARIA: don’t use ARIA if you can use a native HTML element. When you do use ARIA, test with a screen reader. Use roles, states, and properties correctly. For example, aria-expanded should reflect the actual state of a toggle.

Another pitfall is using tabindex="-1" on non-interactive elements just to make them focusable via script. This can confuse users if not managed carefully. Only make elements focusable if they are interactive. Similarly, avoid using aria-hidden="true" on focusable elements, as it hides them from screen readers but not from keyboard focus.

7. Not Providing Sufficient Focus Indicators

Some developers remove focus outlines for aesthetic reasons, leaving keyboard users lost. A strong, visible focus indicator is essential. You can style it with :focus-visible to show it only when needed (e.g., keyboard navigation).

Aim for a 2px solid outline with a color that contrasts well with the background. Do not rely solely on changes in background color, as that may not be noticeable.

For custom components like tabs or menus, ensure focus indicators are visible on all states. If you use a box-shadow for focus, ensure it has sufficient contrast and is not clipped. Test your focus styles in high contrast mode on Windows, as some themes override outlines.

8. Inaccessible Dynamic Content

Single-page applications often update content without page reloads, which can confuse screen readers. When content changes dynamically (e.g., loading more items, updating a cart), you need to inform assistive technologies.

Use aria-live regions to announce changes. Choose the right politeness setting: aria-live="polite" for non-critical updates, aria-live="assertive" for urgent ones. For example, when a user adds an item to a cart, announce “Item added to cart” via a live region. Also, move focus to newly added content when appropriate.

A common mistake is using aria-live on the entire container that gets updated, which may read too much content. Instead, target a small region or use a dedicated live region for announcements. For infinite scroll, provide an accessible way to load more content, like a “Load more” button, and announce the number of new items.

9. Missing Captions and Transcripts for Media

Videos need captions for deaf and hard-of-hearing users. Audio content needs transcripts. This is not just a good practice — it’s required by WCAG at level A.

Provide synchronized captions for videos. For audio podcasts, include a text transcript. Transcripts also benefit SEO and users who prefer reading. Tools like automatic captioning can generate a starting point, but always review for accuracy.

For live media, strive for real-time captions. If that is not feasible, provide a summary or alternative. Also, ensure that video players themselves are accessible — controls should be keyboard operable and labeled with ARIA.

10. Not Testing with Real Users or Tools

Many developers rely only on automated checkers, but automation catches only about 30% of accessibility issues. Manual testing and real user feedback are essential.

Use a combination of tools like axe, Lighthouse, and WAVE for automated checks. Then do manual keyboard testing and test with a screen reader (VoiceOver on Mac, NVDA on Windows). Involve users with disabilities in usability testing if possible. For more on improving site performance alongside accessibility, see Lazy Loading for Better Web Performance.

11. Misusing Heading Hierarchy

Headings are the backbone of page navigation for screen reader users. A common mistake is skipping heading levels, like jumping from an h2 to an h4, or using headings purely for visual styling. This breaks the logical structure and confuses users.

Always maintain a logical heading hierarchy: h1 for the page title, h2 for main sections, h3 for subsections, and so on. Never skip levels — if you need a smaller visual size, use CSS instead of a lower heading level. Use browser extensions like the HeadingsMap tool to verify your structure.

12. Ignoring Motion and Time-Based Interactions

Animations, auto-playing videos, and time limits can be problematic for users with vestibular disorders, ADHD, or cognitive disabilities. A common mistake is not providing controls to pause, stop, or hide moving content.

Offer a way to reduce motion for users who prefer it, using the prefers-reduced-motion media query. For auto-playing videos, include a pause button prominently. For time limits, allow users to extend or disable them. If you use scrolling text or carousels, provide play/pause controls and avoid infinite auto-scroll.

How to Get Started with Fixing Accessibility

Start by auditing your existing site. Run an automated scan, fix critical issues like contrast and form labels, then test manually. Accessibility is an ongoing process, not a one-time fix.

Educate your team on a11y best practices. Add accessibility checks to your CI pipeline. Make it part of your definition of done. Small changes add up to a much better experience for everyone.

For more on performance and accessibility, read How to Improve Web Performance with Lazy Loading.

Frequently asked questions

What is the most common accessibility mistake?

Insufficient color contrast is one of the most common mistakes. Low-contrast text is hard to read for many users. Always ensure text meets WCAG AA contrast ratios of at least 4.5:1 for normal text and 3:1 for large text.

How can I test my site for accessibility?

Use automated tools like axe or Lighthouse for initial checks. Then manually test with keyboard navigation and a screen reader (e.g., VoiceOver on Mac, NVDA on Windows). Involve users with disabilities for the most thorough evaluation.

Do I need to add ARIA to every element?

No. Use native HTML elements first, as they have built-in semantics. ARIA should only augment HTML when native elements cannot provide the needed accessibility. Overusing ARIA can actually harm accessibility.

What should I put in alt text?

Alt text should describe the purpose or content of the image. For informative images, be concise but descriptive. For decorative images, use empty alt (alt=””). Avoid phrases like ‘image of’ and never stuff keywords.

Can accessibility improvements also help SEO?

Yes, many accessibility practices like semantic HTML, descriptive alt text, and good color contrast also benefit SEO. Search engines favor well-structured, readable content. Accessibility and SEO often go hand in hand.