Language-access and accessibility laws are written into requirements for a resident-facing permitting chatbot. What compliance practice is this?
Select an answer to reveal the explanation.
Short Explanation
Resident-facing AI is a public counter, not a private app. Bake in language access and accessibility from day one—English-only 'for now' leaves people outside the door.
Full Explanation
Incorporating accessibility and language-access into civic AI compliance is the correct practice when language-access and accessibility laws are written into requirements for a resident-facing permitting chatbot. That works because a municipal chatbot is a public service channel: residents with disabilities and limited English proficiency have legal and equity claims to usable access. Writing those duties into requirements from the start forces vendors and builders to support WCAG-aligned interfaces, multilingual content or interpretation paths, and human fallback—rather than treating inclusion as optional polish after launch.
Shipping English-only chat first and promising translations later if budget allows fails by concept: deferred language access excludes residents at go-live and often never returns as a funded priority. Claiming AI is inherently accessible so no WCAG or language review is needed fails by concept—models and chat UIs introduce new barriers (vision, keyboard, cognitive load, language) that require explicit testing. Supporting only the single most common language to reduce prompt cost fails by concept: cost optimization that drops mandated languages is noncompliance, not efficiency.
Exam caveat: compliance includes both the chat UI and the content/escalation paths—not only model prompts. Keep permitting chatbot / resident-facing framing. Operational check: put language-access and accessibility into the requirements and acceptance tests; test with assistive tech and priority languages; provide human clerk fallback; and refuse launch when required language or accessibility criteria fail.