Accessibility and Inclusion in Public AI-Powered Services

Why accessibility must be central in public AI projects

AI projects in public administration are not neutral: they affect basic rights (access to services, nondiscrimination, privacy). Beyond general obligations on transparency and data protection (GDPR) and the emerging requirements of the EU AI Act for high-risk systems, municipal teams must ensure technology is usable by people with different abilities, digital skills, languages, and connectivity conditions. If systems are not designed with inclusion in mind, inequalities widen and there is a higher risk of legal noncompliance, public rejection, and costly fixes.

Concrete risks to avoid

• Digital exclusion: interfaces that require high digital literacy or fast connections.
• Algorithmic discrimination: models that perform worse for minority or vulnerable groups.
• Accessibility barriers: formats incompatible with screen readers, color choices that hinder readability, or lack of multimedia alternatives.
• Lack of alternative channels: exclusive dependence on digital channels without phone or in-person options.
• Transparency and human oversight gaps: automated decisions without explanation or human review.

Operational checklist for AI projects (before, during, and after)

1. Project definition

• Identify vulnerable user groups and their specific needs (older adults, people with sensory or cognitive impairments, migrants, low digital literacy).
• Require vendors to demonstrate experience in accessibility and inclusion and to include user testing with real people in the tender.
• Include inclusion metrics and acceptance thresholds in procurement criteria (e.g., minimum success rate in tests with users with disabilities).

2. Data management

• Review representativeness: assess coverage of relevant attributes in the data (age, gender, origin, language, disability when it is legal and ethical to collect).
• Define pseudonymization and minimization processes aligned with the GDPR; avoid sensitive inferences that could harm vulnerable groups.
• Document decisions to exclude/include data and their expected impact on the service.

3. Model development and evaluation

• Fairness tests: evaluate performance segmented by relevant groups and document deviations. Set tolerance criteria and corrective steps.
• Operational explainability: design outputs that allow explaining decisions to a nontechnical person (simple summaries, reasons, key variables).
• Human fallback: ensure that all automated decisions affecting rights or entitlements have accessible human review and an easy way to request it.

4. Interface and service channels

• Mandatory multichannel access: accessible web, telephone support with adaptations (plain-language options, trained operators), and in-person or mail options for those who need them.
• Lightweight alternatives: low-bandwidth versions and non-graphical formats (clear text, voice).
• Inclusive usability testing: sessions with real people from the identified groups and documentation of critical failures.

5. Deployment and monitoring

• Continuous monitoring of usage and errors by user segment; alerts if new barriers are detected.
• Explicit and visible feedback channels (accessible form, phone, physical mailbox) and a commitment to respond within defined timelines.
• Audit logs: retain traceability of decisions and equity metrics for compliance and potential audit under the EU AI Act.

Contractual and organizational requirements (what to ask the vendor)

• Deliverables: accessibility report, fairness test reports, bias mitigation plan, and technical documentation enabling audit.
• Acceptance tests: include scenarios with users with disabilities and low-connectivity conditions as part of final acceptance.
• Training: training for citizen-facing staff and human reviewers on how to interpret system outputs and handle accessibility incidents.
• Maintenance and support: clauses covering updates that improve accessibility and incident management within agreed timelines.

Practical measurement: suggested KPIs

• Success rate on critical tasks by segment (e.g., completing an application) — default target ≥ 90% across all groups.
• Average resolution time with and without human assistance.
• Number of requests for in-person alternatives per 1,000 users.
• Percentage of accessibility incidents resolved within X days.
• Model performance deviation between groups (must be documented and justified).

Example 90-day starter plan (medium-sized municipality)

• Weeks 1–2: Map candidate services and vulnerable users; define inclusion objectives.
• Weeks 3–5: Include accessibility and equity requirements in tenders or agreements; select a vendor with relevant experience.
• Weeks 6–10: Data tests and first prototype with inclusive usability testing.
• Weeks 11–12: Adjustments, KPI definition, and multichannel deployment plan.
• Week 13: Pilot launch with monitoring and active feedback channels.

Conclusion and recommended action

Accessibility and inclusion are not add-ons: they are success and compliance criteria. Immediate recommended action for municipal leaders: review ongoing AI projects against the checklist above and schedule a rapid 30-day audit on accessibility, fairness, and alternative channels. Early diagnosis reduces costs and improves public trust. Solutions like OptimGov include modules and practices that help embed these checks into existing administrative processes, but the key is to start with clear objectives and concrete measurements.

Key takeaway: include testing with real users and disaggregated metrics from the definition phase; require human fallback and alternative channels before putting any citizen-facing AI system into production.