A lot gets written about accessibility, most of it in the form of guidelines. This post takes a different route. I build accessible websites and have them tested by blind and visually impaired people. Much of what stays with you after those tests appears in no guideline. That is exactly what I am passing on here.
Five tests to start with
You do not need a handbook to find out where your site stands.
First, put the mouse away and use your site with the Tab key alone. Watch whether you can always see where you are, and whether you get back out of every overlay. If you get stuck in the cookie banner, real visitors do too.
Then enlarge the page to 200 percent with Ctrl and Plus. Many people browse like this permanently. If text overlaps or the menu button disappears, you know what to do.
Third, have your homepage read aloud. On a Mac, Cmd+F5 starts the built-in VoiceOver; for Windows there is NVDA, free of charge. If all you hear is “graphic, graphic, link”, you are experiencing your site the way a blind visitor does.
Also switch off images in the browser once and see whether the page still says anything. And take your phone out into bright sunlight. What you can no longer read there, some people can never read.
What blind testers taught me
For the association for blind and visually impaired people in Schleswig-Holstein I built a website that was signed off by blind users. The whole story is in the case study. Three lessons from those tests changed how I work.
Headings are navigation. Experienced screen reader users listen at more than 300 words per minute and jump from heading to heading, the way you follow a book by its table of contents. A bold line of text that is not a heading in the code does not exist for them.
The second point is the link list. A screen reader can read out all links of a page in a row. If what comes is “read more” twelve times, none of those links is worth anything. Since then I name every link after its destination.
And finally the entry point. The first press of the Tab key decides whether someone stays. Do you land on a link that jumps straight to the navigation? Or in a banner that swallows the focus and never gives it back?
Twelve mistakes I keep finding
The deleted focus outline. Many stylesheets contain outline: none because someone found the default frame ugly. That makes the site unusable for everyone navigating by keyboard. The better solution is a custom focus state that fits the design.
Placeholders instead of labels. The grey hint text in a form field disappears as soon as you type. Anyone who could not memorise what was asked is left in the dark. Every field needs a real label. With autocomplete attributes the browser even fills in name and address by itself.
Grey that is too light. The popular light grey on white often reaches a contrast ratio of barely 3 to 1. Body text needs 4.5 to 1. This can be measured, for instance with WebAIM’s Contrast Checker. Measure before you argue.
Error messages that are only red. Around nine percent of men cannot reliably tell red from green. A red-framed field tells them nothing. Every error message needs a sentence that says what is wrong and where.
Divs playing buttons. A clickable div looks like a button but cannot be reached with the keyboard. A real button element can do all of that out of the box.
Motion without an off switch. Anything that starts moving by itself needs a way to stop it. Your site should also respect the system setting for reduced motion. My own magic world switches itself off for exactly that reason when the operating system asks, and has a visible switch on top.
Click targets that are too small. Anything smaller than 44 by 44 pixels becomes a test of patience on the phone, all the more for people with trembling hands. Give buttons area and distance from their neighbours.
PDF instead of web page. A PDF without structure tags is a blank sheet to a screen reader. Most of the time the honest answer is to turn the content into an HTML page. If it has to be a PDF, then tagged and with a clean reading order.
Captchas. Distorted letters lock blind people out completely and annoy everyone else. There are invisible alternatives such as honeypot fields or a time check. My forms work without guessing games.
Overlay tools. Vendors promise accessibility via a script in two minutes. The associations of those affected reject these overlays, and in the US there have been rows of lawsuits despite an installed overlay. There is no way around your own HTML.
The missing language attribute. Without lang="en" in the source code, some screen readers use the wrong pronunciation altogether. One line of code fixes that.
Videos without subtitles. Subtitles help deaf people and, along the way, everyone sitting on the underground without headphones. A transcript underneath makes the content readable for search engines as well.
What can be fixed quickly
Six things cost hours, not weeks: the language attribute, meaningful page titles, a visible focus, alternative texts for the most important images, measured main colours and labels on all form fields. A site is not finished and accessible with that. But it is better than most.
What remains real work
Rebalancing a grown colour system, making a date picker accessible or clearing a mountain of old PDFs are projects, not afternoons. The order matters. Clean, semantic HTML comes first, then the finer points. ARIA attributes sit at the end of the list and want to be used sparingly. The first rule of ARIA says, not without reason, that no ARIA is better than wrong ARIA.
Tools I actually use
For colours I use WebAIM’s Contrast Checker, for a quick overview WAVE, for depth axe DevTools. Lighthouse is built into every Chrome and checks along at the press of a button. You still learn most from the screen reader itself. One warning from experience belongs here: automated tools find about half of the problems. The Tab test finds the rest, and what that leaves over is found by people who live with a screen reader every day. And when it comes to type, sizes and contrast I keep returning to leserlich.info, a resource by the German Federation of the Blind and Partially Sighted. The site is gold for anyone designing with accessibility in mind. For ticking off, all of this is available compactly in my WCAG checklist.
From the start, or retrofitting?
If you think about accessibility from the start, it costs almost nothing extra. It is then simply the way things are built. Retrofitting works too, page by page, best with the quick fixes first. Somewhat accessible is better than not at all. What the law demands I have sorted out in my post on the BFSG, and what accessibility brings your business you can read here. If you would like an honest look from outside: accessible web design is exactly my subject.
Frequently asked questions
Does the BFSG apply to my website?
As soon as you sell online or conclude contracts, very probably yes. A pure business-card site usually does not fall under it, and micro-enterprises are exempt for services. The details are in my post on the BFSG.
Is an overlay plugin not enough?
No. An overlay does not repair broken HTML, many affected people switch it off, and it does not protect against claims either. The money is better spent on real fixes.
What does it cost to make a website accessible?
The quick fixes from this post cost a few hours. A complete pass with audit and tests is, depending on size, a small to medium project. Accessibility is cheapest when building new, where it hardly registers.
How do I check whether my website is accessible?
The five tests at the start of this post give you an honest picture. After that, WAVE and Lighthouse help. The proof comes from people who work with a screen reader every day.
Do I have to meet WCAG one hundred percent?
The target is level AA. But do not wait for perfection. Every barrier you remove helps immediately.
Who tests something like this professionally?
People with disabilities. Everything else remains simulation. For this I work with blind and visually impaired testers.