I support your team as it defines journeys, screens and components. We review accessibility decisions before development and translate them into Figma annotations, specifications and acceptance criteria.
I support product leads, designers and developers in decisions that determine accessibility. The work makes explicit how journeys should behave and what the team needs to build and test.
I examine decisions that affect how the product is used and connect them to practical guidance. For each area, I clarify what to change in the design and what to check in the implementation.
I review the sequence of steps, information hierarchy, labels and instructions. I assess how people recognise the result of an action and recover from errors.
I examine contrast, use of colour, readability, control sizes and content adaptation. I distinguish issues visible in a prototype from behaviours to test in a browser, such as magnification and reflow.
I describe keyboard interaction, focus order and management, accessible names and state changes. I also examine loading, errors and confirmations to make expected behaviour explicit.
We define accessibility references starting with WCAG and the product context. We consider markets, existing components and technical constraints; open decisions remain documented and assigned to project leads.
I collaborate with project leads when decisions are made. Each stage produces shared materials and explicit responsibilities, through to discussions with the people implementing the design.
Scoping
We gather goals, user tasks, materials and constraints. We identify journeys to review, contacts and decisions that need discussion.
Team review
I review journeys and components with design and development. We prepare Figma annotations, assess alternatives and resolve ambiguities before implementation.
Development handoff
I clarify expected behaviours with developers and testers. The team builds the product; any implementation verification and retesting of fixes are defined in the engagement.
Guidance needs to be usable in everyday work. For the agreed journeys and components, I prepare deliverables that connect design to development and QA tasks.
Requirements
I document requirements and testable acceptance criteria: what the person must be able to do, how the interface should respond and which tests are needed. Your team can include them in development tasks and its definition of done.
Figma
I work with designers on Figma files to prepare and review accessibility annotations. Alongside screens, components and variants, I document what the visual design alone cannot convey, so developers know which behaviour to implement and QA knows what to check.
Design system
If your team uses a design system, I connect guidance to the reviewed components. We document states, usage rules and behaviours to retain in new features, checking them in context each time.
Two illustrative boards show how to connect a design element to guidance for development and QA. These are fictional examples, not screenshots of Figma files or client work. The numbered notes are also available as text on the page.
The visible title “Send the request?” provides the dialog’s accessible name. On opening, the screen reader must identify the dialog and its title.
In this example, initial focus is on “Cancel”. Tab and Shift+Tab stay within the dialog; Escape closes it without submitting. Background content is not interactive.
On closing without submitting, focus returns to the “Review and send” button that opened the dialog. Behaviour is checked on the implemented component.
“Email (required)” stays visible after the field is filled in and is associated with it in code. The placeholder does not replace the label.
The instruction explains which address to enter. It must be connected to the field so it is available to assistive technologies when the person fills it in.
The message describes the problem and how to fix it. In code, the error and invalid state are associated with the field; colour is accompanied by text and a symbol. The entered value is preserved.
When to start, how to share materials and what can be checked during design.
Tell me what you are designing, your current stage and which decisions are still open. We can start with a journey, a component or a Figma file: you do not need to have written every requirement already.