•
•
A stunning interface is not, by itself, good design. A product that looks impeccable in a Figma mockup but fails a wheelchair user, confuses a colorblind designer, or downloads 4MB of JavaScript to render a single paragraph has failed at its most fundamental level, regardless of how polished it appears on a retina display.
For decades, the design industry has operated under an assumption so deeply embedded it rarely gets questioned: that design is primarily a visual discipline. Beautiful layouts. Refined typography. Harmonious color palettes. And while none of these things are unimportant, they have collectively created a blind spot so significant that it is now one of the greatest sources of friction between the products we design and the humans who actually use them.
This article is not about adding accessibility as an afterthought. It is not about compliance checklists or legal obligations, though those matter. It is about a fundamental reframing of what design actually is — and why sustainability and accessibility are not constraints on good design, but the very definition of it.
Donald Norman's foundational concept of human-centered design was never about aesthetics. It was about the relationship between a human and a system, how that system communicates its affordances, how it responds to input, how it manages errors, and how it builds mental models in the user's mind. The visual layer is one output of that system. It is not the system itself.
When we design a button, we are not simply choosing a color and a radius. We are defining a contract with the user:
This element is interactive. It will do something when you activate it. It will tell you what it does before you click it. It will confirm that it worked after you do.
That contract must hold for every user. The sighted user who clicks with a mouse. The blind user who navigates with a screen reader. The user with a motor impairment who navigates with a keyboard and needs generous hit targets. The user on a slow connection who needs the page to be responsive before the full asset bundle downloads.
1// A button's accessibility contract — what designers must define
2
3const buttonContract = {
4 // Visual: What does it look like? (the surface)
5 appearance: {
6 label: "Clear, concise action verb",
7 colorContrast: "Minimum 4.5:1 against background",
8 size: "Minimum 44x44px touch target (WCAG 2.5.8)",
9 },
10
11 // Semantic: What does it mean? (the system)
12 semantics: {
13 role: "button",
14 label: "Accessible name matches or describes visible label",
15 state: "Communicates disabled, loading, or pressed states",
16 },
17
18 // Interaction: How does it behave? (the contract)
19 interaction: {
20 keyboard: "Activatable via Enter and Space",
21 focus: "Visible focus indicator in all states",
22 feedback: "Immediate visual and programmatic feedback on activation",
23 },
24};There is a well-documented cognitive bias in design called the empathy gap, the tendency to underestimate how different another person's experience is from your own. It is perhaps the single most dangerous bias a designer can hold.
Most designers are young, able-bodied, using high-end devices on fast connections, with full color vision. They design for themselves. Not intentionally, but because their own experience is the only one they have direct access to. And the result is predictable: interfaces that work beautifully for people exactly like the designer, and break down systematically for everyone else.
This is not a failure of moral character. It is a failure of process. And it can be fixed, but only if the design process is explicitly structured to surface experiences beyond the designer's own.
The WCAG guidelines are critical. They are the international standard. They provide measurable, testable criteria. But they are not the ceiling of accessible design, they are the floor.
A website can pass every WCAG AA criterion and still be deeply confusing to use. A navigation structure that meets all technical requirements can still be cognitively overwhelming. A form can have perfect label associations and still be impossible to complete under stress.
True accessibility is about the experience. It is about whether a user, any user, can accomplish what they came to do, without unnecessary friction, confusion, or exclusion. That is a design problem, not a technical one.
Whether you're just starting to think about sustainability and accessibility or you're ready to overhaul your entire stack—there's a place for you here.
No spam. Unsubscribe anytime. Join 300+ developers.