wcag-power-platform

name

wcag-power-platform

description

Ensure web apps, HTML pages, and Power Platform components meet WCAG 2.2 accessibility guidelines. Use this skill WHENEVER building, reviewing, or refactoring any web UI or Power Platform artifact — standalone HTML/CSS/JS pages, websites and single-page apps, React/web artifacts, PCF (PowerApps Component Framework) controls, HTML/JS web resources, model-driven apps and forms, canvas apps, or Power Pages — even if the user does not say "accessibility". Trigger on requests to create pages or components, build forms, style UI, add buttons/inputs/grids/charts, theme an app, apply a Power Apps modern theme / CustomTheme, implement dark mode / high-contrast / design tokens, fix a control, write HTML/CSS/React, or audit a page against WCAG/ADA/Section 508/EN 301 549. Also trigger on "make this accessible", "a11y", "screen reader", "keyboard navigation", "colour contrast", "dark mode", "theme", "ARIA", or "WCAG". Apply the checks proactively so output conforms to WCAG 2.2 AA by default (which also satisfies the WCAG 2.1 and 2.0 targets older regulations name), across every theme variant.

WCAG 2.2 for Web Apps & Power Platform

This skill makes anything you build or review conform to WCAG 2.2 Level AA (the current W3C Recommendation, and what UK public sector sites are monitored against; conforming to 2.2 also satisfies the WCAG 2.1 and 2.0 targets other regimes still name), while flagging the AAA criteria worth reaching for. It covers generic web content, full HTML pages/sites and SPAs, and modern theming (dark mode, high contrast, design tokens), and the four Power Platform component types: PCF controls, model-driven apps/forms, canvas apps, and Power Pages.

Default target

Unless the user states otherwise, conform to WCAG 2.2 Level AA. Level A is the floor and AA is what every regulation requires — the level is constant, only the version differs:

• UK Public Sector Bodies Accessibility Regulations — the law names no version (regulation 9 references WCAG "as amended from time to time"); GDS applies and monitors WCAG 2.2 AA.
• EU Web Accessibility Directive — EN 301 549 v3.2.1, i.e. WCAG 2.1 AA. The WCAG 2.2-aligned EN 301 549 v4.1.0 is still a final draft at vote stage and is not yet cited in the Official Journal.
• EU Accessibility Act — in application since 28 June 2025, but with no harmonised standard cited yet there is no presumption-of-conformity route; conform against the Annex I essential requirements directly.
• US ADA Title II — WCAG 2.1 AA, deadlines 26 April 2027 (population ≥ 50,000) and 26 April 2028 (under 50,000 / special districts) after the April 2026 interim final rule; neither has passed.
• US Section 508 — still WCAG 2.0 AA, unchanged since 2017.

Content conforming to 2.2 conforms to 2.1 and 2.0 as well, so 2.2 AA is the one safe target. Mention AAA only as an optional enhancement.

How to use this skill

1. Identify the component type (web/PCF/model-driven/canvas/Power Pages). The platform changes how you satisfy a criterion — see the routing table below and read the matching reference file.
2. Author or review against the four principles. Read references/wcag-checklist.md — it lists every WCAG 2.2 success criterion grouped under Perceivable, Operable, Understandable, Robust, with the concrete, testable thing to check for each. This is the heart of the skill.
3. Apply the platform-specific guidance from the relevant reference file.
4. Self-verify using the verification section below before declaring done.

When building something new, bake the checks in as you write — don't bolt them on afterwards. When auditing, report findings as a table: criterion, level (A/AA/AAA), pass/fail, location, and the fix.

Component routing

If the work involves…	Read this reference
Generic HTML/CSS/JS or React web artifacts	references/wcag-checklist.md
A full HTML page, website, or single-page app	references/html-pages.md
Theming: Power Apps modern themes, dark mode, high contrast, design tokens	references/theming.md
PCF (PowerApps Component Framework) controls	references/pcf.md
HTML/JS web resources (model-driven)	references/web-resources.md
Model-driven apps, forms, views, dashboards	references/model-driven.md
Canvas apps	references/canvas.md
Power Pages (portals)	references/power-pages.md

Always read references/wcag-checklist.md — every other file assumes it and only adds deltas. Read references/html-pages.md for any standalone page/site/SPA, and references/theming.md whenever colour schemes, dark mode, high-contrast, or a design-token/theme system is in play (these stack with the platform files — e.g. a themed Power Pages site reads the checklist + power-pages + theming).

The four principles (POUR) — quick orientation

• Perceivable — users can perceive the information: text alternatives, captions, colour not used alone, 4.5:1 text contrast / 3:1 large text & UI, reflow to 320px, resizable text, programmatic structure.
• Operable — users can operate it: full keyboard access, no keyboard traps, visible focus that is never entirely obscured, logical focus order, enough time, no seizure-inducing flashing, 24×24 target size, a single-pointer alternative to every drag, skip links, descriptive link text.
• Understandable — readable and predictable: page language set, labels and instructions on inputs, clear error identification + suggestions, consistent navigation and consistently placed help, no redundant re-entry of data, no cognitive-test authentication, no surprise context changes on focus/input.
• Robust — works with assistive tech: correct name/role/value for every control, status messages announced via live regions. (Valid markup is still good practice but is no longer a criterion — 4.1.1 Parsing was removed in 2.2.)

The highest-leverage AA checks (apply to everything)

