← Index

DISH — Disability Information & Support Hub

Accessibility audit and functional automation for an AI search assistant built for people with disabilities.

Client
Codesage · EnAble India
Role
Accessibility audit and test automation owner
Period
2026
repositories in scope
8repositories in scope
feature areas
10feature areas
in-scope delivery items
46in-scope delivery items
WCAG 2.1 conformance target
AAWCAG 2.1 conformance target

Overview

AI / RAG product · 8 repositories

DISH is an AI-powered information assistant for people with disabilities — semantic search over a curated corpus, with a voice interface for users who cannot type. It spans eight interdependent repositories delivered on a patch-and-extend strategy. My remit was the part that decides whether it is usable at all: the WCAG 2.1 AA audit and the automated functional suite.

Typed questionkeyboard pathSpoken questionspeech-to-textQuery rewritingintent expansionQdrant vector storesemantic retrievalIngestion pipelinecorpus → chunks → vectorsLLM + guardrailsethical-AI checksretrieved chunksGrounded answer with sourcesstreamed, keyboard-operable, announcedPostgreSQLfeedback · sessionsfeedbackAssertions target properties that must hold whatever the model returns — grounding, sourcing, guardrails, and operability while the answer streams.
DISH retrieval path — query rewriting into a vector store, with speech-to-text as a first-class input.

01

What I owned

  • The full WCAG 2.1 AA accessibility audit across the product's web interface
  • A Playwright suite covering the search path end to end, including the question-and-answer flow with embedded media
  • Report generators producing complete, shareable WCAG and functional reports for the client
  • Verification of the voice interface as an input path, not as a bolt-on

02

Testing an AI product

A semantic search engine has no fixed expected output, so assertions cannot be string equality. The suite verifies the properties that must hold regardless of what the model returns — that a query produces a grounded, sourced answer; that guardrails hold on out-of-scope input; that the interface stays fully operable by keyboard and screen reader while the answer streams in; and that speech-to-text degrades gracefully when the engine is unavailable.

03

Why the accessibility work was the critical path

The users of a disability information hub are, by definition, the people most affected by inaccessible interfaces. A search product they cannot operate is not a partially working product — it is a non-functional one. That framing drove the audit's priority order.

Stack

Product

  • PostgreSQL
  • Qdrant vector store
  • LLM semantic search
  • Query rewriting
  • Speech-to-text

My tooling

  • Playwright
  • TypeScript
  • axe-core
  • Custom report generators

Standards

  • WCAG 2.1 AA
  • Ethical-AI guardrail checks
  • Data governance review