What Is a11y — Web Accessibility Defined

In this tutorial, you will learn about What Is a11y. We cover key concepts, practical examples, and best practices to help you master this topic.

Web Accessibility (a11y) means designing and developing websites that people with disabilities can perceive, operate, understand, and robustly interact with using assistive technologies like screen readers, voice recognition, and switch devices.

What You'll Learn

You will learn the formal definition of web accessibility, what it means in practice, who benefits, and how it connects to the POUR principles that form the foundation of WCAG.

Why It Matters

Without a clear definition of accessibility, teams cannot agree on what to build. Understanding accessibility as equal opportunity for digital content ensures everyone on your team works toward the same goal.

Real-World Use

When DodaTech builds a feature for Doda Browser, every team member knows accessibility means the feature must be usable without a mouse, readable by screen readers, and understandable without color alone.

flowchart TD
  A[Web Accessibility] --> B[Perceivable]
  A --> C[Operable]
  A --> D[Understandable]
  A --> E[Robust]
  B --> F[See or hear content]
  C --> G[Interact with interface]
  D --> H[Comprehend information]
  E --> I[Works with assistive tech]

The Formal Definition

The World Wide Web Consortium (W3C) defines web accessibility as: websites and tools that people with disabilities can perceive, understand, navigate, and interact with, and that they can contribute to the web.

This definition covers not just consuming content but also creating it. An accessible website allows people with disabilities to be active participants, not passive consumers.

What It Means in Practice

Perceivable

Users must be able to perceive the content through at least one of their senses. This means providing text alternatives for images, captions for videos, and sufficient color contrast.

Operable

Users must be able to operate the interface. All functionality must be available from a keyboard. Users must have enough time to complete tasks. Nothing should cause seizures.

Understandable

Users must be able to understand the content and how to use the interface. Text must be readable. Navigation must be predictable. Errors must be preventable and fixable.

Robust

Content must work with current and future assistive technologies. Use valid semantic HTML and proper ARIA attributes.

The Assistive Technology Connection

Accessibility exists because assistive technologies exist. Screen readers convert text to speech. Switch devices let users with limited mobility interact one click at a time. Voice recognition lets users navigate by speaking.

<!-- A simple accessible card component -->
<article aria-labelledby="card-title">
  <h2 id="card-title">Durga Antivirus Pro Scan</h2>
  <p>Detected 0 threats in the last full system scan.</p>
  <button type="button" onclick="startScan()">
    <span aria-hidden="true">&#9654;</span> Run scan
  </button>
</article>

Expected behavior: A screen reader announces "Durga Antivirus Pro Scan, heading level 2. Detected 0 threats in the last full system scan. Button: Run scan." The aria-hidden icon does not distract.

Common Mistakes

1. Thinking Accessibility Is Only about Blind Users

Accessibility covers auditory, motor, and cognitive disabilities too. Each group has different needs.

2. Confusing Accessibility with Usability

Usability is about ease of use for everyone. Accessibility is about access for people with disabilities. They overlap but are not the same.

3. Assuming ARIA Fixes Bad HTML

ARIA cannot make bad HTML accessible. Start with semantic HTML elements before adding ARIA enhancements.

4. Testing Only with Automated Tools

Automated tools check technical rules but cannot determine if alt text is meaningful or if navigation makes sense.

5. Treating Accessibility as a Checklist

Checking boxes does not guarantee an accessible experience. User testing reveals issues no checklist can predict.

6. Forgetting Cognitive Disabilities

Cognitive accessibility is often overlooked. Plain language, consistent navigation, and adequate time limits matter as much as alt text.

7. Ignoring the Business Case

Accessibility is not just ethics. It reaches 1.3 billion users, improves SEO, and reduces legal risk.

Practice Questions

1. What are the four POUR principles?

Perceivable, Operable, Understandable, Robust. Every WCAG success criterion belongs to one of these.

2. Why does accessibility rely on assistive technologies?

Assistive technologies bridge the gap between a person's abilities and the interface. Accessibility ensures that bridge exists.

3. What does it mean for content to be robust?

Content must work with a wide variety of user agents including screen readers, magnifiers, and future technologies.

4. Can a site be accessible without semantic HTML?

No. Semantic HTML provides the structure that assistive technologies rely on. Divs and spans do not convey meaning.

5. Challenge: Pick a non-technical friend and explain web accessibility in one sentence they would understand.

FAQ

Mini Project

Write a one-page accessibility policy for a fictional company called AccessCorp. Define what accessibility means, who it applies to, and what standards the company follows.

What's Next

Continue to Why a11y Matters to understand the human, legal, and business reasons behind web accessibility. Then explore Disability Types to learn who accessibility serves.