Start with the task, not an expertise label

Accessibility work can appear in design, engineering, content, support, events, and operations. A resume does not need to call you an accessibility expert to show useful experience. Identify one task you personally handled: improving form labels, reviewing keyboard navigation, writing image descriptions, arranging an accessible event format, or documenting a barrier for the responsible team.

Choose an example that relates to the job posting. A content role may value a clear editing and review process; a support role may value how you recognized a barrier and routed it for resolution. If you only attended training or observed a review, describe that accurately instead of presenting it as implementation work.

  • What barrier or user task was the work about?
  • Which part did you do yourself, and who owned the final decision?
  • What artifact, change, test record, or handoff can you point to?

Name your action and the scope of the change

Replace broad claims such as “Made the product accessible” with a bounded action. You might have revised labels on a particular form, checked a small group of pages with a keyboard, or logged issues found in a document review. Use verbs that match your work: wrote, tested, documented, revised, coordinated, or verified. A team project is fine, but distinguish your contribution from what others designed, approved, or shipped.

State the object of the work, not just the tool you used. “Tested the account setup flow using keyboard-only navigation and documented focus-order problems for the frontend team” is more informative than “Used accessibility tools.” Only name a test method or tool if you actually used it and can explain what it did not cover.

Connect the work to evidence without inventing impact

The result might be a revised file, an issue list, a published content change, or a fix verified in a later review. If you have an approved metric, use it with its real scope and timeframe. If not, an honest deliverable is stronger than a made-up improvement percentage or a claim that all users benefited.

Try the frame: [action] + [specific surface or process] + [barrier or review method] + [deliverable or verified next step]. For example, if true: “Revised image descriptions for a set of help articles, then checked them against the article context before publication.” Another example: “Logged keyboard focus issues in the signup flow with reproduction steps for the engineering review.” Neither implies that you alone fixed every issue.

  • Vague: Improved accessibility across our digital experience.
  • Specific, if true: Updated headings and link text in onboarding guides, then reviewed the published pages for reading order.
  • If a fix was only proposed: Documented the issue and recommended a change; do not say you shipped it.

Be precise about standards and testing

A checklist, an automated scan, and a review with people using assistive technology are different kinds of evidence. Do not say a product was compliant because you ran one check. If you worked against a named standard, identify the exact standard only when you know which version and requirements were in scope. Avoid certification or legal compliance language unless your role and evidence justify it.

Describe collaboration when it matters: perhaps a designer updated a pattern after your report, or a specialist reviewed your draft. Credit the team accurately and avoid sharing private user information, internal audit findings, or confidential screenshots. A concise bullet can show judgment without overstating the extent of the work.

Place the example where a reader can verify the context

Put the bullet beneath the role or project where the task happened. For a student or volunteer project, label the setting clearly and specify the actual deliverable. A skills entry such as accessibility testing can help when relevant, but pair it with an experience bullet that shows what you tested and how you reported the findings.

If you have several examples, choose the one nearest the target role rather than listing every small check. In a design application, the decision and revision might be central; in an operations application, the request intake and handoff may matter more. Keep the scope readable for someone who does not know your organization.

Review the claim before exporting your resume

Read each verb against the record of what happened. Did you find, document, recommend, implement, or verify the change? Was the review limited to one page, a workflow, or an entire product? If the answer is narrow, make the bullet narrow. Be ready to discuss the barrier, your method, the people involved, and any unresolved issues without disclosing sensitive details.

Finally, compare the bullet with the job description for relevance and open the exported PDF to check line breaks and legibility. CreateResume can help you keep a structured draft and preview PDF-ready output; the accuracy of the accessibility claim still depends on your own review.

  • Does the bullet identify your own action and its scope?
  • Can you substantiate the stated result or handoff?
  • Have you avoided broad compliance or certification claims?