Inclusive Design: When you design for a minority, everyone wins

The curb on the sidewalk is a small thing, until you are in a wheelchair, not with a stroller and not with a heavy suitcase. It is necessary to cut the corner under the ramp - and everyone begins to use it: couriers, parents, delivery, a person after the operation. This is all inclusive design in one picture.

Designers often hear “accessibility” and think of blind users and screen readers. That’s true, but that’s less than half the story. Inclusive design is about the fact that any person at any time can be in a situation for which the interface is not designed. Broken arm. Loud subway. Old phone roaming. Tired brain at one in the morning. If a product only works for the cheerful, sighted, right-handed user on a fresh MacBook, it works for the minority, not the majority.

---

## Accessibility, adaptability, inclusion: not the same thing

These words often fall into a pile, and the conversation falls apart.

**Accessibility - compliance with specific criteria: contrast, focus, alt texts, navigation from the keyboard. It's about the checklist and the WCAG.

** Adaptability** - about devices and contexts: screen, input, network speed.

Inclusiveness: People and situations: who is excluded from the product right now and why. This is broader than the checklist, because it includes language, tonality, defaults, assumptions about the user.

You can go through the entire WCAG checklist and still release an exclusive product: for example, the form requires a first and last name, and the user has one name; or onboarding assumes that you have a smartphone for the last three years.

---

## Why "extreme case" is not an extreme case

In product discussions, the phrase “this is the edge case, we have this 2%” quickly pops up. The problem is that those 2% are added up.

• 2% visually impaired
• 4% with poor internet
• 7% with an outdated device
• 10% not in the native language of the interface
• 15% with situational restriction right now (child in hand, noise, rush)

It's not the same person. In sum, the “extreme case” is more than half the audience at any given time. When a team refuses to fix a “rare” scenario, it usually cuts not 2%, but a piece of funnel that then doesn’t converge in the metrics and nobody understands why.

### Anti-Patterns at the Review

• "It's for the blind, we don't have them" - you don't have them because they're uncomfortable
• "Let's make it a separate task" - a separate task never comes
• “We will correct if there are complaints” – disgruntled users do not complain, they leave
• “This will reduce conversions for the mainstream audience” – almost always the opposite

---

## The principle of curb-cut: design for the edge, everyone wins

Cut curb invented for wheelchair users - use all. The subtitles were made for the deaf – they watch in the subway, in the waiting room, at night next to a sleeping person. Voice input was originally about motor skills and vision, now it's hands in dough and driving.

The pattern is simple: the constraint forces you to look for a solution that reduces friction in principle. If the interface is clear to a person with cognitive fatigue, it is clear to a tired senior developer on Friday night.

### How to apply to work

• You take the script and you say, "Who can't do this?"
• For everyone, you look for a reason: perception, motor skills, context, language, experience
• Fix the reason so as not to create a separate version for the disabled
• Check that the fix improves the main scenario, not makes it heavier

If a fix worsens the main scenario, it is usually done incorrectly. A good inclusive fix almost always simplifies the interface rather than overloading it.

---

## Who do you rule out right now: a quick audit

This exercise is done in an hour by a team of designer, product and developer. Take one key flow and go through it several times with different “limited personas.”.

### Scripts for running

• Only keyboard. Is it possible to pass the flu without touching the mouse and touchpad?
• Screen reader for 10 minutes. Turn on VoiceOver/TalkBack and try to get to the result
• With your thumb on the phone, with your second hand holding coffee
• Bad lights. Reduce screen brightness by half, go outside
• Slow Internet. Throttling to 3G in Devtulza
• **Not your native language. **Switch the interface to a language you don't speak well
• Cognitive load. Walk the flow while listening to the podcast

### Questions for post-run review

• What step did you first want to quit?
• Where does the interface suggest what the user does not have?
• What mistake didn’t explain what to do next?
• What seemed optional but turned out to be a blocker?
• Which text did I have to read twice?

In summary, inclusive design isn’t a standalone track “for special users,” it’s a way to find places where a product is fragile. You fix the edge, the middle gets stronger.

## Workflow: How to Embed Inclusiveness into Normal Design Flow

The main mistake is to treat inclusivity as a separate step after the layout. It’s like trying to add a foundation to an already built house. Inclusiveness only works if it is built into the same steps as conventional design: research, sketch, layout, review, transfer to development.

### Step 1: Formulation of the task

In the brief on any float, three lines should appear next to the main goal:

• Who is the user in the worst-case scenario (bad light, noise, haste, foreign language)
• What are the restrictions we do not impose (for example: “do not require a smartphone for the last three years”)
• On which device, and in which context, the flow should operate at a minimum acceptable rate

Without this, all subsequent decisions are silently optimized for “himself behind a Macbook in a quiet office.”.

### Stage 2: sketch and frame

At the wireframe level, inclusivity is basically about structure and priority.

• One main CTA on the screen, the rest is secondary
• Logic can be read from top to bottom without icons or color
• Any error has a place where it can be shown alongside the cause
• Any form field experiences a doubling of text length (German, translation, long name)
• There's a way back from every step, and it doesn't take the input

