Clear Candidate Instructions: A Cognitive Accessibility Guide

Clear candidate instructions explain what to do, what to prepare, how much effort to expect, when work is due, and how to know it arrived. For cognitive accessibility, put each action where the candidate needs it. Separate the hiring task from the effort of finding and interpreting its instructions.

A candidate can understand a technical problem and still miss a deadline hidden beneath a calendar link. Another can submit the right work but remain unsure whether the upload finished. These are different problems, and your hiring process should make them easy to distinguish.

A current Hacker News discussion about i-have-adhd, a skill that makes coding assistants put the next action first, raises a useful writing question: how much explanation hides the thing someone needs to do? Its rules concern assistant output, not recruiting or clinical evidence. The hiring advice below applies W3C guidance to practical message examples.

What makes candidate instructions cognitively accessible?

Instructions should let candidates follow the process without having to reconstruct it from scattered clues. Keep actions explicit, information close to the relevant action, and progress understandable after someone leaves and returns.

W3C’s guidance on separating instructions gives a directly relevant example: applying for programming or design work. It separates preparing a résumé, selecting work samples, and sending them to the right destination. It also recommends including steps that the writer considers obvious.

That last point matters in hiring. Your team knows that a calendar booking confirms attendance. A candidate may wonder whether they also need to reply to the recruiter. Your engineers know where to submit repository work. A first-time applicant cannot infer your convention from familiarity with GitHub alone.

Audit the things your process makes people remember: an instruction from the first email, a deadline from another page, a naming rule in a document, and a final action in the portal. Put the relevant information together before asking someone to act.

This is accessibility guidance, not a diagnosis-based writing formula. People with the same diagnosis can have different needs and preferences. Test whether people can use your instructions; do not decide that every candidate with ADHD needs a particular layout or communication style.

Also distinguish the source’s status. W3C explains that this is supplemental guidance, beyond what WCAG requires for conformance. Applying these patterns does not certify your hiring flow. It gives you concrete questions to ask about barriers that a technical checklist may miss.

How do you write an interview invitation someone can act on?

Start with the action the candidate must take, then give the information needed to take it. An invitation to choose a time and a confirmation of a booked interview need different opening sentences.

Consider this illustrative draft:

We’d love to continue the conversation. Please review the attached information and use the link to find a time next week. Have a project ready to discuss and let us know if anything comes up. Looking forward to meeting you!

The tone is friendly. The task is incomplete. Which attachment matters? Must the candidate prepare a presentation? Does booking count as confirmation? Who handles questions?

For example, you could write:

Next action: choose an interview time using the booking link.

Format: A 45-minute video conversation with our engineering lead about a project you worked on.

Preparation: Choose one project you can discuss. Be ready to explain your contribution and one tradeoff. You do not need slides or new code, and you should not share confidential material.

After booking: Check the confirmation for the date, time zone, and meeting link. Your booking confirms attendance; no separate reply is needed.

Questions or changes: Reply to this email. Maya from the hiring team will respond.

The duration, person, and workflow above are examples, not a universal interview format or a promise about any product. Substitute facts your team can honor. If replies are not monitored, provide the monitored route instead.

Keep background reading separate from required preparation. Label a company introduction “optional” if it is optional. If candidates must read a document to participate, name it and explain its purpose. Candidates should not have to open every link to guess which material the interview will cover.

Before sending, open the invitation on a phone. Can someone identify the action without scrolling through your company story? Then check the confirmation separately. It should describe the booked event rather than repeat a request to choose a time.

What should a take-home assignment brief contain?

A useful brief defines the work, the submission, and the boundaries of preparation. Leave room for professional judgment while explaining how your process works.

W3C’s task-expectation guidance recommends giving people an effort estimate, required resources, and an overview before they begin. It also distinguishes work in progress from completed work. Apply that principle to the task summary as well as the detailed brief.

A weak illustrative brief says:

Review the service, fix what matters, and send us your solution by Friday. We value quality and pragmatism.

“Quality” does not tell someone what artifact to produce. “Friday” leaves the cutoff unresolved. “Fix what matters” might be deliberate assessment ambiguity, but the candidate needs to know whether deciding scope is part of the exercise.

Here is an illustrative replacement. Every number and process choice is an example to adapt:

You still need to supply the actual deadline, allowed tools, and submission behavior. Do not paste this example into a process that works differently.

Ask someone outside the hiring team to read the brief. Ask them to describe the requested artifact and where it goes. If they correctly understand the technical task but cannot answer those questions, revise the instructions before changing the assessment.

How do you separate effort, deadlines, and timer starts?

Expected effort tells candidates how much work to plan; a deadline tells them when the submission closes. The event that starts a timer is a third fact. State all three when your process uses them.

“Three hours” could mean an effort estimate, a continuous timed session, or the period during which the upload stays open. Each meaning calls for a different plan. Likewise, “five days” is incomplete until the candidate knows whether the period begins with the invitation, repository access, or a Start task action.

For an illustrative process, you might write:

Expected effort: About three hours of work.

Submission window: Five days from selecting Start task. Receiving this invitation does not start that window.

Before starting: The task page shows the preparation requirements. After starting, it shows your exact deadline and time zone.

If the timing does not work: Contact the hiring team before starting to discuss the schedule.

Those are editorial example values and policies, not default settings. Check the actual system behavior before using the wording. If opening a link starts a timer, make that consequence visible before the person opens it.

