# You Are Already an Accessibility User

> Captions, dark mode, one-handed phone use... you're already benefiting from accessibility features. On GAAD 2026, let's explore what 'accessibility for everyone' really means.

**Published:** 2026-05-20 | **Updated:** 2026-05-20

---


Take a moment to think about your day.

Did you watch a video with captions because you were somewhere too noisy — or too quiet?
Did you crank up your screen brightness because you couldn't see it in the sun?
Did you navigate your phone with just your thumb while carrying something in your other hand?
Did you switch on dark mode because your eyes were tired?

**Congratulations. You are already an accessibility user.**

Tomorrow, May 21, is **[GAAD — Global Accessibility Awareness Day](https://accessibility.day/)**.

GAAD was started in 2012 by web developer Joe Devon and Jennison Asuncion. Held every year on the third Thursday of May, its purpose is to get everyone talking, thinking, and learning about digital access and inclusion. Anyone can participate — developers, designers, companies, and everyday users — and you can find events and ways to get involved on the [official website](https://accessibility.day/).

But when most people hear "accessibility," they think:

> "That's not really for me. I don't have a disability."

Today, I'd like to challenge that assumption.

{{< img src="images/contents/everyday-accessibility.jpg" alt="People using smartphones in various ways in a public space - one using it with one hand, another squinting at their screen in bright light - we use accessibility features every day without realizing it" caption="Photo: <a href='https://unsplash.com/@camstejim' target='_blank' title='Opens in new window'>camilo jimenez</a> / <a href='https://unsplash.com' target='_blank' title='Opens in new window'>Unsplash</a>" >}}

---

## The Misconception: "It's Just for Disabled People"

What comes to mind when you hear the word "accessibility"?

Tactile paving, wheelchair symbols, low-floor buses, audio guidance for the visually impaired... these are probably the first things that pop into your head. The same goes for web accessibility — "features for screen reader users," "alt text for blind people."

That's not wrong. But it's far from the whole picture.

The W3C (World Wide Web Consortium) defines web accessibility as:

> **"Making the web perceivable, understandable, navigable, and interactive for all people, regardless of disability."**

The key phrase is **"all people"** — not just people with disabilities, but older adults, people in temporary situations, and anyone using the web under any circumstances.

---

## Three Types of Disability: Broader Than You Think

Microsoft's Inclusive Design team breaks disability into three categories. This framework tends to shift the way people think about who accessibility is actually for.

| Type | Definition | Examples |
|------|------------|---------|
| **Permanent** | Ongoing physical or sensory differences | Visual impairment, deafness, paralysis, speech impairment |
| **Temporary** | Recoverable conditions | Broken arm, post-eye surgery, ear infection, hand injury |
| **Situational** | Constraints created by environment | Bright sunlight, noisy subway, holding a baby, wearing gloves |

{{< img src="images/contents/three-disability-types.png" alt="A scene showing three types of disability - permanent arm loss, temporary arm fracture, and situational constraint of holding a child" caption="Inspired by the Microsoft Inclusive Design framework" >}}

The one that matters most here is **situational disability**. Permanent and temporary disabilities affect specific people at specific times — but situational disability affects everyone, every single day. Watching a video without earphones, listening to voice navigation while driving, trying to read your phone in bright sunlight: every one of these moments is a situational disability experience.

When you add all three together, it's actually quite hard to find someone who will never need accessibility features.

---

## The Curb Cut Effect: Designing for One, Helping Everyone

In the 1970s in Berkeley, California, disability rights activists took matters into their own hands — literally — and chiseled down the curbs at street corners so wheelchair users could move freely between sidewalks and roads.

Something unexpected happened. Once the curbs were lowered, parents with strollers, travelers with rolling luggage, cyclists, and delivery workers all started using them too. A change made for one group ended up benefiting nearly everyone.

This is the **Curb Cut Effect**: design that removes barriers for a specific group often creates a better experience for all.

{{< img src="images/contents/curb-cut.jpg" alt="A lowered curb cut at a sidewalk corner - designed for wheelchair users, it benefits strollers, bikes, and luggage carts too" caption="Photo: <a href='https://unsplash.com/@35mmtodgt' target='_blank' title='Opens in new window'>Michael Hamments</a> / <a href='https://unsplash.com' target='_blank' title='Opens in new window'>Unsplash</a>" >}}

The same thing happens on the web.

- **Captions**: Made for deaf users → also used in noisy cafés, libraries, and by language learners
- **Keyboard accessibility**: Made for motor-impaired users → also loved by Vim users, power users, and anyone with a hand injury
- **Alt text**: Made for screen reader users → also helps search engines (SEO), slow connections, and broken image loads
- **Sufficient color contrast**: Made for colorblind users → also helps in bright sunlight, with aging eyes, and on low-quality screens

Accessibility features aren't "extras added for someone else." They're **just good design**.

---

## The Scale of It

According to the World Health Organization, **16% of the global population — about 1.3 billion people** — live with some form of disability. Add in temporary and situational disabilities, and the numbers grow dramatically.

Korea has already crossed the threshold into a super-aged society, with over 20% of the population aged 65 or older. Age-related vision loss, hearing decline, and reduced motor control are all directly connected to accessibility needs.

The reality is: **the person who will never need accessibility features barely exists.** Most of us just haven't noticed that we're already relying on them.

---

## For Developers: Practicing Accessibility on GAAD — AI Makes It Easier

If you've read this far and you're a developer thinking "okay, but where do I even start?" — here are just three things you can do today.

### The Basics (5 minutes is enough)

**① Check image alt text**

In Chrome DevTools, right-click any image → Inspect, and look for the `alt` attribute. If it's empty, add a description. If it's purely decorative, mark it explicitly with `alt=""`.

**② Keyboard tab test**

Put down your mouse and try navigating your site using only the Tab key. Can you see where the focus is? Does it move in a logical order? Doing this once reveals problems you'd never catch otherwise.

**③ Color contrast check**

Run Chrome DevTools → Lighthouse → Accessibility tab. It automatically flags contrast issues.

---

### Using AI as Your Accessibility Partner

Most developers are already using AI coding tools — Cursor, GitHub Copilot, Claude Code. You can use the same tools to actively improve accessibility.

**① Add accessibility rules to CLAUDE.md**

If you use Claude Code, add accessibility rules to your project's `CLAUDE.md`. Write them once and Claude will follow them automatically every time it generates code.

```markdown
## Code Guidelines

- All interactive elements must be keyboard accessible
- Images must include meaningful alt text (decorative images use alt="")
- Buttons and links must have clear labels
- Never convey information through color alone
- Prefer semantic HTML elements over div and span
```

No need to mention accessibility in every prompt — the rules are already baked into the project.

**② Create an accessibility review slash command**

In Claude Code, adding a markdown file to `.claude/commands/` makes it available as `/command-name`. A dedicated accessibility review command is easy to build and useful to have around.

`.claude/commands/a11y-review.md`:

```markdown
Review the current file or specified component against WCAG 2.2.

Check for:
- Keyboard accessibility (tab order, focus ring, keyboard traps)
- ARIA attributes (role, aria-label, aria-describedby, etc.)
- Image alt text
- Color contrast (minimum 4.5:1)
- Semantic HTML structure
- Error message accessibility

For each issue found, explain why it matters and provide corrected code.
```

Any time you want a quick accessibility check, just type `/a11y-review`.

**③ Paste axe-core errors into AI for fixes**

Copy the error messages from Lighthouse or axe-core and paste them directly into your AI tool. You'll get an explanation of the problem and corrected code in one go.

```
Fix the following axe-core accessibility errors:
[paste error messages here]
```

**④ Get alt text drafts from AI**

Describe the image and its context and AI can draft alt text for you. Just remember: **you still need to review it**. AI doesn't know the role an image plays in the full context of your content.

**One important caveat**

AI-generated code doesn't automatically come with good accessibility. In fact, quickly generated code often relies on `<div>` overuse and missing ARIA attributes. Build the rules in, run the slash command regularly — those two habits are what protect accessibility in the age of AI.

---

## Wrapping Up

Imagine someone opening your app for the first time.

Maybe they're navigating carefully with just the Tab key. Maybe they've got screen zoom turned on, reading the text line by line. Or maybe it's you — the version of you from this morning, watching that video on the subway without sound.

Accessibility isn't charity. It's **making sure more people can reach what you built**.

Just do one thing today. Tab through your own site once. That's enough to start.

**GAAD 2026, May 21. You are already an accessibility user.**