The Most Common ADA Compliance Issues on Websites

ADA compliance issues for websites: what you need to know

Many organisations find the same accessibility gaps on public websites. This article lists the most common ADA compliance issues for websites, explains why they matter, and gives a practical, prioritised checklist you can use right now.

How ADA and accessibility standards relate to websites

The Americans with Disabilities Act itself does not contain technical standards for websites. Courts and regulators often point to the Web Content Accessibility Guidelines, usually WCAG 2.1 or WCAG 2.2, as the technical benchmark. Commonly used targets are WCAG level A and AA. Other references include Section 508 and WAI-ARIA for dynamic content.

How audits typically fail

• Relying only on automated tools. They catch some issues but miss keyboard, content order, meaning and readability problems.
• Fixing superficial errors while leaving structural problems. For example adding alt attributes that are empty without addressing missing context.
• Confusing ARIA with native semantics. ARIA is for enhancement, not a substitute for proper HTML elements.

Most common accessibility issues on websites

Below are the issues I see repeatedly. Each entry explains the problem, the accessibility impact, and a short mitigation.

1. Missing or poor alternative text for images

Images without useful alt text prevent screen reader users from getting the same information as sighted users. Decorative images should have empty alt attributes. Informative images need concise, descriptive alt text that conveys the image function or content.

2. Keyboard navigation problems

Users who cannot use a mouse rely on the keyboard. Common failures include elements that are not reachable by Tab, custom widgets that do not support arrow keys, and focus that is hidden or hard to see. Test by navigating with Tab and Shift+Tab only.

3. Forms without labels and instructions

Inputs missing visible labels or programmatic labels (label element or aria-label) are confusing. Error messages that are not linked to fields block completion. Ensure label and aria-describedby are used so assistive technology announces the input purpose and errors.

4. Poor colour contrast and reliance on colour alone

Text or interface elements with low contrast are hard to read. Colour must not be the only way information is conveyed. Aim to meet WCAG AA contrast ratios for normal and large text.

5. Lack of captions and transcripts for audio and video

Users who are deaf or hard of hearing need accurate captions. Users who are blind need descriptive audio or transcripts when the visual conveys essential content. Provide synchronized captions and a text transcript for longer media.

6. Inaccessible PDF and document attachments

PDFs and other attachments often lack headings, tagging, or readable text. Provide accessible HTML alternatives or ensure documents are tagged, have logical reading order, and include metadata and alt text for images.

7. Improper use of ARIA and missing semantics

Developers sometimes add ARIA roles that conflict with native elements or use ARIA where native HTML would be better. Use semantic elements first. Add ARIA only when necessary and test with assistive technology.

8. Focus order and visual focus indication

Focus can move in a non-intuitive sequence, especially in custom components or after dynamic updates. Ensure the DOM order reflects reading order and provide a visible focus indicator that meets contrast rules.

9. Dynamic content not exposed to assistive tech

Content loaded or changed by JavaScript needs proper announcements. Use live regions or the correct ARIA attributes so screen readers are informed of updates like validation messages or pop-up content.

10. Inaccessible navigation and headings structure

Pages without clear heading hierarchy, skip links, or consistent navigation make orientation difficult. Use a logical heading structure (h2, then h3), landmark roles, and a skip-to-content link for keyboard users.

11. Language and localisation attributes missing

Without a declared page language, screen readers may use incorrect pronunciation. Set the lang attribute on the html element and change it for sections in a different language.

12. Time limits, CAPTCHA and interactive barriers

Time-limited forms, complex CAPTCHAs and interactive elements without alternatives block people. Provide options like extended time, accessible alternatives to CAPTCHA, and clear instructions for assistive tech users.

Why automated accessibility tests miss key issues

• Tools check markup and contrast but cannot judge meaning or context. For example, a short alt text might pass an automated check but still fail for clarity.
• Keyboard flow, reading order and cognitive accessibility require human review.
• Assistive technology behaviour varies. Manual testing with a screen reader and keyboard is necessary.

Priority fixes: quick table to guide work

Issue	Why it matters	Quick fix
Missing alt text	Blocks understanding of images for screen reader users	Add concise alt or empty alt for decorative images
Keyboard traps	Prevents full site use without a mouse	Ensure all interactive controls receive focus and can be exited
Poor contrast	Reduces readability for many users	Adjust colours to meet WCAG AA contrast ratios
Unlabelled form fields	Stops form completion with assistive tech	Add label elements and aria-describedby for errors

How to run a basic manual accessibility audit

Do this before planning remediation. A one-day check will reveal most critical problems.

1. Automated scan with tools such as axe, WAVE or Lighthouse to find obvious errors.
2. Keyboard test: tab through the page. Look for focus, traps and logical order.
3. Screen reader test: try a typical page with a screen reader (NVDA, VoiceOver or JAWS) and check whether content is understandable.
4. Media check: play videos and confirm captions, transcripts and controls are present.
5. Document check: open PDFs and confirm text can be selected and headings exist.

Common remediation pitfalls

• Applying fixes only to one page template while other templates remain untouched.
• Using ARIA to “fix” missing semantics instead of changing the HTML structure.
• Removing text to improve contrast instead of redesigning components with accessible colour choices.

Decision framework: fix in-house or hire specialists

Choose in-house when you have experienced developers familiar with WCAG and time to test across assistive technologies. Hire specialists when the site is large, when legal risk is present, or when you lack internal accessibility expertise.

When you hire, ask for a remediation plan that includes manual verification, templates, and training for your team so regressions do not reoccur.

Common legal and process mistakes to avoid

• Posting an accessibility statement that claims full conformance without evidence. Statements should be accurate and outline how users can request help.
• Waiting for a complaint before starting fixes. Early, documented remediation reduces risk and helps users sooner.
• Thinking a single test equals compliance. Accessibility is ongoing and must be part of development and content workflows.

Practical next steps (30, 90, 180 day plan)

• 30 days: run automated scans, fix critical issues like broken ARIA, missing labels, and obvious keyboard traps.
• 90 days: complete manual audits for key templates, add captions and transcripts for high-use media, and fix document accessibility.
• 180 days: embed accessibility into design and development workflows, train staff, and set up periodic testing.

Quick manual checks you can run now

• Try tabbing through primary pages and forms only using the keyboard.
• Turn off images in the browser to see if content still makes sense.
• Play a video with captions turned off to check whether the transcript matches visual content.

Where to learn the specifics

Use the official WCAG documents for technical success criteria. Read WAI-ARIA guidance for dynamic content. Refer to Section 508 guidance for US federal requirements. Those sources give the precise tests auditors use.

If you want, I can create a prioritised remediation checklist tailored to specific pages or a short template for a manual audit you can run this week.