These catch the majority of real failures. Verify every one before finishing:

1. Every interactive element is keyboard reachable and operable (Tab/Shift+Tab, Enter/Space), with a visible focus indicator (2.4.7) and no keyboard trap (2.1.2).
2. Every form control has a programmatic label (<label for>, aria-label, or aria-labelledby) — not just a visual placeholder (1.3.1, 3.3.2, 4.1.2).
3. Every meaningful image has alt text; decorative images have empty alt (alt="") or are hidden from AT (1.1.1).
4. Text contrast ≥ 4.5:1 (≥ 3:1 for large text — 18pt/24px, or 14pt/≈18.5px when bold), and UI components & graphical objects ≥ 3:1 (1.4.3, 1.4.11).
5. Colour is never the only way information is conveyed (1.4.1) — pair it with text, icon, or pattern.
6. Semantic structure: real headings in order (h1→h2→h3, no skips), lists as lists, one <main>, landmark regions, tables with <th scope> (1.3.1).
7. Page/screen has a descriptive title and lang is set (2.4.2, 3.1.1).
8. Dynamic updates are announced to screen readers via aria-live / status roles (4.1.3).
9. Content reflows with no horizontal scroll at 320 CSS px / 400% zoom and text resizes to 200% without loss (1.4.10, 1.4.4).
10. Errors are identified in text, near the field, with a suggested fix, and the field is linked via aria-describedby (3.3.1, 3.3.3).
11. Focus is never entirely hidden by sticky headers/footers, cookie banners, or floating panes (2.4.11), and every pointer target is ≥ 24×24 CSS px — or a 24px circle centred on each undersized target intersects neither another target nor another undersized target's circle (2.5.8).
12. Anything operated by dragging has a single-pointer alternative — a click, tap, or arrow-key equivalent (2.5.7) — and sign-in never depends on remembering, transcribing, or solving a puzzle (3.3.8).

Verification before "done"

Run through these — automated tools catch ~30–40%, the rest needs the manual checks:

• Automated: axe-core / Accessibility Insights / Lighthouse / WAVE. In Power Platform the only built-in accessibility checker is the canvas one — open App checker in Power Apps Studio, then Accessibility — and it covers screen-reader and keyboard issues only; it does not check colour contrast. There is no equivalent for model-driven apps, web resources, or Power Pages, so external tooling is mandatory there, not optional. Don't confuse it with the model-driven App access checker (licence and security-role access, nothing to do with accessibility); solution checker's three accessibility rules are canvas-only and Medium severity, so they never block an import. Treat all of these as a first pass, not proof of conformance.
• Keyboard-only pass: unplug the mouse. Tab through the whole UI. Can you reach and operate everything? Is focus always visible? Does order make sense? Can you always Tab back out (no trap)?
• Screen reader spot-check: use a pairing Microsoft has actually verified against Power Apps — JAWS on Edge, Narrator on Edge, NVDA on Chrome or Firefox, TalkBack on Chrome or Power Apps mobile, VoiceOver on Safari (macOS/iOS/iPadOS) or Power Apps mobile. Note NVDA is not on Microsoft's verified list for Edge, and that list was last refreshed in 2022 — it is still the only one published. Is every control announced with a sensible name, role, and state? Are errors and dynamic changes announced?
• Zoom/reflow: 400% browser zoom (≈320px). No two-dimensional scrolling for non-data content; nothing clipped or overlapping.
• Contrast: spot-check text and UI against the 4.5:1 / 3:1 thresholds with a contrast checker; verify in any dark/high-contrast theme too.
• Themes: re-run the contrast, focus-visibility, and colour-only checks in every theme variant you ship — light, dark, and OS high-contrast / forced-colors (see references/theming.md). Conformance is not inherited from the default theme.
• Colour-only: would the meaning survive in greyscale?

If a criterion genuinely can't be met (e.g. essential complex data viz), say so explicitly and propose the closest accessible alternative rather than silently skipping it.

Note on standards version

This skill targets WCAG 2.2 — a W3C Recommendation since 5 October 2023, republished with errata on 12 December 2024, and identical to ISO/IEC 40500:2025. W3C's own advice is to adopt 2.2 as the conformance target "even if formal obligations mention previous versions". WCAG 2.0 and 2.1 are not deprecated, and WCAG 3.0 is only a Working Draft with several years of work left — don't target it.

2.2 is additive over 2.1 apart from one deletion. It adds nine criteria — Focus Not Obscured Minimum (2.4.11, AA) and Enhanced (2.4.12, AAA), Focus Appearance (2.4.13, AAA), Dragging Movements (2.5.7, AA), Target Size Minimum (2.5.8, AA — 24×24 CSS px), Consistent Help (3.2.6, A), Redundant Entry (3.3.7, A), Accessible Authentication Minimum (3.3.8, AA) and Enhanced (3.3.9, AAA) — and removes Parsing (4.1.1). No criterion changed conformance level between 2.1 and 2.2; in particular Focus Visible (2.4.7) is still AA, not A. New criteria were appended to the end of their guideline, so position within a guideline no longer implies level.

The one carve-out is reporting, not testing: where policy binds you to WCAG 2.0 or 2.1 you may still have to record 4.1.1 Parsing, but W3C added a note to both of those versions — "This success criterion should be considered as always satisfied for any content using HTML or XML" — so it is marked satisfied rather than assessed. Report real markup problems under 1.3.1 and 4.1.2 instead.