An automated scan can make you look quick. A transparent record of where it stopped—and what a human did next—can make you look trustworthy.
Accessibility is not a score. It is a real person completing a real task with the tools they use.
AI is making it easier to generate interfaces, write code, and run accessibility checks. That speed is useful. It is also making one kind of portfolio painfully common: a polished screenshot, a big score, a list of fixes, and no evidence that anyone could actually use the experience.
If you are trying to build credibility in accessibility, AI product work, UX, front-end engineering, or quality assurance, your opportunity is not to claim that a model made something “accessible.” It is to show that you know what an automated tool can suggest, what it cannot know, and how you made a responsible decision afterward.
This is a personal-brand strategy disguised as a project strategy. The most memorable proof is not a glossy demo. It is a small, honest case study that lets a reviewer see your standards.
“I used AI to accelerate the first pass. I did not use it as a substitute for context, consent, or human testing.”
Why an AI accessibility portfolio needs a different standard
Accessibility work is easy to overstate. A scanner may find missing labels, contrast problems, and structural issues. It cannot reliably decide whether a generated image description serves the purpose of the page, whether a conversation flow is understandable, or whether a person using a screen reader can complete a task without help. The W3C explicitly recommends combining conformance work with evaluation involving people, because user evaluation finds issues conformance checks alone may miss.
That distinction matters even more when AI is involved. An AI system can produce output that looks plausible while missing the intent that makes an experience usable. In one recent accessibility discussion, practitioners pointed out that automatic image descriptions often miss why an image is on the page. That is not a small technical detail. It is the difference between a page that merely has alt text and a page that communicates.
Your portfolio should make that judgment visible. Not by pretending to be a compliance authority, and not by borrowing someone else’s story. By building a narrow, permissioned or synthetic exercise and documenting your reasoning.
Choose a project small enough to test honestly
Do not start with “I audited an entire platform.” Start with one meaningful user journey. You might create a small demo for booking an appointment, joining a community event, submitting a support request, or comparing a public-service benefit. The subject is less important than the boundary.
Write the boundary before you open an AI tool:
Audience: Who is the journey for? Avoid defining people only by a diagnosis. Define the task and the access needs that could affect it.
Journey: What single start-to-finish task will you test? For example, “find an event and reserve a place without using a mouse.”
Environment: Which browser, operating system, device, and assistive technology are in scope?
Evidence label: Is this a fictional prototype, a public site tested with permission, or a volunteer usability session? Say so plainly.
Out-of-scope list: What did you not evaluate? This is where credibility begins.
W3C’s evaluation methodology similarly begins with scope and representative sampling. Borrow that discipline without claiming certification. A reviewer will learn more from a carefully bounded project than from a heroic but vague promise.
A useful rule: If you cannot explain the task, the test environment, and the limits in three sentences, the project is too big for a credible portfolio case study.
Use AI as a hypothesis engine, not an approval stamp
AI can make the project better when you give it a narrow job. Ask it to generate a first-pass issue inventory, translate a WCAG criterion into a plain-language test question, or propose edge cases you might miss. Then treat every result as a hypothesis that needs verification.
Here is a prompt structure worth adapting:
“Given this task flow and this component markup, list possible keyboard, focus-order, label, error-message, and content-context risks. For each risk, state what evidence a human tester would need before calling it a defect. Do not claim conformance.”
That last sentence matters. It prevents the tool from performing confidence when it should be asking for evidence. If an AI suggests a fix, record the suggestion separately from your decision. “The model proposed X; I rejected it because Y” is strong proof of judgment.
Build a two-column decision record
In your working notes, keep two headings: machine signal and human verification. Under the first, capture the scanner finding, AI hypothesis, or code pattern. Under the second, capture what you actually checked: tab order, visible focus, a screen-reader announcement, a task result, or feedback from an informed participant.
This protects you from the biggest AI personal-brand trap: confusing an articulate explanation with evidence. It also gives you material for thoughtful posts, interviews, and future case studies.
Make the record inspectable. Give every finding a stable identifier, keep the before-and-after state in a private work folder, and write one sentence explaining the decision threshold. For example: “I changed this label only after the keyboard path and announcement were both understandable in the named test environment.” That language is more valuable than a long tool export because it tells the reader exactly what you observed and what you did not infer. If you used a model to summarize notes, retain the original notes and review the summary for lost qualifiers before publishing.
This is also how you avoid accidentally laundering sensitive information through an AI workflow. Redact names, account data, internal URLs, and unreleased product details before asking a tool for help. If a portfolio example is synthetic, say so. If it is permissioned, say what permission covers. A thoughtful boundary makes the work safer to share and easier to trust.
A credible workflow distinguishes a machine’s suggestion from a verified observation.
Run the test that makes your judgment visible
A high-quality accessibility portfolio does not need a giant lab. It needs a repeatable test loop. Begin with automated checks, then use the interface the way a person would: keyboard-only, with relevant assistive technology, and with time to notice confusing language or behavior.
If you invite participants, do it with care. Explain the purpose, what will be recorded, how notes will be anonymized, and that they may stop at any time. Do not use a participant’s diagnosis or lived experience as a portfolio prop. Ask only for the feedback required to improve the task.
You can still build a meaningful case study without participants. State that you performed a limited technical and interaction review, not user research. W3C’s guidance is helpful here: user evaluation has a range, from an informal check of a specific issue to formal usability testing. Describe the level you actually conducted.
Document four moments, not every click
The intended task: “A keyboard user should be able to find the event, select a date, and receive a confirmation.”
The failure: Describe the observed barrier in plain language and relate it to the component or content decision.
The fix and retest: Show what changed, how you retested it, and what improved.
The remaining limit: Name a browser, device, task, or user context you did not test.
This sequence turns a portfolio page into a decision trail. It shows that you do not equate “no errors found” with “works for everyone.”
Publish the case study without overstating it
Use a simple, skimmable page. Put the boundary and takeaway near the top. Recruiters, collaborators, and potential clients should not need to search for the important caveat at the bottom.
A strong page includes:
a one-sentence scope statement;
the user task and the test environment;
a short “AI used for” and “AI not used for” disclosure;
two or three representative findings, with fix-and-retest evidence;
a consent and anonymization note when other people contributed;
an explicit limitations section; and
links to authoritative references such as W3C guidance—not screenshots of a tool dashboard alone.
Avoid phrases such as “fully accessible,” “WCAG compliant,” or “AI verified” unless you have the authority, scope, and evidence to support them. The U.S. Department of Justice notes that WCAG and Section 508 offer useful technical guidance; that is a reason to be specific about the standard and evaluation, not a license to make blanket claims.
Turn one case study into a trust-building content system
The case study is the source asset. From it, publish a short LinkedIn reflection about a decision you changed after a manual test. Write a Substack post about one question your scanner could not answer. Record a brief demo explaining why a focus order is part of the product, not an implementation footnote.
Keep the same evidence boundary in each format. Do not turn a narrow test into a broad claim merely because social posts reward certainty. Your consistency becomes part of your digital identity: you are someone who is fast enough to use modern AI and careful enough to know when it needs supervision.
The outcome worth showing is not a perfect score; it is a more accountable way of deciding.
Your credibility lives in the limits you name
AI can help you notice more, prototype faster, and prepare better questions. It cannot grant you the context of a user, the authority to promise compliance, or the responsibility to stand behind a result. Those remain human work.
Make that the story of your AI accessibility portfolio. Show the task. Show the evidence. Show what changed. Show what is still unknown. In a feed full of polished claims, that level of care is memorable.
Frequently asked questions
What should an AI accessibility portfolio include?
Include a defined user task, scope, test environment, limited AI role, manual verification, representative findings, retest evidence, and a limitations section. The goal is to show judgment, not to display a score.
Can I create an accessibility case study without client work?
Yes. Use a fictional prototype, open-source project, or a public experience only when your use is ethical and clearly labelled. Do not imply authorization, access to private data, or a production relationship you did not have.
Can AI test website accessibility on its own?
AI and automated tools can help identify issues and generate hypotheses. They cannot replace task-based manual checking or user evaluation. State what was tested, how it was tested, and what remains outside scope.
How do I show screen-reader testing in a portfolio?
Describe the task, assistive technology, browser, and observed behavior. Use anonymized notes rather than dramatic screenshots. If you are not an experienced screen-reader user, do not overstate a short self-test as representative user research.
Should I claim WCAG compliance in a portfolio project?
Only if your assessment scope, evidence, and authority truly support that claim. Most career projects are better described as a limited evaluation against selected WCAG success criteria with clearly stated limitations.
How should I disclose AI use in an accessibility case study?
Name the narrow role: for example, issue brainstorming, draft test questions, or code explanation. Then name the human check that governed the final decision. Do not claim that AI validated accessibility.