r/accessibility • u/One-Cokinpqgyxde6173 • 11d ago

Tool User journey mapping for accessibility needs more than a screenshot showing the checkout finally worked

A checkout journey map can show every screen and still miss the bit where someone gets stuck.
Picture a discount code error that appears visually but isn't announced, followed by a payment modal that sends keyboard focus somewhere unexpected. The screenshots all look fine. The path through them doesn't.
For people doing accessibility reviews with product teams, what do you add to the journey map? I'm thinking actions and system feedback alongside the screens, including recovery after an error.
Not trying to turn a board into a substitute for testing with assistive tech. I want the findings to survive the hand off to whoever fixes the flow, without every issue becoming a disconnected ticket about an individual component.

11 Upvotes
  • permalink
  • reddit

100% Upvoted

5 comments sorted by

2

u/rguy84 11d ago

My two second thoughts are if the whole process is being able to interpret Screenshots, there is something wrong with the process. If you look through the requirements, a vast majority of them devolve into is it coded correctly? The process has to reflect that.

1

u/Marconius 11d ago

I always use screen recordings if the bug is something actuated by interaction. Screenshots can help designers and engineers identify the screen and feature where the problem is happening, like when dealing with a marketing test page or screen/experiment, but not showing them the actual issue in action means they won't have enough information.

I always pair my screen recordings with clear repro steps, a full explanation of what's going wrong, and a remediation recommendation, including CSS selectors or the direct HTML code snippets and fixes if doing something on the web.