A product leader does not need to write a single ARIA attribute. Nobody is asking you to open a code editor and hand-wire a focus trap.
But you do need to sit in a roadmap review, listen to an engineer say "we'll just skip the label on that field, it's obvious from context," and recognize that a real accessibility concept just walked into the room wearing a normal feature-decision costume. If you cannot name what just happened, you cannot make a good call on it.
Here are the 11 concepts that show up most often in exactly that moment, explained in plain language, with no code required.
The Stat: Automated accessibility scanners catch roughly 57.38% of WCAG issues on their own, according to Deque's published research, meaning a program that relies only on automated testing is missing nearly half the picture. (Source: Deque)
Why these 11 and not fifty
Accessibility has hundreds of individual success criteria, techniques, and edge cases. You will never memorize them, and you shouldn't try. What you need is a smaller set of concepts that let you recognize the shape of a decision when it appears, so you know when to ask a follow-up question instead of nodding along.
These 11 are the ones that keep resurfacing in roadmap reviews, design critiques, and vendor conversations, regardless of what industry the product is in.
The four ideas that explain everything else
1. POUR principles
Every single WCAG success criterion, all of them, fall under four principles: Perceivable, Operable, Understandable, Robust. This is not marketing language, it is literally how the W3C's own WCAG POUR overview organizes the standard. When someone tells you a feature "isn't accessible," ask which of the four it fails. A vague complaint becomes a specific, assignable problem the moment you can say "this is an Operable issue" instead of "it feels off."
2. Conformance levels A/AA/AAA
WCAG defines three conformance levels: A, AA, and AAA. Most legal and industry benchmarks target AA. Here is the part leaders often get wrong: the W3C's own WCAG conformance requirements explicitly state that AAA is not recommended as a general policy for entire sites. If a vendor or a well-meaning team member pitches "let's just build to AAA everywhere," that is a red flag worth a follow-up question, not a compliment.
The concepts your engineers already know, that you should too
3. Semantic HTML
Using a real <button> instead of a <div> styled to look like one. It sounds cosmetic. It is not. Semantic elements come with built-in keyboard support, screen reader announcements, and focus behavior for free. Every time a team reaches for a generic <div> with a click handler, they are signing up to manually rebuild all of that from scratch, and usually rebuilding it incompletely.
4. Keyboard operability
Can every interactive element be reached and activated using only a keyboard, no mouse? This is one of the fastest sanity checks a non-technical leader can run personally: tab through your own product for five minutes. If you get stuck, trapped, or lost, so will a real user.
5. Focus order
Related but distinct from keyboard operability: when you tab through a page, does focus move in a sensible, predictable sequence, matching what you see on screen? A modal that opens but leaves keyboard focus behind it, still on the page underneath, is a focus order failure. It is one of the most common bugs shipped by teams who tested with a mouse and never touched Tab.
6. Color contrast
The measurable difference in luminance between text and its background. Design systems love a light gray on white because it looks "clean." It is also frequently unreadable for users with low vision, and often for everyone else in bright sunlight. This is one of the few accessibility concepts with a hard number attached to it, which makes it one of the easiest to actually enforce in a design review.
7. Alt text purpose
Alt text is not a caption. Its job is to convey the function or information an image provides to someone who cannot see it. A product screenshot needs alt text describing what it demonstrates. A purely decorative background flourish needs none at all, marked as such so screen readers skip it. Confusing these two cases is the single most common alt text mistake product teams make.
8. ARIA as a last resort
ARIA attributes exist to patch gaps when semantic HTML genuinely cannot express something. They are not a first move. The well-known irony in accessibility engineering is that misused ARIA frequently makes a component less accessible than using no ARIA at all, because it can override correct native behavior with incorrect custom behavior. If a solution starts with "let's just add some ARIA," ask what semantic HTML option was tried first.
The concepts that decide how you actually ship
9. Assistive technology
The umbrella term for the tools real users rely on: screen readers, switch devices, screen magnification, voice control, and more. It is easy for a product team to design and test entirely within their own mouse-and-monitor experience and never once consider that a meaningful share of their audience is not interacting with the product that way at all.
10. Automated vs manual testing
This is the concept behind the stat above. Automated scanners are fast, cheap, and catch a real but limited slice of issues, roughly 57.38% by Deque's own published research. The remainder, things like whether alt text is actually meaningful or whether a focus order makes logical sense, requires a human to check. Any vendor or internal team claiming "we run automated scans, so we're covered" is quietly leaving a large share of real problems on the table. This is exactly the layer we unpack further in Deque's published research on automated accessibility testing coverage, and it is why treating a green automated scan as "done" is a mistake worth catching before it reaches production.
11. Legal exposure (ADA/EAA)
Accessibility is not only a UX conversation. Depending on where your company operates and who it serves, obligations can arise under frameworks like the Americans with Disabilities Act (ADA) in the US or the European Accessibility Act (EAA) in the EU. You do not need to become a lawyer. You do need to know this dimension exists, so it gets raised with legal and compliance stakeholders before a roadmap decision ships, not after.
Quick reference table
| # | Concept | Where it shows up in a roadmap review |
|---|---|---|
| 1 | POUR principles | Naming which kind of accessibility problem a bug report actually describes |
| 2 | Conformance levels | Deciding what "accessible enough" means for this release |
| 3 | Semantic HTML | A "custom component" proposal that reinvents native browser behavior |
| 4 | Keyboard operability | Any new interactive widget, modal, or menu |
| 5 | Focus order | Modals, drawers, multi-step forms |
| 6 | Color contrast | Every new design system color pairing |
| 7 | Alt text purpose | Any image, icon, or chart added to the product |
| 8 | ARIA as a last resort | A proposed "quick ARIA fix" for a broken component |
| 9 | Assistive technology | Any claim that a feature "works fine" based only on mouse testing |
| 10 | Automated vs manual testing | A vendor or team reporting a "100% passing" accessibility scan |
| 11 | Legal exposure | Expansion into a new market, or a customer procurement questionnaire |
A short self-check
- I can name all four POUR principles without looking them up
- I know which conformance level (A, AA, or AAA) my product actually targets
- I have personally tabbed through my product's core flow with no mouse
- I know whether our current testing is automated only, manual only, or both
- I know who on my team owns legal/compliance exposure for accessibility
If you got through that list quickly, you are already ahead of most product leaders. If a few items gave you pause, that is normal, and it is exactly what this list is for: not to make you an engineer, but to make sure the next time one of these 11 concepts shows up disguised as an ordinary feature decision, you catch it. We've gone deeper on the organizational side of this in why this is a leadership problem, not just a developer one, which is worth a read if this list resonated.
None of this requires you to become the accessibility expert on your team. It requires you to ask the right question at the right moment, and then hand the real work to people who live in this every day. If you want to see how these 11 concepts actually apply to your product's real backlog, bring your real roadmap to a free audit conversation, or look at our accessibility program for SaaS product teams if you want the fuller picture, and walk through it together. You can also just reach out directly to the team at experts@wcag.world if you'd rather talk it through first.