A11y Toolkit: Accessibility Resources Guide

Most websites are broken. Not for you. For everyone else.

Accessibility isn't a feature you bolt on later. It's the foundation. If you're still treating a11y like a checklist item, you're doing it wrong. This guide is a toolkit. Nothing more.

What A11y Actually Means

A11y is shorthand for accessibility. The "11" stands for the eleven letters between the "a" and the "y." It's not a framework. It's not a library. It's the practice of making digital products usable by people with disabilities.

That includes:

• Visual impairments (blindness, low vision, color blindness)
• Motor disabilities (can't use a mouse, limited movement)
• Cognitive disabilities (ADHD, dyslexia, memory issues)
• Hearing impairments (deafness, hard of hearing)
• Seizure disorders (photosensitivity, epilepsy)

If your site fails for any of these groups, it fails. Period.

The Hard Truth About Compliance

WCAG 2.1 AA is the standard most lawsuits reference. It's not perfect. It's the bare minimum. Meeting it doesn't mean your site is good. It means you're less likely to get sued.

AAA compliance is rare and often impractical for large sites. Aim for AA. Test beyond it.

Automated Testing Tools

Automated tools catch about 30% of issues. The rest requires human judgment. Don't trust a green score.

Run these. Then assume they're wrong and test manually.

Manual Testing You Can't Skip

Keyboard Navigation

Unplug your mouse. Tab through everything. If you can't reach it, neither can a screen reader user. If focus disappears, you've got a trap. Fix it.

Screen Reader Testing

Download NVDA (Windows, free) or use VoiceOver (built into macOS/iOS). Listen to your site. If it sounds like nonsense, it is.

• Does the heading hierarchy make sense when read aloud?
• Are form labels announced properly?
• Does dynamic content announce itself, or does it sit there silently?

Zoom and Reflow

Set browser zoom to 200%. On mobile, use text size settings. If your layout breaks or text gets cut off, you have a failure. WCAG requires content to work at 400% zoom up to 1280px wide.

Color and Contrast

Use a simulator. Stark (Figma plugin) or Colour Contrast Analyser (desktop app). If you're relying on color alone to convey meaning, stop. Add text, icons, or patterns.

Design and Prototyping Resources

Catch issues before they hit code. Cheaper that way.

• Stark — Contrast checker, colorblind simulator, focus order tool. Lives in Figma, Sketch, Adobe XD.
• A11y - Color Contrast Checker — Figma plugin. Fast. Brutal. Tells you exactly which combos fail.
• Accessible Palette — Builds color systems that actually work for vision deficiencies.
• HTML5 Accessibility — Tracks how well browsers and screen readers support native HTML elements. Use the native element if you can. Custom widgets are where you die.

Code-Level Fixes That Matter

Stop Using Divs for Buttons

If it acts like a button, use a <button>. Divs aren't keyboard focusable. They don't announce to screen readers. You're making extra work for yourself.

Alt Text Is Not an Afterthought

Every image needs a decision:

• Meaningful image? Write descriptive alt text.
• Decorative image? Use alt="" so screen readers skip it.
• Complex chart? Provide a data table or long description nearby.

"Image of..." is redundant. Screen readers already say it's an image.

ARIA: Use Sparingly

No ARIA is better than bad ARIA. If you can solve it with native HTML, do that. ARIA doesn't add behavior. It only adds semantics. You still have to build the keyboard support yourself.

How to Run a 30-Minute Accessibility Audit

You don't need a week. You need half an hour and honesty.

1. Run an automated scan. Use axe or WAVE on your homepage and one interior page. Export the results. Don't fix yet. Just look.
2. Tab through the page. Start at the address bar. Hit Tab. Where does focus go? Is it visible? Can you activate every link and button? Can you escape modals?
3. Check heading order. Use a bookmarklet or dev tools. Is there an h1? Do headings descend logically? Skipping from h2 to h4 breaks navigation for screen reader users.
4. Zoom to 200%. Does content reflow without horizontal scrolling? Do buttons disappear?
5. Test one form. Can you complete it with only a keyboard? Are errors announced clearly? Is required field status communicated?
6. Review alt text. Turn off images in dev tools. Does the page still make sense?

Log everything. Prioritize by user impact. Color contrast and keyboard traps block people entirely. Fix those first.

Documentation and Checklists

Don't memorize all this. Bookmark it.

• The A11Y Project Checklist — WCAG 2.1 breakdown in plain English. Filter by role.
• WebAIM Articles — Deep dives on specific topics. The contrast article alone will save you from lawsuits.
• MDN Accessibility Docs — Authoritative reference for how HTML elements should behave.
• GOV.UK Accessibility Blog — Real testing from a team that actually ships accessible services.

Who Does the Work?

Not one person. Not the "accessibility person" you hire later.

• Designers — Color, typography, focus states, touch targets.
• Developers — Semantic markup, keyboard support, ARIA when necessary.
• Content writers — Alt text, link text that makes sense out of context, plain language.
• QA — Testing with real tools, not just eyeballing it.

If it's siloed, it fails. Build it into every ticket.

The Bottom Line

Accessibility isn't charity. It's basic quality. Broken sites exclude people. Excluding people is bad business and, increasingly, illegal.

Start with one page. Fix the keyboard flow. Fix the contrast. Write real alt text. Then do the next page. Momentum beats perfection.

Now close this tab and break something with your keyboard. 🛠️