Accessibility terms are the vocabulary you’ll hit the moment anyone runs a WCAG audit on your site - alt text, ARIA, contrast ratio, keyboard navigation, screen readers, semantic HTML - and the basic shorthand for making the web work for people who don’t browse the way you do.

You’ll learn this vocabulary the easy way or the expensive way. The expensive way is a procurement form you can’t fill out, a deal that stalls, or a demand letter from a law firm specialising in ADA suits. Worth getting ahead of.

The terms that come up most

Alt text

The written description of an image, used by screen readers and shown when an image fails to load. It’s also what Google reads to understand the image. One sentence describing what’s actually in the picture and why it matters - not “image of” anything, not keyword stuffing. See alt tag (alt text) for the full breakdown.

ARIA

Accessible Rich Internet Applications. A set of HTML attributes (like aria-label, aria-hidden, role) that tell assistive tech what an element is doing when standard HTML doesn’t make it obvious. Used heavily on custom UI components - modals, dropdowns, tabs - that aren’t built from semantic elements.

Screen reader

Software that reads the page aloud for blind or low-vision users. Common ones: NVDA and JAWS on Windows, VoiceOver on Mac and iOS, TalkBack on Android. They navigate by headings, links, and landmarks - which is why structure matters as much as styling.

Contrast ratio

The numeric difference in luminance between text and background. WCAG 2.1 AA requires 4.5:1 for normal text, 3:1 for large text. Grey text on a white background usually fails. So does fashionable low-contrast hero copy. Test with any browser DevTools or a free contrast checker.

Keyboard navigation

Everything on the page should be reachable and operable using only a keyboard - Tab to move forward, Shift+Tab back, Enter to activate, Escape to dismiss. If your custom dropdown only opens on hover, it fails. If your modal traps focus inside it correctly, it passes.

Semantic HTML

Using HTML elements for what they actually mean - <button> for buttons, <nav> for navigation, <h1> through <h6> for hierarchy. The lazy version uses <div> for everything. Semantic markup makes the page work for assistive tech without you doing extra ARIA work.

WCAG

Web Content Accessibility Guidelines, the W3C standard most accessibility audits and laws reference. WCAG 2.1 AA is the practical bar most teams target - strong enough to cover the common failure modes, achievable without rebuilding your whole stack.

Where this matters for content people

You’re a content lead at a 30-person SaaS. Procurement at an enterprise prospect sends you a VPAT (Voluntary Product Accessibility Template) to fill out. You don’t know what half the questions mean. Your engineering team is busy. Learn the vocabulary fast or lose the deal.

The good news: most fixes are content-side. Better alt text, descriptive link anchors (“read the WCAG quickstart” not “click here”), proper heading hierarchy, contrast that doesn’t require a magnifying glass. Engineering owns ARIA and keyboard traps. You own most of the rest - and the same structural choices that pass an audit also help page speed, UX, and how cleanly Google parses your pages.

Related terms

• Alt Tag (Alt Text) - the single most-cited accessibility deliverable for content people
• User Experience (UX) - the broader discipline accessibility lives inside
• Page Speed - the other technical bar that compounds with accessibility wins
• Search Engine Optimization (SEO) - overlaps heavily with accessibility on structure and semantics
• SEO Audit - the cousin process; many checks (headings, alt text, link text) overlap directly with accessibility audits