Accessibility & i18n
The cross-cutting accessibility compliance, internationalization, and accommodation layer — every module's UI, documents, notifications, and public-facing content must adhere to standards enforced here.
WCAG Level
AODA Compliance
Languages
Screen Readers
Purpose-Built for Canadian Municipalities
How It Works
The identity journey, step by step
From first registration to golden record resolution — how a resident's identity evolves across the platform.
One-Click Language Switch
A French-speaking citizen switches the entire portal to French.
How it works
The citizen clicks the 'FR' toggle in the header. The entire application re-renders in French — navigation, labels, forms, content, notifications, and dates/numbers adapt to French Canadian formatting. Their preference is saved to their profile and applied on future visits across all devices.
Step 1 of 5
Purpose & Scope
What this module owns
Clear ownership boundaries prevent duplication and ensure every capability has exactly one authoritative home.
Owns
13Delegated to
3UI component library
Content authoring
Notification content
These capabilities are handled by dedicated modules and consumed via stable API contracts — keeping boundaries clean and ownership unambiguous.
Core Capabilities
What it does
5 capability groups comprising 13 discrete capabilities — each with API surface, business rules, and data ownership.
Text alternatives for non-text content, captions for video, adaptable content, and distinguishable visuals with enforced color contrast ratios.
Text Alternatives
Alt text for all non-text content; captions and transcripts for audio/video.
Color Contrast
Minimum 4.5:1 contrast ratio for normal text, 3:1 for large text — enforced platform-wide.
Adaptable Content
Content structure conveyed through proper semantic markup independent of presentation.
Distinguishable
Color is not the sole means of conveying information; audio control provided for auto-playing media.
Full keyboard accessibility with no keyboard traps, sufficient timing, no seizure triggers, and navigable interfaces with skip links and focus order.
Keyboard Accessible
All functionality available via keyboard; no keyboard traps; visible focus indicators.
Sufficient Time
Users can extend or disable time limits; auto-updating content can be paused.
Seizure Prevention
No content that flashes more than 3 times per second.
Navigable
Skip links, logical focus order, descriptive link purpose, multiple navigation methods.
Readable content with declared page language, predictable navigation, and input assistance with clear error identification and labels.
Readable
Language of page and language of parts declared; content written at appropriate reading level.
Predictable
Consistent navigation and identification patterns across the platform.
Input Assistance
Error identification, descriptive labels, inline error suggestions, and error prevention on important submissions.
Compatibility with assistive technologies through valid HTML, ARIA landmarks/roles, and proper name/role/value attributes.
Assistive Tech Compatibility
Tested with NVDA, JAWS, and VoiceOver screen readers.
Valid HTML
Proper semantic markup; no parsing errors that break assistive technology interpretation.
ARIA
Appropriate ARIA landmarks, roles, states, and properties for custom UI components.
Name / Role / Value
All interactive elements expose accessible name, role, and state to the accessibility API.
Real-World Scenarios
Who uses this, and how
4 persona-driven scenarios showing how Accessibility & i18n works in practice — from resident registration to privacy compliance.
Citizen with Disability
Accessibility Complaint & Accommodation
A citizen with a mobility impairment encounters a form that requires drag-and-drop interaction and cannot complete it with keyboard only.
Steps
- 1The citizen attempts to use the form with keyboard-only navigation
- 2They encounter a drag-and-drop widget that is not keyboard accessible
- 3They submit an accessibility complaint through the accessible feedback form
- 4The system logs the issue, creates an accessibility audit record, and notifies the responsible team
- 5Staff provides an alternative method to complete the task while the fix is developed
- 6The development team remediates the widget to support keyboard operation
- 7The fix is verified by automated axe-core testing and manual review
Outcome
The citizen's task is completed via accommodation, the underlying accessibility issue is permanently fixed, and the audit trail documents the entire resolution for AODA compliance.
View scenario
Municipal Clerk
Bilingual Election Content
The municipal clerk needs to publish election notices, candidate information, and voting instructions in both English and French before election day.
Steps
- 1The clerk creates election content in English through the CMS
- 2The translation management system queues all new strings for French translation
- 3A certified translator translates the election-specific content
- 4A reviewer verifies the French translations for legal accuracy
- 5Both language versions are published simultaneously
- 6Citizens see content in their preferred language; the language toggle works on all election pages
Outcome
Election information is available in both official languages, meeting MEA requirements. Citizens can participate fully regardless of language preference.
View scenario
Accessibility Coordinator
Quarterly Manual Accessibility Audit
The accessibility coordinator conducts the quarterly IAAP-certified manual audit of the platform's most-used citizen-facing pages.
Steps
- 1The coordinator selects the top 20 citizen-facing pages based on analytics
- 2Manual testing is performed with NVDA, JAWS, and VoiceOver screen readers
- 3Keyboard-only navigation is tested on every page and form
- 4Color contrast is verified with manual spot-checks beyond automated testing
- 5Findings are logged as Accessibility Audit records with severity and remediation guidance
- 6A compliance report is generated showing WCAG 2.1 AA conformance status
- 7Remediation items are assigned to development teams with SLAs
Outcome
The platform maintains its AODA compliance certification. All critical issues are remediated within one sprint. The audit report is filed as part of the municipality's multi-year accessibility plan.
View scenario
Citizen
Accessible Document Request
A citizen using a screen reader needs to review their property tax assessment notice, which was originally generated as a PDF.
Steps
- 1The citizen opens their property tax assessment notice in the portal
- 2The PDF is generated with PDF/UA compliance — tagged structure, alt text, reading order
- 3The screen reader announces the document structure and reads content in logical order
- 4The citizen requests an HTML alternative format for easier navigation
- 5The system generates an accessible HTML version of the same document
- 6The citizen reviews the assessment using their preferred format
Outcome
The citizen fully accesses their tax assessment regardless of ability. PDF/UA compliance ensures the default PDF is accessible, and alternative formats provide additional options.
View scenario
Internal Architecture
How it's built
4 architectural layers comprising 24 components — from API gateway to data quality engine.
4 layers · 24 total components
Accessibility & i18n
Every module owns a single bounded context, exposes stable APIs, and can be composed into any Civic product — that's the architecture that scales.
Krutik Parikh
Creator of Civic
Data Model
Entity Architecture
3 entities with 3 relationships — the authoritative schema for this bounded context.
Entities
Select an entity to explore its fields and relationships
API Surface
Integration Endpoints
9 RESTful endpoints across 3 resource groups — plus 4 domain events for async integration.
/api/v1/i18n/strings/{module}/{language}
Get all translation strings for a module in specified language
/api/v1/i18n/string/{key}/{language}
Get single translation by key and language
/api/v1/i18n/string/{key}
Update a translation string (EN or FR value)
/api/v1/i18n/missing/{language}
List all strings missing translation for a language
Ecosystem
Products that depend on this module
9 Civic products consume Accessibility & i18n — making it one of the most critical platform services in the ecosystem.
Accessibility Compliance
This IS the Accessibility Compliance spec — full AODA platform for managing compliance, audits, and accommodation requests
View product →
CMS
All public website content bilingual and accessible; translation workflow integration
View product →
Citizen Engagement
Surveys and consultations accessible to all abilities; bilingual participation
View product →
Portal / Digital Identity
All citizen-facing screens WCAG 2.1 AA; accommodation profile integration
View product →
Elections
Ballot and voting interfaces accessible per MEA requirements; bilingual ballots
View product →
Recreation
Registration forms accessible; program descriptions bilingual
View product →
Transit
Real-time transit information accessible; announcements and alerts bilingual
View product →
Emergency Management
Emergency alerts in accessible formats; bilingual emergency communications
View product →
Court / POA
Court notices accessible; interpretation support; bilingual legal documents
View product →
Technical Specifications
Performance, Compliance & Configuration
WCAG Compliance
AODA Compliance
Translation Coverage
Automated Testing
Manual Audit
Screen Reader
Keyboard
FAQ
Frequently Asked Questions
Ready to Integrate
Build on Accessibility & i18n
Request an architecture brief, integration guide, or live demo environment for your team.