A practical accessibility checklist covering semantics, keyboard use, focus, contrast, touch targets, motion, and content.
Use semantic structure
Native landmarks, headings, lists, buttons, links, and form controls give browsers and assistive technology useful structure without requiring custom ARIA everywhere.
Make the horizontal rail optional
The project rail is an enhancement, not the only route to project content. Every project should have a normal link and indexable detail page so keyboard users, search crawlers, and people who do not want drag interaction can still navigate.
Design visible focus
Keyboard focus should be obvious against the dark theme. Focus treatment is part of the visual system, not an afterthought.
Respect reduced motion
Animations should be shortened or removed when the user requests reduced motion. This keeps the interaction model consistent with user preferences.
Check contrast and touch size
Dark interfaces can fail contrast tests while looking attractive. Text, borders, controls, and touch targets need explicit accessibility checks.
- State the problem before the tools.
- Expose the system boundary.
- Use metrics with context and limitations.
- Document one meaningful trade-off.
- Link to adjacent project or topic pages.
What is accessible portfolio WCAG 2.1?
A practical accessibility checklist covering semantics, keyboard use, focus, contrast, touch targets, motion, and content.
Why does it matter?
Native landmarks, headings, lists, buttons, links, and form controls give browsers and assistive technology useful structure without requiring custom ARIA everywhere.