Whenever you display an exact cutoff, include the date, time, and time zone. Distinguish the preferred deadline from any later hard cutoff. If late uploads remain possible, explain how you handle them before a candidate needs to find out.

Extensions also need precise wording. “Ask for more time” and “extend once using this button” are different promises. Name the available action, any cutoff for using it, and what confirmation the candidate should expect.

The candidate experience documentation is a useful starting point for checking what your configured flow actually shows. Follow the whole journey yourself; do not derive candidate-facing deadlines from an internal field label alone.

What should candidates see after they submit?

A confirmation should answer whether the work arrived and whether the candidate needs to act again. Completing the task changes what the candidate needs to know.

W3C’s form-notification tutorial recommends feedback that makes submission success or failure clear. The receipt below applies that principle to an assignment.

A weak illustrative receipt reads:

Thanks! We’ll be in touch.

That is polite but leaves practical questions unanswered. Did both files arrive? Was the submission final? Can the person close the page? Is another action waiting in email?

An illustrative replacement could read:

Your assignment was submitted.

Received: repair.patch and approach.pdf.

Submission status: Final. You cannot replace these files through this submission page.

Next: The engineering team will review your work. You have no further task to complete now.

Questions: Reply to your assignment email if you believe the wrong files were submitted.

Add a receipt time and reference when the system provides them. The filenames and finality policy above are examples. A workflow that allows revisions should explain how revisions work instead.

Keep any promise about review timing separate from the submission receipt. A receipt confirms that a file arrived. “We will decide by Tuesday” is a commitment requiring an owner and capacity. If you cannot give that commitment, say what happens next without inventing a deadline to make the message sound reassuring.

Check what happens when the candidate returns, too. A candidate may close the confirmation, reopen the portal later, and need to check whether the submission is complete. The page should not look like a fresh unfinished assignment.

For an error, use the same discipline: identify what arrived, what did not, and the action still needed. Do not show a success message for one file in a way that implies the whole task is complete. Treating receipt, completion, and review as separate states helps your team write each message accurately.

Does clearer guidance make the assessment easier?

You can explain how to participate while preserving the difficulty of the work you intend to assess. Decide which judgments belong to the exercise, then make the surrounding process explicit.

If prioritization is the skill, leave room for candidates to choose a problem. Tell them that choosing and defending a priority is part of the task. You can disclose the expected artifact, available time, allowed tools, and submission route without telling them which problem to select.

If you are evaluating debugging, an undocumented upload rule adds a different challenge. Decide whether that challenge belongs in the assessment. Check for hidden expectations about presentation polish, response speed, or working late. Your team should know whether it intends to judge those things.

W3C’s short-path guidance recommends keeping required workflows to necessary steps and separating optional activities. In hiring, apply that to participation: do not require a candidate to navigate optional company material before reaching the scheduling action. It is not a rule about how many interviews a role needs.

Clear writing also does not mean the shortest possible message. W3C’s succinct-text guidance favors focused paragraphs and descriptive headings, while acknowledging that a longer sentence can sometimes be clearer. Preserve any condition that changes what a candidate must do.

Give reviewers the same version of the instructions candidates received. If one person asks a useful logistical question, decide whether the answer belongs in the brief for everyone. Track substantive changes so reviewers do not judge earlier submissions against requirements added later.

How do you review candidate communications before sending?

Review the action and the state behind every message, then test whether someone can explain the next step. Proofreading alone cannot catch a polished instruction that describes the wrong workflow.

Walk through an invitation, an active task, a submission, and a return visit. At each point, ask a colleague unfamiliar with the configuration to answer:

• What must I do now?
• What do I need before I begin?
• What is required, and what is optional?
• How much work should I plan for?
• When is it due, and what starts that deadline?
• How will I know I am finished?
• Who can help if I cannot continue?

Let them use the material a candidate receives. Do not explain the missing parts aloud. Their questions show where the instructions rely on knowledge your team has not written down.

Then inspect a change: a rescheduled interview, a revised deadline, or a replaced attachment. Identify the current instructions and make clear which details in older messages have changed. A reminder should not silently reintroduce an outdated cutoff.

Keep this content review alongside your keyboard-accessibility checks. Understanding an action and operating its control are separate requirements. Neither review replaces the other.

Record the confusing instruction, the observed question, the edit, and the person responsible for retesting it. Candidate feedback can guide further revisions, but one person’s preference should not become a claim about an entire group.

How can you apply clear candidate instructions in Kit?

Start by checking the words and settings your candidates will actually encounter. In Kit, stage descriptions, private briefs, task deadlines, and interview confirmations provide distinct places for that work.

Use the Candidate Description for public expectations. It appears on the public job timeline, template gallery, and stage notification email. Put private Portfolio Upload task instructions and their links in the Brief, which eligible candidates read after starting the task. The distinction is documented under stage description versus brief.

For those tasks, estimated effort can be shown before starting, while days to complete run from the Start task action. Check configured grace periods and extension options before promising how additional time works. These fields help you write accurate instructions. Your team still needs to check the promises it makes.

Interview confirmation emails include the date, start and end time, time zone, and duration. They include the meeting link when available or a message explaining its absence. The candidate portal also distinguishes states such as awaiting review, a confirmed interview, and a completed stage.

Use those existing states as a starting point for your audit. The invitation, brief, and receipt examples in this article are recommended writing patterns, not a claim that Kit ships each sentence, contact route, or policy. Review your configuration and candidate journey before adopting them.