Compliance

WCAG

Web Content Accessibility Guidelines

WCAG, the Web Content Accessibility Guidelines, is the internationally recognised technical standard for making web content usable by people with disabilities, published by the World Wide Web Consortium's Web Accessibility Initiative (W3C WAI).

Why WCAG matters in a Microsoft estate

WCAG matters because customers, resellers, and procurement teams need evidence that controls are defined, operated, and reviewable. A useful glossary definition should help a reader connect the term to audit preparation, policy work, or repeatable assurance activity.

How WCAG shows up in practice

It is organised around four core principles, commonly remembered by the acronym POUR. Content must be Perceivable (available to the senses, such as text alternatives for images and captions for video), Operable (usable via keyboard alone, with no time limits that cannot be extended, and no content that triggers seizures), Understandable (readable and predictable, with clear error identification and input assistance), and Robust (compatible with current and future assistive technologies such as screen readers). Each guideline under those principles is broken into testable success criteria, and each criterion is assigned a conformance level of A, AA, or AAA. AA represents the level almost universally adopted as the practical compliance bar in both regulation and procurement, since AAA includes some criteria widely regarded as impractical to apply site-wide.

The current stable version in wide use is WCAG 2.1, with WCAG 2.2 adding further success criteria (such as clearer focus indicators and consistent help placement) and formally recommended as the version organisations should be targeting for new or updated content. For UK organisations, WCAG 2.1 AA is the explicit technical standard referenced by the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018. It also functions as the de facto benchmark that courts and regulators reference under the Equality Act 2010's requirement to make reasonable adjustments, even for private-sector organisations with no direct statutory citation. In a Microsoft 365 and Azure context, WCAG conformance is not automatic, even when using accessible-by-default platforms.

SharePoint intranet sites, Power Apps and Power Pages applications, Teams-embedded content, and custom Azure-hosted web applications are all capable of introducing accessibility failures through custom theming, low-contrast colour choices, missing alt text on uploaded images, poorly structured heading hierarchies, or custom components that are not properly keyboard-operable. This holds regardless of how accessible the underlying platform chrome is. Automated scanning tools such as axe or Lighthouse can reliably catch a meaningful subset of WCAG failures, typically estimated at around 30 to 40 percent of total issues, such as missing alt attributes and insufficient colour contrast. Criteria that depend on judgement, like whether alt text is actually meaningful or whether a tab order is logical, require manual testing instead, ideally including testing with an actual screen reader and keyboard-only navigation, before a genuine AA conformance claim can be made.

Glossary