If the frame falls apart without icons and without color, it is not a frame, it is a coloring book.

### Stage 3: Visual layout

Here live the most frequent failures. A list of minimum requirements to keep right in the file:

• The contrast of text to the background is AA, for large - at least 3:1
• Touch-targets at least 44×44, between them there is air
• The state of focus is visible without squinting, not only hover
• Color is never the only carrier of meaning (the error is not only red – it has text and an icon)
• The font reads 13-14px on a medium-sized phone, not just on a retina
• Hierarchy works in black and white screenshot

### Stage 4: Texts and Microcopy

This is part of the layout, which designers somehow give “we will write later”. This is where the exception most often occurs.

• Placeholder doesn't replace label - it disappears when needed most
• Enter the correct email is not a mistake, it is a reproach. Tell me what's wrong
• Don’t write “just”, “easy”, “just one click” – for someone it is not
• The fields “name” and “surname” almost always have to be the same field “how to address you”
• Appealing to "you"/"you" is a conscious decision, not a legacy of a pattern

---

## Diagnostics of the finished layout: 15-minute check

When the layout is already there, run it on a short protocol before giving it to the development.

### Six quick tests

1. ** Screenshot in Gray Grade.** Still clear where what is?
2. 5px blur. Is hierarchy visible and where is the main action?
3. Only the Tab prototype. Getting to the end without getting stuck?
4. **Doubling the length of all lines. ** Nothing breaks, cuts, hits?
5. ** Scrolling with one finger on the phone in one hand.** The thumb reaches the main?
6. Reading aloud all texts in a row. Sounds like a person or a form of government services?

If some test falls down, it's not "for the better later," it's editing now. Most fixes take less time than arguing about them.

### Questions for design review

• What happens if the user doesn’t have what we assumed?
• What text is written for us and not for the user?
• Where do we use color as the only signal?
• What form field can be removed altogether?
• What's going to break in this layout on slow internet and old phone?

---

## Common mistakes that are easiest not to make

• **Accessibility mode with a separate button. ** If you have a version for the visually impaired, the main version is bad. Chinni primary
• Capcha that cannot be passed with a screen reader. The alternative should be at the same point, not "write in support"
• Modals without a focus ladder and without Esc. Keyboard user gets stuck forever
• Icon without signature. If the value is not obvious in half a second, you need text
• Animations without prefers-reduced-motion. For some people, it literally causes nausea
• Error reports are only frame color. Screenreader does not see color, colorblind does not distinguish red from gray

### Segment summary

Inclusive design isn’t added at the end — it’s built into each stage as a set of little “who doesn’t and why” questions. 15 minutes of testing on the layout saves weeks of controversy and rework after release, and most edits improve the experience for everyone, not only those for whom they seem to be made.

## Advanced scenarios: where the usual checklist no longer cope

The basic test of contrast and focus is gender. The ceiling begins where the user has a combination of constraints, poor context, and an interface that is collected by features rather than scripts. Then there are the situations where inclusion breaks down the quietest.

### Multiple restrictions simultaneously

The real user is rarely "just visually impaired" or "just on the keyboard." More often - a person in the sun, with one hand occupied by a child, on 4G in the subway, with a larger font in the system by 130%.

Useful scenarios for running the layout:

• Screenreader + font enlargement 200% - does not disperse layout
• Keyboard + window narrowing to 320px - whether all activities remain achievable
• Voice input instead of click – do elements have clear names available
• High contrast system (Windows / macOS) – do not disappear boundaries and icons painted by the background alone

If even one scenario crashes the interface, it’s not an “extreme case,” it’s the point where you lose quiet users without complaining.

### Context is more important than diagnosis

Situational constraints are more common than permanent ones, but they are almost never incorporated into design.

• One hand is occupied - thumb and lower area of the screen
• Noisy - subtitles by default, not "turn on if necessary"
• Sound is not the only notification signal
• English not native - short sentences, no idioms, terms deciphered at first appearance
• Stress or fatigue – Critical actions have confirmation and recoil

## AI in inclusive design: what really helps and what hurts

LLM and Figma-built assistants speed up routine but create a new class of bugs: believable junk that looks like a normal interface.

### Where AI works well

• Rewrite the reproaching error into a human one (“Enter the correct email” → “Looks like the address missed @”)
• Generate long localizations for stress test fields (German, Finnish, Arabic)
• Offer alternative text for icons and illustrations - as a draft, not as a finale
• Run the copy to readability and simplify to the level of 6-7 class
• Describe the layout with words to check “is it clear without vision” – if AI can’t explain the screen, the screen reader won’t be able to either

### Where AI consistently fails

• Making up available names that are not in the code
• Generates "accessible" colors that don't actually pass AA on real backgrounds
• Confidently explains the non-existent WCAG rules
• Offers an alt-text of the kind “image on which it is depicted” – formally there is, in fact, useless

The rule is simple: AI availability is always checked by a tool or a person who knows how to test with their hands. A generated alt without a review is worse than an absent one because it creates a false sense that the task is closed.

### MCP, plugins and automatic checks

