Images are reused AI-generated editorial illustrations, not documentary photographs or verified product screenshots.
A Figma dropdown menu can demonstrate an interaction flow, but a clickable prototype is not evidence of production accessibility. Define the intended control and its behavior before drawing the menu. A navigation menu, listbox and ordinary form selection can have different implementation requirements even when they look similar.
Specify purpose and expected states
Describe what opening the control lets a person do, including the initial selection, available choices and closed state. Review labels and empty or disabled cases. Do not choose a dropdown simply because it looks compact; confirm that the control matches the user’s task and can be implemented appropriately.
Prototype the relevant interaction clearly
Use Figma’s supported prototype interactions and, where useful, reviewed component variants. Demonstrate opening, choosing an item, closing and returning to the previous context. Avoid an impressive animation that hides the actual decision path. Record behavior the prototype cannot fully demonstrate instead of presenting a visual state as a complete specification.
Document production accessibility separately
Specify expected keyboard, focus, naming and error behavior for the implemented control, with appropriate specialist or standards review. Test the actual application rather than claiming compliance from a Figma preview. A prototype can help discuss interaction, but it does not establish semantic structure, screen-reader output or every supported input method.
A practical checklist
- Define the control’s task and type.
- List initial, open, selected and exceptional states.
- Prototype relevant selection and dismissal paths.
- Record behavior the prototype cannot prove.
- Test production accessibility separately.
Worked example
Illustrative example: a synthetic service selector demonstrates opening a list and selecting an option. The design notes also specify expected focus and error behavior for development review. The team does not call the result accessible merely because mouse clicks work in the prototype, and it does not substitute animation for a clear selection label.
Common questions
Is every dropdown-looking control the same type? No. Does a working prototype establish semantic HTML? No. Can a prototype still support useful discussion? Yes, when its limits are explicit.
What to do next
Keep an interaction specification with the prototype. Clear intent and honest implementation limits make the design more useful than a visual demo described as a finished accessible control.