Usability & Accessibility

A feature can pass every functional test and still fail a human: the button nobody finds, the error message nobody understands, the form a blind traveler's screen reader cannot navigate. Two disciplines catch what functional testing can't. Usability asks "can people actually use this?"; accessibility asks "can all people use it?" And the crucial reframe for a tester: both are testable — not matters of taste. This page shows the testable core of each, and hands you one skill you can use on any product tomorrow.

Usability Is Testable

The trap is thinking usability means opinions — "I'd prefer blue." It doesn't. Usability is measured against task success: give a real person a real task — "book a 3-night stay at The Juniper Inn" — and watch. Did they succeed? How long did it take? Where did they hesitate, backtrack, or give up? Those are data, not preferences. Formal usability testing — watching representative users attempt representative tasks — is a specialist practice, but every tester does the cheap version daily: noticing your own stumbles and filing them as Chapter 6's feedback lane, argued with evidence. "I couldn't find the cancel button for 40 seconds; here's the screen recording" is a usability finding with data attached — not "I don't like the layout," which is the version that gets ignored. Success, time, and stumble-points turn taste into testable.

What Accessibility Means

Accessibility — often written a11y (an "a", 11 letters, a "y") — means designing so people with visual, motor, hearing, and cognitive differences can use the product. Concretely: screen readers (software that reads the page aloud for blind users — and you'll hear the difference when developers never tried one: buttons announced as "button button button," images as nothing at all), keyboard-only navigation (for people who can't use a mouse), color contrast (text readable for low-vision and color-blind users), and captions (for deaf users). Each serves a real population, and — the reframe that matters — each is checkable.

WCAG, at Beginner Altitude

The web's accessibility standard is WCAG — Web Content Accessibility Guidelines. Don't memorize its checklist; learn its four principles, which spell POUR: content must be Perceivable (can you sense it — text alternatives for images, captions for audio), Operable (can you use it — keyboard access, enough time), Understandable (can you follow it — clear language, predictable behavior), and Robust (does it work with assistive tech — screen readers, braille displays). Principles over checklist-memorization, because the principles let you reason about any element; the checklist just lists instances of them. And one honest sentence about stakes: in much of the world, accessibility is law, not courtesy — public-sector and large commercial sites face real legal requirements, which is why "a11y" appears in more QA postings every year.

The Keyboard Tour — Your Tomorrow Skill

Here's a technique you can run on any website tomorrow, with no tools: the keyboard tour. Put the mouse away entirely. Navigate the whole flow with Tab (move to next element), Shift+Tab (previous), Enter/Space (activate), arrow keys (within components). Can you complete a booking? Where does the focus indicator vanish so you can't tell where you are? Where does focus get trapped — enters a component and can't escape? Every trap and every dead end is a bug that locks out keyboard-only users entirely. Alongside it: zoom the text to 200% (does the layout survive, or does content overlap?), run a contrast checker (a one-line tool category — many free browser extensions), and check alt text on the property photos (the description a screen reader reads aloud). Four checks, no specialist training, real bugs on most products' first try.

FW-418, and the Curb-Cut Effect

You run the keyboard tour on Fernway's redesigned date picker. Focus enters the calendar, tabs through the days... and gets trapped: Escape doesn't exit, no keyboard path reaches "confirm." FW-418. Now reframe it, because the reframe is the whole lesson: this isn't a niche edge case for a rare user. A traveler using only a keyboard — through disability, injury, or preference — cannot book at all. "Some of our travelers cannot give us money" is how that bug reads once you name who's affected, and the severity follows. The deeper point closes the empathy trap: accessibility is engineering quality, not charity. The curb-cut effect names why — sidewalk curb cuts were built for wheelchairs and turned out to help everyone with a stroller, a suitcase, a delivery cart. Captions help in loud rooms; keyboard navigation helps power users; high contrast helps everyone in bright sunlight. Fixes for some help all — which is why accessible products are simply better products, and why framing a11y as a favor to a minority misunderstands it entirely.