Designing Accessible Websites: A Practical Checklist

Accessibility gets introduced to a lot of designers the wrong way: as a compliance checklist handed down late in a project, framed around legal risk rather than the people it actually serves. That framing does real damage, because it makes accessibility feel like a tax on "real" design work rather than what it actually is — a core part of designing for the full range of people who will actually use a website, including the roughly one in six people worldwide living with some form of disability that affects how they browse the web.

Contrast and color are the most common, most fixable failures

Insufficient color contrast between text and its background is consistently the single most common accessibility failure found in automated audits across the web, and it's also one of the cheapest to fix — often a matter of darkening a text color by a shade or two, with minimal visual impact on the overall design. Pairing this with never relying on color alone to convey meaning (covered in more depth in the color theory discussion elsewhere) closes out the two most impactful, least disruptive fixes available to any design team.

Keyboard navigation reveals a lot about underlying structure

Try navigating an entire page using only the Tab key, without touching a mouse. Can every interactive element be reached? Is the current focus always visible? Does the tab order follow a logical sequence rather than jumping unpredictably around the page? This single exercise, which takes only a few minutes, reliably surfaces structural problems that a purely visual review misses entirely — custom-styled buttons built from a `div` instead of a real `button` element, for instance, are frequently invisible to keyboard navigation entirely, a defect a mouse-only review would never catch.

Semantic HTML does more accessibility work than any ARIA attribute

There's a persistent myth that accessibility is primarily about adding ARIA attributes to markup. In practice, using the correct native HTML element for the job — a real `<button>` instead of a styled `<div>`, a proper `<label>` associated with its form input, heading tags (`<h1>` through `<h6>`) used in a genuine hierarchical order rather than picked for their default font size — handles the overwhelming majority of what assistive technology needs, automatically, with zero extra markup. ARIA attributes matter for genuinely custom components without a native equivalent, but reaching for them before exhausting semantic HTML is usually solving a problem that shouldn't exist in the first place.

Alt text needs to describe purpose, not just contents

"Image of a laptop" technically describes an image but tells a screen reader user almost nothing about why that image is there. Better alt text describes the image's function in context — "Dashboard showing monthly revenue trending upward" conveys the same information a sighted user would take away at a glance. Purely decorative images that add no informational value should have empty alt attributes (`alt=""`) so screen readers skip over them entirely, rather than forcing a user to sit through a description of an image that was never meant to convey information in the first place.

A practical, non-exhaustive starting checklist

• Check every text/background color combination against WCAG AA contrast minimums
• Tab through the entire page and confirm every interactive element is reachable, with a visible focus state
• Use semantic HTML elements as the default, reserving ARIA for genuinely custom components
• Write alt text that describes function and context, and leave it empty for purely decorative images
• Ensure form inputs have properly associated, visible labels — not just placeholder text, which disappears once a user starts typing
• Test with a real screen reader occasionally, not just automated tools, which catch a meaningful but incomplete share of real issues

Accessibility built into the design process from the start is rarely a significant additional burden — most of the meaningful fixes are small, specific habits rather than large redesigns. It's almost always more expensive, both in effort and in the compromises required, when it gets addressed as a retrofit after launch instead of a default practice from the first wireframe onward.

Motion and animation need an accessible default too

Accessibility discussions often focus heavily on static content — contrast, structure, alt text — and give comparatively little attention to motion, despite it being a real, documented concern for users with vestibular disorders, who can experience genuine physical discomfort, including dizziness and nausea, from certain kinds of animation, particularly large-scale parallax or auto-playing motion. Respecting the `prefers-reduced-motion` media query, and offering a substantially calmer, motion-reduced experience for users who've indicated that preference at the operating system level, is a straightforward technical addition that closes a real gap most accessibility checklists still under-emphasize relative to its actual impact on affected users.

Automated tools catch roughly a third of real issues

It's worth setting realistic expectations about automated accessibility scanners: research from organizations including WebAIM consistently finds that automated tools catch somewhere around a third of real WCAG violations, because a meaningful share of accessibility problems — confusing navigation order, unclear error messaging, a genuinely usable focus flow — require human judgment and manual testing to catch reliably. Automated scans are a valuable, fast first pass that catches the easy, high-volume issues (missing alt text, contrast failures) at scale, but they should be treated as a floor, not a ceiling, with manual testing — including real keyboard and screen reader use — filling in the substantial gap automated tools structurally can't cover.