Start from user tasks

Accessibility work starts with a person trying to get something done. Not with a checklist, not with a browser extension, not with a score. If you start from the score, you fix what the tool sees. If you start from the task, you fix what stops people.

In this course we work on one page from start to finish: the registration page for a small web development meetup. It has a form with name, email, ticket type and contact preference, a schedule table, a speaker video and a guest modal. I made it deliberately flawed. We audit it, repair it and retest it with real evidence, one lesson at a time.

Write the task before you open the code

The task on this page is one sentence: a visitor registers for the meetup and knows it worked. Now add the conditions under which that sentence must stay true.

I keep them in a plain text file next to the project:

tasks.md

1. Register without a mouse. Keyboard only.
2. Register without sight. VoiceOver in Safari, NVDA in Firefox.
3. Register at 400% zoom on a 1280px wide screen.
4. Register with reduced motion and with forced colors on.
5. Make three mistakes in the form and recover without retyping anything.

Each line is a user task: who does what, under which input, perception or cognitive constraint. Notice that none of them mentions a WCAG number yet. The standard comes later, as a way to name the barriers we find.

Run the first task right now

Let’s take task 1 on the flawed page. Open it, click in the address bar, and press Tab repeatedly. Say out loud where focus lands.

Here is what I get on the broken page:

Tab 1: "Web Dev Meetup" logo link
Tab 2: Full name field
Tab 3: Email field
Tab 4: "Privacy policy" link in the footer

The Register button never receives focus. The reason is in the markup:

<div class="btn" onclick="submitRegistration()">Register</div>

A div is not focusable and has no keyboard behavior. A mouse user never notices. A keyboard user cannot finish the task at all. That single observation is worth more than a page of tool output, because it describes a person who cannot register.

Why this order matters

The common mistake is to treat accessibility as a badge to earn at the end, for one imaginary user. Real users differ. A screen reader user and a low vision user hit different walls on the same page, and a checklist written for neither catches neither.

So my advice is to write the tasks first, with the conditions spelled out, and only then open the inspector. Write down what you expect to happen before you try it. When the result differs, you have found a barrier, and you already know which task it blocks.

Try this on your own project: pick the one page that makes you money or gets you signups, write its task in one sentence, and run it with the keyboard only. Write down the first place you get stuck.