{How to } Make Power Page Portal WCAG 2.1 Level A and AA Standards

Hello Everyone,

Today I am going to share my thoughts on how to make power pages portal according to the WCAG 2.1 Level A and AA Standards.

Let's get started.

Making a Power Pages portal (from Microsoft’s Power Platform) compliant with WCAG 2.1 Level A and AA means addressing accessibility across design, content, and code. Power Pages gives you a solid starting point, but compliance depends on how you build and customise it.

Here’s a practical, structured way to get there:

1. Start with an Accessible Theme

Power Pages portals use templates (often based on Bootstrap).

• Choose themes with good colour contrast

• Avoid heavily customised UI that breaks semantic structure

• Ensure responsive design (important for accessibility + zoom)

👉 Tip: Use tools like contrast checkers to meet 4.5:1 ratio (AA).

2. Use Proper HTML Semantics

WCAG relies heavily on structure.

• Use correct heading hierarchy (h1 → h2 → h3)

• Use semantic elements (<nav>, <main>, <footer>)

• Avoid using <div> for everything

In Power Pages:

• Edit templates via Portal Management app

• Ensure Liquid templates output proper HTML

3. Keyboard Accessibility (Critical for Level A)

Every feature must work without a mouse.

Check:

• Tab navigation works logically

• No keyboard traps

• Focus indicators are visible

Fix:

• Add tabindex where needed (carefully)

• Ensure modals and menus are accessible

4. Add Alternative Text

or all non-text content:

• Images → meaningful alt text

• Decorative images → alt=""

• Icons → labelled via aria-label if needed

5. Forms Must Be Accessible

Power Pages often includes forms (Dataverse forms).

Ensure:

• Every input has a <label>

• Errors are clearly described

• Required fields are indicated

• Instructions are clear

Enhancements:

• Use aria-describedby for hints/errors

• Provide inline validation messages

6. Colour Is Not the Only Indicator

WCAG Level A/AA requires:

❌ Don’t rely only on colour
✔ Add:

• Icons

• Text labels

• Underlines for links

7. ARIA (Use Carefully)

Use ARIA only when HTML isn’t enough.

Examples:

• aria-label

• aria-live for dynamic updates

• role="navigation"

⚠️ Don’t overuse ARIA—bad ARIA can make things worse.

8. Ensure Accessible Navigation

• Provide skip to content link

• Use consistent menus

• Highlight current page

• Make dropdowns keyboard accessible

9. Multimedia Accessibility

If your portal includes media:

• Videos → captions (AA requirement)

• Audio → transcripts

• Avoid auto-play

10. Test with Real Tools

You cannot rely on assumptions—test everything.

Automated tools:

• axe DevTools

• Lighthouse

• WAVE

Manual testing:

• Keyboard-only navigation

• Screen readers like NVDA or JAWS

11. Handle Dynamic Content (Important in Power Pages)

Power Pages often loads data dynamically.

Ensure:

• Screen readers are notified (aria-live)

• Focus moves correctly after updates

• No unexpected context changes

12. Documentation & Governance

For ongoing compliance:

• Create accessibility guidelines for your team

• Train content editors

• Add accessibility checks to deployment process

13. Common Power Pages Pitfalls

Watch out for:

• Custom JavaScript breaking keyboard navigation

• Poorly styled buttons/links

• Missing labels in Dataverse forms

• Modals that trap focus

• Low contrast in branding overrides

Quick Checklist (AA Ready)

✔ Keyboard accessible
✔ Proper headings & landmarks
✔ Alt text everywhere
✔ Form labels + error messages
✔ Colour contrast compliant
✔ Captions for video
✔ Skip navigation link
✔ Tested with screen reader

That's it for today.

I hope this helps.

Malla Reddy Gurram aka @UK365GUY