Someone hands you a PDF. It says "Fails: 1.4.3, 2.4.7, 2.5.8, 3.3.2, 4.1.2" and nothing else. No explanation, no plain English, just five criterion numbers stacked like a phone extension list. You are the developer who now has to fix this, and the deadline was yesterday.
So you open a new tab. You search "1.4.3 WCAG." You land on a spec page written for standards lawyers, not for someone trying to ship a bug fix before lunch. You do this four more times, once per number, and by the time you understand what you're even looking at, half your afternoon is gone and you haven't touched a single line of code.
This happens constantly, and it's the reason audit reports feel so hostile even when the underlying issues are simple. The numbers aren't cryptic because the fixes are hard. They're cryptic because nobody handed you the decoder ring.
The Stat: WCAG 2.2 added SC 2.5.8 (Target Size, Minimum), a Level AA criterion requiring most interactive targets to be at least 24 by 24 CSS pixels unless an exception applies. (Source: W3C WCAG 2.2)
What This Cheat Sheet Actually Fixes
Most of the site's WCAG content, including our own breakdown of Level A, AA, and AAA, explains the standard as a structure: principles, guidelines, conformance levels. That's the right way to learn the framework. But it's the wrong tool for the moment you're staring at a bare number in a ticket and just need to know what it means and how to close it.
This is that second tool. Five of the most commonly cited success criteria, translated from spec language into "here's what broke and here's the minimal fix." Bookmark it. The next time an audit report drops a number on you with zero context, come back here first.
SC 1.4.3, Contrast Minimum
What the auditor is telling you: somewhere on the page, text color and background color are too close to each other for someone with low vision to read comfortably.
The actual rule: normal text needs a contrast ratio of at least 4.5:1 against its background. Large text (roughly 18pt, or 14pt bold) gets a break at 3:1.
The minimal fix: darken the text, lighten the background, or both, until a contrast checker confirms you've cleared the ratio. This is almost never a redesign. It's a hex code change on a CSS variable, most often on gray body text sitting on an off white card or a light colored button label.
Where it hides: placeholder text in form fields, disabled looking buttons that are actually meant to be usable, and light gray "secondary" text that a designer picked because it looked calm, not because anyone tested it.
SC 2.4.7, Focus Visible
What the auditor is telling you: someone navigating by keyboard can't tell where they are on the page.
The actual rule: whatever element currently has keyboard focus needs a visible indicator, a highlight, a border, an outline, something. Nothing subtle enough to miss.
The minimal fix: stop removing the default focus ring with outline: none unless you're replacing it with something equally visible. If a previous developer stripped outlines for aesthetic reasons, restore a clear focus style, ideally one with enough contrast of its own to satisfy SC 1.4.3 too.
Where it hides: custom buttons and dropdown menus built from <div> elements instead of native form controls, since those are the ones most likely to have had their focus styling silently stripped or never defined. Our deeper walkthrough on keyboard navigation and visible focus covers the patterns worth copying instead of re-inventing.
SC 2.5.8, Target Size Minimum
What the auditor is telling you: something clickable is too small or too cramped next to its neighbors for a finger, a stylus, or an unsteady hand to hit reliably.
The actual rule, added in WCAG 2.2: most interactive targets need to be at least 24 by 24 CSS pixels, unless a listed exception applies (inline text links, controls with enough spacing around them, or targets already sized by the browser or OS).
The minimal fix: increase padding around small icon buttons rather than redrawing the icon itself. A 16px icon inside 4px of padding on every side already clears the 24px box without changing how anything looks.
Where it hides: icon-only buttons in toolbars, close ("x") buttons on modals, and dense mobile navigation bars where five icons got squeezed into a 40px strip.
SC 3.3.2, Labels or Instructions
What the auditor is telling you: a form field exists that a screen reader user can't identify by name.
The actual rule: every input that requires user action needs a label or instruction that's programmatically tied to it, not just visually placed near it.
The minimal fix: connect a <label for=""> to its matching input id, or add an aria-label where a visible label genuinely doesn't fit the design. Placeholder text is not a label. It disappears the moment someone starts typing, and many assistive technologies don't reliably announce it in the first place.
Where it hides: search bars with a magnifying glass icon and no text, checkout forms using placeholder text as the only field description, and filter inputs on data tables.
SC 4.1.2, Name, Role, Value
What the auditor is telling you: a custom widget, a toggle, a tab, a slider, a dropdown, doesn't announce what it is or what state it's in.
The actual rule: every interactive component needs a programmatically exposed name, role, and current state, so assistive technology can describe it the same way a sighted user would see it.
The minimal fix: use native HTML elements (<button>, <select>, <input type="checkbox">) wherever you can, since they get name, role, and value for free. Where a custom component is unavoidable, add the matching ARIA role and state attribute (aria-expanded, aria-checked, aria-selected) and keep it updated as the state changes.
Where it hides: custom toggle switches built from styled <div> elements, accordion headers with no aria-expanded, and tab interfaces where clicking changes the visible panel but never tells assistive tech which tab is now active.
Using the Cheat Sheet During Triage
When a report lands, don't fix issues in the order they're listed. Group them by category first, contrast, focus, target size, labels, naming, and knock out every instance of one category before moving to the next. Fixing all your contrast issues in one pass is faster than bouncing between five different kinds of problems in the order an auditor happened to write them down.
For the full technical wording behind any of these five, or the dozens of other criteria that didn't make this shortlist, the W3C's official quick reference is the fastest way to check an edge case, and the WCAG 2.2 specification itself is the source of truth when you need the exact normative language for a client or a legal team. This cheat sheet is meant to get you moving fast, not to replace the spec when precision matters.
If you'd rather not translate audit numbers by hand every time one lands in your inbox, run your site through our free accessibility tools and get the plain language version attached to every finding automatically.
Keep This Bookmarked
Audit reports aren't going to start speaking plain English on their own, so having a fast lookup for the criteria you'll see again and again beats re-searching the same five numbers every quarter. If you'd rather talk to a person about a report you're staring at right now, email us at experts@wcag.world, or run a scan yourself with our free tools and get a head start before you even open the ticket.