11 minutes

Review one digital service for access barriers

A review anyone can run without tools or budget: walk the whole workflow, try it the way other people have to, make it fail on purpose, and write findings someone can act on.

What you’ll be able to do

Run a digital access review on one real service or workflow and record findings that name the step, who is stopped, what it costs them, who owns the change and what you did about it.
Compare the responses to this question and explain your choice: What is the best use of the two weeks?
Draft a digital access review for one service or workflow for your work, including service and the people it is for, step, barrier and who is stopped, owner and the change requested.

What a review is, and what it is not

A digital access review is not an audit and should not pretend to be one. An audit is a specialist assessment against the full standard, usually purchased, and it belongs in the process for a system the division is buying or rebuilding. A review is something you can run in an afternoon on a service that already exists, with nothing but the computer in front of you, to find the barriers that are stopping people now.

It covers the workflow, not the page. Start where a person starts — the invitation, the letter, the search, the flyer — and go all the way to the confirmation and the question afterward. Do it as yourself first. Then repeat the parts that matter with the settings other people have to use: keyboard only, text enlarged, sound off, a phone screen, a connection that drops. Then do the thing most reviews skip. Make it fail. Enter the wrong thing, let the session end, send the wrong file type, and read what the screen tells a person who now has to decide whether to start again.

Write findings someone can act on. A finding that says the form is not accessible produces a meeting. A finding that names the step, quotes what the screen says, names who is stopped and what it costs them, names an owner and offers specific wording produces a change. Then sort what you found into three piles — fix it yourself, route it with wording, send it up for a decision — so the review becomes work rather than a list.

One limit is worth saying plainly. A staff review is not review by the people the service is for. Disabled Minnesotans, disability-led organizations, interpreters and culturally specific organizations can be invited and paid as reviewers and co-designers, early enough that what they say can still change the design. They are not learners in this work and not a courtesy at the end of it. Their time is expertise, and expertise is paid for.

Checks you can run without tools or budget

Keyboard only: put the mouse aside. Can you reach every control, see where you are on the page, and finish the task?
Enlarged text: raise the text size well above the default. Does anything disappear, overlap, or force you to scroll sideways to read one line?
A phone screen: do the whole task on a phone, including sending any document. Is a photograph taken on a phone accepted?
Sound off, then captions on: can you follow any recording without sound, and are the captions right on the terms that matter?
A slow or interrupted connection: start the task, wait, come back. Are the answers still there?
Make it fail: a wrong entry, a wrong file type, an ended session, a password nobody has. What does the screen tell a person to do next?
The route that is not online: call the number, in the hours a working person would call. How long does it take, and does a person answer?
The confirmation: is it readable later, and does it say what was received, what happens next and roughly when?

A digital access review for one service or workflow

One page you can copy and run on a single online service, form or internal workflow.

Service and the people it is for Name the service or workflow, what a person is actually trying to accomplish, and who uses it: members of the public, families, community organizations, staff, or all of them. Then write the two or three situations you will hold in mind while you walk it — no device of their own, a mobile connection with a monthly limit, a screen reader, enlarged text, a communication device, a shared household screen, a first language that is not English.

Step, barrier and who is stopped One line per step, in the order a person meets them: finding out, getting on, getting in, reading the screen, finishing, confirmation, asking for help, and what happens when something fails. For each barrier, quote what the screen actually says or does, name who it stops, and say what it costs them — a second appointment, a borrowed phone, a lost deadline, a person who gives up and is never counted.

Owner and the change requested Name who owns the step: your own team, the business owner for the system, communications, the grants or contracts staff, the office that set the security rule. Write the change as wording or a setting somebody can act on — the sentence to replace, the session length to extend, the file type to accept, the phone number to publish — rather than as a description of the problem.

Fix, route or decide Sort every finding into three lists. Fix: inside your own authority, done this month. Route: send to the named owner with the quoted screen, who is stopped, and suggested wording. Decide: needs someone with authority over the requirement itself, and goes up with the cost written next to it, so the decision is made knowingly rather than by default.

What changed and who was told Record what you changed, what you sent onward, and what you decided not to change and why, so the next reviewer inherits the thinking instead of repeating it. Then close the loop with whoever raised the problem — the partner, the participant, the colleague — and say what happened to it. A review that never reaches the person who reported the barrier teaches them not to report the next one.

Copy the five fields into a blank page, walk one real service this month, make the changes you own, route the rest with wording, and tell the people who raised the problem what happened.

