An accessible portfolio is one that every visitor can perceive, operate and understand, including recruiters who navigate by keyboard, use a screen reader, zoom to 200%, or read on a low-brightness phone. The practical baseline is WCAG 2.2 Level AA, verified through both automated scans and manual testing, and documented as part of the case studies themselves. For professionals whose work is evaluated by hiring managers, accessibility functions as a second layer of evidence: the portfolio is itself an artifact that either demonstrates or contradicts the competence it claims.
TL;DR
- Target WCAG 2.2 Level AA: at least 4.5:1 contrast for normal text, 3:1 for large text, full keyboard operability, and descriptive alternative text for functional images.
- Low-contrast text remains the most common failure on the web, found on 83.9% of home pages in the 2026 WebAIM Million, so fixing it first removes the most frequent barrier.
- Automated tools catch only a fraction of defects. Add keyboard-only and screen-reader walkthroughs before publishing.
- Structure each case study as Problem, Strategy, Execution, Result, and attach verifiable artifacts, including your accessibility annotations and audit results.
- Treat the portfolio as a product: version it, test it, and keep the evidence behind every claim retrievable.
Table of Contents
- Why accessibility is now a hiring signal
- The baseline: WCAG 2.2 Level AA in portfolio terms
- Case studies that are accessible and evidentiary
- Showing accessibility work as proof
- Testing: automated first, human always
- Where a static portfolio falls short
- Perspective: the portfolio as a verifiable data surface
- Building it with Alloquy
- A practical checklist
- FAQ
- Sources
Why accessibility is now a hiring signal
Portfolios have moved from optional to expected in many creative and product roles. According to a 2025 portfolio playbook published through ADPList, over 41% of recruiters in marketing, design and product roles require one, and hiring managers increasingly use these assets to validate real-world problem solving rather than self-reported resume claims. The same source reports that candidates with comprehensive profiles have a 71% higher chance of securing an interview.
That shift raises the evaluation standard. A reviewer who opens a portfolio and cannot tab to the main navigation, or who squints at pale gray body text, forms a judgment before reading a single case study. This matters most for designers, front-end engineers and product managers, where the portfolio doubles as a work sample. Practitioners at The Crit note that slow loading and poor keyboard navigation are often read by hiring managers as a failure of frontend competence, which can undercut a candidate who claims technical proficiency.
There is also a plain inclusion argument. Recruiters and hiring managers include people with disabilities, and candidates with disabilities deserve a portfolio they can both build and present. Clear navigation, readable type and sensible structure improve the experience for everyone, a point echoed in Marcelo Paiva’s argument for accessible portfolios, though the standards below come from W3C and WebAIM rather than opinion.
The baseline: WCAG 2.2 Level AA in portfolio terms
WCAG is organized around four principles: perceivable, operable, understandable and robust. For a personal site or a hosted profile, the following criteria carry most of the weight.
| Area | Requirement at Level AA | Typical portfolio failure |
|---|---|---|
| Text contrast | 4.5:1 for normal text, 3:1 for large text | Light gray captions on white; text over hero images |
| Keyboard access | Every function operable without a mouse, no keyboard traps | Carousels, modals and hover-only menus |
| Alternative text | Functional and informative images described | Screenshots with empty or filename alt text |
| Focus visibility | Visible indicator on the focused element | Outline removed by a CSS reset |
| Structure | Logical headings, landmarks, page language | Headings chosen for size, not hierarchy |
| Motion and media | User control over moving content; captions on video | Autoplay background video, uncaptioned walkthroughs |
The contrast thresholds are defined in the W3C’s Understanding Success Criterion 1.4.3, which also specifies that computed ratios must not be rounded: 4.499:1 fails the 4.5:1 threshold. If a brand color sits at 4.4:1, it needs adjusting, not a favorable reading.
Contrast and typography
Start with contrast because it is the most frequent defect. The 2026 WebAIM Million found low-contrast text on 83.9% of the top one million home pages, up from 79.1% the previous year. Designers often fail here because they favor subtle palettes, and dark mode variants frequently go untested.
Practical rules:
- Test every text and background pair, including text on gradient or image backgrounds, with a contrast checker.
- Check hover, focus, disabled and visited states, not only the default.
- Use a body size of at least 16px with generous line height, and confirm the layout holds at 200% zoom without horizontal scrolling.
- Never encode meaning in color alone: pair a red error or a green success with an icon or text label.
Keyboard operability
Put the mouse aside and tab through your portfolio. Every link, button, filter and gallery control must be reachable, in a logical order, with a visible focus ring. Modals must move focus inside when they open, trap it only while open, and return it to the trigger on close. Sliders and carousels deserve special scrutiny: a case study on accessible components illustrates how inaccessible modals and low-contrast calls to action create compliance risk even when the visual design looks polished.
Add a “skip to content” link as the first focusable element. Lucey Kim’s portfolio highlights this as a frequently neglected improvement: without it, keyboard users must tab through the entire navigation on every page load.
Alternative text for work samples
Portfolios are image-heavy, which makes alt text a recurring weakness. Describe what the image communicates in context, not its appearance in the abstract. For a dashboard redesign screenshot, an effective description names the decision the image supports (for example, that the new layout surfaces overdue invoices first), while decorative flourishes receive empty alt attributes so screen readers skip them. Videos need captions and a transcript; the walkthrough of a prototype is evidence only if everyone can access it.
Case studies that are accessible and evidentiary
Accessibility extends past code into content design. The modular case study format recommended in the ADPList playbook, Problem, Strategy, Execution, Result, also happens to suit assistive technology: a predictable sequence of headings lets a screen-reader user jump between sections rather than listen to a linear narrative.
The same source recommends 3 to 5 high-impact case studies, noting that going beyond 6 to 8 forces hiring managers to filter, and suggests a text-to-media ratio of 60 to 80% text for product-focused portfolios. Text-forward pages are inherently easier to make accessible, because text can be resized, reflowed, translated and read aloud.
Within each case study:
- Use one H1 for the project title and H2s for the four blocks. Do not skip heading levels.
- Present metrics as text or a real table, never only as an image of a chart. If a chart is essential, provide the underlying figures beneath it.
- Write link text that makes sense out of context. “View the audit report” works; “click here” does not.
- Keep line length near 60 to 80 characters for readability.
For a deeper template, see our six-block case study structure for designers and the broader portfolio case study guide.
Showing accessibility work as proof
If accessibility is part of your craft, the portfolio should show it, not assert it. Stephanie Smith’s documentation of a component library accessibility uplift at JPMorganChase, covering 49 design system components, shows the pattern: scope, method and outcome are stated concretely, and the work is framed as an organizational requirement rather than a decorative feature.
Evidence worth including:
- Annotated design files. Mark intended ARIA roles, focus order and screen reader announcements in Figma frames. Visual compliance alone rarely covers complex components such as sliders or modals, as the Sima Darvish case study demonstrates with its focus on modal and CTA defects.
- Audit artifacts. A before-and-after summary of issues found, severity, and remediation status.
- Test notes. Which assistive technologies you used, which tasks you tried, what failed.
- Collaboration records. Who implemented the fix, how you handed off specifications, how you verified the result.
Without client work to show, the Q&A threads that rank for this topic converge on one remedy: build a small demonstration site that contrasts inaccessible and accessible patterns, and document your reasoning. Confidentiality is a legitimate constraint; anonymize the client and keep the method visible.
Testing: automated first, human always
Automated scanners such as Lighthouse and axe are fast and worth running on every release. They are not sufficient. The Crit’s WCAG 2.2 review stresses that you must also test the actual tasks visitors need to complete, using keyboard-only navigation and screen-reader walkthroughs.
A compact pre-launch protocol:
- Scan. Run Lighthouse or axe on the home page, one case study and the contact page. Resolve every flagged issue.
- Keyboard pass. Unplug the mouse. Reach the primary navigation, open a case study, play a video, submit the contact form. Confirm focus is always visible.
- Screen-reader pass. Using VoiceOver on macOS and iOS or NVDA on Windows, listen to the home page. Confirm that headings, landmarks and image descriptions convey the same story a sighted reviewer receives.
- Zoom and reflow. Set browser zoom to 200% and test a narrow viewport. Nothing should be cut off or overlap.
- Performance. Aim for a Largest Contentful Paint under 2.5 seconds, the threshold cited in the Crit’s review as a signal reviewers read as engineering competence.
- Task test. Ask two or three people who do not know your work to find your role, your best project and your contact method.
Accessibility and discoverability also overlap, since semantic structure helps both assistive technology and search crawlers. This overview of web accessibility and SEO is a useful reference if you maintain a self-hosted portfolio and want to understand the relationship.
Where a static portfolio falls short
A conventional portfolio asks reviewers to read, infer and trust. Dense case studies are hard to scan for a screen-reader user, and any visitor must locate the one fact they need, such as whether you led the project or what the measured result was. Static PDFs compound the issue: untagged files are frequently inaccessible, and claims inside them cannot be traced to source documents.
An interactive layer can reduce that burden if it is built on evidence. When a recruiter can ask a direct question and receive an answer grounded in the underlying documents, the information is available in a conversational text format that works with many input methods. The condition is that the answers remain tied to verifiable sources rather than generated from unverified claims. That is the design principle behind interactive case studies and behind how we think about portfolio navigation for hiring teams.
Perspective: the portfolio as a verifiable data surface
We approach accessibility as an information-architecture problem before it is a styling problem. A career story is a set of claims, and each claim has supporting artifacts: a metrics export, a specification, a research deck, an audit report. When those artifacts are linked to the claims they support, the reader no longer depends on the visual presentation to establish credibility. They can query it.
That has two consequences for accessible design. First, structure carries meaning: consistent headings, labeled sections and plain-text metrics make a profile legible to people and to machines, including screen readers and the AI assistants recruiters increasingly use. Second, evidence must be as accessible as the narrative. An audit buried in an untagged PDF, or a result shown only in a screenshot of a chart, fails the reader who needs it most.
Our recommendation is to treat accessibility documentation as a first-class case study asset. Record what you tested, what failed and what you changed, then attach the source files. A reviewer who can verify one claim tends to extend credibility to the rest.
— Alloquy Team
Building it with Alloquy
If you would rather spend your effort on evidence than on front-end maintenance, Alloquy lets you link Google Drive documents or add evidence manually, then publishes an interactive public profile with a custom AI assistant that recruiters can question. You can apply customizable themes and branding, which is where the contrast and typography rules above apply, and generate tailored resumes and cover letters traced to your source documents. You can start with the free profile, or review plan details on the pricing page. For visual direction, our guides to UX portfolio examples and portfolio branding show how to keep a distinctive look within accessible limits.
A practical checklist
- Body text and UI components meet 4.5:1 and 3:1 respectively, across all states and themes.
- Focus indicators are visible; a skip link is the first tab stop.
- Headings follow a logical hierarchy; landmarks are present; the page language is set.
- Informative images have specific alt text; decorative images have empty alt.
- Videos have captions and transcripts; no autoplay with sound.
- Case studies follow Problem, Strategy, Execution, Result, with metrics in text.
- Three to five projects are featured, each with retrievable evidence.
- Automated scan, keyboard pass, screen-reader pass and 200% zoom test are complete and noted.
FAQ
What WCAG level should a portfolio meet?
Level AA of WCAG 2.2 is the practical baseline for professional sites, and it is the level most commonly referenced in audits and procurement requirements. It includes the 4.5:1 and 3:1 contrast ratios, keyboard operability and text alternatives. Meeting AA also positions you well if a reviewer tests your site.
Is an automated accessibility checker enough?
No. Tools such as Lighthouse and axe are valuable for a fast first pass, but practitioners consistently recommend adding manual keyboard and screen-reader testing. Automated scans cannot judge whether alt text is meaningful or whether a modal behaves sensibly for a screen-reader user.
How do I show accessibility skills without client work?
Build a small demonstration project that pairs inaccessible and accessible versions of common patterns, such as a form, a modal and a navigation menu. Document the issues, the WCAG criteria involved and your fixes. Annotated design files and audit-style write-ups count as evidence.
Do accessibility and portfolio speed really matter to recruiters?
They can. Slow loading and broken keyboard navigation are often interpreted by hiring managers as signs of weak engineering practice, particularly for candidates who claim front-end or design-systems expertise. Keeping Largest Contentful Paint under 2.5 seconds is a sensible target.
Sources
- The Crit: Portfolio Accessibility, A Practical WCAG 2.2 Review
- ADPList: The best portfolio playbook that’s worked 99% of the time
- W3C: Understanding Success Criterion 1.4.3, Contrast (Minimum)
- WebAIM: The WebAIM Million, 2026 report
- Stephanie Smith: JPMC components accessibility uplift
- Sima Darvish: Accessibility case study
- Lucey Kim: Accessibility audit work
- Marcelo Paiva: Should your portfolio be accessible?