An attractive Figma screen does not explain every decision needed to build an accessible website. It may show a navigation menu in its open state without explaining keyboard focus, or a form error without defining how the person entering information discovers and corrects it. Those missing details become expensive questions during development.
Accessibility annotations help connect the visual design with intended behaviour. This guide outlines a practical handover workflow for service websites and ecommerce projects. It is a design and collaboration guide, not a claim that a Figma review alone can establish accessibility conformance or replace testing the implemented website.
Begin with the journeys people need to complete
List the primary tasks before annotating individual components. A service website might require visitors to understand the offer, compare relevant work and send an enquiry. A shop might require product comparison, variant selection and an understandable purchase journey.
For each task, identify the controls, content and feedback the user needs. This keeps the review focused on complete experiences. A carefully labelled icon is useful, but it cannot rescue an enquiry journey whose error state or completion message has never been designed.
Record these tasks in the project brief and link them to the relevant design frames. The same task list should later guide development review and acceptance testing.
Agree on an annotation structure
Figma provides measurement and annotation features for communicating design decisions. Confirm the capabilities available in your team's workspace and plan, then choose a consistent approach that everyone can access.
Use short notes with a clear subject, expected behaviour and verification step. For example, a navigation annotation can describe where focus moves when the menu opens and what happens when it closes. Link to a shared component rule rather than repeating slightly different instructions across many pages.
Assign ownership for unresolved questions. A note saying accessibility needed does not tell anyone what to build or test. A concrete open question with a named owner is much more useful.
Specify meaningful structure beyond visual styling
Mark the intended page heading and the relationship between major sections. Visual size does not always reveal the correct content structure. A small section heading may still have an important structural role, while a large decorative statement might not belong in the heading hierarchy.
Discuss landmark and grouping decisions with the developer. The design file should communicate the reading sequence and content relationships, while the implementation uses appropriate HTML and controls. Avoid demanding a particular technical attribute without understanding whether a native element already provides the needed behaviour.
Use realistic copy when reviewing structure. Placeholder text can hide repeated headings, vague link labels and instructions that only make sense beside a particular image.
Design focus and keyboard behaviour as visible states
Include a visible focus state for interactive components. Show how it works against the actual backgrounds used in the website, including image cards, dark sections and sticky interfaces. A focus treatment that disappears on one background is an incomplete component specification.
Document the logical order through a representative page. The visual arrangement should not create an unexpected journey when controls are reached sequentially. Be particularly careful with layouts that move content into different positions on mobile.
For dialogs and overlays, describe entry, exit and return behaviour. Include the close control and explain where the user resumes after closing. Developers should validate the implementation with a keyboard rather than assume the design notes prove the behaviour works.
Give forms a complete set of states
A form component needs more than an empty input and a styled submit button. Include labels, instructions, optional information, validation feedback, submission progress and a clear completion state. Explain what happens when a request fails without losing the person's useful input.
Create an illustrative enquiry scenario with a missing email address and an overly long project description. Write the actual messages and show where they appear. Confirm that the design does not rely on colour alone to distinguish a problem.
Use the enquiry form usability guide to review the wider flow. Ask the developer how errors and status changes will be exposed in the working interface, then test that result with appropriate assistive technology.
Annotate images and icons according to purpose
Record whether an image communicates information, supports an action or is decorative. The same image can serve different purposes in different contexts. A portfolio thumbnail linking to a project requires a different decision from a purely decorative background texture.
Where alternative text is needed, draft it around the relevant information instead of copying the filename or adding keywords. For icons, explain the meaning of the control rather than describing the drawing. A visible label is often clearer than an unexplained symbol.
Do not fill every annotation with final text before the content is approved. Mark provisional wording clearly and include image and icon decisions in the editorial review before launch.
Define responsive behaviour without hiding essential content
Show what happens when space becomes limited. Long navigation labels, larger text and narrow screens can reveal decisions that a wide desktop frame conceals. Specify whether content wraps, stacks or moves into a disclosure pattern, and what remains available.
An important instruction should not disappear simply because it complicates a mobile layout. Consider how the content can be reorganised while preserving its purpose. Test with realistic names, longer headings and meaningful form feedback.
Coordinate these rules with the Figma design-token handover guide. Shared spacing and typography rules make components easier to maintain, but individual tasks still need review in context.
Include motion preferences and interaction alternatives
Document where motion is decorative and where it communicates state. A hover animation should not be the only way to discover important content. A moving portfolio presentation still needs usable controls and a clear reading experience.
Define the intended experience when reduced motion is requested. Keep the important information and actions available while reducing unnecessary movement. Avoid writing a vague instruction to disable all animation, because some transitions may communicate useful feedback that needs a suitable alternative.
Test interactions on touch devices as well as with a mouse. Essential information should be available without requiring a hover state that the customer may never encounter.
Turn annotations into acceptance evidence
Choose representative pages and components for an implementation review. Track each design intention alongside the observed behaviour, issue owner and retest result. This creates an accountable connection between the Figma file and the website people actually use.
Review the W3C WAI accessibility evaluation resources when planning appropriate checks. Automated tools can support the process, but human evaluation is also needed. Be explicit about the scope reviewed and any limitations.
A useful handover ends with shared understanding and testable behaviour. If your project needs that level of clarity, explore Figma UI/UX design or contact Ali Dev Solutions to plan a design and development workflow around your visitors' most important tasks.