Web Accessibility Basics: A Beginner’s Guide to WCAG 2.2

Web accessibility means designing and building websites and apps so that people with disabilities can perceive, understand, navigate and interact with them. That includes people who are blind or have low vision, people who are deaf or hard of hearing, people with motor impairments who cannot use a mouse, and people with cognitive or learning disabilities. It also helps many others: older users, people on small or cracked phone screens, people in bright sunlight, and anyone with a temporary injury.

This guide to web accessibility basics explains the Web Content Accessibility Guidelines (WCAG) in plain language and gives designers and front-end developers a practical set of checks to start with.

What is WCAG?

WCAG is published by the World Wide Web Consortium (W3C) through its Web Accessibility Initiative (WAI). At the time of writing, the current version is WCAG 2.2, first published in October 2023 and also approved as the international standard ISO/IEC 40500:2025. WCAG 3 is still an early draft, so WCAG 2.2 is the version to follow today.

WCAG is organised into four principles, often remembered as POUR:

Under the principles are guidelines, and under those are testable success criteria, each at one of three levels: A (minimum), AA (the level most organisations and laws aim for) and AAA (the highest, not always achievable for whole sites). When people say “WCAG compliant” they usually mean WCAG 2.1 or 2.2 Level AA.

Ten essential checks for designers

Designers who know the web accessibility basics can prevent most problems at the design stage, before a line of code is written.

1. Text contrast. Normal text needs at least 4.5:1 against its background; large text needs 3:1 (1.4.3). See colour theory for UI designers.
2. Non-text contrast. Input borders, icons that carry meaning and focus indicators need 3:1 against adjacent colours (1.4.11).
3. Do not rely on colour alone. Pair colour with text, icons or patterns, for example error messages and chart labels (1.4.1).
4. Design visible focus states. Every interactive element needs a clear focus indicator for keyboard users (2.4.7), and it should not be hidden behind sticky headers or banners (2.4.11, new in 2.2).
5. Target size. Pointer targets should be at least 24 by 24 CSS pixels, or have enough spacing around them (2.5.8, new in 2.2). Larger targets, such as 44 by 44, are easier for everyone on touch screens.
6. Labels for every input. Use visible labels, not placeholder text alone, and write helpful instructions (3.3.2).
7. Clear error messages. Identify the field and explain how to fix it (3.3.1, 3.3.3).
8. Logical headings and reading order. Annotate heading levels and tab order in your designs so developers implement them correctly.
9. Text that can grow. Layouts should survive 200% text resize and increased text spacing (1.4.4, 1.4.12). Avoid fixed-height text boxes.
10. Motion with care. Avoid flashing content, give users a way to pause moving content, and respect reduced-motion preferences.

Ten essential checks for developers

1. Use semantic HTML. Real button, a, nav, main and heading elements give assistive technology the right information for free. See HTML semantic elements and semantic HTML for SEO.
2. Everything works with a keyboard. Users must be able to reach and operate every control with Tab, Shift + Tab, Enter and Space (2.1.1).
3. Do not remove focus outlines without providing a better visible style. :focus-visible helps.
4. Text alternatives. Meaningful images need alt text describing their purpose; decorative images get alt="" (1.1.1). See HTML images.
5. Associate labels with inputs using <label for> and add autocomplete where it applies (1.3.5). See HTML forms.
6. Set the page language with <html lang="en">, and mark passages in other languages, for example lang="hi" (3.1.1, 3.1.2).
7. Give icon-only buttons an accessible name, for example with visually hidden text or aria-label.
8. Use ARIA only when needed. Native HTML elements are more reliable. Incorrect ARIA can make things worse.
9. Announce dynamic changes, such as “Added to cart”, using a live region where appropriate (4.1.3).
10. Respect user preferences such as prefers-reduced-motion; see CSS animation performance tips.

Example: an accessible form field

This small example shows a labelled input, a hint linked with aria-describedby, an error message and a clear focus style. Use Tab to move through it and notice the focus ring.

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Accessible field</title>
<style>
  body { font-family: system-ui, sans-serif; font-size: 1rem; line-height: 1.5; padding: 24px; color: #1f2937; }
  label { display: block; font-weight: 600; margin-bottom: 4px; }
  .hint { color: #4b5563; font-size: 0.875rem; margin: 0 0 8px; }
  input { font-size: 1rem; padding: 10px 12px; border: 1px solid #6b7280; border-radius: 6px; width: 100%; max-width: 320px; box-sizing: border-box; }
  input[aria-invalid="true"] { border-color: #b91c1c; }
  .error { color: #b91c1c; font-size: 0.875rem; margin-top: 6px; }
  button { margin-top: 16px; font-size: 1rem; padding: 10px 20px; min-height: 44px; border: 0; border-radius: 6px; background: #1d4ed8; color: #fff; }
  input:focus-visible, button:focus-visible { outline: 3px solid #1d4ed8; outline-offset: 2px; }
</style>
</head>
<body>
  <form id="f" novalidate>
    <label for="mobile">Mobile number</label>
    <p class="hint" id="mobile-hint">10 digits, for example 9876543210</p>
    <input id="mobile" name="mobile" type="tel" inputmode="numeric" autocomplete="tel-national" aria-describedby="mobile-hint mobile-error">
    <p class="error" id="mobile-error" role="alert"></p>
    <button type="submit">Send OTP</button>
  </form>
  <script>
    const form = document.getElementById("f");
    const input = document.getElementById("mobile");
    const error = document.getElementById("mobile-error");
    form.addEventListener("submit", function (e) {
      e.preventDefault();
      if (/^[0-9]{10}$/.test(input.value)) {
        input.removeAttribute("aria-invalid");
        error.textContent = "";
        form.insertAdjacentHTML("beforeend", "<p>Thanks! OTP sent.</p>");
      } else {
        input.setAttribute("aria-invalid", "true");
        error.textContent = "Error: enter a 10-digit mobile number.";
        input.focus();
      }
    });
  </script>
</body>
</html>

How to test accessibility

No single tool catches everything. Combine automated and manual checks.

Common myths

• “Accessibility is only for blind users.” It covers visual, auditory, motor, speech and cognitive disabilities, plus situational limits.
• “Accessible design is ugly.” Good contrast, clear focus states and readable type are signs of quality design.
• “We will fix accessibility at the end.” Fixing late is much more expensive. Build it into components and the design system from the start.
• “An overlay widget makes the site compliant.” Plugins that claim to fix accessibility automatically do not replace accessible design and code.

Accessibility in the Indian context

Many users in India access the web on mobile phones, in several languages, and sometimes on slower connections. Accessible practices such as clear language, good contrast, large targets, semantic HTML and lightweight pages help all of them. If you work on government or public-sector projects, check the current official accessibility requirements that apply to the project, which are generally aligned with WCAG.

Web accessibility basics: your starter checklist

• Contrast: text 4.5:1, large text and UI components 3:1.
• Information never conveyed by colour alone.
• Visible focus on every interactive element, never obscured.
• All functionality works with a keyboard.
• Every input has a visible label; errors are clear and specific.
• Meaningful images have alt text; decorative ones have empty alt.
• Headings in a logical order; page language set.
• Targets at least 24 by 24 CSS pixels or well spaced.
• Layouts survive 200% zoom and larger text.
• Tested with keyboard, a screen reader and real users.

Frequently asked questions

Further reading

• w3.org/WAI/standards-guidelines/wcag
• w3.org/WAI/standards-guidelines/wcag/new-in-22
• w3.org/WAI/WCAG22/quickref
• w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
• web.dev/learn/accessibility