Accessibility and inclusive design review

What it does

It checks that the people an organisation serves can use what it has built. Before release, the channel is tested against accessibility standards, with the assistive technologies customers use, and by people with a range of impairments and levels of confidence with technology. Barriers are removed or an equivalent alternative is provided. The business owner of the channel is accountable; design and engineering carry out the work. It operates at design, before each release and after significant change.

How to implement it

• Identify who uses the channel and what access needs they have.
• Test with screen readers, voice control, magnification and keyboard-only use.
• Test speech and image features with people whose voice, appearance or movement is atypical.
• Allow more time, simpler language and other adjustments on request.
• Keep a human or other alternative that gives the same result, and make it easy to find.
• Record known barriers and the plan for each.

Evidence it operates

Design: accessibility requirements for AI channels. Operation: test reports including sessions with disabled users; a log of barriers and fixes; evidence that the alternative route is available and used; adjustments recorded for individual customers.

Where it fits

At design and before release. It is the primary control for exclusion and inaccessibility and supports unequal performance across groups where the cause is an impairment. It forms part of pre-deployment testing and acceptance.

Limits

Standards written for web pages do not fully cover conversational and voice interfaces. Testing with a few people cannot represent the range of impairments. The underlying model's weaknesses, such as poorer recognition of atypical speech, may not be fixable by the organisation, which makes the alternative route essential and not optional.