Accessibility in Power Pages
Microsoft is committed to making its products and services accessible to everyone. This page summarizes the accessibility standards Power Pages conforms to out of the box, and—more importantly for architects and developers—outlines what you remain responsible for once you start customizing a site.
For general Microsoft accessibility information, see the Microsoft Accessibility website and Accessibility features of Microsoft products.
Key takeaway for solution builders
Power Pages the platform conforms to WCAG 2.2, Section 508, and EN 301 549. However, conformance is not automatically inherited by your site once you add custom HTML, Liquid, JavaScript, CSS, or embedded components (Power BI reports, custom web templates, etc.). You own the accessibility of anything you customize.
For Solution Architects: Power Pages is the strongest conformance story in this repo—explicit, documented conformance to WCAG 2.2, Section 508, and EN 301 549 (see comparison across surfaces). You can tell stakeholders the platform conforms; you can't tell them the site conforms until every customization (Liquid, HTML, embedded components) has been reviewed. Effort to reach full compliance: Low–Medium, concentrated entirely on what you customize.
Accessibility standards Power Pages conforms to
Detailed conformance reports for each standard are published at Microsoft Accessibility Conformance Reports.
WCAG 2.2
The Web Content Accessibility Guidelines (WCAG) 2.2 cover a wide range of recommendations for making web content accessible to people with visual impairments, hearing loss, limited mobility, inability to speak, blindness and low vision, deafness, limited movement, photosensitivity, and cognitive or developmental disabilities. The guidelines also address accessibility of content across desktops, laptops, tablets, and mobile devices.
Power Pages conforms to the WCAG 2.2 accessibility standard.
US Section 508
The US General Services Administration (GSA) Office of Government-wide Policy (OGP) is tasked under Section 508 of the Rehabilitation Act with providing technical assistance to help Federal agencies comply with these requirements, ensuring that covered information and communication technology (ICT) is accessible to, and usable by, individuals with disabilities.
Power Pages conforms to the Section 508 guidelines defined by the US GSA.
EN 301 549
EN 301 549, published by the European Telecommunications Standards Institute (ETSI), provides an open, inclusive, and collaborative environment supporting the timely development, ratification, and testing of globally applicable standards for ICT-enabled systems, applications, and services.
Power Pages conforms to ETSI EN 301 549.
| Standard | Governing body | Scope | Conformance |
|---|---|---|---|
| WCAG 2.2 | W3C / WAI | Global web content accessibility | Conforms |
| Section 508 | US GSA (Rehabilitation Act) | US Federal ICT accessibility | Conforms |
| EN 301 549 | ETSI (EU) | ICT accessibility across EU member states | Conforms |
Creating an accessible webpage
When building or extending a Power Pages site, follow the WAI-ARIA Authoring Practices 1.1 for widget patterns, keyboard interaction, and ARIA usage.
Customizing your site and accessibility
Important: When you customize a Power Pages site, you are responsible for meeting the applicable accessibility standards (WCAG, Section 508, EN 301 549, or others mandated by your organization/jurisdiction). Platform conformance does not extend to custom code you add.
Basic forms
A basic form renders a model-driven Power Apps form on a webpage. Basic forms typically don't require a developer to design or configure, though a developer may be useful to extend certain form features.
- More information: How to create and modify Dataverse forms using the Data workspace
Basic form accessibility options
Controls in basic forms are built to follow WCAG 2.2. The following options help make forms more accessible:
| Name | Description |
|---|---|
| ToolTips Enabled | Set using the description of the attribute on the target table. Adds a title attribute, giving screen readers additional information. Default: false. |
| Enable Validation Summary Links | Boolean. When true, renders anchor links in the validation summary that scroll to the field containing an error. Default: true. |
- More information: Add a form
Liquid templates and content snippets
When you add custom HTML and Liquid content to a Power Pages site, accessibility must be explicitly considered. Whoever edits Liquid templates or content snippets is responsible for ensuring that content is accessible and adheres to the required policies (e.g., WCAG 2.2, US Section 508, ETSI EN 301 549).
- Reference: WCAG 2.2 Quick Reference—a searchable list of WCAG requirements with links to full descriptions.
Power BI embeds
Power Pages lets you embed Power BI reports/dashboards as a first-party component. As the report/dashboard author, you're responsible for ensuring your Power BI content itself is accessible.
- More information: Power BI accessibility guide
Quick tips for accessible content
Practical checks to apply during development and QA:
- Parity of experience—a person who is blind or has low vision must be able to do everything a sighted user can do.
- Reflow at 400% zoom—verify text stays readable and pages/controls function as expected. See WCAG 1.4.10 (Reflow).
- Color contrast—use a color contrast checking tool. See WCAG 1.4.3 (Contrast Minimum).
- Don't rely on color alone—if color highlights meaning or state, also convey it through text or another visual cue. See WCAG 1.4.1 (Use of Color).
- Alt text on every
<img>—use an emptyalt=""to hide purely decorative images from screen readers (ideally define decorative images via CSS instead). See WCAG C9. - Automated scanning—use Accessibility Insights for two types of scans:
- FastPass—automated check against dozens of common accessibility requirements.
- Assessment—measures compliance against WCAG 2.2 Level AA success criteria.
- Follow ARIA authoring patterns—apply WAI-ARIA Authoring Practices when designing page layout and custom widgets.
- Test with real assistive tech:
- Screen reader: Windows Narrator.
- Immersive Reader in Microsoft Edge—confirm the site renders and reads correctly, adjusting as needed.
Suggested review checklist
Use this as a pre-release gate for any Power Pages site with custom Liquid/HTML/CSS/JS or embedded components:
- [ ] All images have appropriate
alttext (or emptyalt=""for decorative images). - [ ] Color contrast meets WCAG 2.2 AA (contrast ratio ≥ 4.5:1 for normal text, ≥ 3:1 for large text).
- [ ] No information is conveyed by color alone.
- [ ] Site is usable and readable at 400% zoom/reflow.
- [ ] Custom widgets follow WAI-ARIA Authoring Practices (roles, states, keyboard interaction).
- [ ] Forms use tooltips and validation summary links where helpful.
- [ ] Embedded Power BI reports/dashboards are independently verified for accessibility.
- [ ] Site passes an Accessibility Insights FastPass scan.
- [ ] Site has been spot-checked with a screen reader (e.g., Narrator) and Immersive Reader.
Microsoft accessibility features
Microsoft accessibility features help organizations address accessibility requirements and conform to the standards described above.
- More information: Accessibility features of Microsoft products