Most digital accessibility in web design work is done by people who have never watched somebody use a screen reader.
That is not a criticism; it is the situation, and it explains why so much of it consists of running an automated checker and fixing whatever it flags. The checker finds real problems. It cannot tell you whether somebody can actually complete the task your page exists for, which is the only question that matters.
Digital accessibility in web design is mostly the discipline of building things that work without sight, without a mouse, and without assuming anything about the person.
The four principles of WCAG 2.1 Levels, in plain terms
WCAG 2.1 Level AA organises everything under four headings, and they are more useful as questions than as categories.
- Perceivable. Can the information reach somebody through whichever senses they use? Text alternatives for images, captions for video, sufficient contrast, content that survives being zoomed.
- Operable. Can somebody use it with whatever they have? Keyboard operation throughout, enough time to complete things, no content that flashes in ways that trigger seizures.
- Understandable. Is it predictable and clear? Consistent navigation, plain language, error messages explaining what to fix rather than announcing that something is wrong.
- Robust. Does it work with assistive technology? Valid markup, proper roles and labels, nothing that depends on one browser behaving a particular way.
Level AA is the standard most organisations work to and the one that appears in procurement.
The Core Requirements of Digital Accessibility in Web Design
1. Semantic HTML does most of the work
The single highest-value habit, and it costs nothing.
A `<button>` is focusable, operable by keyboard and announced correctly to a screen reader. A `<div>` styled to look like a button is none of those things until somebody rebuilds all three by hand, usually incompletely.
The same applies to headings, lists, form labels, tables and landmarks. Used properly, they give assistive technology a structure it can navigate: jump between headings, list all the links, skip to the main content.
Most accessibility failures are not exotic. They are custom components replacing native elements that already worked.
2. Keyboard operation is the fastest test win for digital accessibility
- Put the mouse aside and tab through your most important journey.
- Can you reach everything? Can you see where you are? Does the order make sense? Can you escape a menu or a modal once inside it?
- The invisible focus indicator is the most common failure, and it is usually deliberate: somebody removed the outline because it interfered with the design. That single decision makes keyboard navigation guesswork.
3. Forms are where it matters commercially
- Every field needs a properly associated label. Placeholder text is not a label, because it disappears the moment somebody starts typing.
- Errors need to be announced to assistive technology, not only shown in red. Colour alone is never sufficient to convey anything.
- Group related fields sensibly, keep the tab order logical, and describe what is expected before somebody gets it wrong rather than after.
- An enquiry form that cannot be completed with a keyboard turns away somebody who had already decided to contact you.
4. Content is part of it
- Write in plain language. Complex sentences exclude people with cognitive differences, people reading in a second language, and anybody in a hurry.
- Use real headings in a sensible order, since screen reader users navigate by them.
- Write link text that makes sense read on its own. “Click here” repeated twelve times gives somebody listing the links no information at all.
- Write alternative text that describes what the image conveys in context, and leave it empty for purely decorative images so it gets skipped.
Testing honestly
- Automated tools catch a portion of failures. Use them first because they are free and fast, and do not stop there.
- Then keyboard navigation, browser zoom at 200 per cent, and a contrast check on body text.
- Then, where you can, watch somebody who uses assistive technology attempt a real task. Nothing else surfaces the same problems.
- Publish an accessibility statement describing your standard, how you test and what you know is not yet fixed. Stating known gaps reads as more credible than claiming full compliance.
Where performance and environmental impact both apply, treat them as the same lever: reducing unnecessary data transfer and processing supports a faster experience while lowering estimated digital carbon, though environmental figures remain modelled rather than directly measured.
Our sustainable web design work builds to WCAG 2.1 Level AA from the brief rather than auditing at the end.