If the team has a pipeline configured with an MCP server or plugins in Figma, it is logical to enter there: a contrast checker, checking the size of touch targets, a printer for the text “click here” and “learn more”. This removes the debate on the review: either passes or does not.

What not to bring there: automatic generation of alt without a person in the cycle and “AI accessibility audit” as the only report before the release. The tool catches the mechanics, no point.

## How to explain a decision to a team without becoming an accessibility police

The most common failure of an inclusive designer is to be the one who blocks everything. It works one or two sprints, then they start to get around you.

### Translate into the language of the interlocutor

• Products: “This fix closes the segment, which now falls off at step 2, by support is N tickets per month”
• “This is semantic HTML, not a separate mode, there will be less code.”
• Designer: “Contrast does not limit the palette, it cuts off combinations that already looked vague”
• Marketing: “Subtitles are also views without sound in the tape”

### Arguments that work for a review

• Show the same screen through the eyes of a screen reader or in gray gradation – a short video convinces faster presentation
• Link the edit to a specific user script, not to a WCAG paragraph
• Offer an option, not just a ban: “That’s how it goes, and it looks the same.”
• Consider the cost of rework now vs. after release – it is always in favor of “then”

### Anti-patterns of communication

• Refer to the law when the team is not in the jurisdiction where it applies
• Argue about “properly WCAG” instead of “works for the user”
• Bringing a list of 40 comments without priority is ignored altogether
• Pretend that you have no compromises: they exist, and it is more honest to say that we are not closing now and why

### Segment summary

Advanced inclusion is not more about rules, but rather about scripts and honest communication. AI speeds up routine, but doesn’t shut down responsibility; command agreement is based not on references to a standard, but on the fact that editing solves a problem that everyone understands.

## Checklist: inclusive design on the layout review

This is not a WCAG audit, but a quick run, which is really in time for 10-15 minutes before being sent to the development.

### Contrast and color

• Text and icons pass AA on real backgrounds, not on white palette
• No state (error, success, chosen) is conveyed by color alone
• Focus is visible on any background, including dark images
• Disabled state is not only transparent

### Text and language

• Button headings describe the action, not “Confirm”, “OK”, “Learn more”
• Mistakes explain what to do, not failure
• Abbreviations and terms are deciphered at the first appearance
• The tone does not reproach the user

### Structure and navigation

• The order of reading coincides with the visual
• Every icon without a signature has an accessible name
• Groups of interactive elements have a common title
• Logic without a mouse: everything is achievable with a keyboard, the focus does not go into void

### Motor and input

• Touch targets at least 44×44 on mobile
• Critical actions have confirmation and recoil
• No gestures without a button alternative
• Timers are either turned off or extended

### Media

• Video has subtitles, audio has transcripts
• In meaningful images – alt in fact, decorative – empty alt
• Autoplay without sound, traffic can be stopped

## Anti-Patterns Masquerading as Accessibility

These are things that look like care, and in practice break experience more than no feature.

### Separate “available mode”

The “version for the visually impaired” button in the corner is almost always a sign that the main interface is unavailable, and the team paid off with a separate page. This page becomes obsolete first, breaks when redesigned and is not tested by anyone.

### Contrast for a tick

Black text in bright yellow passes AA, but it hurts to read it. Accessibility is not a maximum of contrast, but a sufficient contrast in a calm palette.

### Alt text for the sake of presence

“Image”, “photo”, “button icon” – formally there is an attribute, in fact, the screen reader voices garbage. Better an empty alt in a decorative image than a stub.

### Tultypes as the main explanation

If the key information lives only in the hover toult, it is not for the touch, keyboard and screen reader. The toult is a clue, not content.

### Capcha without alternative

A picture captcha with no audio or logical alternative cuts off some users completely. If you need protection from bots, you need a second way.

### "We'll fix it in the next sprint."

Availability postponed for later is never done. After the release, edits are more expensive, and priority always goes to new features.

## Questions for design review

These questions should be kept before your eyes when looking at someone else’s layout or yours every other day.

• What happens if the user has one hand occupied?
• What would a person who reads a screen without color see?
• How does this screen sound to a screen reader - in what order and in what words?
• If you remove the icons, you can still see what each button does?
• What happens if the text grows one and a half times in translation?
• What’s the most expensive step here – and is there any protection against random clicking?
• Where will the user get stuck if the Internet slows down and half does not load?
• Who will be uncomfortable with this screen – and is it a conscious decision?

If you answer “I don’t know” to any of the questions, it’s a place for a prototype in code or a pass with a real assistive tool, not for guesswork.

## Practical outcome

Inclusive design is not a separate discipline next to a product, but a way to make ordinary decisions with more people in mind. Contrast, touch-target size, error formulation, and focus order are not “availability,” it’s just a well-made interface.

A simple sequence works: choose scenarios where the exception really hurts; sew basic checks into tools so as not to argue about them manually; keep AI on rough work and never on final responsibility; say compromises out loud rather than mask them. Then minority edits cease to be a sacrifice for the sake of conscience and become what they are in practice - an upgrade of the product for all.