Why accessibility and sustainability must be at the core of UX

The illusion of good design

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.

Design is a system, not a surface

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.

// A button's accessibility contract — what designers must define

const buttonContract = {
  // Visual: What does it look like? (the surface)
  appearance: {
    label: "Clear, concise action verb",
    colorContrast: "Minimum 4.5:1 against background",
    size: "Minimum 44x44px touch target (WCAG 2.5.8)",
  },

  // Semantic: What does it mean? (the system)
  semantics: {
    role: "button",
    label: "Accessible name matches or describes visible label",
    state: "Communicates disabled, loading, or pressed states",
  },

  // Interaction: How does it behave? (the contract)
  interaction: {
    keyboard: "Activatable via Enter and Space",
    focus: "Visible focus indicator in all states",
    feedback: "Immediate visual and programmatic feedback on activation",
  },
};

The empathy gap

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.

Accessibility is more than a checklist

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.

Cognitive load: the invisible barrier

Cognitive load is the total amount of mental effort being used in working memory at any given moment. It is one of the most researched concepts in psychology and one of the most ignored in interface design.

Every element on a screen demands cognitive resources. Every choice forces the user to evaluate options. Every unfamiliar pattern requires the user to learn before they can act. And cognitive load is not evenly distributed across users, it hits hardest on the people who can least afford it: users with cognitive disabilities, users under stress, users who are unfamiliar with your product, and users operating in a second language.

• Visual complexity: too many elements competing for attention fragments focus and increases processing time.
• Inconsistent patterns: when buttons look different across pages, or navigation behaves unpredictably, users must re-learn the interface constantly.
• Unclear language: jargon, long sentences, and passive voice force users to work harder to extract meaning.
• Decision overload: presenting too many options at once paralyzes decision-making rather than empowering it.
• Hidden affordances: if an interactive element doesn't look interactive, users won't find it, or will find it too late.

Sustainability as a design constraint

Every design decision has a carbon cost. A full-page hero image. An auto-playing video. A complex animation that forces GPU rendering. A bloated icon library where only three icons are used. A font loaded in six weights when two would suffice. Each of these decisions consumes energy, not just in the user's browser, but in the data centers that serve the assets and the networks that transmit them.

The performance-accessibility paradox

Here is something that most design teams never discuss: performance and accessibility are deeply, fundamentally linked, and optimizing for one almost always improves the other.

A page that loads in 1 second is not just faster than a page that loads in 5 seconds. It is more accessible. Users with cognitive disabilities benefit from faster feedback. Users on slow connections — disproportionately users in developing nations, can actually use the product. Screen readers can parse a lighter DOM faster. Animations that respect prefers-reduced-motion don't just reduce carbon, they prevent vestibular discomfort for users with motion sensitivity.

Designing for the edges

The "edge cases" in design are not edge cases at all. They are the cases where the design is most honestly tested.

A design that works for a user with perfect vision, full motor control, on a fast connection, using the latest browser — that design has been tested under ideal conditions. It tells you almost nothing about how robust the design actually is.

The real test is the edges:

• A user navigating entirely by keyboard after a stroke left them unable to grip a mouse.
• A user on a 2G mobile connection in a rural area trying to access a government service.
• A user with dyslexia trying to read a long-form article in a small, low-contrast font.
• A user with ADHD trying to complete a multi-step form that auto-resets on timeout.
• A user with color blindness trying to interpret a data visualization that relies solely on hue.
• A user with a vestibular disorder watching an interface animate on every scroll event.

These are not rare scenarios. They are common ones. And designing for them does not compromise the experience for other users, it elevates it for everyone.

Rethinking the design process

If accessibility and sustainability are to be treated as core design values, not afterthoughts, the process itself must change. Here is what that looks like in practice:

1. Define accessibility requirements before wireframing:before a single pixel is drawn, the team must agree on target WCAG level, supported assistive technologies, and key user scenarios beyond the "happy path."
2. Design with constraints visible: show contrast ratios on color swatches, show file sizes on image assets, show focus states alongside default states, make the invisible costs visible at every stage.
3. Include assistive technology in prototyping: don't wait for development to test with a screen reader, design tools now support accessibility annotations, use them.
4. Test with real users, not just real tools: automated audits and screen reader walkthroughs are valuable, but nothing replaces watching a real person with a disability try to use your product.
5. Measure what matters: if your success metrics are limited to conversion rates and time-on-page, you are measuring a narrow slice of design quality, add accessibility audit scores, page weight, and carbon emissions to your dashboard.

The path forward

The design industry is at an inflection point. The tools are better than they have ever been. Accessibility testing is built into design platforms. WCAG guidelines are clearer than ever. The knowledge exists.

What is missing is not capability. It is priority.

Accessibility and sustainability must stop being treated as compliance exercises performed at the end of a project. They must become the criteria by which design quality is defined, from the first wireframe to the final launch and beyond.

The best design does not sacrifice beauty for function or function for beauty. It finds the intersection, the place where something works beautifully for everyone, costs the planet as little as possible, and respects the full spectrum of human experience.

That intersection is not a compromise. It is the highest form of design there is.