We looked at somewhere around a hundred UX portfolios over the last several hiring rounds, and most of them treated accessibility as a single bullet point: "ensured WCAG compliance." Tucked between "conducted user interviews" and "iterated on wireframes," it read like a box someone checked at the end of a project, not a decision that shaped the work.
The candidates we actually hired never wrote that sentence. They showed the ugly part instead: the specific thing that failed, the criterion it violated, and the decision they made to fix it. That difference, between claiming compliance and demonstrating judgment, was the single clearest signal in every stack of portfolios we reviewed.
The Stat: WCAG's own structure names 4 principles - Perceivable, Operable, Understandable, and Robust - and organizes every testable success criterion underneath them. (Source: W3C)
The bullet point that tells us nothing
"Ensured WCAG compliance" is the design-portfolio equivalent of "responsible for synergy." It sounds correct. It commits to nothing. When we asked candidates in interviews what that line actually meant, most couldn't name a single criterion they'd tested against. A few admitted a developer had handled "the accessibility part" separately, after the design was final, and they'd simply signed off on it without knowing what changed.
That's the pattern we kept seeing: accessibility treated as a QA step bolted onto the end of a project, rather than a constraint that shaped decisions along the way. It's not that these candidates didn't care. It's that nothing in their process, or their portfolio, showed where the caring happened.
We noticed the same gap show up in interviews, too. Ask someone to walk through a decision they made because of an accessibility constraint, and the vague-bullet-point candidates would pause, then describe something a teammate had told them to change. The candidates we hired didn't pause. They had a specific memory attached: a specific screen, a specific failure, a specific reason they chose one fix over another. That kind of recall doesn't come from reading a checklist once before a deadline. It comes from actually sitting with the problem.
It's worth saying plainly: none of this is about gatekeeping the field with jargon. Plenty of strong designers are new to accessibility and haven't built up a vocabulary yet. What separated candidates wasn't years of experience, it was whether they'd taken thirty minutes at some point to understand why a rule exists, instead of memorizing that it exists.
What the hired candidates did instead
The portfolios that stood out shared a specific structure, almost every time, even though the candidates had never spoken to each other:
They named the failure precisely. Instead of "the modal wasn't accessible," they wrote things like "the modal trapped focus incorrectly and didn't return it to the triggering button on close, which violates the criteria under Operable." They weren't reciting checklist language for show. They understood the four principles well enough to place their own bug inside one of them.
They showed the before and after. A screenshot or short clip of the broken interaction, next to the fixed one, with a caption explaining the change. This took maybe ten extra minutes to assemble. It did more to convince us of real competence than three paragraphs of process narrative.
They connected it to a person, not a policy. "This fix means a keyboard-only user can actually close this dialog and get back to where they were" reads completely differently than "this ensures compliance." One is about a rule. The other is about someone's Tuesday afternoon trying to finish a task.
They referenced structure, not vibes. A few candidates mentioned they were studying for or held a credential from IAAP, the International Association of Accessibility Professionals. IAAP offers named credentials: CPACC as the foundational one, WAS for the more technical track, and CPWA for both combined. We didn't require certification to get hired. But candidates who mentioned working toward one showed a deliberate, structured interest in the field rather than a single project mention. It read as "I've decided this matters to my career," not "I did this once because a client asked."
If you want the primer we point junior designers to on this exact structure, the W3C's own WCAG POUR overview is the clearest starting point, and it costs nothing to read closely. Reading it once, slowly, does more for a portfolio than any amount of polishing the visual design of the case study itself. You start to notice which of your own past projects had a Perceivable problem versus an Operable one, and that vocabulary is exactly what lets you write the specific version of the bullet point instead of the vague one.
Why "specific" beats "impressive" almost every time
We want to be honest about something: none of the case studies that got someone hired were flashy. They weren't full accessibility audits with a dozen findings and a polished report. Most were a single, well-explained fix inside a larger project that was mostly about something else entirely, a checkout flow redesign, a dashboard rebuild, a marketing site refresh.
That surprised some candidates when we told them afterward. Several assumed they needed a dedicated "accessibility project" to compete, so they either skipped the topic entirely because they didn't have one, or they padded a minor detail into an oversized section that felt disconnected from the rest of their narrative. Neither approach worked as well as a small, well-placed example inside an otherwise normal project.
The lesson there is simple: you almost certainly already have the material. Most working designers have touched at least one accessibility issue in the last year, a color contrast fix, a form label that got added late, a focus state that got debated in a design review. The candidates who stood out weren't the ones with the most dramatic story. They were the ones who slowed down enough to explain an ordinary one clearly.
A side-by-side of the two approaches
| What most portfolios showed | What hired candidates showed |
|---|---|
| "Ensured WCAG compliance" (one line, no detail) | Named the specific criterion and principle it fell under |
| Final screenshot only | Before-and-after comparison with a caption |
| No mention of who benefits | A sentence connecting the fix to a real task a real person needed to complete |
| Accessibility as an afterthought bullet | Accessibility as a decision point in the actual design narrative |
| No credential or study mentioned | Reference to CPACC, WAS, or CPWA as an active or planned credential |
The checklist we'd hand a candidate before their next portfolio review
If you're rebuilding a case study and want it to hold up under this kind of scrutiny, work through this before you submit anything:
- Pick one accessibility fix from a real project, even a small one
- Name the specific WCAG principle (Perceivable, Operable, Understandable, or Robust) it relates to
- Include a visual or clip of the broken state, not just the fixed one
- Write one sentence describing the actual person and task affected, not just "improves accessibility"
- Cut any line that just says "ensured compliance" without evidence behind it
- Mention if you're studying toward or hold a recognized credential
We also wrote a longer piece on the one skill we saw in every promoted designer, which overlaps with a lot of what separated our hires from the rest of the stack. And if you're rebuilding your resume alongside your portfolio, we've covered how to actually put accessibility on your resume in detail, including which phrasing tends to get skimmed past versus which gets a second look.
Where to start if you're rebuilding your case study this week
None of this requires a redesign of your whole portfolio. It requires picking one project, finding one real fix, and writing three or four honest sentences about what broke, why, and who it affected. That's a smaller task than it sounds, and it's the exact thing that separated the candidates we hired from the other ninety-something we didn't.
Give yourself an hour, not a weekend. Open one old project file, find the messiest accessibility decision you remember making, and write it down exactly as it happened, including the part where you got it wrong the first time. That honesty is more persuasive than a clean narrative where everything went right on the first try, because every hiring manager who has shipped real software knows that's not how it actually goes.
If you want a structured way to check your own reasoning against real success criteria before you write it up, you can use our free tools to audit your own portfolio case study, no signup pressure, just a way to see if your fix actually lines up with the criterion you think it does. You can also look at IAAP's official certification overview if you're weighing whether a credential is worth the time for your career stage. And if you'd rather just talk it through with a person, our team is reachable directly at experts@wcag.world.