Practiced here, too.
I run an accessibility program for a living, so this portfolio holds itself to the same standard it describes: WCAG 2.1 AA as the working target, verified as part of every change.
What this site does
Contrast is enforced, not eyeballed
Every accent theme on this site — including the ones it rolls on each visit — passes through the same contrast engine I built for work: light and dark are derived independently, and every text-on-surface pairing is clamped until it clears WCAG's 4.5:1. The engine is covered by tests, so an inaccessible combination can't ship.
Keyboard-complete
Everything interactive — navigation menus, the theme controls, the case-study demos, the card carousel, the password gate — works without a mouse. A skip link jumps straight to content, and focus is always visible.
Motion is a preference
The site honors your operating system's reduced-motion setting, and the settings menu (the sliders icon in the nav) can force it regardless. With motion reduced, animations resolve instantly to their completed states rather than disappearing.
High contrast and larger text
The same settings menu offers a high-contrast mode (stronger text and hairlines) and a larger-text mode (scales all type up ~12%). Both persist for your next visit.
Semantics underneath
Landmarks, one h1 per page, labelled controls, alt text on meaningful images, and titled iframes. The interactive case-study demos expose their state to assistive technology rather than being decorative videos.
Known limits
The embedded design-library demo runs as its own application inside a frame — it’s the real shipped library, audited in its own right, but its internals aren’t re-audited by this site. And the case studies sit behind a shared password; if you use assistive technology and anything about that flow gets in your way, I want to know.
Found a barrier?
Tell me and I’ll fix it — lukegram@icloud.com.