Website Accessibility Best Practices and Standards

What is accessibility?

Accessibility means nobody is disadvantaged when trying to use your site. For our purposes, the focus is users with disabilities — vision, hearing, cognitive, motor, speech, or neurological. Roughly 1 in 4 US adults (~27%, per the CDC) lives with some form of disability. A site that doesn’t work for them is a site that excludes a quarter of its potential audience.

Accessibility is required by law in most developed markets:

• The Americans with Disabilities Act (ADA), particularly Title III for public-facing business websites and Title II for state/local government. Courts have largely interpreted Title III to cover commercial websites; Domino’s v. Robles (Supreme Court cert. denied 2019) is leading precedent.
• DOJ’s April 2024 Title II Final Rule, requiring state and local government websites to conform to WCAG 2.1 AA by April 2027 (populations ≥50,000) or April 2028 (smaller entities). The original deadlines (April 2026 / April 2027) were extended by twelve months under the DOJ’s Interim Final Rule published April 20, 2026.
• The European Accessibility Act (EAA), enforced since June 28, 2025, which requires private-sector compliance across EU member states for e-commerce, banking, e-books, communications, and other covered services.
• Section 508 for US federal agencies (WCAG 2.0 AA since the 2017/2018 refresh), AODA in Ontario, Canada’s Accessible Canada Act, Germany’s BFSG, and parallel national laws in the UK, Australia, Israel, and dozens of other jurisdictions.

Beyond legal requirements, accessibility benefits users without disabilities too. Captions help in noisy environments. Keyboard navigation helps power users. High contrast helps everyone reading a screen in sunlight. Clear writing helps non-native speakers. Good accessibility is good usability.

See our US web accessibility laws and international accessibility laws guides for deeper legal context.

Universal design

Universal design is the principle of creating products usable by the widest possible audience without adaptation or specialized design. Applied to the web, it means designing so that vision, hearing, motor, and cognitive variations are all accounted for from the start — not bolted on as an accessibility layer after launch.

A universally-designed website is:

• Respectful of diverse needs — flexible, adaptable, and accommodating of different interaction styles and preferences.
• Accessible across platforms — works on mobile, desktop, tablet, and assistive technologies like screen readers, switch devices, and voice control.
• Cost-effective from the start — accessibility is dramatically cheaper to build in during design than to retrofit after launch. Remediation typically costs 5-10x upfront implementation.
• Enhancing for everyone — the same features that support users with disabilities (captions, keyboard shortcuts, clear structure) improve the experience for users without disabilities.

The seven principles of universal design (from NC State’s Center for Universal Design): equitable use, flexibility, simple and intuitive use, perceptible information, tolerance for error, low physical effort, and size and space for approach and use. Each has specific web-design implications.

Perceptual design and cognitive accessibility

Visual design grounded in perceptual principles benefits users with cognitive disabilities as much as anyone else. The Gestalt principles of perception — proximity, similarity, continuity, closure, figure-ground — guide clear visual hierarchy. Applied to accessibility:

• Proximity — related items grouped close together; unrelated items separated. Form labels adjacent to their inputs, error messages near the fields they describe.
• Similarity — elements that perform the same function should look alike. Consistent button styling across the site reduces cognitive load.
• Figure-ground — foreground content must be distinguishable from background. This is the perceptual basis of WCAG’s contrast requirements.
• Consistency — WCAG 2.2 added 3.2.6 Consistent Help requiring help mechanisms to be in the same relative order across pages. Repeated components should behave consistently site-wide.

Technical accessibility standards

The practical accessibility standards below map to specific WCAG 2.2 success criteria. The current standard is WCAG 2.2 Level AA (published October 5, 2023), which is backward-compatible with 2.1 and adds nine new success criteria. For most compliance regimes, Level AA is the target.

Alternative text for images

Every meaningful image needs descriptive alt text (WCAG 1.1.1 Non-text Content). Rules:

