Accessibility in design
An inclusive design review identifies barriers in journeys, prototypes and components before they reach development. Your team receives recommendations while there is still time to refine the design.
We review the screens and interaction states that shape the experience, including forms, navigation, errors and dynamic content. The scope can cover a product concept or an established design system.
Design standards
Reviews apply WCAG to journeys and components, with relevant ISO 9241-171 software guidance. UAE services can include the UAE A11y Code and accessible implementation of the UAE Design System.
WAI-ARIA informs recommendations for interactive controls where appropriate. We turn requirements into design feedback and implementation notes that developers can use.
What we review
Journeys and navigation
Task sequences, navigation and information structure, including journeys across several screens or services.
Controls and states
Labels, instructions, errors, loading and confirmation states that explain what people need to do and what has happened.
Visual communication
Contrast, typography, spacing and colour, including how the design responds to longer content and different viewport sizes.
Interaction requirements
Keyboard behaviour, focus movement and information for assistive technology that may not be visible in a static design.
Review outputs
Design findings
Feedback on barriers in content, layout and interaction, with recommendations tied to the relevant design or component.
Implementation guidance
Accessibility annotations and behavioural requirements to support implementation, including details that visual specifications cannot convey.
From design to implementation
We discuss findings with your designers and review changes within the agreed scope. Shared patterns receive particular attention because their behaviour carries across the product.
A design review assesses what can be established before development. An audit of the working product checks the code, keyboard interaction and assistive technology support after implementation.
Preparing for a review
Share the design files, key journeys and component guidance. We identify the decisions still open to change and the feedback your team needs for its next iteration.
For bilingual services, include Arabic and English designs with representative content. Mixed-language text, mirrored layouts and language switching should be considered together.
Design review questions
When should a review take place?
When a journey or component is developed enough to explain its intended behaviour and there is time to respond to findings. Reviews can support early prototypes or mature design systems.
Can the review support developer handover?
Yes. We can provide accessibility annotations and interaction requirements for developers. Testing the implemented service then checks how those decisions work in practice.
Build sustainable accessibility
Tell us about your services, your priorities and the people who use them. We will help you define the right support, agree a clear scope and plan your next steps.
Get in touch