Start with the default path
An async interview has a default path: open the link, read the instructions, test the device, record the answer and submit. Each step can exclude someone. A candidate on a small phone, a candidate with a slow connection or a candidate who uses a keyboard cannot always follow the path the designer imagined.
Walk the flow yourself on the devices and settings a candidate may use. Try a small screen, a keyboard and a slow connection. Write down where the screen gives no clear next action. That list is your first set of fixes.
Put the format in the invitation
Tell the candidate what will happen before they open the link. The questions, the time available, whether there is a practice step, whether retakes are allowed and how the answer is reviewed. If the employer sets a think time before recording, say that too. A candidate who knows the format can prepare instead of discovering the rules under pressure.
Include the support route in the same message. A name, a channel and a response expectation are enough. Do not hide the contact behind a help centre that the candidate has to search.
Give the instructions in plain language
Write short sentences and put the action first. Name the button, the next screen and the result. Avoid jargon about codecs, uploads or review states. If the candidate needs to do something before the interview, say it in the first line, not in a footnote.
Offer the instructions as text and, where possible, as audio. A candidate who cannot read the screen or who uses assistive software should get the same information in a form that works.
Design for time and attention
A countdown can help a candidate plan and it can also create a barrier. Show the time limit before the recording starts. Allow a pause between questions when the employer's settings allow it. If an answer can be re-recorded, say how the retake works and what happens to the earlier attempt.
Do not put several instructions on one screen. Break the flow into steps with one action each. A candidate who has to remember a rule from a previous screen will focus on the rule instead of the answer.
Offer a route for an adjustment
Some candidates need a change in the route, not a change in the bar. Offer a way to ask for extra time, a written version of the questions, a different device or support during the recording. Keep the criteria the same and document the adjustment in the record.
Train the person who answers those requests. A quick yes or no with a clear reason is clearer than a long chain of messages. If the request needs a decision from the hiring manager, say who will decide and when the candidate can expect an answer.
Review the flow after a real interview
Ask a few candidates what happened before the recording started. Where did they hesitate, what did they have to look up, and what did they do when a step failed? Combine those answers with your own device test. Fix the step that caused the pause before you change the content of the interview.
Accessibility is not a separate project at the end of the design. It is a check on every handoff: the invitation, the link, the instructions, the recording and the support route. Make the check part of the launch routine and the next interview starts from a clearer path.