Accessibility gets treated like a compliance task. Something you bolt on at the end, run through a checker, check a box, and call done. In my experience, that approach produces work that technically passes and practically fails — sites and systems that look fine on paper but frustrate real people trying to use them.
I think about accessibility differently. It's not a list of rules to satisfy. It's a set of design decisions that either respect your audience or don't. And the earlier those decisions get made, the better the work becomes — not just for users with disabilities, but for everyone.
Here's how I actually approach it.
The First Step
Start in grayscale.
One of the most useful things a professor ever told me: design everything in grayscale first. Then transition to color.
It sounds counterintuitive — color is one of the most powerful tools in a designer's kit. But stripping it out early forces you to solve problems with structure, contrast, and hierarchy before color enters the picture. If something only works because of a color difference, it doesn't actually work.
This is especially relevant for interactive states. A button that relies solely on a subtle color shift to communicate hover or focus isn't accessible — not because it fails a contrast ratio test, but because a dark-to-dark color transition with nothing else accompanying it is genuinely hard to see. Pair that color change with a shape change, a weight change, a border, an underline — something structural — and suddenly the state is communicated clearly regardless of how someone perceives color.
The grayscale-first approach catches these issues before they're baked in. It's a habit I recommend to every designer I work with.
Contrast
Contrast isn't just a number.
WCAG gives us contrast ratios — 4.5:1 for normal text, 3:1 for large text — and those numbers matter. But contrast is more than a ratio. It's about the relationship between elements: text and background, button and page, active state and inactive state.
Low contrast is one of the most common issues I push back on. It shows up everywhere — light gray body copy on white backgrounds, muted CTAs that disappear into the page, navigation that's invisible against a hero image. It looks minimal and sophisticated in a mockup. It's exhausting to read in real life, especially as you get older. I say that from experience.
I'm not 25 anymore. My eyes work differently than they did ten years ago, and designing with that awareness has made me a better designer — not a more conservative one. There's nothing timid about legible type. There's nothing boring about a button you can actually see.
Typography
Font hierarchy is doing more work than you think.
Most clients think of typography as a style choice. I think of it as navigation.
A well-built type hierarchy tells a reader where to start, where to go next, and when they've arrived somewhere important. It creates scannable structure without requiring the user to read every word. It guides attention the same way a good layout guides the eye — invisibly, intuitively.
On the Vernier campaign websites, a significant portion of the type work started with an art director's established system. My job was to take that vision and expand it — making sure the hierarchy actually functioned across the range of content, viewport sizes, and use cases the campaigns required. There were moments where the original system needed to flex further than it was designed to, and those were the moments that required the most careful advocacy. Accessibility decisions made by committee, within constraints, are harder than the ones you make alone — but they matter just as much.
On PDXWIT, I built the type hierarchy from scratch. That meant making every decision intentionally — size relationships, weight contrast, line height, spacing — and then building the color system alongside it, so the two worked as a unified whole rather than two separate layers bolted together. When you build both at once, accessibility stops being a checklist item and becomes a natural output of the process.
The Laws I Keep Coming Back To
Jakob's Law, Law of Proximity, and Hick's Law.
Jakob's Law states that users spend most of their time on other sites, so they expect your site to work the way those sites do. I reference this constantly — to clients, in presentations, in design reviews. Being unconventional isn't inherently good. Patterns exist because they work. Navigation in the top left, primary CTA above the fold, contact in the footer — these aren't limitations, they're starting points that let users spend their cognitive energy on your content rather than figuring out how your interface works.
The Law of Proximity states that objects near each other are perceived as related. This one sounds obvious until you look at how often it gets violated — form labels floating away from their fields, captions that belong to one image sitting closer to another, related actions scattered across a layout with no visual grouping. Proximity is how you communicate relationship without saying a word. Get it wrong and users have to work harder to understand the structure. Get it right and the layout explains itself.
Hick's Law states that the time it takes to make a decision increases with the number and complexity of choices. This is why I push back on endless scroll, overcrowded navigation, and pages that try to do everything at once. Every option you add to a page is a decision you're asking the user to make. Curate ruthlessly and the experience speeds up. Give people everything and they often choose nothing.
All three of these connect directly to accessibility. Familiar patterns reduce friction. Grouped elements reduce confusion. Fewer choices reduce abandonment. And all of that falls hardest on users who already have more barriers to navigate — whether that's a cognitive difference, a visual impairment, or just someone trying to find something quickly on a phone with one hand.
Attention
Endless scrolling and the attention problem.
Endless scroll is a pattern I push back on regularly. The idea is that more content equals more engagement. In practice, more content often equals decision paralysis and abandonment.
Human attention spans are short. People scan, not read. They make quick judgments about whether something is worth their time. An interface that asks someone to scroll indefinitely before finding what they need is working against that reality, not with it. Contained sections, clear endpoints, and deliberate pagination respect the user's time and attention in a way that infinite scroll rarely does.
This isn't just an opinion — it's something I've observed consistently across projects. When content is contained and purposeful, users find what they need. When it sprawls, they leave.
The Bottom Line
What this looks like in practice.
Accessibility isn't something I add to a project. It's something I build into it from the first decision — the type scale, the color relationships, the interaction patterns, the information architecture. The earlier it's considered, the less it costs, and the better the work is.
When I inherited constraints on Vernier, I worked within them and pushed where I could. When I built PDXWIT from scratch, I made accessibility a foundation, not an afterthought. Both approaches required intentionality. Neither required compromise.
The checkbox version of accessibility produces work that technically passes. The design version produces work that actually works — for more people, in more contexts, more of the time. That's the version I'm interested in.
