KBeezie

What I Don't Do (Yet)

I use ARIA sparingly and only where the purpose is unambiguous. An aria-label="Page navigation" on a nav element tells a screen reader what that block is for — it's a signpost, not a complex interaction. That's the kind of ARIA worth using: the simple, well-understood labels that browsers and screen readers have supported consistently for years.

What I avoid are ARIA roles and states that override native HTML semantics. If I mark up a <button> and then add role="tab", aria-selected, and aria-controls to make it behave like a tab panel, I've now taken on the responsibility of managing keyboard focus, state announcements, and panel visibility — all things the browser would have handled for free with a simpler approach. A misconfigured aria-expanded that never updates is worse than no ARIA at all, because it actively lies to the user about what's happening on the page.

For a content-focused site with no custom widgets, standard HTML elements with proper heading hierarchy and descriptive link text cover most of what complex ARIA would add. If I introduce interactive components later, I'll learn the relevant ARIA patterns properly before shipping them. Until then, simplicity is the more accessible choice.

---

The Real Takeaway

You don't need to be an accessibility expert to build something that doesn't exclude people. You need to care about the experience of someone who isn't you, and you need to make the low-effort decisions correctly: heading levels, link text, contrast, font choice, structural HTML. Most of it is routine, not expertise.

The caption gap taught me that a single missing feature can make content useless. I can't fix every accessibility problem on the web, but I can make sure my own site doesn't shut the door on someone the way a missing caption shuts it on me.

---

Accessibility Checkers Are Already in Your Workflow

Most of the performance tools I regularly use also check for accessibility issues.

PageSpeed Insights runs Lighthouse under the hood and gives you an accessibility score alongside your Core Web Vitals. The breakdown flags specific issues: contrast failures, missing labels, heading order problems. If you're already testing performance, the accessibility check costs you nothing extra.

For a quicker look, Chrome's DevTools has a Lighthouse tab built in — no extension needed. Run an accessibility audit against a local development build before it ever hits production. It won't catch everything (automated tools can't tell you if your alt text is useful, only whether it exists), but it catches the structural problems: heading hierarchy, link text, contrast ratios, form labels.

If you want a dedicated accessibility checker, WAVE from WebAIM runs as a browser extension and overlays results directly on the page — errors, alerts, and structural outlines in context rather than in a separate report. axe DevTools from Deque is the industry standard for automated accessibility testing and integrates into both browser DevTools and CI/CD pipelines if you're maintaining a larger project.

None of these replace testing with an actual screen reader. But they catch some of the obvious pitfalls — the stuff you'd fix if you knew it was broken — and that alone puts you ahead of most sites on the web.

---

Going Further

I'm deaf, but I'm not fluent in ASL. My experience is one data point, not the whole spectrum. For deaf and hard-of-hearing readers who do use ASL as a primary language, sites like DPAN (the Deaf Professional Arts Network) publish content created and communicated entirely in ASL — no captions to chase, no lip-reading fatigue, just native language content. That's a different kind of access than the one I need, but it matters just as much.

If you're looking for a deeper dive into the standards and guidelines that shape accessible web content, here's where to start:

• WCAG 2.2 Quick Reference — the current Web Content Accessibility Guidelines, filterable by level (A, AA, AAA) and by component (text, images, forms, etc.). Not light reading, but it's the standard most accessibility laws reference.
• Section 508 Accessible Typography — referenced earlier in the fonts section. Part of the broader Section 508 standards that apply to US federal agencies and any organization that does business with them.
• WAI Making Audio and Video Media Accessible — covers captions, transcripts, audio descriptions, and sign language alternatives. If you publish video or audio content, this is where the caption conversation starts.
• WebAIM — a nonprofit at Utah State University that publishes practical, readable guides on accessibility testing, screen reader usage, and contrast checking. Their contrast checker is a quick way to test color combinations without installing anything.

None of these are prerequisites for caring about accessibility. They're where you go when you want to move from "I think this helps" to "I know this meets a standard." The routine comes first. The reference material backs it up.