WCAG

WCAG (Web Content Accessibility Guidelines) is the W3C’s standard for making web content accessible to people with disabilities. It is organized around four principles — content must be Perceivable, Operable, Understandable, and Robust (POUR) — expressed as testable success criteria grouped into conformance levels A, AA, and AAA. WCAG 2.1 and 2.2 are the widely referenced versions, and they underpin legal accessibility requirements in many jurisdictions.

• POUR principles - Perceivable, Operable, Understandable, and Robust, the four pillars every guideline hangs from.
• Conformance levels A / AA / AAA - Tiers of increasing strictness, with AA the common legal and procurement target.
• Testable success criteria - Concrete, checkable requirements rather than vague goals, which makes conformance auditable.
• Legal and procurement baseline - Referenced by regulations like the ADA, Section 508, and the European Accessibility Act.

WCAG is aimed at web content rather than APIs directly, but it matters across an API operation in ways that are easy to overlook: developer portals, documentation, dashboards, and API consoles are all web content that must meet these guidelines, and public-sector API programs are increasingly held to WCAG conformance by law. Treating accessibility as a governance requirement — measurable, tiered, and auditable like any other policy — is the practical way it shows up in the work I do, and it’s a reminder that the human-facing surface of an API is part of the product, not an afterthought.