Web Accessibility: Practical Ways to Make Websites More Inclusive

To make a website more accessible, use the Web Content Accessibility Guidelines (WCAG) 2.2 as your technical framework, then improve content, design, and code and evaluate the site with both automated checks and people familiar with disability and assistive technology use. Start with core tasks: make all functionality keyboard-accessible, give controls and form fields clear names, provide useful alternatives for images and media, communicate errors, and preserve a meaningful reading order.

No short checklist can cover every person or situation. WCAG provides testable success criteria organized by conformance levels A, AA, and AAA under four principles: perceivable, operable, understandable, and robust. W3C recommends using the latest WCAG version. Treat this guide as a practical starting point, not a conformance determination.

1. Start with the tasks people need to complete

List the important journeys on your site: finding information, navigating to a section, signing in, submitting a form, or completing a purchase. Review the pages and states those tasks use, including validation errors, menus, dialogs, media, and smaller viewports. This keeps accessibility work connected to actual use instead of only a homepage scan.

Fix barriers that prevent a task from starting or finishing first: keyboard traps, unlabeled fields, controls with no accessible name, missing instructions, and errors that are difficult to find or correct. Then address broader presentation and content issues, and repeat the review after changes. This sequence is a practical workflow recommendation; WCAG itself is the source for the criteria.

2. Make information perceivable

Use text alternatives that fit the image’s purpose

For an informative image, write alternative text that conveys the relevant information in context. For a functional image, describe the action or destination rather than its appearance. Decorative images should generally use empty alt text (alt="") so assistive technology can skip them. Avoid repeating nearby text or adding details that do not help someone understand or use the page.

<!-- Informative image: convey the useful content -->
<img src="monthly-sales-chart.png" alt="Sales rose from January through April, then remained steady in May.">

<!-- Functional image: describe the link's destination or action -->
<a href="/account">
  <img src="account-icon.svg" alt="Account settings">
</a>

<!-- Decorative image: omit it from the text alternative -->
<img src="blue-divider.svg" alt="">

Choose the alternative based on what the image contributes, not a formula based on image dimensions. If a complex chart needs more explanation than fits in an alt attribute, provide the key conclusion in nearby text and make the underlying data or a longer description available.

Do not rely on color alone

Color can reinforce meaning, but pair it with another cue such as a text label, icon with an accessible name, shape, or pattern. For example, identify an invalid field with text and a programmatic error association, not just a red border. Check contrast for text, controls, and text placed over imagery; WCAG success criteria specify the requirements to evaluate.

Provide alternatives for media and control motion

Provide captions and other appropriate alternatives for multimedia. If audio or video starts automatically, give users a way to pause, stop, or control it as applicable. Make sure important information is not available only through sound, color, animation, or visual position.

3. Make every interaction work from the keyboard

Use native links, buttons, inputs, and other semantic HTML controls where possible. They already expose expected roles and keyboard behavior to browsers and assistive technologies. Verify that users can reach interactive elements, understand which one has focus, operate it, and leave it again. Keep focus visible and the reading and focus order sensible.

<button type="button" id="menu-toggle" aria-expanded="false" aria-controls="site-menu">
  Menu
</button>
<nav id="site-menu" aria-label="Main navigation">
  <a href="/services">Services</a>
  <a href="/contact">Contact</a>
</nav>

<script>
  const toggle = document.querySelector('#menu-toggle');
  const menu = document.querySelector('#site-menu');
  toggle.addEventListener('click', () => {
    const expanded = toggle.getAttribute('aria-expanded') === 'true';
    toggle.setAttribute('aria-expanded', String(!expanded));
    menu.hidden = expanded;
  });
</script>

This small example uses a native button and exposes whether the menu is expanded. A production menu also needs a deliberate visibility and focus strategy appropriate to its design. Do not add custom keyboard handling to native controls without a need; custom widgets must provide behavior users expect from that kind of control.

Test with the keyboard alone: move through the page, operate menus and dialogs, activate links and buttons, and confirm focus does not get stuck. Automatically starting content or movement should have controls where required so users can stop or manage it.

