Web Accessibility

Accessibility Is Part of Quality

Accessibility means more people can perceive, navigate, understand, and use your site. It helps people with disabilities, people using assistive technology, people on mobile devices, and anyone dealing with temporary limits like glare, injury, noise, or slow connections.

For your final project, treat accessibility as a quality check. A page is not finished until it works with a keyboard, has readable contrast, uses meaningful structure, and communicates clearly to assistive technology.

The POUR Principles

WCAG 2.2 AA

WCAG stands for Web Content Accessibility Guidelines. It is the shared standard used to evaluate web accessibility.

For student projects, use WCAG 2.2 AA as the practical target. Level A covers basic barriers, level AA is the common professional goal, and level AAA is stricter but not always realistic for every page.

WCAG is not a replacement for empathy or testing. It gives you measurable checks, but you still need to use the page the way real users might use it.

Native HTML First

Start with the HTML element that already has the meaning and behavior you need. A real button can receive focus, respond to keyboard input, and communicate its role automatically. A clickable div cannot do those things unless you rebuild them manually.

Use ARIA only when native HTML cannot express the meaning. ARIA can improve custom interfaces, but incorrect ARIA can make a page more confusing.

Final Project Accessibility Pass

Use this order when reviewing a project. It moves from structure to interaction to automated checks, which helps you catch the problems students most often miss.

Headings and Landmarks

Headings create the page outline. Landmarks help users jump to major regions of the page. Do not choose heading levels based only on font size; choose them based on structure.

<header>
  <nav aria-label="Main navigation">
    <a href="/">Home</a>
    <a href="/projects/">Projects</a>
  </nav>
</header>

<main>
  <h1>Restaurant Guide</h1>

  <section aria-labelledby="featured-heading">
    <h2 id="featured-heading">Featured Restaurants</h2>
    <article>
      <h3>Coastal Kitchen</h3>
      <p>Seafood restaurant with outdoor seating.</p>
    </article>
  </section>
</main>

Alt Text

alt text should communicate the purpose of the image in context. A product photo, project screenshot, chart, or important illustration usually needs descriptive alt text.

Use empty alt="" only for decorative images that add no new information.

Links and Buttons

Links move users to another place. Buttons perform an action on the current page. Do not use vague link text like "click here" when the link can describe its destination.

<!-- Less helpful -->
<a href="/projects/responsive-landing-page/">Click here</a>
<div class="button">Open menu</div>

<!-- Better -->
<a href="/projects/responsive-landing-page/">View the responsive landing page project</a>
<button type="button">Open menu</button>

Forms and Errors

Every form control needs a programmatic label. Helpful instructions and error messages should be connected to the input with aria-describedby when they provide extra context.

<label for="email">Email address</label>
<input
  id="email"
  name="email"
  type="email"
  autocomplete="email"
  aria-describedby="email-help email-error"
  aria-invalid="true"
>
<p id="email-help">Use the email address you check most often.</p>
<p id="email-error">Enter an email address that includes an @ symbol.</p>

Focus Styles

Keyboard users need to see where focus is. Do not remove outlines unless you replace them with a visible focus style.

a:focus-visible,
button:focus-visible,
input:focus-visible,
textarea:focus-visible,
select:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

Contrast and Color

For normal body text, aim for at least 4.5:1 contrast. Large text can pass at 3:1, but body copy, navigation, buttons, and form text should be easy to read in real conditions.

Never rely on color alone to communicate meaning. Pair color with text, icons, labels, borders, or patterns.

Motion and Media

Animation, video, and autoplay can create barriers. Avoid flashing content, avoid surprise motion, and respect prefers-reduced-motion when using animation.

If a video includes speech or important sound, provide captions or a transcript. If a carousel or animation autoplays, give users a way to pause it.

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms;
    animation-iteration-count: 1;
    scroll-behavior: auto;
    transition-duration: 0.01ms;
  }
}

Automated Tools Are Support

Tools like Lighthouse and axe can catch missing labels, contrast issues, invalid ARIA, and other common problems. They cannot fully judge whether link text is meaningful, whether alt text is useful, or whether a keyboard workflow feels clear.

Run automated checks after a manual pass, then fix issues and test again. Passing an automated audit does not guarantee the page is accessible.

Use the Accessibility Check Lab

The interactive demo below models the same checks you should run on your project: text alternatives, contrast, visible focus, and semantic controls.

Toggle each issue, inspect the code, then find the matching pattern in your own project. The goal is to practice noticing problems before they ship.

Common Mistakes