• Content images — describe what the image conveys, not what it looks like. “Woman explaining chart to team” is better than “photo of people.”
• Decorative images (backgrounds, dividers, purely presentational) — use empty alt: alt="". Screen readers skip them entirely, which is correct.
• Functional images (icons inside buttons/links) — alt describes the function. A magnifying-glass icon inside a search button should be alt="Search", not alt="magnifying glass icon".
• Complex images (charts, infographics) — provide a short alt text for the image, plus a longer description in surrounding text or via longdesc/link.
• Text in images — avoid. Text should be HTML, not pixels. If you must use text in an image, alt text must exactly match the visible text.

Proper document structure

Use semantic HTML headings (H1-H6) in logical hierarchy (WCAG 1.3.1 Info and Relationships, 2.4.6 Headings and Labels):

• Exactly one H1 per page, describing the page’s primary purpose.
• H2s for main sections, H3s for sub-sections, etc. — don’t skip levels.
• Use headings to describe content, not for visual styling. If you want a large, bold block that isn’t a section heading, style it with CSS, not a heading tag.
• Use semantic landmarks — <nav>, <main>, <header>, <footer>, <aside>, <article>, <section> — so screen readers can navigate directly to regions.
• Reading order in the DOM should match visual reading order. CSS can’t rearrange logical sequence for screen readers.

Tables

Use tables only for genuine tabular data. For layout, use CSS Grid or Flexbox.

• Mark column and row headers with <th> and scope="col"/scope="row".
• Provide a caption via <caption> so screen readers announce the table’s purpose when landing in it.
• For complex tables with merged cells or multi-level headers, use headers attributes on cells to explicitly associate them with their header cells.
• Avoid nested tables — they are extremely hard to navigate with a screen reader.

Accessible forms

Forms are often the most critical accessibility surface — they gate purchases, registrations, applications, support requests. Requirements:

• Every input has a programmatic label — <label for="...">, or aria-label/aria-labelledby when a visible label isn’t appropriate. Placeholder text alone isn’t enough; placeholders disappear when typing starts.
• Required fields are announced — aria-required="true" or HTML required attribute, plus visible indication.
• Errors are announced programmatically with aria-describedby pointing at the error message, and the error text explains how to fix the problem.
• WCAG 2.2 adds 3.3.7 Redundant Entry — information previously entered by the user in the same session must not require re-entry (auto-fill or carry-forward).
• WCAG 2.2 adds 3.3.8 Accessible Authentication — login must not require a cognitive test that cannot be passed by assistive technology (no unassisted CAPTCHA-solving, no forced memorization). Support password managers, biometric, or other alternative authentication.
• Timeouts must be announced and extendable (WCAG 2.2.1 Timing Adjustable). Don’t log users out silently during form completion.

iFrames

Every iframe needs a title attribute describing its content (WCAG 4.1.2 Name, Role, Value). A screen reader will announce “Frame: Site search” for <iframe title="Site search">; an iframe without a title is announced as just “frame” with no context. For third-party embeds (maps, videos, social widgets), confirm the embedded content itself meets accessibility standards — an accessible page surrounding an inaccessible embed is still partially inaccessible.

Links

Link text should describe the destination independently of surrounding context (WCAG 2.4.4 Link Purpose):

• “Read our accessibility policy” beats “click here” — screen reader users often navigate by list of all links, so each link’s text needs to stand on its own.
• Multiple “Read more” links on a page all pointing to different articles is a common accessibility failure. Either change the visible text per link, or add aria-label/visually-hidden text describing each destination.
• Distinguish links from non-link text visually (underline, color, or both). Color alone doesn’t meet WCAG 1.4.1 Use of Color.
• Announce when a link opens in a new tab — include “(opens in new tab)” in the accessible name, so users aren’t surprised when focus jumps elsewhere.

Captions and transcripts for media

Video and audio content must be accessible to users who can’t hear or see it (WCAG 1.2.x):

