Accessibility statements are often written as compliance documents, technical, generic, and disconnected from real user needs.

This project focused on redesigning an existing accessibility statement to make it clear, actionable, and aligned with how people actually look for support.

An accessibility statement should do three things well:

• Set clear expectations

• Acknowledge limitations transparently

• Provide a reliable way to get help

The original version had the right components (WCAG reference, compatibility, feedback), but lacked clarity, structure, and usability.

This project reframes the accessibility statement as a user experience, not a legal artifact.

Plain Language & Direct Tone
Removed vague phrasing and replaced it with clear, accountable language.

Defined Conformance Status
Shifted from “we seek to conform” → explicit status + transparency about gaps.

Complete Compatibility Information
Added real versioning and clarified testing scope.

Clear Feedback Mechanism

• Contact options

• Expected response time

• Defined ownership

Structured Complaint Process

• Clear steps to submit a complaint

• Internal workflow requirement (tracking, follow-up, accountability)

• No dead ends

Limitations with Accountability
Instead of disclaimers, framed limitations with commitment and action.

Accessibility is Communication
If users can’t understand your accessibility statement, it’s already failing.

Trust Comes from Transparency
Acknowledging gaps builds more credibility than overclaiming compliance.

Support Must Be Actionable
A contact email without process = broken experience.

This redesign transforms the accessibility statement into:

• A trust-building document, not a disclaimer

• A clear support entry point, not a dead-end email

• A governance tool, connecting user feedback to internal accountability

It shifts accessibility from static compliance → active responsibility.

The accessibility statement itself follows best practices:

• Plain Language: Clear, concise, readable content

• Semantic Structure: Proper headings and hierarchy

• Keyboard Navigation: Fully accessible interaction

• Color Contrast: Meets WCAG standards

• Assistive Technology Support: Compatible with screen readers

• Clear Interaction Patterns: Predictable links, labels, and actions