Accessibility in Web Design: The Practical Standards I Build In From Day One

Accessible web design gets treated as an afterthought on a lot of projects I audit, usually because it's assumed to mean a slow, expensive compliance exercise. In practice, most of what makes a site accessible also makes it faster, clearer, and easier to use for every visitor — not just people using screen readers or keyboard navigation. That's why I build these standards in from the first wireframe rather than trying to retrofit them after launch.

Colour Contrast Is Non-Negotiable

Low-contrast text over busy background images looks stylish in a mockup and becomes unreadable the moment someone views it on a phone in daylight, let alone for a visitor with low vision. I check contrast ratios against the WCAG 2.1 AA standard as part of the design review, not after a client complains they can't read their own site. This one habit alone fixes a surprising number of usability complaints that have nothing to do with disability at all.

Every Image Needs Real Alt Text

Alt text isn't just an SEO trick, though it helps there too. It's how someone using a screen reader understands what an image is showing. I write descriptive alt text for every meaningful image and leave decorative images correctly marked as empty, so screen readers don't waste someone's time reading out a decorative border graphic on every page.

Keyboard Navigation Has to Actually Work

Not everyone uses a mouse or a touchscreen. I test every site by unplugging the mouse and tabbing through it: can you reach every link, button, and form field in a sensible order? Does the focus state show clearly where you are on the page? A surprising number of otherwise well-designed sites fail this basic test because a custom dropdown or a modal was built without keyboard support in mind.

Forms Need Labels, Not Just Placeholder Text

Placeholder text that disappears the moment someone clicks into a field is a common accessibility failure, because it removes the only cue for what that field is once someone starts typing or if a screen reader announces it incorrectly. Every form field I build gets a proper, persistent label, and every error message is written clearly enough that someone knows exactly what to fix and where.

A few numbers worth knowing:

• The World Health Organization estimates that over one billion people globally live with some form of disability, a meaningful share of any website's potential audience.
• W3C's Web Accessibility Initiative research consistently shows that accessible design patterns — clear labels, sufficient contrast, logical navigation — improve task completion rates across all users, not only those with disabilities.
• Legal accessibility complaints and lawsuits related to inaccessible websites have risen steadily worldwide over recent years according to industry accessibility trackers, making this an increasing business risk as well as a usability one.

Semantic HTML Does More Work Than People Expect

Using actual heading tags, list elements, and button elements instead of styled <div> tags pretending to be interactive elements is one of the simplest accessibility wins available, and it also happens to help search engine optimization because search engines rely on the same structural signals that assistive technology does. I treat clean, semantic markup as a baseline requirement on every web development project, not an accessibility-specific add-on.

Motion and Video Need an Off Switch

Auto-playing carousels, background video, and animated transitions look impressive in a pitch deck and can be genuinely disorienting or even triggering for some visitors. I build in respect for the reduced motion preference browsers expose, and I make sure autoplaying media has clear pause controls, rather than assuming everyone wants the same visual experience.

Link Text Needs to Make Sense on Its Own

A page full of "click here" links is a small thing that causes a real problem for screen reader users, who often navigate a page by pulling up a list of every link on it out of context. Link text that describes its destination clearly — read our case studies rather than click here — helps every visitor scan a page faster, not just those using assistive technology.

Responsive Text Sizing Matters as Much as Layout

Fixed pixel font sizes that don't respond to a visitor's browser zoom settings are a common accessibility gap I still see on older sites. I build type scales using relative units so that someone who increases their browser's text size for readability gets a layout that adapts cleanly, instead of overlapping text or a broken mobile menu. This is one of those details that costs almost nothing to get right at build time and is genuinely painful to retrofit later.

Testing With Real Assistive Technology Beats Guessing

Automated accessibility scanners catch a useful baseline of issues, but they miss a lot of the experience that actually matters — whether a screen reader announces a form error in a way that makes sense, whether tab order follows a logical reading path. Where the budget allows, I test key user journeys with an actual screen reader rather than relying purely on an automated report, because the two don't always agree on what a good experience looks like.

None of this needs to slow down a project timeline meaningfully. Building with these habits from the start is a matter of choosing the right component patterns early rather than adding a separate accessibility phase at the end. Most of the clients I've worked with are surprised at how little extra time it actually adds once a team is used to designing this way by default.

Frequently Asked Questions

What accessibility standard should my website meet?

WCAG 2.1 Level AA is the widely accepted practical baseline most businesses should target. It covers the areas that matter most — contrast, keyboard access, alt text, and form labelling — without demanding an unrealistic level of technical complexity for a typical business site.

Does accessible web design cost more?

Building it in from the start costs very little extra, since most of it is about how components are structured rather than adding new features. Retrofitting accessibility onto an existing site after launch is where the real cost shows up.

Does accessibility help SEO?

Indirectly, yes. Many accessibility practices — semantic headings, descriptive alt text, clear link text — overlap directly with what search engines use to understand and rank a page.

Do I need to hire a specialist accessibility auditor?

For most business websites, no. A development team that understands and applies WCAG principles from the design stage covers the vast majority of real-world accessibility needs without a separate audit engagement.

Can an existing website be made accessible without a full rebuild?

Often, yes. Contrast fixes, alt text, form labelling, and keyboard navigation improvements can usually be applied to an existing site without touching its overall structure, though a genuinely inaccessible template may need deeper changes.

If you want to see how accessibility fits into the bigger picture, I cover the full process in how I take a website from brief to launch.

Further Reading

• W3C: Web Content Accessibility Guidelines (WCAG)
• WebAIM: Colour Contrast Checker
• MDN Web Docs: Accessibility

Accessible design is one of those areas that quietly improves a site for every single visitor, not just the ones it's most often associated with. If you'd like an honest look at where your own site stands, see how we work through these details on our how we work page, or get in touch through our contact page.