Imagine you built a beautiful website. Clean design. Smooth animations. Then one day, a blind user opens it on her screen reader and hears only silence. Or worse — random words with no meaning. This is happening on millions of websites right now. Yours might be one of them.
Last year, I watched a YouTube video where a blind developer named Marco tried to book a flight on a popular airline website.
He pressed Tab. His screen reader said “button”.
He pressed Tab again. “button”.
Again. “button, button, button, link, button, edit text, button”.
No labels. No headings. No way to know what any of these buttons actually did.
After 20 minutes of trying, Marco closed the tab and used a competitor instead.
That airline didn’t just lose a customer. They lost a customer who needed their service the most. And they didn’t even know it happened.
This is the story behind every accessibility guideline you’ll read in this article. So before we talk about WCAG, ARIA, or POUR principles, remember: we are not writing code for browsers. We are writing code for people.
Let me show you how to do this right.
What This Guide Will Teach You
By the end of this article, you will understand:
- The four golden rules of accessible websites (called POUR)
- The three levels of accessibility (A, AA, AAA) and which one your project needs
- What's new in WCAG 2.2 and why it matters
- How ARIA works (and when NOT to use it)
- How blind users actually navigate websites (it's not what you think)
- The tools real users depend on every day
Section 1: The Four Words That Make a Website Accessible (POUR)
Every accessibility guideline in the world traces back to four simple ideas. Web experts call them POUR. You can think of them as the four questions every website should pass.
P — Perceivable: Can the User Sense Your Content?
If your website has a beautiful image but no description, a blind user perceives nothing. If your video has no captions, a deaf user perceives only silence. If your text is light gray on white background, a low-vision user perceives only blur.
Perceivable means: Every piece of information must reach the user somehow — through sight, sound, or touch.
O — Operable: Can the User Actually Use It?
Some people cannot use a mouse. They use only a keyboard. Others use voice commands. Some use a single switch they tap with their head.
If your website only works with a mouse, all these users are locked out.
Operable means: A user must be able to operate every feature without depending on any single input method.
Simple example: Try this on your own website right now. Unplug your mouse. Can you fill out a form using only Tab and Enter? Can you open a dropdown menu? Can you close a popup? If the answer is no, your site is not operable.
U — Understandable: Does Your Content Make Sense?
A website can be perceivable and operable but still confusing. If your error messages say “Error 4xx”, users have no idea what to do next. If your form suddenly submits without warning, users feel lost.
Understandable means: Both your content and the way it behaves should be predictable and clear.
Simple example:
<!-- ✅ Good: clear and actionable --> <p style="color: red"> <strong>Email is required.</strong> Please enter your email address to continue. </p>
R — Robust: Will It Work With Any Tool?
Some users have a brand new iPhone. Others use a 10-year-old screen reader on an old laptop. Some use Chrome, others use Firefox, and many depend on tools you have never heard of.
Robust means: Your code must be clean enough that any tool, present or future, can interpret it correctly.
Simple example: Use real HTML elements like <button> and <nav> instead of styled <div> everywhere. Real HTML works with every browser and every assistive technology. Custom code might not.
Memory Trick for POUR
When you build any feature, ask yourself these four questions:
- P — Can a blind user understand this? (Perceivable)
- O — Can a keyboard-only user use this? (Operable)
- U — Will this confuse anyone? (Understandable)
- R — Will this work in every browser and screen reader? (Robust)
Section 2: The Three Levels of Accessibility (And Which One You Actually Need)
WCAG defines three conformance levels. Most articles explain them in complicated language. Here is the truth in simple words.
Level A — The Bare Minimum
This is the floor. If your website fails Level A, some users literally cannot use it at all.
Example: An image with no alt text. A form input with no label. A keyboard trap that prevents users from leaving a popup.
Level A is not a goal. It is the absolute minimum every website should meet.
Level AA — The Real Target
This is what most laws, contracts, and corporate policies require. The ADA in the United States, the European Accessibility Act, and many other regulations point to WCAG Level AA.
Example: Color contrast of at least 4.5 to 1 for normal text. Text can be resized up to 200 percent without breaking. All functions work with keyboard.
When someone says “make this website accessible”, they almost always mean Level AA.
Level AAA — The Gold Standard
This is the highest level, and it’s hard to achieve for an entire website. WCAG itself recommends not requiring AAA for all content.
Example: Sign language interpretation for every video. Color contrast of 7 to 1. No more than three flashes per second of any content.
AAA is great for specific pages where it matters most — like emergency information, government services for disabled citizens, or healthcare portals.
Which Level Should You Pick?
| Project Type | Recommended Level |
|---|---|
| Personal blog | Level A as minimum, aim for AA |
| Business website | Level AA (required by most laws) |
| Government website | Level AA (often legally required) |
| Healthcare or banking | Level AA, with AAA for critical pages |
| Children's content | Level AA, with extra care for clarity |
Section 3: Meet the Tools That Disabled Users Depend On
Screen Readers (For Blind and Low-Vision Users)
A screen reader is software that reads what’s on the screen aloud.
| Screen Reader | Used On | Cost |
|---|---|---|
| NVDA | Windows | Free |
| JAWS | Windows | Paid (expensive) |
| VoiceOver | macOS, iOS | Built-in, free |
| TalkBack | Android | Built-in, free |
| Narrator | Windows | Built-in, free |
If you have never tested with a screen reader, install NVDA today. It takes five minutes. You will instantly understand things about accessibility that no article can teach you.
Screen Magnifiers (For Low-Vision Users)
These tools zoom in on parts of the screen. ZoomText, Windows Magnifier, and macOS Zoom are common examples.
If your website breaks at 200 percent zoom, magnifier users cannot use it.
Speech Recognition (For Motor-Impaired Users)
Software like Dragon NaturallySpeaking lets users control their computer entirely by voice. They say “click submit” and the Submit button activates.
For this to work, your visible button text must match the button’s accessible name. If your button shows “Submit” but its aria-label is “Send Form”, a voice user saying “click submit” will fail.
Alternative Keyboards and Switches
Some users with severe motor disabilities use switches — single buttons they can press with a finger, foot, or head. Each switch press selects something on screen.
For switch users, every interactive element must be reachable in the natural tab order. No exceptions.
Refreshable Braille Displays
Deaf-blind users often use braille displays — devices that physically translate screen content into braille characters they can feel.
These devices read your HTML through the screen reader, so all the same accessibility rules apply.
Section 4: How Blind Users Actually Navigate Your Website
Here is something most developers don’t know: blind users do not read your website top to bottom.
That would be slow and painful, like listening to an entire audiobook just to find one paragraph.
Instead, screen reader users scan websites using keyboard shortcuts that jump between specific element types.
The Real Navigation Patterns (Tested in NVDA)
| What User Wants | Keyboard Shortcut | What Happens |
|---|---|---|
| Jump to next heading | H | Moves to next h1, h2, h3, etc. |
| Jump to next landmark | D or R | Moves to next nav, main, banner, etc. |
| Show all links | K or Insert + F7 | Opens a list of every link on the page |
| Jump to next form field | F | Moves to next input, select, textarea |
| Jump to next button | B | Moves to next button |
| Jump to next table | T | Moves to next data table |
| Jump to next list | L | Moves to next list |
| Read entire page | Insert + Down | Reads from top to bottom |
Frequently Asked Questions
Do I need to memorize all WCAG success criteria?
No. Focus on understanding the four POUR principles deeply. Refer to specific criteria when needed. The W3C provides a free quick reference at w3.org/WAI/WCAG22/quickref.
Will accessibility slow down my development?
Initially, a little. But once you build accessibility into your workflow, it becomes natural. Many accessible practices also improve SEO, performance, and code quality.
Is ARIA difficult to learn?
The basics are simple — roles, properties, states. The hard part is knowing when NOT to use ARIA. Start with native HTML, and reach for ARIA only when needed.
Can I make my old website accessible without rebuilding it?
Yes, in most cases. Start by running an automated audit, fixing easy issues like alt text and form labels, then work through harder problems like color contrast and keyboard navigation. Full accessibility may take weeks or months, but you can make significant improvements quickly.
Are there legal risks if my website isn't accessible?
Yes. Lawsuits over inaccessible websites are increasing every year in the US, EU, Canada, Australia, and many other countries. Even if you’re not sued, you lose customers and damage your brand.
How do I know when my website is "accessible enough"?
You aim for WCAG 2.2 Level AA conformance, test with real users with disabilities when possible, run automated tests regularly, and treat accessibility as an ongoing practice — not a one-time project.
