Designing for Accessibility: My Practical Checklist

Accessibility can feel big and intimidating—especially for designers. Between guidelines, legal requirements, and assistive technology support, it’s easy to assume that accessibility is a developer’s responsibility or something to worry about after launch. But as designers, we’re in a powerful position to shape accessibility early—through structure, language, visual clarity, and predictable interaction patterns. Many of these decisions happen before a single line of code is written.

The A11Y Project’s checklist is one of the most trusted resources out there for making digital experiences more inclusive. This post isn’t a rewrite of that—it’s my adapted version of their checklist, made for designers working with design systems and headless CMS tools.

It reflects my experience designing accessible websites and collaborating with content writers, engineers, and system designers. Along the way, I also learned how to separate what’s handled by our Base UI design system + the new CMS tool vs. what content teams still need to be mindful of.

1. Color & Contrast

What’s baked into Base UI/CMS tool

Our Base UI system already ensures that all text-to-background color combinations meet WCAG AA contrast requirements. This means designers don’t need to manually check every heading or body text—they inherit this from the tokenized color system.

What to watch for

Still, color alone shouldn’t be the only way to communicate meaning. We saw this surface with tabs and links—minimalist design trends tempted us to rely only on color changes to signal interaction or selected states. For example:

• Tabs now include an underline and icon when selected—not just a different color.

• Links are underlined or styled clearly so they’re recognizable even without color.

Takeaway: Even in clean, minimal designs, be cautious of going too minimal. Use contrast and multiple visual cues to support all users.

2. Typography & Readability

What’s baked into Base UI/CMS tool

• A minimum font size of 16px for body text

• Comfortable line height and spacing

• Consistent scale and rhythm across headings

Where content teams come in

One recurring issue we faced was content writers using all caps for emphasis—especially in blog posts and headings. While it may look “attention-grabbing,” full caps reduce readability, especially for users with dyslexia or low vision.

We addressed this by:

• Updating editorial guidelines to discourage all caps

• Letting the CMS enforce style rules for headings and emphasis

Takeaway: A readable system doesn’t just come from font choice—it comes from how the content is written and styled.

3. Layout & Visual Hierarchy

What’s baked into Base UI/CMS tool

• Heading styles that map visually to semantic structure (H1–H6)

• Grouping mechanisms like cards, lists, and containers that guide scannability

What to watch for

We saw content writers using headings as visual styling, not for actual content hierarchy. For instance:

• Using multiple H2s just to make something look bold

• Manually applying underline and caps to text that wasn’t semantically a heading

With the new headless CMS setup, we locked down formatting so content creators use heading levels properly. This means they have to structure content logically—which also helps with screen reader navigation and SEO.

We also built visual “cards” into the CMS editor, so related content can be grouped without writers needing to manually style sections.

Takeaway: Consistent layout and hierarchy make content navigable—for everyone. Don’t let visual styling override semantic meaning.

4. Interactive Elements

System-level improvements

• We ensured every component—from buttons to toggles—has visible focus states

• We updated selected states to include icons, labels, or shape changes—not just color

What we learned

One guideline I didn’t fully consider until recently: tap targets should be at least 44x44px. During a design audit, we found several touch targets (especially on mobile) that were smaller—particularly in dense navigation bars and filters.

We adjusted padding and spacing across the board to fix this and improve mobile usability.

Takeaway: Focus styles and target sizing affect real usability. Don’t overlook them in tight UI layouts.

5. Forms & Inputs

What was missing

Initially, several inputs (like search bars and filters) had placeholders instead of labels. This was confusing for screen reader users and made the fields less clear when autofilled.

What we fixed

We updated the component library to include:

• Properly associated labels for all inputs

• Clear helper text where needed (e.g., “Enter 5-digit zip code”)

Takeaway: Placeholders are not labels. Labels give context and persist after interaction—don’t skip them for the sake of cleaner UI.

6. Images & Icons

What we caught

• Decorative dividers used by content writers were being interpreted as meaningful images by screen readers. We removed these in the updated CMS editor.

• Alt text is now required for all images uploaded through the CMS. But that introduced a new issue: how to localize alt text.

What we solved:

We streamlined the content model so alt text now passes through our translation pipeline, keeping it consistent across languages. We’re also revisiting our icon-only buttons (e.g., bookmark, share) to make sure they either:

• Include a visible label, or

• Are clearly recognizable across contexts (e.g., a trash can always meaning “delete”)

Takeaway: Alt text and icon clarity often fall between design and content. Make time to align both sides.

7. Keyboard & Focus

Where we started

Not all components were fully keyboard-navigable—especially dropdowns and interactive filters. Focus states were missing or inconsistent.

What we changed

We made keyboard navigation a standard part of component testing, with developers and QA validating that all interactions can be done without a mouse.

We also took note of hover-only behaviors (like showing tooltips or menus). These are now being phased out or supplemented with click/keyboard alternatives.

Takeaway: Hover is not enough. Keyboard access needs to be built and tested intentionally—not assumed.

Final Thoughts

Accessibility isn’t one person’s job. It’s a shared mindset that spans design, content, and development—and the earlier it starts, the better the results. As designers, we don’t need to memorize every WCAG guideline. Instead, we can build good habits, use tools like the A11Y Project’s checklist, and design systems that make accessible decisions easy by default.

Start small. Audit one section. Educate your team. And build on the idea that accessible design is just good design—for everyone.