Accessibility in Dynamics 365 apps

Accessibility — designing apps so that users with disabilities can use them effectively — is a legal requirement in many jurisdictions and an ethical baseline everywhere. Dynamics 365 ships with accessibility features in standard pages and components; customisations can reduce or improve accessibility. Understanding the baseline and how to preserve it during customisation is essential.

The standards.

• WCAG (Web Content Accessibility Guidelines) — international standard from W3C.
• WCAG 2.1 AA — common compliance target.
• WCAG 2.2 AA — newer; some additional criteria.
• Section 508 (US) — federal requirement; references WCAG.
• EN 301 549 (Europe) — public sector procurement; references WCAG.
• ADA (US) — Title III applies to private organisations; often referenced as WCAG-equivalent in practice.

Most organisations target WCAG 2.1 AA as the working standard.

Microsoft's accessibility commitment.

• Microsoft publishes Voluntary Product Accessibility Templates (VPATs) for Dynamics 365 products.
• Standard pages are designed with accessibility in mind.
• Accessibility is part of the product development standards.

VPATs are useful evidence for procurement compliance.

What standard Dynamics 365 provides.

• Keyboard navigation through forms, views, and commands.
• Screen reader support — Narrator, JAWS, NVDA work with model-driven apps and canvas apps.
• High contrast modes — Windows high contrast respected.
• Scalable text — browser zoom up to 200%.
• Logical tab order — focus moves predictably.
• ARIA labels on standard controls.
• Skip navigation — jump past repeated headers.

For an un-customised app, baseline accessibility is reasonable.

Where customisation breaks accessibility.

• Custom JavaScript that intercepts keyboard events without preserving accessibility.
• PCF controls without ARIA attributes.
• Custom forms with poor tab order.
• Inaccessible third-party embeds — iframes, web resources.
• Colour-only information — status communicated only through colour.
• Missing labels on custom controls.

Each is a regression from baseline; cumulative impact significant.

Power Apps canvas — accessibility considerations.

• AccessibleLabel property on controls — set this on every input.
• Logical TabIndex — preserves keyboard navigation order.
• Color contrast — built-in App Checker flags low-contrast.
• Avoid colour-only communication — pair colour with icon or text.
• Screen reader support — verify each screen with NVDA or Narrator.

App Checker (built into Power Apps Studio) flags many accessibility issues at design time.

Model-driven app accessibility.

• Form layouts — sections labeled; controls have labels.
• Sub-grids — accessible by default; verify custom views.
• Ribbon and command bar — keyboard accessible.
• Custom forms via JavaScript — JavaScript can introduce regressions; test.

Power Pages accessibility.

• Web template authors must follow web accessibility practices.
• Liquid templates — ensure semantic HTML.
• Custom CSS — preserve focus styles; don't remove outlines.
• Forms — labels, fieldsets, proper input types.

Power Pages is web; full web accessibility practices apply.

Voice and screen reader testing.

• Test with actual screen readers — NVDA (free), JAWS, Narrator.
• Keyboard-only test — disable mouse for a session.
• High contrast mode test — Windows high contrast enabled.
• Browser zoom to 200% — verify layout doesn't break.

These tests reveal issues that visual review misses.

Common accessibility failures.

• Custom button without keyboard support — only mouse-clickable.
• Form field without label — screen reader announces "edit text" only.
• Colour-only state indicator — "red means error" invisible to colour-blind.
• Modal dialogs without focus management — focus stuck behind dialog.
• Custom dropdowns — keyboard navigation broken.
• Image without alt text — screen reader skips meaningful image.

Common pitfalls in development.

• Accessibility tested at end. Far cheaper to fix issues during development.
• No accessibility champion. No one owns the accessibility story; gaps accumulate.
• Reliance on automated tools alone. Automated tools catch ~30% of issues; manual testing essential.
• Customisations not VPAT-evaluated. Microsoft VPAT covers standard product; customisations need their own evaluation.
• Regression after release. Updates introduce regressions; periodic re-audit needed.

Audit and certification.

• Internal audit — periodic accessibility review by trained staff.
• External audit — formal review by accessibility specialists.
• VPAT — for procurement compliance with US federal agencies and others.
• Continuous monitoring — automated tools (axe, WAVE) running in CI.

Accessibility in design phase.

• Wireframes reviewed for accessibility before build.
• Colour palette validated for contrast.
• User journeys checked for keyboard completability.

Catching issues at design is cheaper than fixing post-build.

Operational rhythm.

• Per release — automated accessibility check in CI; spot-check by humans.
• Quarterly — fuller audit of high-traffic surfaces.
• Annually — full external audit for compliance evidence.
• On regression — fix and re-audit affected surfaces.

Strategic positioning. Accessibility is non-negotiable for many organisations:

• Public sector — legal requirement.
• Regulated industries — often explicit standards.
• Multi-national — Europe, Canada, Australia have strong requirements.
• Customer-facing portals — ADA-style lawsuits a real risk in US.

For internal-facing Dynamics deployments, accessibility broadens who can be hired and supported. For external-facing, it's a compliance and inclusion baseline.

The investment is modest if built in early; expensive if retrofitted. Build accessibility practices into design, build, and deployment processes from the start. The payback is in compliance, in user inclusion, and in avoiding costly retrofits or legal action. Most modern organisations should treat accessibility as foundational, not optional.