Accessibility

People who build screens tend to build for someone like themselves: good eyesight, a mouse under the right hand, a large monitor in a quiet office. Anyone outside that picture hits a wall the moment the page loads, and the team that shipped it stays unaware for a long time. The page isn't broken in the way a crash is broken. It opens, it renders, it simply cannot be operated, and nothing about that lands in an error log.

For years the support queue showed what this looked like from the other side. A customer would write in to say that the Tab key never reaches the save button, and the reply would suggest clicking it with the mouse. The question came from someone who cannot use a mouse, and the answer told them to use one. Nobody involved meant any harm. It just had never occurred to the team that such a customer existed. Tickets like that usually arrive once. When the second reply repeats the first, people stop writing and switch products, so the only trace left in the numbers is an unnamed churn event.

As long as the trouble reads as a fact about a person, no one owns the fix. That reframing is the work the word accessibility does. "She can't use it because she can't see" leaves nothing to repair. "She can't use it because the image has no text description" names a file, a line, and an engineer. Moving the cause out of the body and into the interface is close to the whole contribution of the concept. Once the problem is written down as a defect, it sits in the same list as other defects and can compete for priority like anything else.

Then accessibility law changed the order of that list. These are rules requiring that services be usable by people with disabilities — the Americans with Disabilities Act in the United States and the European Accessibility Act are the two most often cited in software contracts. Public sector buyers and companies above a certain size face complaints, remediation orders, or lawsuits when they ignore them. Once a thing that had been framed as consideration became a thing that costs money to skip, accessibility moved from work done in spare weeks to a line on the release checklist. The shift shows up in who asks about it. Five years ago the question came from a designer who cared; now it arrives in a procurement questionnaire with a deadline attached, and the person chasing an answer is usually in sales rather than design.

The terms under accessibility fall into three groups: the standards that say how far a product has to go, the implementation details someone changes in the interface, and the assistive technology that reads the interface back to the person using it.

Standards is a single entry. The Web Content Accessibility Guidelines (WCAG) come from the international body that maintains web standards, and they sort requirements into three levels — A, AA and AAA. Most teams aim at AA, the middle one, because it is what contracts and public procurement usually name. The value of the document is that many of its criteria are numeric, so a disagreement can be settled rather than argued. The best-known example asks for a contrast ratio of at least 4.5 to 1 between body text and its background: light grey text on white sits near 2.8 to 1 and fails, while the same grey a few steps darker passes. The criteria hang off four principles — that information not depend on one sense alone, that every function work without a mouse, that wording and behavior stay predictable, and that the result behave the same across browsers and assistive software. Accessibility clauses in enterprise and government contracts are mostly written on top of this document, so a sentence in a vendor questionnaire almost always traces back to a numbered criterion here.

Assistive technology is also a single entry. A screen reader speaks the contents of a screen aloud. It does more than read top to bottom: people jump heading to heading, pull up a list of every link or button, and skim a document the way a sighted reader skims with their eyes. That is why most of the implementation group is really about what reaches this program and under what name. A toolbar of unlabeled icon buttons is announced as "button, button, button". The same toolbar with labels is announced as "share button, comment button, delete button". One version carries no information at all; the other works as a table of contents. The same gap opens up in forms. A field whose label is only a placeholder that vanishes on typing leaves the listener with an input box and no idea what belongs in it, while a properly associated label is read out every time focus lands there.

Implementation has seven entries, each touching a different layer of the interface.