4. Make content and page structure understandable

Use headings to describe sections and nest them in a meaningful order. Use lists, landmarks, and other semantic elements for their intended purpose. Keep the order in the markup aligned with the order that makes sense when reading or navigating the page. Declare the page language and mark changes in language when needed.

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>Request a consultation</title>
  </head>
  <body>
    <header><a href="/">Home</a></header>
    <main>
      <h1>Request a consultation</h1>
      <p>Tell us how to contact you and what you need.</p>
      <!-- Form goes here -->
    </main>
  </body>
</html>

Clear, consistent navigation and recognizable controls help people understand how to move through the site. Check that content still works at different viewport sizes; do not make a particular screen size, pointer, or visual layout necessary for understanding a task.

5. Make forms usable and errors actionable

Associate every form field with a label. Explain required formats and constraints before submission when people need that information. When validation fails, identify the problem in text, associate the message with the relevant control, and help the user correct it. Preserve entered data when practical so an error does not force people to start over.

<form action="/subscribe" method="post">
  <label for="email">Email address</label>
  <input
    id="email"
    name="email"
    type="email"
    autocomplete="email"
    aria-describedby="email-help email-error"
    required
  >
  <p id="email-help">Use an address you can access.</p>
  <p id="email-error">Enter an email address in the format name@example.com.</p>
  <button type="submit">Subscribe</button>
</form>

In a real form, show the error message only when relevant, connect it to the field, and ensure that users are informed when submission produces errors or success. A placeholder is not a substitute for a persistent label. For a long form, consider a clear error summary and links to fields that need attention.

6. Use semantic code and preserve robust meaning

Choose HTML elements that describe the content and controls. Ensure interactive elements have accessible names, roles, and states, and that assistive technologies can determine their meaning. Keep the DOM reading order useful even if styling changes visual placement. Custom controls require additional work to expose their state and support keyboard operation; prefer native controls where they meet the need.

Check that language is declared, labels remain available, and content does not depend on a fragile visual arrangement. W3C’s developer guidance covers structure, language, labels, errors, reading order, custom controls, keyboard support, and CAPTCHA considerations.

7. Evaluate with tools and people

Automated accessibility tools can help find some failures, especially issues that can be checked against machine-readable conditions. They cannot establish that every WCAG criterion is met or that people can complete real tasks. W3C notes that some criteria require human testers and recommends qualitative review and usability testing with people who understand disability and web use.

Use the WCAG 2.2 Quick Reference to identify relevant success criteria and plan evaluation.
Run an automated checker on representative pages and fix clear findings, while checking whether each finding applies to the page.
Review keyboard access, focus, headings, labels, image alternatives, error handling, contrast, media alternatives, and responsive states manually.
Ask people familiar with disability and assistive technology use to review important journeys; usability testing helps reveal barriers automated rules cannot judge.
Recheck the same tasks after fixes and whenever relevant content or components change.

The choice of representative pages and task flows is an editorial workflow, not a prescribed W3C testing sequence. Include pages with different templates and interactions, not only the landing page. Screenshot review can help inspect visual presentation across viewport sizes, but an image does not show keyboard behavior, accessible names, or how assistive technology announces a page. ScreenshotNeo is a website screenshot API and MCP server that can capture pages for visual review; it complements accessibility evaluation and does not determine whether a site conforms to WCAG.

8. What WCAG 2.2 means for a project

WCAG 2.2 is the latest WCAG 2 version identified by W3C’s overview. Its success criteria are testable and grouped at levels A, AA, and AAA. The four principles are perceivable, operable, understandable, and robust. W3C states that content conforming to WCAG 2.2 also conforms to 2.1 and 2.0, and recommends using the latest version. Check the current W3C overview when setting project requirements because standards context can change.

Conformance is assessed against the applicable success criteria, not a general impression that a site looks accessible. A quick list, automated scan, or single test session is not a complete evaluation. Use the criteria as a framework and combine them with review of actual tasks and user experience.

9. Legal context: check the rule for your organization

