Portfolio Accessibility: A Practical WCAG 2.2 Review

What This Review Can—and Cannot—Prove

WCAG is organized around testable success criteria, but accessibility is also about whether people can complete real tasks. For a portfolio, those tasks include identifying your role, opening a project, understanding a case study, playing media, downloading a resume, and contacting you.

Keyboard and Focus

• Start at the address bar and use Tab, Shift+Tab, Enter, Space, arrow keys, and Escape as appropriate.
• Confirm every control is reachable, operable, and visited in a logical order.
• Keep a visible focus indicator; do not remove the browser outline without a strong replacement.
• Make sure sticky headers, cookie banners, and dialogs do not hide the focused item.
• When a modal opens, move focus into it, contain focus while open, close with Escape when appropriate, and return focus to the trigger.
• Do not put essential information or actions behind hover alone.

WCAG 2.2 adds Level AA requirements that keyboard focus not be entirely hidden by author-created content. Its Level AAA Focus Appearance criterion defines a stronger size and contrast target for the indicator. Even when AAA is not your conformance target, a generous, high-contrast focus style is good interface design.

Contrast, Type, and Reflow

Structure and Clear Interaction

• Use one descriptive page title and one clear H1. Nest H2 and H3 headings by meaning, not visual size.
• Use semantic elements. Real links, buttons, lists, form labels, landmarks, and tables carry behavior and meaning that styled divs do not.
• Name links by destination. “Read the payment-flow case study” is more useful than repeated “learn more.”
• Keep navigation and help consistent. Repeated controls should stay in predictable locations and use the same labels.
• Write actionable errors. Identify the field, describe the problem, and tell the person how to correct it.
• Size and separate targets. WCAG 2.2 AA sets a 24 by 24 CSS-pixel target minimum with exceptions; larger controls can improve comfort.

Images and Case-Study Graphics

For implementation details, use the portfolio image optimization guide.

Media and Motion

• Provide accurate captions for prerecorded video with meaningful audio; provide transcripts or audio description when the content requires them.
• Make player controls keyboard accessible and labeled.
• Avoid autoplay with sound. Give people a way to pause, stop, or hide moving content that starts automatically and continues.
• Respect the operating system's reduced-motion preference and remove nonessential motion in that mode.
• Do not use flashes that could trigger seizures; review WCAG's thresholds if flashing content is unavoidable.
• Communicate the same meaning without requiring a person to perceive motion, color, sound, or spatial position alone.

A Useful Testing Routine

1. 1. Automated pass: run axe, WAVE, or Lighthouse to catch detectable markup, name, and contrast problems.
2. 2. Keyboard pass: complete the portfolio's main tasks without a pointer.
3. 3. Visual adaptation pass: test 200% zoom, narrow reflow, increased text spacing, high contrast, and reduced motion.
4. 4. Screen-reader pass: review page title, landmarks, headings, links, image alternatives, forms, and dynamic updates with VoiceOver or NVDA.
5. 5. Content pass: verify captions, transcripts, instructions, error messages, and reading order.
6. 6. Human pass: when possible, include disabled people in research and compensate them for their expertise.
7. 7. Regression pass: repeat the critical checks after content, template, or platform changes.

Standards and Tools

• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 — the normative standard behind the criteria in this guide.
• W3C: How to Meet WCAG 2.2 Quick Reference — filterable criteria and techniques.
• W3C: Alt Decision Tree — choosing an appropriate text alternative.
• WAVE, axe DevTools, and Chrome Lighthouse — automated checks that support, but do not replace, manual review.
• NVDA and VoiceOver User Guide — screen-reader resources.