1. Semantic markup — using the tag that matches what an element actually is. A box styled to look like a button is announced as a box and cannot be reached with the keyboard. Built as a real button, it gets both behaviors for free.
2. ARIA — Accessible Rich Internet Applications, a set of attributes that describe a role or a state that no tag can express on its own. It is how a custom dropdown says whether it is currently open or closed. It is meant for the gaps, not as a substitute for the tag that already does the job.
3. Alt text — a written description of an image. "Image" and "Q3 revenue chart, up 12 percent from July" are not the same sentence to someone listening to the page.
4. Keyboard navigation — making every function reachable with Tab, Enter and the arrow keys. It serves people who cannot use a pointing device, and it serves anyone whose mouse died five minutes before a deadline.
5. Focus ring — the outline showing which element is currently selected. Designers often ask for it to be removed because it looks untidy in a mockup, and without it a keyboard user presses Enter without knowing where they are.
6. Touch target — reserving enough area for a fingertip. The icon can be drawn at 16 points as long as the region that responds to a tap is nearer 44.
7. Color blindness — never carrying meaning in color alone. A list that marks success with a green dot and failure with a red one is unreadable for roughly one man in twenty, so the dot needs a shape or a word beside it.

One term sits across the edges of those groups. Reduced motion reads an operating system setting and scales back animation for people who feel dizzy when large areas of the screen move. It belongs to accessibility and to interaction design at the same time.

Standards decide how far to go, implementation builds it in the interface, and assistive technology delivers the result to the person. Miss one and the other two stop mattering. Fill in every alt text while leaving the buttons as styled boxes and the page reads beautifully and clicks nowhere. Make every control reachable by keyboard without showing where focus currently sits, and the path is open while the person walking it has no idea where they stand.

"This grey runs about 3 to 1 against the background, so it misses AA. I'm taking it one step darker."

The color is being changed against a published threshold, not a preference.

"Open the modal, press Tab, and focus escapes to the page behind it. You can't get to save."

Anyone not using a mouse cannot finish the task on this screen.

"The security review from this enterprise account has accessibility questions in it. How far can we get by the deadline?"

It is now a contract condition, and someone needs a read on the current state.

At Pagedeck the term came up constantly during the quarter before a public sector contract closed. The questionnaire Sofia brought back had twelve accessibility lines in it, and Theo confirmed that nine already passed. The remaining three all pointed at the document editor. Its toolbar had been hand-built out of plain containers, so Tab skipped over it, and tables announced themselves with no name at all.

The judgment Noa and Theo had to make was about where to repair it. Patching that one toolbar would take two weeks and the next screen would reproduce the same problem. Fixing the shared components underneath would take six, after which every later screen would inherit the correct behavior. Weighing that against the contract date, Mia chose the toolbar first and put the shared components on the next quarter's plan. She also required that any new screen built in the meantime follow the shared-component rules already, so that the list of things to fix stopped growing.

The most common mistake is reading accessibility as work done for blind users. Introductions always lead with screen readers, so the association sets early. The actual range is far wider: people whose hands shake and miss small buttons, people who cannot hear an alert sound, people who lose the thread of a long sentence. It also covers anyone temporarily in one of those situations — carrying a bag on the subway with one hand on the phone, or reading pale grey text outdoors in direct sun. Read narrowly, the work gets deprioritized with a line like "how many of our users can that really be". The people lost afterward are not the few in that sentence. They are the many who cannot read the pale text in bright light and quietly close the tab. That is also why the business case rarely rests on the size of any one group. Captions get used on muted phones in open offices, larger tap areas help people typing on a moving train, and clear error wording saves support time for everyone who reads it.

The second mistake is treating it as a check performed just before release. It arrives as a checklist, so it looks like something to sweep at the end. Most of what fails, though, is structure rather than color. Which tag an element was built from, the order things are announced in, how a state is communicated — those get decided while the screen is being assembled, and changing them later means rebuilding. Left alone, the pattern is familiar: two weeks before launch a few contrast values get corrected and the screens nobody can reach by keyboard ship exactly as they are. Pull the check forward into the mockup stage and the same work shrinks to hours. Checking a contrast value while picking the text color, and pressing Tab once while laying out a screen, is a small task early and a rebuild late. Teams that make the shift usually do it by moving the rules into the design system — contrast-approved color tokens, components that ship with their own focus styles and labels — so that following them is the path of least effort rather than a separate pass over finished work.