Meeting WCAG 2.2 on Power Pages for WA Government Digital Services

Western Australian agencies delivering citizen-facing services increasingly build public portals on Microsoft Power Pages, drawn by its integration with Dataverse, Microsoft Entra, and the wider Power Platform. Accessibility conformance is not an optional refinement in these projects; it is a condition of responsible public service delivery and a recurring theme in procurement evaluation and post-implementation audit. Agencies that treat accessibility as a design constraint from the outset avoid the far greater cost of remediating a live portal under scrutiny. This article sets out practical patterns for aligning a Power Pages portal with the Web Content Accessibility Guidelines version 2.2 in a way that stands up to review.

The guidance here is deliberately technical and pattern-led rather than aspirational. It assumes a delivery team that understands liquid templates, Bootstrap-based layouts, and the customisation surface that Power Pages exposes. The goal is to help teams recognise where conformance risks commonly arise, how to address them within the platform's native capabilities, and how to demonstrate the result to an assessor. Accessibility is ultimately about ensuring every resident can complete a task, and the engineering discipline that supports that outcome is entirely achievable within a Microsoft-native stack.

Understanding WCAG 2.2 in the Western Australian context

WCAG 2.2 was published by the World Wide Web Consortium as a formal Recommendation in October 2023, extending the earlier 2.1 guidance with additional success criteria rather than replacing it. The Level AA conformance target remains the widely expected benchmark for Australian government digital services, and WA agencies routinely reference it in service standards and contractual obligations. Because WCAG 2.2 is backwards compatible with 2.1, teams that already conform to the earlier version have a manageable path forward, focused on a defined set of new criteria. Treating 2.2 as an incremental uplift rather than a wholesale rebuild keeps remediation proportionate and auditable.

Several of the new WCAG 2.2 criteria are particularly relevant to transactional portals of the kind agencies build on Power Pages. Target Size (Minimum) expects interactive controls to occupy at least 24 by 24 CSS pixels or provide adequate spacing, which affects densely packed form controls and icon buttons. Accessible Authentication discourages cognitive function tests during sign-in, Redundant Entry discourages asking users to re-enter information they have already provided in a process, and Consistent Help expects help mechanisms to appear in a consistent location across pages. Focus Not Obscured and Dragging Movements round out the additions and warrant explicit checking against the interactive components in your portal.

Common remediation patterns on Power Pages

Power Pages generates much of its markup from configured forms, lists, and web templates, which means accessibility defects often originate in customisation rather than the platform itself. A frequent issue is the loss of programmatic labelling when developers replace default form rendering with bespoke liquid or JavaScript, leaving inputs without associated labels or with labels conveyed by placeholder text alone. The remediation is to ensure every control has a persistent, programmatically associated label using correct for and id pairing, and to reserve placeholder text for supplementary hints rather than the primary label. Where multi-step forms span several pages, aligning with Redundant Entry means carrying forward previously captured Dataverse values rather than prompting the resident to key them again.

Colour and contrast defects are the second recurring category, often introduced when agency branding is applied over the default Bootstrap theme. Text and interactive elements must meet the contrast ratios required at Level AA, and status information conveyed only through colour must be reinforced with text or iconography. Keyboard operability is equally important, so custom components such as modal dialogs, accordions, and date pickers must expose a logical focus order, a visible focus indicator, and the ability to complete every action without a pointing device. When you introduce custom widgets, prefer native HTML controls or well-supported ARIA patterns, and verify that focus is never trapped or hidden behind sticky headers, which addresses the Focus Not Obscured criterion directly.

Structural and navigational patterns deserve the same rigour as individual controls. Every page should present a single, correctly ordered heading hierarchy, meaningful page titles, and descriptive link text so that assistive technology users can orient themselves quickly. Help mechanisms, whether a contact link, a phone number, or a support chat entry point, should appear in a consistent position across the portal to satisfy Consistent Help. Error handling on submitted forms must identify the field in error, describe the problem in text, and move focus to the first affected control, which supports both usability and conformance.

Testing, evidence, and audit readiness

Demonstrating conformance requires evidence, not assurances, so build accessibility testing into the delivery pipeline rather than leaving it to a final gate. Automated tooling such as axe-based scanners and Microsoft Accessibility Insights will surface a meaningful proportion of defects, but automated checks alone cannot confirm conformance because many criteria require human judgement. Combine automated scans with manual keyboard-only navigation, screen reader testing using common tools, and review against a documented WCAG 2.2 checklist for each template and component. Recording the outcome of these checks against specific pages produces the traceable evidence that procurement and audit processes expect.

An Accessibility Conformance Report structured against the criteria, together with a register of known issues and their remediation timelines, gives assessors a clear picture of the portal's status. Involving people with disability in usability testing strengthens both the outcome and the evidence base, because lived experience frequently reveals barriers that structured testing overlooks. Maintaining this discipline across releases matters because Power Pages portals evolve, and a conformant portal can regress when new forms or components are added without review. Embedding accessibility into change management protects the investment and keeps the service defensible over time.

References

• W3C Web Content Accessibility Guidelines (WCAG) 2.2
• Microsoft Power Pages documentation