• Captions for all pre-recorded video with audio. Synchronized, accurate, and include speaker identification when relevant. Auto-generated captions are a starting point but usually need human correction for accuracy.
• Audio descriptions for pre-recorded video where visual content conveys meaning not in the audio track (WCAG 1.2.5, Level AA).
• Transcripts for audio-only content like podcasts. Bonus: transcripts are also crawlable for SEO and AI search, so they benefit discoverability too.
• Live captions for live video where WCAG 2.1 AA applies and the context warrants (webinars, all-hands, streamed events).

The US CVAA (21st Century Communications and Video Accessibility Act, 2010) adds specific captioning requirements for internet-distributed video that was previously captioned on TV.

Non-HTML content (PDFs, Office documents)

PDFs and Office documents are frequent accessibility failures. For any document content:

• Tag PDFs properly (reading order, headings, alt text for images, form field labels). Adobe Acrobat Pro and third-party tools like CommonLook and axesPDF support PDF/UA compliance.
• For Word and other Office documents, use built-in heading styles, alt text for images, and descriptive link text — then verify with the Accessibility Checker built into modern Office apps.
• Prefer HTML over PDF where possible. HTML is universally more accessible than PDF and easier to maintain.
• IAAP offers the ADS (Accessible Document Specialist) certification specifically for practitioners who create and remediate accessible documents.

Repetitive elements and skip links

Every page has repetitive elements — navigation, footer, search. Keyboard users shouldn’t have to tab through 50 navigation items on every page to reach main content (WCAG 2.4.1 Bypass Blocks):

• Implement a “Skip to main content” link as the first focusable element on the page. Visually hide it until focused.
• Use semantic landmarks (<main>, <nav>, etc.) so screen reader users can jump to regions directly.
• WCAG 2.2 added 3.2.6 Consistent Help — help mechanisms (contact info, human help) appearing on multiple pages must be in the same relative order on each page.

Don’t rely on color alone

Color is often used to convey information — red for errors, green for success, red/blue for required vs optional. For ~8% of men and ~0.5% of women with color vision deficiency, those signals are ambiguous or invisible (WCAG 1.4.1 Use of Color).

• Always pair color with another signal — text label, icon, pattern, or shape.
• Text contrast must meet 4.5:1 for normal text, 3:1 for large text (WCAG 1.4.3).
• Non-text UI components (buttons, form borders, focus indicators, icons) must meet 3:1 contrast (WCAG 1.4.11 Non-text Contrast).
• WCAG 2.2 adds 2.5.8 Target Size (Minimum) — interactive targets must be at least 24×24 CSS pixels (with exceptions for inline links and spacing). Much better than the previous 44×44 AAA-only requirement.
• Support Windows Forced Colors Mode — don’t hard-code colors that disappear when users override them. Use system colors (ButtonText, CanvasText) where appropriate.

Clear writing

Plain language benefits users with cognitive disabilities, non-native speakers, users in stressful situations, and everyone scanning for information (WCAG 3.1 Readable):

• Write at a reading level appropriate for your audience — often 8th-10th grade for general audiences, simpler for accessibility-sensitive contexts.
• Use short sentences and paragraphs. Break complex instructions into numbered steps.
• Define acronyms and jargon on first use, or link to a glossary.
• Provide content summaries for long articles.
• Use descriptive page titles and headings that clearly indicate content.

JavaScript and rendering

Modern accessibility works in harmony with JavaScript frameworks, not against them:

• Server-rendered (SSR) or statically-generated content loads accessibly for screen readers from the initial HTML. Pure client-side rendering (CSR) relies on the rendered DOM, which is fine for Googlebot (evergreen Chromium since 2019) but often problematic for AI crawlers (GPTBot, ClaudeBot, PerplexityBot) and some assistive tech in specific cases.
• Framework-native accessibility support is strong in Next.js, Nuxt, Astro, SvelteKit, and Remix — use their built-in patterns for focus management, ARIA, and routing.
• Use ARIA sparingly and correctly. ARIA is a last resort when native HTML doesn’t provide the needed semantics. Incorrect ARIA is worse than no ARIA — it misleads assistive technologies.
• Single-page applications (SPAs) need custom focus management on route changes — focus must move to the new content, typically to an H1 or landmark, and screen readers must be notified of the page change via aria-live or page-title updates.
• Dynamic content updates (live regions, notifications, toasts) use aria-live="polite" for informational messages and aria-live="assertive" for urgent ones. Use sparingly to avoid overwhelming screen reader users.

