An accessible website is one that everyone can use, including people with visual, auditory, motor, or cognitive disabilities. About one in five people have some form of disability — that is more users than the entire population of Europe. Yet most websites still treat accessibility as an afterthought. This article is a plain-English introduction to web accessibility: what WCAG is, what ARIA is, and the small set of habits that will make every page you build dramatically more inclusive.

Why accessibility matters

There are three reasons to care about accessibility, and they are all important. The first is ethical: the web was invented to be universal, and we should honour that. The second is legal: many countries require accessibility by law for public-facing sites, and the lawsuits are real. The third is practical: accessible websites are easier to use for everyone. Closed captions help people in noisy rooms. High-contrast text helps in bright sunlight. Keyboard navigation helps power users. Accessibility work benefits you, your boss, your users, and the people who would otherwise be locked out.

This is the single most generous part of being a web developer. You have the power to make the internet usable for people who would otherwise be excluded. Use it.

What is WCAG?

WCAG stands for Web Content Accessibility Guidelines. It is the international standard, maintained by the W3C, that defines what "accessible" actually means. WCAG is organised into three levels: A (the bare minimum), AA (the legal requirement in most countries), and AAA (the gold standard). Aim for AA on every project you ship.

WCAG is built on four principles, sometimes remembered with the acronym POUR:

  • Perceivable — users can perceive the information (text alternatives for images, captions for video).
  • Operable — users can interact with the page (keyboard support, no time-based traps).
  • Understandable — users can understand the content (clear language, predictable behaviour).
  • Robust — the content works with assistive technology (semantic HTML, valid markup).

What is ARIA?

ARIA stands for Accessible Rich Internet Applications. It is a set of attributes you can add to HTML elements to give screen readers and other assistive tech more information about what an element does. Most of the time, the right answer is to use the right semantic HTML element rather than adding ARIA at all. ARIA exists for cases where HTML alone cannot describe the interaction.

The five rules of ARIA, from the W3C, are useful to memorise:

  1. Use native HTML elements where possible.
  2. Do not change native semantics unless you really have to.
  3. All interactive ARIA controls must be usable with the keyboard.
  4. Do not use role="presentation" or aria-hidden="true" on focusable elements.
  5. All interactive elements must have an accessible name.

That last rule is the one most often missed. A button with no text content needs an accessible name — either visible text, an aria-label, or a label that an icon-only button points to via aria-labelledby.

The habits that get you ninety percent of the way

You do not have to memorise the entire WCAG specification. Most accessibility wins come from a small set of habits you can build into every project.

  • Use semantic HTML. Pick <button> for buttons, <a> for links, <h1> through <h6> for headings, <nav> for navigation, <main> for the main content, and <footer> for the footer. The browser already knows what these mean.
  • Label every input. We covered this in HTML Forms for Beginners but it is worth repeating: every <input> needs a <label>. No exceptions.
  • Provide alt text for images. Decorative images get alt="" (empty alt). Informative images get a short, descriptive alt. Never stuff keywords into alt text.
  • Ensure colour contrast. Body text should have at least 4.5:1 contrast against its background. Large text needs 3:1. Use a tool like the WebAIM Contrast Checker to verify.
  • Make focus visible. Never set outline: none on a focusable element without providing an alternative focus style. Keyboard users navigate by focus, and they need to see where they are.
  • Use heading levels in order. <h1>, then <h2>s, then <h3>s. Do not skip levels for visual effect.
  • Support keyboard navigation. Tab, Enter, Space, Escape, arrow keys. If your interface needs a custom keyboard pattern, document it.

The image alt-text decision tree

Alt text is the single biggest accessibility win you can make, and also the place people most often get it wrong. Here is the decision tree:

  • Is the image purely decorative? Use alt="" (empty). This tells screen readers to skip it.
  • Is the image the only way to convey meaning? Describe what the image shows in the alt text, briefly.
  • Does the image illustrate a piece of text? Use a short alt, or use alt="" with a longer description in aria-describedby.
  • Is the image a complex chart or graph? Provide a long description, either in surrounding text or via a link to a fuller version.

The wrong answers include: leaving out the alt attribute entirely (the browser will read out the file URL, which is awful), stuffing keywords (it is spam), or describing the visual appearance ("a round red button") instead of the meaning ("Submit").

A worked example: making a navigation menu accessible

Here is a navigation menu that uses semantic HTML and ARIA correctly:

&lt;nav aria-label="Main"&gt;
  &lt;ul&gt;
    &lt;li&gt;&lt;a href="/"&gt;Home&lt;/a&gt;&lt;/li&gt;
    &lt;li&gt;&lt;a href="/articles"&gt;Articles&lt;/a&gt;&lt;/li&gt;
    &lt;li&gt;&lt;a href="/about"&gt;About&lt;/a&gt;&lt;/li&gt;
  &lt;/ul&gt;
&lt;/nav&gt;

That is a perfectly accessible menu with zero custom ARIA. The <nav> tag identifies it as navigation. The aria-label="Main" distinguishes this menu from any other navigation landmark on the page (a footer menu, for example). Each link is a real <a> with visible text, so screen readers announce them correctly.

Now imagine a "hamburger" menu that opens a panel of links. You would add a button with aria-expanded="false" (or "true") and aria-controls="menu-id". When the user activates the button, you toggle both the panel visibility and the aria-expanded value. Screen reader users hear "Menu, collapsed, button" or "Menu, expanded, button" — they know what state they are in. MDN's ARIA reference has more examples.

Common pitfalls

  • Using <div> for everything. A <div> tells assistive tech nothing. Use the right element.
  • Removing focus outlines. Always provide a visible focus style. The default outline is ugly but accessible.
  • Auto-playing audio or video. Never. Users cannot stop what they cannot find. Always provide pause and mute controls.
  • Using ARIA instead of fixing the HTML. ARIA is a patch, not a substitute. Use it when HTML cannot do the job, not because it is easier.
  • Forgetting keyboard users. If a feature requires a mouse, it is broken for many users. Test every feature using only the keyboard.
  • Low-contrast text. The single most common accessibility failure. Run every colour pair through a contrast checker before shipping.

Testing your work

Three quick tests will catch most accessibility bugs before they ship.

  1. Keyboard-only test. Unplug your mouse (or at least put it aside). Can you reach every interactive element with Tab? Can you activate them with Enter or Space? Can you see where focus is at all times?
  2. Screen reader test. macOS has VoiceOver built in (Cmd+F5). Windows has Narrator (Win+Ctrl+Enter). Read through your page and listen to what gets announced. Surprise: your headings are probably missing, or your alt text is wrong.
  3. Automated tool. Run your page through axe DevTools, Lighthouse, or the WAVE extension. They catch about thirty percent of issues. The other seventy percent require the first two manual tests.

Further reading

Accessibility is a deep topic. We trust these sources above all others when we audit or train.

FAQ

Is accessibility only for blind users?

No. It covers visual, auditory, motor, and cognitive disabilities. It also covers temporary disabilities (a broken arm, a noisy room, a bright sun on a phone screen) and situational limitations. The "curb-cut effect" — designing for the edges makes things better for everyone — is real.

Do I have to make my site WCAG 2.2 AA compliant?

It depends on where you live and what your site does. In the EU, the European Accessibility Act requires it for most public-facing services. In the US, ADA-driven lawsuits target inaccessible commerce sites. If you are unsure, ask a lawyer. AA is the default target in any case.

What is the easiest thing I can do today?

Add alt text to every image on your site. That alone fixes a huge percentage of accessibility issues. Then make sure every interactive element has a visible focus style. You can do both in an afternoon.

What is the difference between ARIA and HTML semantics?

HTML semantics are built into the elements — <button> is always a button. ARIA is extra information you add to elements that may not have it. Use HTML semantics first, ARIA only when needed.

How do I make a custom widget accessible?

Pick the closest existing HTML element (<button> for a button, <a> for a link). If you must build something truly custom, give it a role, an accessible name, and keyboard support. Document the keyboard pattern for screen reader users.

What is the prefers-reduced-motion media query?

It is a media query that respects the user's operating system preference for reduced motion (animations, transitions). Wrap your animations in @media (prefers-reduced-motion: no-preference) so they only run for users who have not opted out. This is a small, kind gesture that costs almost nothing.

What is the tabindex attribute?

tabindex controls whether an element can be focused with the keyboard and in what order. tabindex="0" adds the element to the natural tab order. tabindex="-1" makes it programmatically focusable but not in the tab order (useful for skip links). Avoid positive tabindex values — they create confusing tab orders that are hard to maintain.

Homework

Take a webpage you have already built (the click counter, the favourite-thing page, anything). Run it through three tests:

  • Open it with the keyboard only. Can you reach every interactive element? Can you see where focus is?
  • Open it with VoiceOver or Narrator. Listen to what gets announced. Note any surprises.
  • Run it through the axe browser extension. Fix anything in the top three issues.

Then improve the alt text on every image using the decision tree from the article. Finally, add a visible focus style to all interactive elements. When you are done, the page should pass a basic accessibility audit and feel noticeably easier to use with the keyboard.