Accessibility obligations depend on jurisdiction, organization, and applicable law. Do not treat one deadline as applying to every business or website. The U.S. Department of Justice’s current Title II information says compliance dates for the state and local government web and mobile application rule were extended to April 26, 2027, for entities serving populations of 50,000 or more, and April 26, 2028, for entities serving populations below 50,000 and special district governments.

Those dates concern the specified state and local government entities. The DOJ’s general ADA guidance page is dated March 18, 2022, says it does not reflect the later Title II rule, and states the guidance is not a final agency action and has no legally binding effect. For a legal decision, consult the current official rule materials and qualified counsel.

10. Troubleshooting common accessibility problems

Problem	Common cause	What to check or change
A keyboard user cannot reach or operate a control	A non-semantic element is being used as an interactive control, or custom behavior lacks keyboard support.	Use a native button, link, or form control where possible; verify keyboard access, visible focus, and a way to leave the interaction.
Focus disappears or moves in a confusing order	Visual placement and DOM order diverge, or focus styles were removed.	Review the markup order and restore a visible focus indicator; test a full task with the keyboard.
A screen reader announces an image unhelpfully	Alt text is missing, redundant, overly literal, or used for a decorative image.	Describe the image’s purpose in context; use empty alt text for decorative images and action-oriented text for functional images.
A form field is announced without a useful name	The visible label is not associated with the control, or only placeholder text is provided.	Use a label whose `for` matches the control’s `id`; keep instructions and errors available and associated.
An error is visible but users cannot identify or correct it	The error relies on color, is detached from the field, or gives no correction guidance.	State the problem in text, connect it to the control, and explain the needed correction.
Automated scans pass but users still struggle	Automated checks cover only some testable conditions and cannot judge every criterion or task experience.	Do manual review and usability testing with people who understand disability and assistive technology use.
The page is hard to use at a narrow viewport	Content or controls depend on a fixed layout or visual placement.	Review representative responsive states and verify content remains understandable and operable.

11. Performance, reliability, and cost of evaluation

Automated scans are repeatable and can be run during development, but their results still need interpretation and they do not replace human review. Human evaluation takes coordination and time; focus it on important journeys and include people who understand disability and assistive technology use. Repeating checks after fixes helps catch regressions. The appropriate scope and cost depend on the site, its changes, and the evaluation method; no single scan or session guarantees accessibility.

For visual checks across page states, a screenshot workflow can make it easier to compare layouts, but screenshots do not expose semantic structure or interaction behavior. ScreenshotNeo supports page screenshots and PDFs through an API and MCP server. Its captures can inform visual review alongside keyboard and assistive technology evaluation.

Or skip the browser setup

For visual review, ScreenshotNeo can capture a page with one request. The API also supports PDF output, custom viewports, full-page capture, and other capture options; see the API documentation for parameters and examples.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com -o accessibility-review.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
    timeout=90,
)
open("accessibility-review.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://example.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('accessibility-review.webp', res);

ScreenshotNeo accepts cookie or consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and response headers report the page verdict and billing status. Its MCP server gives AI agents tools for screenshots, page information, and PDF capture. The free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots. Use captured images to review visual states, then assess semantics, keyboard access, and real tasks separately.

For the product overview, visit ScreenshotNeo.

Frequently asked questions

Can an accessibility checker tell me whether my website is accessible?

No single automated checker can establish that every criterion is met or that users can complete important tasks. Use automated findings as one input, then review manually and involve people familiar with disability and assistive technology.

Should every image have descriptive alt text?

No. Informative images need a useful text alternative, functional images should communicate their action or destination, and decorative images generally use empty alt text.

Does the Title II deadline apply to my business website?

The cited 2027 and 2028 dates apply to specified state and local government entities under the U.S. Title II rule. They are not a universal deadline for businesses or every jurisdiction. Check current official materials and seek legal advice for your organization.

Is WCAG 2.2 the only thing a team needs to evaluate?

WCAG 2.2 provides a technical framework of success criteria. A useful evaluation also considers whether people can use the site’s real content and tasks, including with assistive technology.