Browse and download only. Staff notes are not typed or saved on this page.

Fix it, route it, or send it up for a decision?

The confirmation your team writes says only that a submission was received, and nothing about what happens next.

The registration page your team publishes says nothing about how to ask for captions, an interpreter or materials in another format.

The slide deck posted with your recording is a scan with no readable text in it.

The online form ends the session after ten minutes and discards everything entered.

The help page uses program acronyms that are never explained.

The upload accepts one file type and rejects photographs taken on a phone.

Signing in requires a code sent to a mobile phone, and there is no other route.

The only way to reach a person is a phone line staffed three hours a day, and the paper form has been discontinued.

Which review finding can the person who receives it actually act on?

“The application system is not accessible and should be reviewed.”

“Several users reported difficulty with the sign-in process.”

“Getting in: after the code step the page says “Invalid entry” and nothing else, and the only code route is a message to a mobile phone. This stops applicants without a mobile phone or without coverage, and they lose the deadline. Owner: the business owner for the system. Requested change: add a voice-call code and printed backup codes, and replace the message with wording that says what failed and who to call.”

“Accessibility should be considered earlier in projects like this one.”

Make it fail on purpose, before somebody else does

What you can change

You control whether your test of a service follows the path that works or the path that breaks.

What to watch for

Do not review a digital service only by completing it correctly. Nearly every real barrier lives in what happens after a mistake, an ended session, a rejected file or a password nobody has.

Your next step

In your next review, spend half the time making the service fail, and write down exactly what the screen tells a person to do next.

Where to go next in this area

Accessible public communications — the documents, pages and notices a digital service is built out of
Language access in state programs — what an online process owes people who do not read English
Inclusive meetings and engagement — the same questions asked of a room, a call and a hybrid session
Program and service design — deciding how a service is delivered, before it is built
Responding to concerns and feedback — what happens after somebody tells you a process stopped them

Try a situation

An administrative team is asked to check a new online registration and accommodation-request form before it replaces email sign-ups for a DSD community listening session. They have two weeks, no testing tools and no budget. The program manager says a full accessibility audit is not possible in the time available, so the team should simply confirm that the form works.

What is the best use of the two weeks?

Confirm the form submits correctly and note in the record that a full audit should be scheduled later.

Run the checks the team can run — keyboard only, enlarged text, a phone screen, a slow connection, captions, the route that is not online and the help line — walk the whole workflow from the invitation to the confirmation, and write findings sorted into fix, route and decide.

Wait for specialist review so the team does not report something incorrectly.

Carry this forward

You do not need to be a specialist to find most barriers. Keyboard only, enlarged text, a phone screen, captions, a slow connection and a deliberate mistake will surface more than a conformance report will.
A review covers the workflow, not the page: how people learn it exists, how they get on, how they get in, how they read it, how they finish, what confirmation they keep, how they ask for help, and what happens when something fails.
A finding is usable when it names the step, quotes what the screen says, names who is stopped and what it costs them, names an owner, and offers wording or a setting someone can act on.
Sort every finding into fix it yourself, route it with wording, or send it up for a decision. That sorting is what turns a review into changes rather than a list nobody reads.
A staff review is not review by the people the service is for. Disabled Minnesotans, disability-led organizations, interpreters and culturally specific organizations can be invited and paid as reviewers and co-designers, early enough to change the design. Their time is expertise, and expertise is paid for.
Working this way is the program's larger movement in miniature: away from minimization, where one process for everyone counts as fair, toward acceptance and adaptation, where a service is built to change when the people it is for say what stopped them. The continuum describes the work, never a person.

A scenario about reviewing a registration form in two weeks with no budget, a completed digital access review you can copy, sorting practice that separates fix from route from decide, and a knowledge check on what makes a finding usable.

Run the review on one service or workflow this month. Fix what you own, route the rest with suggested wording, and tell the people who raised the problem what happened to it.

Your next step

Which service or workflow will you review, and who will you tell what you found?

Name the service and the day you will walk it end to end

Name the person who owns the step you expect to be worst, and how you will send them wording they can use as written

Name one thing you will pay a community reviewer or a disabled Minnesotan to look at, and where that money comes from

Browse and download only. Course notes are not typed or saved on this page.

Mark this lesson complete

Participation and course completion in this program do not count toward DHS-required training credits unless management, a director, or DHS leadership expressly approves an exception.