Testing accessibility

Automated tools catch 30–50% of accessibility issues; the rest requires manual testing. A practical combination:

• axe DevTools (Chrome/Firefox extension) or WAVE — automated scans of a page, with specific issue descriptions and WCAG references.
• Lighthouse (built into Chrome DevTools) — runs axe-core under the hood for its accessibility audit; useful for trend tracking.
• Keyboard-only navigation (unplug the mouse) — the single highest-signal manual test.
• Screen reader — NVDA (free) on Windows, VoiceOver (free, built-in) on macOS/iOS, or TalkBack on Android. Fifteen minutes on your homepage and a key workflow will teach you more than hours of reading specs.
• Zoom testing — Ctrl/Cmd+= up to 200% (WCAG 1.4.4) and 400% (WCAG 1.4.10 Reflow). Content should remain usable and reflow without horizontal scrolling.
• Forced Colors Mode (Windows 11 Contrast themes, or DevTools emulation) — catches color-dependent UI that breaks under user overrides.

See our manual accessibility testing guide for a detailed walkthrough of each test.

Frequently asked questions

What WCAG level should I target?

WCAG 2.2 Level AA is the practical compliance target for most organizations. It’s backward-compatible with 2.1 (which is referenced by most current laws) and future-proofs against the 2.2-referencing requirements that are gradually appearing in updated regulations.

Are “accessibility overlays” a valid compliance strategy?

No. Accessibility overlays (widget-based “one-line fix” accessibility tools) have been repeatedly shown to fail real accessibility tests, and they’ve been named in lawsuits where plaintiffs argued the overlay didn’t actually make the site accessible. Major disability-rights organizations (including the NFB and multiple coalitions) have issued public statements against overlays. Build genuine accessibility into the site itself.

How much does accessibility remediation typically cost?

For sites that weren’t designed accessibly, remediation typically runs 5-10x the cost of building accessibility in from the start. A medium-complexity commercial site might require $20,000-$100,000 for a full WCAG 2.2 AA remediation, plus ongoing maintenance. Building accessibility into new features costs maybe 10-15% more than building without — a fraction of the remediation cost.

Does accessibility help SEO?

Yes. Many accessibility best practices — proper heading hierarchy, alt text, descriptive link anchors, semantic HTML, captions and transcripts, fast loading — are also SEO best practices. Core Web Vitals (LCP, INP, CLS) overlap heavily with accessibility metrics. Sites that invest in accessibility routinely see SEO improvements as a side effect.

What’s the single highest-impact accessibility change I can make?

Keyboard-only navigation. Ensure every interactive element on your site works with just Tab, Shift+Tab, Enter, Space, Arrow keys, and Esc — no mouse. This single test exercises the foundational assumptions that most accessibility criteria rest on, and fixing keyboard issues cascades into fixing many other problems (focus visibility, logical structure, ARIA correctness, form labels).

How often should I audit accessibility?

Automated scans on every deploy (via CI). Quarterly manual testing on critical paths. Full audit at least annually, or before any major product launch. User testing with people who have disabilities whenever feasible — the gold standard that catches issues automated tools and able-bodied testers miss.

Bottom line

Website accessibility in 2026 is both a legal floor and a product-quality ceiling. WCAG 2.2 Level AA is the practical compliance target; laws (DOJ April 2024 Rule, EAA since June 2025, Section 508, and dozens of parallel national statutes) continue to tighten; and the business case strengthens every year as lawsuits increase, user expectations rise, and search engines reward accessible markup. Build accessibility in from the start using universal-design principles, test continuously with a combination of automated and manual methods, and treat accessibility as a product commitment rather than a compliance afterthought. The sites that get this right serve more users, rank better, and avoid the legal and reputational exposure that comes with getting it wrong.