Skip to main content

Web Accessibility

Updated 2 min read

Share this page

Send the link, quote the definition with a link back, or show it as a card on your own site.

https://softwaredictionary.org/terms/web-accessibility

In short

Web accessibility is the practice of building websites that everyone can use, including people who rely on screen readers, keyboards, captions, or zoom.

What is web accessibility?

Web accessibility, often shortened to a11y because there are 11 letters between the a and the y, means designing and coding websites so that people with disabilities can perceive, understand, navigate, and interact with them. That includes people who are blind or have low vision, are deaf or hard of hearing, or have motor or cognitive disabilities, and it also helps anyone with a temporary injury, a slow connection, or a screen in bright sunlight.

The main reference is the Web Content Accessibility Guidelines (WCAG) from the W3C, with WCAG 2.2 as the current version and level AA as the usual target in laws and contracts. Its four principles say content must be perceivable, operable, understandable, and robust. In practice, that means text alternatives for images, sufficient color contrast, captions for video, clear labels on form fields, and pages that can be used with a keyboard alone.

Semantic HTML does most of the work: a real <button> can be focused and activated with the Enter and Space keys, while a clickable <div> cannot. ARIA attributes such as aria-label can fill gaps in custom widgets, but the first rule of ARIA is not to use it when a native HTML element already does the job. A ramp next to the stairs of a building is a good analogy: it is essential for wheelchair users, yet parents with strollers and travelers with luggage use it too.

A common misconception is that accessibility is only about screen readers or can be fixed with an overlay widget added at the end. Automated tools such as Lighthouse and axe catch only part of the problems, so teams also test with a keyboard, a screen reader, and browser zoom throughout development. Accessible pages also tend to be easier for search engines and AI tools to understand, because they have clear structure and text alternatives.

Key takeaways

  • Accessibility makes websites usable by people with disabilities.
  • WCAG is the main standard, and level AA is the common target.
  • Semantic HTML provides keyboard and screen reader support for free.
  • Use ARIA only when native HTML elements cannot do the job.
  • Automated checks catch only some issues; manual testing is essential.

Example

Inaccessible vs. accessible markuphtml
<!-- Inaccessible: not focusable, no role, no text for screen readers -->
<div class="icon-btn" onclick="search()">
  <img src="search.svg">
</div>

<!-- Accessible: a real button with a visible text label -->
<button type="button" onclick="search()">
  <img src="search.svg" alt="">
  Search
</button>

<!-- Every form field has a label linked by its id -->
<label for="email">Email</label>
<input id="email" type="email" autocomplete="email">

Readers ask

What does a11y mean?

A11y is a numeronym for accessibility: the first letter a, the last letter y, and the 11 letters in between. It is common in developer discussions, hashtags, and tool names.

What is WCAG?

WCAG, the Web Content Accessibility Guidelines, is the W3C standard that defines testable accessibility requirements at three levels: A, AA, and AAA. Most organizations and many laws aim for WCAG 2.1 or 2.2 at level AA.

Do accessibility overlays make a website accessible?

No. Overlay widgets that promise automatic fixes cannot repair missing labels, broken keyboard support, or poor structure in the underlying code, and they can interfere with users' own assistive technology. Real accessibility comes from building and testing the site itself.

See also

Spotted a mistake or something missing on this page?Suggest an edit

Read a random page
Open today's review
Switch to the dark theme
Read this page in Türkçe

More

Settings