How web accessibility is measured
The Web Content Accessibility Guidelines, published by the World Wide Web Consortium, are the reference almost everyone uses. They are organised around four principles: content must be perceivable, the interface must be operable, the language and behaviour must be understandable, and the code must be robust enough for assistive technology to interpret. Each principle breaks down into success criteria, and each criterion is assigned a level — A, AA or AAA. Level AA is what most organisations, procurement rules and legal frameworks point at.
In practice the criteria describe ordinary building decisions. Images carry text alternatives. Video carries captions. Every control can be reached and operated with a keyboard alone. Text has enough contrast against its background to be read in poor light. Form fields have visible labels that are properly associated with their inputs. Headings run in a logical order. Nothing depends on colour alone to convey meaning.
Why web accessibility matters
The obvious reason is that a portion of every audience has a permanent impairment of sight, hearing, movement or cognition, and a site that excludes them excludes their money too. The less obvious reason is that most accessibility work helps everyone. Strong contrast is what makes a page readable on a phone in Kathmandu sunlight. Captions serve the person watching without sound on a bus. Clear labels help anyone filling a form in a hurry.
There is a commercial and legal dimension as well. For clients selling into Australia, the UK, the United States, Canada or the EU, accessibility obligations exist and complaints do happen. A good deal of the work also overlaps with search: alternative text, heading order, descriptive link text and clean semantic markup are read by crawlers as well as by screen readers.
Common mistakes with web accessibility
The costliest is buying an overlay widget marketed as instant compliance. An overlay is a script layered on top of the existing code; it cannot repair a missing label, a broken heading structure or a menu that a keyboard cannot reach, because those live underneath it. Many disabled users find overlays actively obstructive.
The second is trusting an automated scan alone. Scanners catch contrast failures and missing attributes; they cannot judge whether alternative text is meaningful, whether the reading order makes sense, or whether an error message explains what to do. Beyond that, the recurring faults are familiar: decorative images given descriptive alternative text instead of an empty attribute, brand colours that fail contrast in small text, carousels and dropdowns that cannot be operated without a mouse, placeholder text used in place of labels, and links that read simply as “read more” when heard out of context.
How to act on it
Put accessibility into the brief rather than the launch checklist, because retrofitting a finished design is where the cost appears. Then do three passes on the key templates: navigate the whole page using only the keyboard and watch where focus goes, check every text and interface colour against the contrast requirement, and read the page structure as a heading outline to see whether it makes sense on its own.
Fix labels, alternative text and focus states before anything cosmetic, and test with a real screen reader or, better, a real user. Say honestly what you have achieved and what remains rather than claiming compliance you have not verified. Raising it during web design and development costs far less than adding it later, and it pairs naturally with the responsive design work already happening.