Inclusive Design

Patterns For
2025

Vitaly Friedman
September 2024
 Table of Contents

i. EAA, WCAG 2.2

ii. Colorblindness, Motion
iii. Children, Older Adults
iv. Autism, Dyscalculia
v. Deafness, Blindness
vi. Building A Strong Case
Inclusive Design Patterns

Accessibility &
Inclusive Design
Inclusive Design

Accessible Isn’t A Checklist

Accessibility is not a compliance
checklist. It’s an e ort to keep a digital
experience meaningful and usable for
as many people as possible. There are
no edge cases or average users.
ff
Inclusive Design

Retaining Accessibility
Accessibility is not something we add
to a website, but something we start
with initially — and risk losing with
every single change. Our task is to
retain it throughout the design process.

Scott Jehl, Front-End Engineer (and just an incredibly kind person)

 Inclusive Design

Misaligned Vocabulary
Business language Accessibility / UX Language
01 — “Conquer” the market 01 — “Reduce” friction

02 — “Capture” mindshare 02 — “Improve” consistency

03 — “Target” customers 03 — “Empower” users

04 — “Destroy” the competition 04 — “Enable” and “help” users

05 — “Fight” for marketshare 05 — “Meet” user’s expectations

06 — “Convert” and “follow-up” 06 — “Re ne” touch points

07 — Employ a sales “force” 07 — “Enable” users/customers

08 — Hire “head-hunters” 08 —“Customer service”, support

09 — Pick their “battles” 09 — Build “trust” with users

10 — Attract more “eye-balls” 10 — Understand “user needs”

11 — Get users “hooked” 11 — Develop “empathy“

12 — Increase “life-time value” 12 — “Inclusive” experience

fi
↬ Inclusive Design Toolkit, https://www.microsoft.com/design/inclusive/
Inclusive Design

“Disability” Mindset
People don’t think of themselves as
disabled, so they don’t think the
accessibility features apply to them.
People often don’t realize that they rely
on accessibility all the time. 👓

Eric Bailey, Accessibility preference settings

Inclusive Design

“Disability” Mindset
There is no “one true way” to use a
computer. There are limitations and
barriers we all need to contend with.
Some issues a ect everyone, others are
present circumstantially.

Eric Bailey, Accessibility preference settings

ff
Inclusive Design

Accessible, Inclusive, Universal

Accessible design aims for equal access
for people with disabilities.
Inclusive design meets needs of diverse
users (age, gender, culture, mental state).
Universal design aims for a solution that
works for full spectrum of abilities.
Inclusive design

Every Person Is Unique

People have multiple attributes
that are unique to them. Every
person is on a spectrum, and there
are overlaps and various levels of
severity.
Inclusive design

Dealing With Emotions

What people do, think, feel and say
are often very di erent things,
often contradicting each other.
Don’t ask what people thing, track
what their emotions tell you.
ff
How To Fix A Bad User Interface, Scott Hur
f
Inclusive Design

Designing Unhappy Paths

People are never edge cases. Average
users don’t exist. Exceptions will occur,
it’s just a matter of time. To prevent
failures, explore unhappy paths early.
Accessibility is a reliable way to ensure
design resilience.
User Behavior Patterns

User Frustrations In 2025

Argh! Tiny scrollable panes. Argh! Unsupported “Back” button.
Argh! Tiny click targets. Argh! Disabled copy-paste.
Argh! Unexpected content shifts. Argh! No text input fallback in sliders.
Argh! Unexpected page reloads. Argh! Draconian pass requirements.
Argh! Country selector dropdown. Argh! Retyping complex input.
Argh! Generic error messages. Argh! Birthday picker, starting 2020.
Argh! Input fully cleared on error. Argh! Scrolljacking and parallax.
Argh! Disabled “Next” buttons. Cry ;-( Identifying buses/crosswalks.
User Behavior Patterns

User Delighters In 2025

Awww! Fast, accessible experience. Awww! Smart, fast autocomplete.
Awww! Large, legible text. Awww! User input persisted on refresh.
Awww! Large checkboxes, radios. Awww! Drop-down opening on tap/click.
Awww! Input boxes as input boxes. Awww! Easy undos, edits, cancellations.
Awww! Focus and active states. Awww! Predictable “Back” button.
Awww! Simple pass requirements. Awww! Snoozing noti cations.
Awww! Predictable tabbing in forms. Awww! Pausing subscriptions.
Awww! Helpful error messages. Awww! Transparent pricing.
fi
Inclusive Design

EU Accessibility
Act, WCAG 2.2
Accessible Legislation

European Accessibility Act (EAA)

Aimed at improving accessibility of
for people with disabilities and
functional limitations across the EU.
Framework with min requirements
that all member states must uphold.
Compliance and regulation

European Accessibility Act (EAA)

01 — EEA is a new EU directive to standardize accessibility.
02 — It mandates accessibility for “essential” products.
03 — Public products: devices, self-service, eBooks, e-readers.
04 — Public services: digital products, banking, transport, eCommerce.
05 — Applies to all private companies globally that sell to EU customers.

06 — EU operations: your products must meet EAA’s requirements.

07 — Grace period: 5 years for “unaltered” service providers/contracts.
08 — EEA doesn’t reference WCAG, but implies 2.2 AA compliance.
09 — The deadline to comply with EAA is 28 June 2025.
↬ WAD and EAA Explained, Deque, https://www.youtube.com/watch?v=MOiGSHw5CoA
Compliance and regulation

European Accessibility Act (EAA)

01 — Only applies to consumer interactions/transactions in EU market.
02 — Exception: B2B and employee-facing systems.
03 — Exception: Micro-enterprises (<10 people, turnover < EUR 2 Mio).
04 — Exception: Archives (not updated after the eective date).
05 — Exception: Pre-recorded media, unaltered third-party content (map).

06 — Should support text-to-speech, screen readers, customization.

07 — Must comply even if you don’t have a shop, but support (“service”).
08 — Accessibility overlays aren’t accepted as-is under the EAA.
09 — Company providing a service is responsible for EAA compliance.
10 — Companies must do due diligence to request EAA compliance explicitly.
ff
Accessible Legislation

European Accessibility Act (EAA)

National authorities are responsible
for carrying out regular compliance
checks, which will include reviewing
complaints and following up on any
reported non-compliance.
Accessible Legislation

European Accessibility Act (EAA)

Service providers will need to
explain how a service meets digital
accessibility requirements. They
must provide public evidence that
the way service is delivered and
monitored complies with EAA.
 WCAG 2.2 Map
1.2.1 Audio-only and Video-only
(Prerecorded)
A
1.2.2 Captions (Prerecorded)
1.2.3 Audio Description or Media 2.1.1 Keyboard
Alternative (Prerecorded) 2.1.2 No Keyboard Trap 2.2.1 Timing Adjustable
A 2.4.1 Bypass Blocks
2.1.4 Character Key Shortcuts 2.2.2 Pause, Stop, Hide A
2.4.2 Page Titled
1.2.4 Captions (Live) 2.3.1 Three Flashes or
AA 1.2.5 Audio Description (Prerecorded) 2.1.3 Keyboard 2.2.3 No Timing Below Threshold A 2.4.3 Focus Order A
AAA 2.4.4 Link Purpose
(No Exception) 2.2.4 Interruptions
1.2.6 Sign Language (Prerecorded) 2.2.5 Re-authenticating
AAA 2.3.2 Three Flashes
(In Context)

1.2.7 Extended Audio Description 2.2.6 Timeouts 2.3.3 Animation from 2.4.5 Multiple Ways
1.3.1 Info and Relationships AAA (Prerecorded) 1.1.1 Non-text Content Interactions
AAA
1.3.2 Meaningful Sequence
A 2.1 Keyboard 2.4.6 Headings and Labels
A 1.2.8 Media Alternative (Prerecorded) Accessible
1.3.3 Sensory Characteristics 2.4.7 Focus Visible AA
1.2.9 Audio-only (Live)
2.2 Enough 2.4.11 Focus Not Obscured
1.3.4 Orientation 1.1 Text Alternatives Time (Minimum)
AA 1.3.5 Identify Input Purpose 2.3 Seizures
2.4.8 Location
Information and Physical
1.2 Time-based Media 2.4.9 Link Purpose (Link Only)
AAA 1.3.6 Identify Purpose and user interface Reactions
2.4.10 Section Headings
components must be AAA
presentable to users User interface 2.4.12 Focus Not Obscured
components and (Enhanced)
in ways they can
1.3 Adaptable navigation must be 2.4.13 Focus Appearance
perceive.
operable.

1.4 Distinguishable 2.4 Navigable

Perceivable Operable
A 1.4.1 Use of Color
WCAG 2.5 Input Modalities
1.4.2 Audio Control
Robust 2.2 Understandable
1.4.3 Contrast (Minimum)
1.4.4 Resize Text
Content must be
2.5.1 Pointer Gestures
1.4.5 Images of Text
robust enough that it
AA can be interpreted Information 2.5.2 Pointer Cancellation
A
1.4.10 Reflow and the 2.5.3 Label in Name
reliably by a wide
1.4.11 Non-text Contrast operation of 2.5.4 Motion Actuation
variety of user
1.4.12 Text Spacing user interface
agents, including 2.5.7 Dragging Movements
1.4.13 Content on Hover or Focus must be AA
assistive 2.5.8 Target Size (Minimum)
technologies. understandable.
1.4.6 Contrast (Enhanced) 2.5.5 Target Size (Enhanced)
1.4.7 Low or No Background Audio 3.3 Input 2.5.6 Concurrent Input AAA
AAA 1.4.8 Visual Presentation Assistance Mechanisms
1.4.9 Images of Text (No Exception) 4.1 Compatible

3.1 Readable
3.2 Predictable
4.1.1 Parsing (Removed in 2.2)
A 4.1.2 Name, Role, Value 3.3.1 Error Identification
3.3.2 Labels or Instructions
A
3.1.1 Language of Page A 3.3.7 Redundant Entry
AA 4.1.3 Status Messages

3.1.2 Language of Parts AA 3.2.1 On Focus 3.3.3 Error Suggestion

A
3.2.2 On Input 3.3.4 Error Prevention (Legal,
3.2.6 Consistent Help Financial, Data) AA
3.1.3 Unusual Words
Key: New in WCAG 2.2 3.1.4 Abbreviations 3.3.8 Accessible Authentication
AAA 3.2.3 Consistent Navigation (Minimum)
AA Success Criteria Level 3.1.5 Reading Level
3.2.4 Consistent
AA
3.1.6 Pronunciation Identification 3.3.5 Help

Visual map of Web Content Accessibility Guidelines 2.2 Based on World Wide 3.2.5 Change on Request
3.3.6 Error Prevention (All) AAA
AAA 3.3.9 Accessible Authentication
Web Consortium documentation available at https://www.w3.org/TR/WCAG22
intopia.digital Licenced under Creative Commons Attribution-ShareAlike 4.0 International
(Enhanced)
 Compliance and regulation

WCAG 2.2 AA Criteria

01 — Each WCAG Level comes with “success criteria”.
02 — Level AA is referenced in most laws and policies globally.
03 — Most websites aim to achieve WCAG A + AA compliance.
04 — WCAG 2.2 has 6 new level A+AA, 3 new level AAA criteria.

05 — Don’t obscure a focused element (e.g. with sticky headers, modals).

06 — Focus should always be visible: at least partially (AA) or fully (AAA).
07 — Use a focus outline of 2px, with a su cient contrast (AAA).
08 — Help is presented and located consistently across all pages.
09 — O er UI controls for dragging movements (e.g. drag-n-drop).
10 — Allow users to click/tap on an item, “pick it up”, move it, “drop” it.
ff
ffi
Compliance and regulation

WCAG 2.2 AA Criteria

11 — Allow users to click/tap on an item, “pick it up”, move it, “drop” it.
12 — Avoid redundant entry: don’t make users re-enter the same data.
13 — Don’t block copy/paste, avoid CAPTCHAs or cognitive puzzles (AA).
14 — Avoid object recognition (e.g.re hydrants, bikes etc) (AAA).
15 — Set up accessible auth: 2FA, magic links, ngerprint, app auth.
fi
fi
Universal Design Playbook
https://universaldesignguide.com
 This is WCAG
https://thisiswcag.com
 MagentaA11Y
https://www.magentaa11y.com/web/
Inclusive design
T
Colorblindness, o
Motion Sickness t
W

S
Inclusive design

Colorblindness
300 million people have some kind
of colorweakness, or are colorblind.
The safest bet is to never rely on
colors alone to communicate data.
Inclusive Design

Living With Colorblindness

01 — Chargers with a single red/green LED
02 — Buying matching clothes
03 — Visited and not visited links
04 — Climbing with color-coded holes
05 — Finding dropped peas on a carpet
06 — Knowing when the food is cooked
07 — Red/green lights appear ashing
08 — Dashboards/charts hard to read
09 — Can’t remember colors of things
10 — Hard to judge ripeness of fruit
11 — Color-coded transport routes
12 — Identify colors through prior knowledge
fl
 Inclusive design

Colorblindness
Be careful when combining hues
and patterns: patterns change how
bright or dark colors are perceived.
Consider designing in monotone
rst, then add color.
fi
Inclusive design

Color Contrast
Contrast captures the di erence in
brightness between colors, by using
relative luminance of colors. The
greater the di erence in luminance,
the higher the contrast ratio.
ff
ff
 Inclusive design

Color Contrast
White-on-white has 1:1 ratio (min)
Black-on-white has 21:1 ratio (max).
High color contrast alone isn’t
su cient to address colorblindness.
ffi
Inclusive design

“Dark Yellow Problem”

For design systems, we de ne main
colors of a similar relative luminance.
When we swap colors for statuses, they
still pass accessibility requirements.
fi
 Dark Yellow Problem in Systems
https://uxdesign.cc/the-dark-yellow-problem-in-design-
system-color-palettes-a0db1eedc99d
 Accessibility Developer Guide
https://www.accessibility-developer-guide.com/
knowledge/colours-and-contrast/colour-is-not-enough/
Colorblindness

Add Shapes, Textures, Outlines

To help elements stand out, add
an option to augment color with
additional accessibility cues:
divider lines, textures, shapes,
outlines, alternate views.
Colorblindness

Shapes Toggle, Viridis

In case you can’t change the color
palette, but understanding colors
is crucial, provide a colorblind
toggle with shapes, or use a friendly
ubiquitous palette like viridis.
Colorblindness

Increase Color Contrast

To highlight a selected item, we can
use a higher contrast color, change
the background, add labels, use
established components (e.g. toggle).
Inclusive Design

Colorblindness
01 — Blue is the safest hue for users to perceive color as you do.

02 — Use any 2 colors you like as long as they vary by lightness.

03 — Colorblind users can tell red/green apart, but not which is which.

04 — Colorblind-safest palette: mix blue 🔵 with orange 🟠 or red 🔴.

06 — Don’t design with pastel colors only ⬤⬤⬤⬤⬤

06 — Don’t mix red 🔴, green 🟢 and brown 🟤 together.

07 — Don’t mix pink , turquoise and grey together.

08 — Don’t mix purple 🟣 and blue 🔵 together.

09 — Don’t mix green 🟢 and pink 🟣 if you use red 🔴 and blue 🔵.

10 — Don’t mix green 🟢 with orange 🟠, red 🔴 or blue 🔵 of the same lightness.
 Who Can Use?
https://www.whocanuse.com
 Accessible Color Palettes
https://venngage.com/tools/
accessible-color-palette-generator
Accessible Color Palettes
https://www.figma.com/community/
file/909176640411029401
 Viz Palette
https://projects.susielu.com/viz-palette
 Colorblind and Colorweak Experiences
https://blog.datawrapper.de/colorblindness-
Inclusive design

Motion Sickness
When people experience a
sensory con ict between what
they see and what they feel, it
often causes motion sickness.
Ca 30% are highly susceptible to
it (vestibular disorder, migraine).
fl
 Inclusive Design

Designing Accessible Motion

01 — Respect the physics: map scrolling to your animations.

02 — Avoid ashing images/video, esp. when people are reading.

03 — Ask for consent to present “interactive” features.

04 — Provide controls on individual elements of a story.

05 — For animated charts, add skip to the end shortcut.

06 — Respect reduced motion, provide alternate version.

07 — Avoid ashes and limit bounces to 3 times.

08 — Avoid parallax scrolling (movements at di erent speeds).
fl
fl
ff
Design Patterns

Inclusive
Design
Inclusive design

Children
Designing for children (age 3–12)
is hard. Children tend to lose focus
and motivation quickly. They need
steady achievements. We need to
reward and encourage small wins.
Inclusive design

Children
Children communicate volumes by
how they play, what they choose to
play with, how long they choose to
play with it, and when they decide
to play with something else.

Deb Gelman, “Design For Kids”

Inclusive Design

The Brain Of A Child

01 — Age of 2: kids develop a sense of self, but few mental models.

02 — Very rough motor skills, but know how to swipe and tap.

03 — Around the age of 6, they can focus for longer period of time.

04 — That’s also the time when they start developing empathy.

05 — By the age of 8, they can decode simple written language.

06 — Typing is di cult: ne motor skills aren’t yet developed.

07 — At the age of 10, they start using keyboard and mouse.

09 — Yet they still can’t think abstractly until the age of 12.

10 — I.e. they can’t distinguish promotions from real content.

ffi
fi
Inclusive Design

Design Patterns For Children

01 — Translate text into visuals, icons, sounds, characters.

02 — Storytelling brings abstract concepts in a concrete form.

03 — Large text (18–19px), large tap targets (min 75×75px).

04 — Use typefaces that approximate how children learn to write.

05 — Avoid bottom buttons as children often tap on them by mistake.

Inclusive Design

Design Patterns For Children

06 — Children expect feedback on every single action.

07 — Kids welcome sounds, voices, background music.

08 — Show large navigation cards/carousels, not search.

09 — Beware of positive reinforcement → intrinsic motivation.

 Inclusive Design

Support Intrinsic Motivation

01 — Most games use rewards, progression mechanics.

02 — They t into 2 external categories: carrots and sticks.

03 — Intrinsic motivation comes from caring deeply + enjoyment.

04 — Competence: challenges, so players feel that they are e ective.

05 — Give players skill-related feedback, e.g. what they could try next.

06 — Autonomy: give people real choice to choose their own adventure.

07 — Relatedness: sense of belonging from collaborative features.

Paula Gomes, “How to increase players’ intrinsic motivation”

fi
ff
How To Increase Players’ Intrinsic Motivation
By Paula Gomes, Medium
Inclusive design

Teenagers
Teenagers (13–17 years old) are
often fast-moving, less cautious
and make snap judgements. Think
of them as younger adults, not kids.
Don’t underestimate their skills.
Inclusive Design

Teenagers’ Behavior
01 — Most teens have mobile devices, but not all have laptops.

02 — To some, the default search engine is YouTube, not Google.

03 — Teenagers have dramatically low levels of patience and focus.

04 — They also have low tolerance for slow or passive activities.

05 — They don’t spend time just on social media or playing games.

Inclusive Design

Teenagers’ Behavior
06 — They heavily rely on apps related to school, work, shopping.

07 — They relate best to content created by teens of a similar age.

08 — Teens often experience di culty formulating search queries.

09 — They read, but mostly skim key points and skip long text blocks.
ffi
 Inclusive Design

Design Patterns For Teenagers

01 — Design large text (18–19px), large tap targets (min 75×75px).

02 — Show content in small, meaningful chunks, with illustrations.

03 — Re ne autocomplete to drive teens to better search queries.

04 — Use a neutral adult language without being condescending.

05 — Show sources/data: it’s di cult for teens to judge credibility.

06 — Never label teens as “kids”: to many, that’s a deal-breaker.

07 — Think of them as “younger adults” and don’t underestimate them.

fi
ffi
Inclusive design

Older Adults
One billion people aged 60+ live
today, often healthy, active and
with a solid income and capital to
spend. Also, they are often ignored
and seen as one single entity.
Older Adults: Are We Really Designing for Our Future Selves?, Elizabeth Buie, Slideshare
Older Adults: Are We Really Designing for Our Future Selves?, Elizabeth Buie, Slideshare
Older Adults: Are We Really Designing for Our Future Selves?, Elizabeth Buie, Slideshare
Older Adults: Are We Really Designing for Our Future Selves?, Elizabeth Buie, Slideshare
↬ Hover Tunnels, Chris Coyier, https://css-tricks.com/dropdown-menus-with-more-forgiving-mouse-movement-paths/
↬ Hover Tunnels, Chris Coyier, https://css-tricks.com/dropdown-menus-with-more-forgiving-mouse-movement-paths/
↬ SVG Exit Path Areas, Hakim al-Hattab, https://slides.com/wireframe?debug=2#menu
↬ A Guide to Build Context Menus, Michael Villar, https://height.app/blog/guide-to-build-context-menus
↬ A Guide to Build Context Menus, Michael Villar, https://height.app/blog/guide-to-build-context-menus
Goldman Sachs, https://design.gs.com/patterns/grids-tables-formatting
GE Healthcare, https://design.gs.com/components/table#states
Salesforce Drag’n-Drop, https://salesforce-ux.github.io/dnd-a11y-patterns/
Salesforce Drag’n-Drop, https://salesforce-ux.github.io/dnd-a11y-patterns/
 Drag-and-Drop UX

Summary
01 — Users should feel like they are moving physical objects..

02 — Design states for components and drop zone areas.

03 — Dragged items should move towards users in the z-axis.

04 — Animate the drop of an item (100ms) into its new home position.

05 — Add shadows and elevation to make interaction obvious.

06 — Simulate a “magnetic” e ect that snaps objects into place.

07 — Reshu e when a center of a dragged item overlaps an edge.
08 — Collapse large components into summaries during transit.

09 — Keep handle icons accessible and support screen readers.

10 — Use a haptic “bump” to indicate grabbing on mobile.

ffl
ff
Inclusive design

Independence and Competence

When designing for older adults,
prevent errors by providing a calm
experience, presets, inline lters
and avoid precise movements.
fi
Guidelines and Tips
Designing for Different Ages

Children 1 Give kids clear and specific instructions by stating

Ages 3-12 the goal of a game (or other online tasks) and how
to achieve it.

2 Instructions should be tailored to a

kids’ level of comprehension.

3 Touchscreen designs for kids under 9 should

emphasize swiping, tapping, and dragging.

4 Use existing mental models and knowledge about

the world to help kids accomplish tasks.

5 Instructions should be clear and specific, but not too

prescriptive. Because kids’ reasoning skills are still
developing, they are more likely to take specific
instructions literally.

Teenagers 1 Write for impatient users.

Ages 13-17
2 Beware of overusing interactive features just because
you design for younger audiences. Multimedia can
engage or enrage teens, depending on its usefulness.

3 Avoid anything that sounds condescending

or babyish.

4 Facilitate sharing but don’t force it. Teens rely on

technology for social communication, but they don’t
want to be social all the time.

5 Design for mobile viewing as they are often viewing

your content from their phone or mobile device.
Young Adults 1 Feature visual design that matches your brand.
Sites that appear unprofessional or dated recieve
Ages 18-25
strong criticism from young adults.

2 Attract young adults with clean designs and

ample whitespace.

3 Avoid including fancy features just for the sake of

having them. Young adults tend to consider gratuitous
interactive elements as childish.

4 Young adults scan categories and links for clues on

what to click. Links that contain keywords that match
the user’s tasks get clicked on; generic or imprecisely
labeledlinks get ignored.

5 Feature URLs that are short, readable, and

memorable. Young adults are heavily reliant on
search engines for navigating the web, but they
sometimes utilize URL structure to re-find content.

Seniors 1 Sites and apps designed by and for young people are
Ages 65+ often inaccessible for older users. Ensure you are using
accessible text sizes and touch targets.

2 Older users make more mistakes than younger

users do. When dealing with errors, focus on the
error, explain it clearly, and make it as easy as
possible to fix.

3 Don’t treat seniors as a niche interest group, but

rather as a diverse and growing demographic to help
them feel included in online content.

Based on research from NN/g Reports:

UX Design for Teenagers (Ages 13-17), 3rd Edition
Designing for Young Adults (Ages 18-25), 3rd Edition
UX Design for Children (Ages 3-12), 4th Edition
UX Design for Seniors (Ages 65 and older), 3rd Edition
Inclusive design

Left-Handed Users
Roughly 10% of people are left-
handed. It doesn’t mean that they
are left-handed users. We can’t
impose design decisions, but we
can allow customization based
on preferences.
↬ Diagonal UI, Michael Oh, https://www.behance.net/gallery/12419409/VICE-VERSA-diagonal-UI-optimized-for-single-hand-IX
↬ Diagonal UI, Michael Oh, https://www.behance.net/gallery/12419409/VICE-VERSA-diagonal-UI-optimized-for-single-hand-IX
↬ Diagonal UI, Michael Oh, https://www.behance.net/gallery/12419409/VICE-VERSA-diagonal-UI-optimized-for-single-hand-IX
↬ Diagonal UI, Michael Oh, https://www.behance.net/gallery/12419409/VICE-VERSA-diagonal-UI-optimized-for-single-hand-IX
↬ Diagonal UI, Michael Oh, https://www.behance.net/gallery/12419409/VICE-VERSA-diagonal-UI-optimized-for-single-hand-IX
User Behavior Patterns

User Frustrations In 2021

Argh! Tiny scrollable panes. Argh! Unsupported “Back” button.
Argh! Tiny click targets. Argh! Disabled copy-paste.
Argh! Unexpected content shifts. Argh! No text input fallback in sliders.
Argh! Unexpected page reloads. Argh! Draconian pass requirements.
Argh! Country selector dropdown. Argh! Retyping complex input.
Argh! Generic error messages. Argh! Birthday picker, starting 2020.
Argh! Input fully cleared on error. Argh! Scrolljacking and parallax.
Argh! Disabled “Next” buttons. Cry ;-( Identifying buses/crosswalks.
User Behavior Patterns

User Delighters In 2021

Awww! Fast, accessible experience. Awww! Smart, fast autocomplete.
Awww! Large, legible text. Awww! User input persisted on refresh.
Awww! Large checkboxes, radios. Awww! Drop-down opening on tap/click.
Awww! Input boxes as input boxes. Awww! Easy undos, edits, cancellations.
Awww! Focus and active states. Awww! Predictable “Back” button.
Awww! Simple pass requirements. Awww! Snoozing noti cations.
Awww! Predictable tabbing in forms. Awww! Pausing subscriptions.
Awww! Helpful error messages. Awww! Transparent pricing.
fi
↬ Grønland – Color Picker Microinteraction, Mykolas Puodžiūnas
https://dribbble.com/shots/3202469-Gr-nland-Color-Picker-Microinteraction
Inclusive design

Mental Health
People with di cult experiences
often feel vulnerable. They need
to be genuinely listened and
responded to, and they need a
clear route to anonymity.
ffi
 In nite Scroll

Usability Issues
01 — Overwhelming, di cult to manage
02 — High abandonment rates
03 — Hard to spot “new” and “old”
04 — URL in the address bar often broken
05 — Can’t bookmark a location
06 — Hard to reach the footer
07 — Breaks the scroll bar
08 — Accessibility issues
09 — Performance issues
fi
ffi
 Loading
Behavior
Pagination is the most popular,
and the slowest solution. Users
browse signi cantly less, and
often feel “slowed down”. But:
users spend more time on the rst
page and use lters/sorting more.
fi
fi
fi
Loading
Behavior
Load more pattern works best
across mobile and desktop. Gives
users control, all items on a single
page, footer is reachable. Users
browse more, and focus on single
items, often scrolling up/down.
 Loading
Behavior
In nite scroll is the most over-
whelming option. Users often dive
into exploration mode, scan fast,
and focus less on single items.
Loading of products often feels
like “out of control”, footer issues.
fi
eCommerce UX

Scrollbar Range Intervals

With soft-boundaries in mind, customers
tend to either use“scroll and sort” to scroll
down to the boundaries of interest, or
“paginate ahead”. It takes time, and often
requires unprecise “swoosh”-scrolling.
eCommerce UX

Scrollbar Range Intervals

We show users’s current position in
the range, and the exact position they
can jump to. Useful only if the user
changes the default sorting type.
 Design Patterns For Mental Health
https://designpatternsformentalhealth.org
 Plain Language Guidelines
https://www.plainlanguage.gov/guidelines/
↬ Neurodiversity Design System, Will Soward, https://neurodiversity.design
Inclusive design

Designing For
Neurodiversity
 Inclusive design

Neurodiversity
Refers to a wide range of
di erences in how people think —
similar to diversity in ethnicity,
gender, sexuality etc. For traits
associated with many diagnoses.
ff
Intuit Content Design System
https://contentdesign.intuit.com/
Inclusive design

Dyscalculia
3–10% of people have dyscalculia,
but many are unaware of that. It’s a
persistent, life-long di culty in
understanding numbers.
ffi
 Inclusive design

Dyscalculia
Di culty to read and spot patterns
in numbers. Can be hard to tell
apart numbers/letters: 7/L, 0/O.
Struggle with time blindness,
managing nances, planning.
ffi
fi
 Inclusive Design

Living With Dyscalculia

01 — Hard to plan and estimate time/costs
02 — Hard to spot mistakes in bills/receipts
03 — Cooking is tricky because of quantities
04 — Medicine dosage requires a lot of attention
05 — Distances for objects are hard to gauge
06 — Di cult to read and tell times/time tables
07 — Di culty in arranging appointments
08 — Hard to hold numbers in memory
09 — Hard to remember PINs, birthdays, scores
10 — Also phone numbers and directions
11 — Count zeros to understand how big number is
12 — Poor spatial skills (graphs, tables, North/South, left/right)
ffi
ffi
Inclusive Design

UX Guidelines For Dyscalculia

What to avoid What to use
01 — Don’t use decimals unless you must 01 — Leave space around numbers
02 — Don’t ask to repeat/remember numbers 02 — Support spaces when typing numbers
03 — Countdowns and frequent lock-outs 03 — Support copy/paste into forms
04 — Don’t require numbers as only option 04 — Show how to nd a reference number
05 — Sequencing: “1 or 2 200mg tablets” 05 — “One or two 200mg tablets”
06 — Poor formatting: “1993,38” or “.5mg” 06 — “1,993.38” and “0.5mg”
07 — Mixing numbers: “3–4+ teaspoons” 07 — “At least 3 to 4 teaspoons”
08 — Review superscript: “1st” and “2nd” 08 — “1st” and “2nd”, same letter size
09 — Spaces for units: “12 mg”, “100 kcal” 09 — “12mg”, “100kcal”, “38C”
10 — Avoid shortened months: “Jan”, “Feb” 10 — “January”, “February”
11 — Fractions are tricky: “14.3%” 11 — Better: “1 in 7 people”
fi
↬ Tina Roth Eisenberg, https://twitter.com/swissmiss/status/1305268698840788992
 Accessible Numbers
https://accessiblenumbers.com
Inclusive design

Dyslexia
Around 6–10% of population have
some sort of dyslexia. It’s a condition
involving di culties with writing or
typing, reduced reading experience,
word recognition, spelling, decoding.
ffi
 Inclusive design

Dyslexia
People with dyslexia are more likely to
nd most important details hidden in
a sea of data. There aren’t di erent
types of dyslexia — it’s one thing and
everyone is on a continuum.
fi
ff
Inclusive design

Neurodiversity
People with neurodiversity have
sensory experiences, unique ways of
social interaction, problem-solving,
“uneven” skill pro les.
fi
↬ Neurodiversity Design System, https://neurodiversity.design/principles/font/
↬ Neurodiversity Design System, https://neurodiversity.design/principles/font/
 Inclusive Design

Living With Dyslexia

01 — Di cult to follow sequential instructions
02 — Struggle with spelling and writing
03 — Trouble with scheduling and time management
04 — Challenges in expressing ideas verbally
05 — Heavily distracted by ashing images or sounds
06 — Challenges in organizing thoughts/materials
07 — Di culty in lling out forms accurately
08 — Trouble following rules in games and at workspace
09 — Hard to understand abstract concepts (idioms)
10 — Hard to understand subtle social cues
11 — Di culty with reading signs or labelsqu
12 — Poor spatial skills (graphs, tables, North/South, left/right)
ffi
ffi
ffi
fi
fl
 Designing For Users With Dyslexia
https://ukhomeoffice.github.io/accessibility-posters/
 Inclusive design

Autism
Nearly 1% of population has
autism. It’s not a sickness, but a
di erent way of experiencing the
world. Autistic children grow up
into autistic adults. No two people
with autism are the same.
ff
Inclusive Design

Living With Autism

01 — Experience life in constant chaos, like rollercoaster
02 — Usually quite intense and tangled
03 — Low tolerance to uncertainty and lack of control
04 — Highly sensitive to bright colors and high contrasts
05 — Highly sensitive to cold/hot, skin, loud music/sounds
06 — Trust people as they want to see the best in others
07 — Often prefer quiet, nature sounds, instead of conversations
08 — Might feel overwhelmed in a crowded setting
09 — Extraordinary level of concentration for things loved
10 — Can be very literal and direct in conversations
11 — Unique in problem solving and ideation
↬ The Problem With Tooltips, Adam Silver, https://adamsilver.io/blog/the-problem-with-tooltips-and-what-to-do-instead/
 Adam Silver on

Tooltips Often Unnecessary

“ Tooltips have their issues as well. They

are hard to spot and take extra e ort, but
most important they are often
inaccessible and block out the UI.

Adam Silver, design lead at Gov.uk

ff
↬ The Problem With Tooltips, Adam Silver, https://adamsilver.io/blog/the-problem-with-tooltips-and-what-to-do-instead/
↬ Designing Better Tooltips for Mobile, Eric Olive, https://www.smashingmagazine.com/2021/02/designing-tooltips-mobile-user-interfaces/
↬ Designing Better Tooltips for Mobile, Eric Olive, https://www.smashingmagazine.com/2021/02/designing-tooltips-mobile-user-interfaces/
↬ Designing Better Tooltips for Mobile, Eric Olive, https://www.smashingmagazine.com/2021/02/designing-tooltips-mobile-user-interfaces/
↬ Designing Better Tooltips for Mobile, Eric Olive, https://www.smashingmagazine.com/2021/02/designing-tooltips-mobile-user-interfaces/
Better Tooltips

If possible, try to avoid covering input

with a displayed tooltip. For example,
with a slide-in or conditional reveal. Both
qestion mark and “info” icons work well.
Tooltips Best Practices

Focus Management
Most of the time, it’s a good idea to leave
focus order alone if we use <button> for
buttons, <input> for inputs and <a> for links.
No need to apply tabindex to interactive
elements that can receive keyboard focus,
and not for non-interactive elements.
Note on tooltips

tabindex
tabindex allows an element to be focused. It
accepts an integer as a value. It’s never a
good idea to use a positive integer value as it
will override the expected tab order, causing
disorienting experiences.
Note on tooltips

tabindex="-1"
We can use tabindex="-1" for focusing
with JavaScript. It will make an element
focusable via JavaScript or click/tap.
These elements are removed from the
tab sequence, but can still received
keyboard focus programatically.
Note on tooltips

Focus Trapping & Mechanics

01 — Determine the container elements of all focusable elements.

02 — Set the bounds of the trapped content, rst/last focusable item.

03 — Remove interactivity from focusable items outside the trap.

04 — Move focus into the trapped content (tabindex=“-1”).

05 — Listen for events that signals dismissing the trapped content

(save, cancel, dismissal/hitting the Esc key, etc.).

06 — Dismiss the trapped content area when triggered.

07 — Restore previously removed interactivity.

08 — Move focus back to the interactive element that triggered trap.

09 — Common for: dropdowns, layers, view changes, loading screens.

fi
Default Tooltip
01 — Avoid if possible.
02 — Requires focus trapping.
03 — Doesn’t cover input.
04 — Displayed as a slide-in block.
05 — Can be dismissed or collapsed.
06 — Visible within the viewport.
07 — Doesn’t require scrolling.
Modal Dialogs
Modals move the system into a special
mode requiring user interaction. That
means that users have to leave everything
and focus entirely on resolving the issue.
Similar to phone calls, alarm clocks or cats.

via Therese Fessenden, Modal & Nonmodal Dialogs, Nielsen Normal Group
↬ Onboarding, https://dribbble.com/shots/3546996-Onboarding-Art-Direction/attachments/788404
↬ Best Practices for Modals, Naema Baskanderi, https://uxplanet.org/best-practices-for-modals-overlays-dialog-windows
Modals Are Disruptive
Disruptions of users focused on a
task often lead to forgetting the as-
left conditions (45%), forgetting to
return to the original task (25%)
and slowdown of task completion.

Fergus I. M. Craik, E ects of distraction on memory and cognition, 2014

ff
Disruption Is Expensive
When interrupted, users need 3–27% more
time to complete tasks, they commit 2× the
number of errors across tasks, and have 2×
the increase in anxiety compared to tasks
presented at the boundary between tasks.

Brian P. Bailey, Joseph A. Konstan, “On the need for attention-aware systems”, 2006
Disruption Is Expensive
Because modal windows require
immediate attention, they interrupt
user’s work ow, cause users to lose
their train of thought and block the
content located in the background.

via Therese Fessenden, Modal & Nonmodal Dialogs, Nielsen Normal Group
fl
Modal Dialogs
Modals move the system into a special
mode requiring user interaction. That
means that users have to leave everything
and focus entirely on resolving the issue.
Similar to phone calls, alarm clocks or cats.

via Therese Fessenden, Modal & Nonmodal Dialogs, Nielsen Normal Group
↬ Enterprise Design: Dialogs, James Jacobs, /modern-enterprise-ui-design-part-2-modal-dialogs @ Medium
↬ Enterprise Design: Dialogs, James Jacobs, /modern-enterprise-ui-design-part-2-modal-dialogs @ Medium
↬ Enterprise Design: Dialogs, James Jacobs, /modern-enterprise-ui-design-part-2-modal-dialogs @ Medium
↬ Enterprise Design: Dialogs, James Jacobs, /modern-enterprise-ui-design-part-2-modal-dialogs @ Medium
Not All Modals Are Equal
Modals allow users to maintain multiple
contexts at the same time: perform related
actions without interrupting current state
on the main page. They are useful when
sending users to another page is disruptive.

James Jacobs, Modern Enterprise UI Design: Modal Dialogs

↬ Enterprise Design: Dialogs, James Jacobs, /modern-enterprise-ui-design-part-2-modal-dialogs @ Medium
↬ Enterprise Design: Dialogs, James Jacobs, /modern-enterprise-ui-design-part-2-modal-dialogs @ Medium
Avoid Auto-Triggered Modals
In general, users don’t show much annoyance
with self-initiated modals, but they gey very
frustrated with any kind of auto-triggered
modals. But if a modal helps users avoid
critical mistakes, they nd them acceptable.
fi
Avoid Auto-Triggered Modals
Ideally, modals would always be
triggered by user interaction. If they
appear on their own, users are likely to
close them before they even have a
chance to understand what they are.
 Navigation UX

Modals Use Cases

Use Avoid
01 — Only if users will value the disruption 01 — Newsletter box pop-ups
02 — If a modal is speci c for a task at hand 02 — Feature noti cations
03 — For repeatable tasks (adding new items) 03 — Onboarding modals
04 — To reveal more details (quick view) 04 — Auto-triggered modals
05 — To display important warnings 05 — Modals with unrelated tasks
06 — If you need immediate user input 06 — Displaying large amount of data
07 — To con rm a destructive action 07 — Displaying error messages
08 — To avoid irreversible mistakes/errors 08 — Displaying nested modals
09 — To prevent critical transactions/data loss 09 — For complex, multi-step-tasks
10 — To verify and review complex input 09 — During important ows (e.g. checkout)
fi
fi
fi
fl
 eCommerce UX

Gathering Quality Emails (eComm)

Use Avoid
01 — Friendly messaging, respectful tone. 01 — Pop-ups displayed on rst load.
02 — Add newsletter box on the product page. 02 — Pop-ups on the homepage.
03 — Add newsletter box on the sales page. 03 — Pop-ups on category pages.
04 — Add newsletter box on con rmation page. 04 — Pop-ups on support pages.
05 — Customize messaging for each page. 05 — Pop-ups on search results pages.
06 — De ne the messaging activation matrix. 06 — Pop-ups in critical ows (e.g. checkout).
07 — Provide a helpful PDF, guide, eBook etc. 07 — Blocking the rest of the UI.
08 — Use a collapsible modal, not a pop-up. 08 — Flashy, noisy animations.
09 — Show modals on 2nd/3rd product pages. 09 — Disabled copy-pate.
10 — Always build trust and deliver value rst. 10 — Clock countdowns & con rmshaming.
fi
fl
fi
fi
fi
fi
↬ Modal/Nonmodal Dialogs, Therese Fessenden, https://www.nngroup.com/articles/modal-nonmodal-dialog/
↬ Haufe Lexware Business Cockpit, https://shop.lexware.de/persoenliche- nanzen
fi
Modals & Popovers

Focus Management
Most of the time, it’s a good idea to leave
focus order alone if we use <button> for
buttons, <input> for inputs and <a> for links.
No need to apply tabindex to interactive
elements that can receive keyboard focus,
and not for non-interactive elements.
Accessibility Strategy

Focus Trapping & Mechanics

01 — Determine the container elements of all focusable elements.

02 — Set the bounds of the trapped content, rst/last focusable item.

03 — Remove interactivity from focusable items outside the trap.

04 — Move focus into the trapped content (tabindex=“-1”).

05 — Listen for events that signals dismissing the trapped content

(save, cancel, dismissal/hitting the Esc key, etc.).

06 — Dismiss the trapped content area when triggered.

07 — Restore previously removed interactivity.

08 — Move focus back to the interactive element that triggered trap.

09 — Common for: dropdowns, layers, view changes, loading screens.

fi
↬ The Problem With Tooltips, Adam Silver, https://adamsilver.io/blog/the-problem-with-tooltips-and-what-to-do-instead/
↬ The Problem With Tooltips, Adam Silver, https://adamsilver.io/blog/the-problem-with-tooltips-and-what-to-do-instead/
↬ The Problem With Tooltips, Adam Silver, https://adamsilver.io/blog/the-problem-with-tooltips-and-what-to-do-instead/
↬ The Problem With Tooltips, Adam Silver, https://adamsilver.io/blog/the-problem-with-tooltips-and-what-to-do-instead/
↬ The Problem With Tooltips, Adam Silver, https://adamsilver.io/blog/the-problem-with-tooltips-and-what-to-do-instead/
↬ The Problem With Tooltips, Adam Silver, https://adamsilver.io/blog/the-problem-with-tooltips-and-what-to-do-instead/
 Adam Silver on

Tooltips Often Unnecessary

“ Tooltips have their issues as well. They

are hard to spot and take extra e ort, but
most important they are often
inaccessible and block out the UI.

Adam Silver, design lead at Gov.uk

ff
Modals UX

Modals Design Checklist

01 — Where do we need to use any dialog prompts?
02 — Can we prevent critical errors with inline validation rather than a modal?
03 — When do we need to warn the user or prevent critical errors (modal)?
04 — When do we absolutely need user input to continue (modal)?
05 — When do we want to support or inform the user (overlays, pop-overs)?
06 — When are we legally obliged to ask for consent (cookie prompts, age verif.)?
07 — Do we want to advertise to users (ads, surveys, etc.) (no modal, inline box)?
08 — When do we absolutely need to interrupt the user (modal)?
09 — If we do interrupt, are we certain that users will value that disruption?
10 —When is the right time for the modal to appear to get a positive response?
11 — Do we show prompts on success moments (completed task, new paycheck)?
Modals UX

Modals Design Checklist

12 — Do we avoid showing errors as a modal window?
13 — Do we avoid asking for feedback or rating as a modal window?
14 — Do we want to use a modal to display a loading message/indicator?
15 — Do we want to use a modal for larger images or image galleries?
16 — Do we want to use a modal for video content?
17 — Do we want to use a modal for cookie pop-ups?
18 — Do we want to use a modal for critical noti cations?
19 — Do we want to use a modal to con rm an intent (deactivate, delete, restore)?
20 — Do we want to use a modal to bring user attention to important details?
21 — Do we want to use a modal to verify the correctness of user input?
22 — Can we avoid opening modals automatically?
fi
fi
Modals UX

Modals Design Checklist

23 — Do we never interrupt users with non-critical requests or details?
24 — Do we never interrupt users when they perform critical, focused tasks?
25 — Do we never show a modal before the page nishes loading?
26 — Do we never show a modal when a user has just logged in?
27 — Do we avoid modals that try to keep users from leaving the page?
28 — When do we want to dim the background (modal, lightbox)?
29 — When can the main content coexist with the dialog (overlay)?
30 — On opening, is a modal always in sight/ t the screen (desktop/mobile)?
31 — How much space do the modals take up on mobile/desktop (<75% / <30%)?
32 — Do we show lengthier modals as full-page overlays/pop-overs on mobile?
33 — Do we avoid scrollbars or scrollable areas within the modal?
fi
fi
Modals UX

Modals Design Checklist

34 — On opening, is it clear that a modal is separate from the rest of the UI?
35 — On opening, does a modal receive keyboard focus?
36 — Is tabbing through links and controls in the modal window possible?
37 — Do we have a focus-trapping mechanism built in?
38 — Does the title of the modal match the CTA on the button that triggers it?
39 — Can we use an icon/color to indicate the nature and purpose of the modal?
40 — How do we arrange the buttons: [primary] [secondary], or vice versa?
41 — Do we have actionable labels on buttons?
42 — Is it always possible to dismiss a modal, or are some modals blocking?
43 — Do we have a high-contrast “Close” button in the top-right corner?
44 — Do we want to add an additional “Dismiss” link at the bottom of the modal?
Modals UX

Modals Design Checklist

45 — Can users escape every modal with the Esc key?
46 — Can users escape every modal with “Close” or ”Dismiss” links?
47 — Can users escape every modal by clicking outside of the modal?
48 — Do we verify user’s intent to leave the modal if they’ve already entered data?
49 — Do we provide an option to undo the action or restore the previous state?
50 — Do we avoid nested modals?
51 — Do we avoid multiple modals appearing consecutively?
52 — Do we avoid lengthy multistep modals (more than 5 steps)?
53 — If we do use a multistep modal, do we provide navigation between the steps?
54 — Do we group critical noti cations in one prompt, rather than multiple ones?
55 — What exactly happens if the user doesn’t act on the modal but closes it?
fi
Modals UX

Modals Design Checklist

56 — What happens if a modal is fully blocked by the browser/extension?
57 — Do we measure how many people act on the modal, and how many dismiss it?
58 — Can we test the alternatives: separate page, injected content, or accordions?
Modal Dialogs
When it comes to modal dialogs,
consider this: no one likes to be
interrupted, but if you must, make
sure it’s worth the cost.

via Therese Fessenden, Modal & Nonmodal Dialogs, Nielsen Normal Group
Modals

Summary
01 — Modals should be mostly triggered by user interaction.

02 — Include semi-transparent background overlay.

03 — Nonmodals allow users to stay focused on the task.

04 — Provide obvious ways to close (large X, ESC, click out).

05 — Useful to con rm a destructive action or complex input.

06 — Useful to avoid an irreversible error/action.

07 — Useful when we absolutely need user input.

08 — Ideal for repeatable tasks and only for critical activities.

09 — Avoid for non-critical tasks as they will be dismissed.

fi
Inclusive design

ADHD
Attention-De cit/Hyperactivity
Disorder a ects 5% of children,
2.5% of adults. Shows in
forgetfulness, time-blindness,
impulsivity, hyperactivity.
ff
fi
Inclusive Design

Living With ADHD

01 — Easily forget details, insights, tasks, actions
02 — Seek novelty, not routine (unlike autism)
03 — Poor focus and attention for boring tasks
04 — Chase attention and excitement non-stop
05 — Have trouble sitting still, racing thoughts
06 — Easy to come up with ideas, hard to execute them
07 — Routine tasks are very di cult to execute
08 — Hard to handle unstructured situations
09 — Hard to listen to others while holding a thought
10 — Often don’t remember where things are
ffi
Inclusive Design

UX Guidelines For ADHD

What to avoid What to use
01 — Large number of options all at once 01 — Ask to prepare docs ahead of time
02 — Don’t ask to repeat/remember numbers 02 — Ask what the goal is upfront
03 — Countdowns and frequent lock-outs 03 — One-thing-at-a-time works best
04 — Avoid auto-playing videos/animations 04 — Remind of key events, un nished drafts
05 — Poor performance → abandonment 05 — Show recent les, used lters/presets
06 — Long, unstructured text paragraphs 06 — Reduce lock-outs and log outs
07 — Poor scannability for content 07 — Chunk everything, continue later
07 — Painful and strict password recovery 08 — Show progress, and never break it
09 — More simpler pages, not 1 long page
10 — Disclose details, options gradually
fi
fi
fi
Search UX

User Behavior in Search

Users don’t always process search
results sequentially. They distribute
their attention more variably across
the page. They bounce between results
and SERP features (pinball pattern).

via Kate Moran, Cami Goray, The Pinball Pattern

↬ Pinball Pattern, Kate Moran, Cami Goray, https://www.nngroup.com/articles/pinball-pattern-search-behavior/
Search UX

User Behavior in Search

Scanning is partial attention. Reading
is focused attention. Screen without
intentional rhythm will lose attention
as it is being scanned. Length is not
the problem — lack of rhythm is.

via Christopher Butler, The Rhythm of Your Screen

Search UX

User Behavior in Search

More people have been to the Mount
Everest than page 10 of Google’s
search results. Focus on top results
and measure their quality repeatedly.

via Gerry McGovern

User Behavior For Search
01 — Users don’t always explore results sequentially.
02 — Top search result often gets around 30% of all clicks.
03 — Top 3 search results get around 60% of all clicks.
04 — Results near the top have 10–20% chance of a click.
05 — Results near the top have 40–80% chance of being seen.
06 — Scoped search gets results faster, but users often overlook it.
07 — Users need visited search results to be marked as such.
08 — They often navigate autocomplete suggestions with keyboard.
09 — They rarely select exactly one
lter when searching.
10 — They make an impression about all results based on top 10 results.
fi
Inclusive Design

Navigation Queries
We could give users an option to
construct their own navigation query
with a set of straightforward selections.
An additional navigation layer for the
main navigation and search.
↬ Marcin Ignac, https://twitter.com/marcinignac/status/1400806180797231104
↬ Marcin Ignac, https://twitter.com/marcinignac/status/1400806180797231104
Inclusive Design

Skip Search Results

Help users jump straight to relevant
results, rather than search results.
Show categories, pages, media les,
instead of keywords suggestions.

fi
↬ Statistics Estonia, https://www.stat.ee/en
Adam Silver on

Task List Pattern

We can reduce complexity by framing long
forms into a series of tasks necessary to
complete the form. Each of this tasks
lives on a separate page. It makes the
process much more manageable.

Adam Silver, Gov.uk

↬ Task List Pattern, Gov.uk, https://design-system.service.gov.uk/patterns/task-list-pages/
Adam Silver on

Task List Pattern

For long-winded forms, set the right
expectations early. Before users start, tell
them if a) they are eligible, b) what the
process involves, c) how long each step
takes and d) what documents they’ll need.

Adam Silver, Gov.uk

Adam Silver on

Task List Pattern

Alternatively, we could ask users a few
questions, so they can gure out if a
product/service is eligible to them.
fi
↬ Task List Pattern, Gov.uk, https://design-system.service.gov.uk/patterns/task-list-pages/
↬ Task List Pattern, Gov.uk, https://design-system.service.gov.uk/patterns/task-list-pages/
↬ Task List Pattern, Gov.uk, https://design-system.service.gov.uk/patterns/task-list-pages/
↬ Task List Pattern, Gov.uk, https://github.com/alphagov/govuk-design-system-backlog/issues/72
↬ Coinbase, https://www.coinbase.com/
 Issues With Progress Indicators
01 — With the task list pattern, progress indicators aren’t needed.
01 — Some users are confused about how they work.
02 — Some users are intimidated when seeing them.
04 — Some users don’t notice them.
05 — They do not scale well on smaller screens.
06 — It’s di cult to make them work with longer labels.
07 — It’s di cult to handle conditional sections.
08 — If extra sections are needed, we need to inform users about them.
09 — Include the total number of sections (= pages).
10 — Explain what users need and how long it will take to complete.
ffi
ffi
Adam Silver on

Task List Pattern

01 — For complex forms, break down the journey into small tasks.
02 — Put tasks in a sensible order and use verbs to describe them.
03 — A task list is a page on its own, with a permanent URL.
04 — Update the URL when moving between subpages.
05 — Tell users what they need before they start (documents, time).
06 — Pick statuses each task might have, mark them for each task.
07 — If some tasks depend on others, explain it with statuses.
08 — Works well if multiple people ll in a long, complex form.
09 — For complex forms, let users save their progress and nish later.
fi
fi
Modals & Popovers

Cancel UX
Users need Cancel when they fear that
they’ve committed to something they
want to avoid. Best strategy is to
calibrate expectations with clear end
explicit labels — not the “X” icon.
↬ Cancel vs. Close UX, Aurora Harley, https://www.nngroup.com/articles/cancel-vs-close/
↬ Cancel vs. Close UX, Aurora Harley, https://www.nngroup.com/articles/cancel-vs-close/
↬ Cancel vs. Close UX, Aurora Harley, https://www.nngroup.com/articles/cancel-vs-close/
↬ Cancel vs. Close UX, Aurora Harley, https://www.nngroup.com/articles/cancel-vs-close/
↬ Clearing Input Fields, Jens Brandt
 ↬ Pattern y Design System, https://www.pattern y.org/2022.05/guidelines/ lters/
fl
fl
fi
Modals & Popovers

Reset vs. Cancel UX

Reset clears user’s current input, but
Cancel undoes the entire process.
Adding both is often a source of
confusion. Better: “Clear lters” and
“Cancel entire application”.
fi
Modals & Popovers

Cancel UX
Add Cancel Things To Note
01 — Especially for complex multi-step dialogs. 01 — Nothing is more ambiguous than X.
02 — When exiting the page doesn’t clear input. 02 — X can mean Cancel, Close, Ignore.
03 — When all data is automatically saved. 03 — Or also: Save, Back, Delete, Reset.
04 — To cancel radios/dropdown selections. 04 — Make destructive buttons hard to nd.
05 — Link if Cancel dismisses a modal. 05 — Explain what happens to data/settings.
06 — Button if it reverts a process or changes. 06 — Close large overlays with Back button.
07 — Explicit and clear labels work best. 07 — Avoid pre-selected radio buttons.
08 —“Apply and Continue”, “Close and Dismiss”. 08 — Add an option “None of the above”.
09 — Use con rm prompts to avoid data loss. 09 — Add Reset if users often restore defaults.
10 — On mobile, put a primary button last. 10 — …or they ll in the same form repeatedly.
fi
fi
fi
↬ Where To Place Buttons In Forms, Adam Silver, https://adamsilver.io/blog/where-to-put-buttons-on-forms/
↬ Improving Usability of Multi-Select, Zina Szőgyényi, https://medium.com/tripaneer-techblog/improving-the-usability-of-multi-selecting
Modals & Popovers

Multi-Select In Long Lists

Multi-Select Pills work when users are
familiar with the content of the list, or
know what they are looking for. If not, it
might cause 100% abandonment.
↬ Improving Usability of Multi-Select, Zina Szőgyényi, https://medium.com/tripaneer-techblog/improving-the-usability-of-multi-selecting
↬ Improving Usability of Multi-Select, Zina Szőgyényi, https://medium.com/tripaneer-techblog/improving-the-usability-of-multi-selecting
↬ Improving Usability of Multi-Select, Zina Szőgyényi, https://medium.com/tripaneer-techblog/improving-the-usability-of-multi-selecting
 Modals & Popovers

Con rm vs. Undo

Users need guardrails to prevent
critical mistakes. Con rm veri es user’s
intent to perform an action. Undo trust
users to do the right thing and reverse
later if needed.
fi
fi
fi
 Adam Silver on

Con rm vs. Undo

“ For critical actions, e.g. deleting an item, we

might need to provide an option to con rm
before the action is made, and undo once it
has been made. Di cult for repetitive tasks,
so we need to track how often it’s used.

“Form Design Patterns”, published by Smashing Magazine

fi
ffi
fi
 Jakub Linowski on

Con rm vs. Undo

“ Con rmation prompts question user’s intent

and are often con rmed instinctively, while
undos respect the initial intent by allowing
the action to happen smoothly rst, and
recover from mistakes quickly and easily.

GoodUI.org
fi
fi
fi
fi
 Alan Cooper on

Con rm vs. Undo

“ For con rmation dialog boxes to work, they

must only appear when a user will almost
de nitely click the “No” or “Cancel” button,
and they should never appear when a user is
likely to click the “Yes” or “OK” button.

“About Face”
fi
fi
fi
 Modals & Popovers

Con rm vs. Undo

Choice depends on frequency of use and
also level of severity. Con rm works for
rare mistakes and high impact. Undo
works for low impact but high frequency.
fi
fi
 Modals & Popovers

Con rm vs. Undo

Con rmation Types Things To Note
01 — Low impact, high freq -> No con rm. 01 — Users often instinctively Con rm.
02 — High impact, low freq -> Con rm + Undo. 02 — Users often overlook Undo.
03 — Max impact, low freq -> Type to con rm. 03 — Avoid ambiguity: Yes, Con rm, Cancel.
04 — Undo: mostly any impact + any frequency. 04 — Avoid double negatives: cancel “Cancel”.
05 — Only few user actions are irreversible. 05 — Better: Stay, Leave, Quit, Delete.
06 — Treat Undo as a general default behavior. 06 — Irreversible: add Forever, Permanently.
07 — Delay critical actions if you can’t undo them. 07 — Ask to type to prevent instinctive clicks.
08 — Low severity: Moving folders. 08 — Don’t show “Undo” as fading toasts.
09 — Medium severity: Re-arranging les. 09 — An “Undo” button often works better.
10 — High severity: Deleting entire project. 10 — Always test wording on Undo/Con rm.
fi
fi
fi
fi
fi
fi
fi
fi
fi
 Designing For Users On The Autistic Spectrum
https://ukhomeoffice.github.io/accessibility-posters/
Inclusive Design

Deafness,
Blindness
Inclusive design

Deafness
466 million people have some
kind of deafness. About 90–95%
of deaf people come from hearing
families — often occurs due to
exposure to loud noises, emerges
with age, disease, accidents.
↬ UX Design Collective, https://uxdesign.cc/a-guide-to-the-visual-language-of-closed-captions-and-subtitles-2fda5fa2a325
Captioning UX

Captioning
01 — Subtitles
02 — Voiceover
03 — Closed captions [CC]
04 — Open captions Captions are on-screen text
05 — Transcripts
descriptions — used to describe
06 — Audio description
07 — On-screen text
audio content on video.
08 — Auto-generated captions
09 — Auto-generated chapters
10 — Video chapters design
11 — Search and time stamps
12 — Video player UX
↬ European Parliament: Multimedia Centre, https://multimedia.europarl.europa.eu/en
↬ European Parliament: Multimedia Centre, https://multimedia.europarl.europa.eu/en
↬ European Parliament: Multimedia Centre, https://multimedia.europarl.europa.eu/en
Captioning UX

User’s Environment
Captions are used not just in busy
and noisy environments — also in
video content, social media, real-time
communication, games, courses.
Captioning UX

User’s Environment
Captions are the only way to
consume audio for viewers who
are hard of hearing — permanently
or temporarily.
Captioning UX

User’s Environment
Using Closed Captioning is often a
choice or preference, rather than
being caused by impairment or
restraints from using audio.
↬ America’s Subtitle Use, Preply, https://preply.com/en/blog/americas-subtitles-use/
↬ Inclusive Design Toolkit, https://www.microsoft.com/design/inclusive/
Captioning UX

Bene ts of Captioning
Contextual details Managing distractions
Sarcasm, synth voice, lyrics, Gym, multi-tasking, child care, public
background sound details. space, work space, lack of headphones.

Better understanding Courtesy to others

Strong accents, mumbling, Inclusive behavior toward sleeping
fast talking, unknown words. and focused partners, children, elderly.

Technical issues Life situations

Poor audio levels of voice vs. Barking and snoring pets, neighbours,
music, ability to share with text. easier memorability, easier to follow.
fi
↬ UX Design Collective, https://uxdesign.cc/a-guide-to-the-visual-language-of-closed-captions-and-subtitles-2fda5fa2a325
Captioning UX

Subtle Differences
Captions are part of accessibility.
Designed for people who are hard of
hearing to access aural information
with speaker IDs and sound desc.
Captioning UX

Subtle Differences
Audio description is also a part of
accessibility. Designed for people
with visual impairments to access
details about crucial visual elements
on the screen.
 ↬ Net ix, https://www.net ix.com
fl
fl
Captioning UX

Subtle Differences
Subtitles: part of internationalization.
Designed as a translation from one
spoken language to another written
language for hearing people. They aren’t
necessarily accessible.
Captioning UX

Subtle Differences
Open captions are “burnt” onto the
video and can’t be turned o .

Closed captions [CC] are text

descriptions on a separate track;
they can be turned on and o .
ff
ff
 Captioning UX

Rules of Captioning
The Pyramid pattern Full person’s ID on the same line
With 2 relatively equal parts Don’t break person’s identi cation
(40 ch top line, a bit less bottom line) details across multiple lines.

20–30 characters per sec Use meta textual indications

Any length beyond that make it — change of characters, [ ] voice-over,
di cult for content to be consumed. music, ( ) additional hints.

Sequence lasts 1–8 sec

Avoid lengthier sentences that stay
on screen for a longer period of time.
ffi
fi
↬ Subtitle Conventions, Gareth Ford Williams, https://uxdesign.cc/a-guide-to-the-visual-language-of-closed-captions-and-subtitles-2fda5fa2a325
↬ Captioning Key, https://dcmp.org/learn/captioningkey
Captions UX

Native Integration
Captions are often seen as an
additional layer on top of existing
audio and video. We could also
natively design and integrate it in
the viewing experience.
↬ Living Comic, Agung Tarumampen, https://www.cmd-amsterdam.nl/portfolio/living-comic-thanos-vs-iron-man/
Captions UX

Enable Search
With search, viewers could jump
to a speci c part of the video as
every sentence is linked to the
time stamp within the video.
fi
↬ TED, https://dcmp.org/learn/captioningkey
↬ TED, https://www.ted.com
↬ Zoom, https://www.zoom.us
Captions UX

Decouple Audio and CC

Not everyone prefers to read
captions in the same language as
the original video track. Sometimes
captions include detailed audio
desc only in some languages.
 ↬ Net ix, https://www.net ix.com
fl
fl
 ↬ Net ix, https://www.net ix.com
fl
fl
Captions UX

Customization Settings
Subtitles were never designed.
But some people need di erent
subtitles in terms of font size,
color or a typeface.
ff
↬ Amazon Prime Subtitles, https://www.amazon.com
 Captions UX

Position of Captions

“ Positioning subtitles below a video clip

in a web browser, rather than within
the video, leads to an increase in user
experience. This was mirrored in
conversations with 26 participants.

BBC, Online News Videos: The UX of Subtitle Position, 2015

Captions UX

Customization Settings
Enable users to change the font
and font size, choose presets for
display of captions, to relocate the
caption across the screen and a
setting to use captions by default.
↬ Best Practices for Closed Captioning, https://www.smashingmagazine.com/2023/01/closed-captions-subtitles-ux/
↬ European Parliament: Multimedia Centre, https://multimedia.europarl.europa.eu/en
↬ European Parliament: Multimedia Centre, https://multimedia.europarl.europa.eu/en
↬ European Parliament: Multimedia Centre, https://multimedia.europarl.europa.eu/en
↬ Multimedia Center Mock-up, by Christian Kuhrt
↬ Multimedia Center Mock-up, by Artem Shykov
↬ Multimedia Center Mock-up, by Artem Shykov
↬ Multimedia Center Mock-up, by Katharina Schönefeld
Captions UX

Summary
01 — Captions are often used by default (especially Gen Z).

02 — Subtitles are as translations for hearing people.

03 — Captions are for people who are hard of hearing.

04 — Audio descriptions are for people who are hard of seeing.

05 — Closed captions for video players, open captions for socials.

06 — Apply captioning guidelines to make reading comfortable.

07 — Flags aren’t languages: label languages locally.

08 — Consider native integrations and showing subtitles by default.

09 — Support search in transcripts and customization settings.

10 — Videos have high environmental costs: suggest audio-only option.

Inclusive Design

Designing For Deaf People

01 — Avoid stereotypes: “disabled” older adults with hearing aid.

02 — Some Deaf people see themselves as a cultural linguistic minority.

03 —To many, spoken language of their country is their second language.

04 — To communicate with a deaf person, always ask by writing down.

05 — Avoid “hearing impairment” when speaking about users who are deaf.
06 — Use the words Deaf (most of their lives) or deaf (later in life).

07 — Hard of hearing means some but not complete hearing loss.

08 — Deafness is a continuum: minor <-> moderate <-> profound.

09 — Don’t assume that every deaf person can lip read well.
Inclusive design

Screen Readers
253 million people worldwide have a
visual impairment. Screen readers help
them translate text to speech or Braille.
They use the same voice regardless of
font size, weight and color.
 Measuring UX

Accessible Usability Scale (AUS)

Similar to SUS, a 10-items-questionnaire
with ve response options; from Strongly
agree to Strongly disagree. An average
score is 65. One of the few statistically
reliable accessibility surveys.
fi
Inclusive design

Beware Of Accessibility Overlays

Overlays often end the conversation
about accessibility, before it even
begins. They in uence the UI layer, but
not the accessibility of content.

Ruben Ferreira Duarte, Front-End Engineer

fl
Inclusive design

Beware Of Accessibility Overlays

…With it, companies often see no need
to conduct any accessibility testing. The
product might be functional but di cult
to use. Or: it will entirely change and
break the functionality of your website.

Ruben Ferreira Duarte, Front-End Engineer

ffi
Inclusive design

Beware Of Accessibility Overlays

You don’t need a “permission” to build
accessible solutions. Many principles
are inherent to what we do anyway. Start
small with inclusive thinking early on.
Visualize accessibility with early testing.

Ruben Ferreira Duarte, Front-End Engineer

Inclusive design

Design Patterns
And Guidelines
Inclusive design

Accessible Forms
Mega-sites are usually extremely
large, many levels deep, are made of
many micro-websites and many sub-
sections, cater to many audiences and
have multiple entry points.
Single vs. Multiple Input Fields
In theory, we’d always ask users only for
their full name. But systems often require a
structured input, so asking with multiple
inputs is needed. In that case, Middle Name
should be optional, but not marked.
 I
r
I
f
a
fi
Single Field Works Best
A single name eld can accommodate
the broadest range of name types, but
means you cannot reliably extract
parts of a name.

Gov.uk, Name eld pattern, https://design-system.service.gov.uk/patterns/names/

fi
fi
 I
r
I
f
a
fi
 I
r
I
f
a
fi
 I
r
I
f
a
fi
 I
r
I
f
a
fi
 I
r
I
f
a
fi
 Name Input

01 — Ideally, one “Full name” text box.

02 — Otherwise broken by elds.
03 — Allow all chars (e.g. numbers).
04 — Accept browser’s auto ll.
05 — Spellcheck is o .
06 — Avoid asking for a title.
07 — For titles, use another text box.
ff
fi
fi
 Disabled Interfaces
Disabled state is an indicator that
something is wrong. Speci cally with
disabled buttons, users have more
con dence that there is a problem that’s
directly related to their input.
fi
fi
 Disabled States
When encountering a disabled button,
users rst slow down massively. Then they
search for error messages. Then they look
for the usual suspects — wrong formatting,
accent chars etc. Then they scan the entire
form, up and down, eld by eld.
fi
fi
fi
 Adam Silver on

Disabled Submit Buttons

“ Disabled buttons don’t explain what’s wrong.

Sometimes users are left wondering what’s
missing. They are not focusable and hard to
read as they are greyed out. With enabled
buttons we can better highlight all the errors.

“Form Design Patterns”, published by Smashing Magazine

Useful Disabled Buttons
Disabled buttons work when they help avoid
double bookings or wrong purchases. They also
work to validate magic sign-in code. Either way,
stop listening to click/tap after the rst click/
tap (except: “Undo” buttons/steppers). Also, add
a spinner and change text to “Processing…”.
fi
 Adam Silver on

Disabled Submit Buttons

“ To avoid double bookings, sometimes it might

seem right to disable a submit button on
submit. Instead, we can include a spinning
indicator, or change the text to “waiting”.
Provide A Way Out
With disabled buttons, some customers
will never be able to proceed — we can
give them a way out. Also, by clicking on
a link, they can choose to be contacted by
customer support.
Provide A Way Out
If something goes wrong, explain what’s
wrong in an error summary. Obviously,
this doesn’t a ect disabling a submit
button when the button is activated
(and should be activated only once).
ff
↬ Buttons — UI component series, Taras Bakusevych, https://uxdesign.cc/button-design-user-interface-components-series-85243b6736c7
Inclusive Disabled Buttons
01 — On hover, change the cursor to cursor: not-allowed.
02 — Always keep disabled buttons focusable.
03 — On focus/tap/click, explain why the button is disabled.
04 — We can show a tooltip or a text message on focus/tap/click.
05 — To avoid double bookings, add a spinner/change the wording on tap/click.
06 — Prevent double click programmatically via JS with aria-disabled.
07 — Use ARIA live regions to announce dynamic content.
08 — Avoid pointer-events: none as it won’t prevent focus/key nav.
09 — Guide the user to error summary, or to form errors directly.
10 — Provide a “way-out”-link under the disabled button.
11 — Allow customers to overrule errors and continue despite them.
12 — Keep the “Continue” button accessible and validate on submit.
13 — Consider replacing disabled buttons with more actionable alternatives.
Disabled Buttons

Summary
01 — Avoid disabled buttons if you can.

02 — If not, make them focusable and inclusive.

03 — Explain what exactly is wrong, and how to x it.

04 — Allow customers to proceed despite errors.

05 — Show error summary above the “Submit” button.

06 — Disable buttons to prevent critical mistakes.

07 — One way or the other, always provide a way out.

fi
Inclusive Disabled Buttons
01 — On hover, change the cursor to cursor: not-allowed.
02 — Always keep disabled buttons focusable.
03 — On focus/tap/click, explain why the button is disabled.
04 — We can show a tooltip or a text message on focus/tap/click.
05 — To avoid double bookings, add a spinner/change the wording on tap/click.
06 — Prevent double click programmatically via JS with aria-disabled.
07 — Use ARIA live regions to announce dynamic content.
08 — Avoid pointer-events: none as it won’t prevent focus/key nav.
09 — Guide the user to error summary, or to form errors directly.
10 — Provide a “way-out”-link under the disabled button.
11 — Allow customers to overrule errors and continue despite them.
12 — Keep the “Continue” button accessible and validate on submit.
13 — Consider replacing disabled buttons with more actionable alternatives.
↬ Microcopy for con rmation dialogues, Kinneret Yifrah, UXdesign Medium
fi
↬ Microcopy for con rmation dialogues, Kinneret Yifrah, UXdesign Medium
fi
↬ Microcopy for con rmation dialogues, Kinneret Yifrah, UXdesign Medium
fi
↬ Microcopy for con rmation dialogues, Kinneret Yifrah, UXdesign Medium
fi
 Adam Silver on

Con rm vs. Undo

“ For critical actions, e.g. deleting an item, we

might need to provide an option to con rm
before the action is made, and undo once it
has been made. Di cult for repetitive tasks,
so we need to track how often it’s used.

“Form Design Patterns”, published by Smashing Magazine

fi
ffi
fi
 Jakub Linowski on

Con rm vs. Undo

“ Con rmation prompts question user’s intent

and are often con rmed instinctively, while
undos respect the initial intent by allowing
the action to happen smoothly rst, and
recover from mistakes quickly and easily.

GoodUI.org
fi
fi
fi
fi
 Alan Cooper on

Con rm vs. Undo

“ For con rmation dialog boxes to work, they

must only appear when a user will almost
de nitely click the “No” or “Cancel” button,
and they should never appear when a user is
likely to click the “Yes” or “OK” button.

“About Face”
fi
fi
fi
Default buttons UX

Saving by Default

Save button might be unnecessary. We

should auto-save input anyway, “Close”
or X could mean “Save and close” , and
“Done” could mean “Save and exit”.
↬ Odoo, https://stackover ow.com/questions/49505146/how-to-remove-save-and-new-from-one2many-form-view-in-odoo-10
fl
↬ Cancel vs Close: Design to Distinguish the Difference, https://www.nngroup.com/articles/cancel-vs-close/
↬ Cancel vs Close: Design to Distinguish the Difference, https://www.nngroup.com/articles/cancel-vs-close/
Default buttons UX

Close and Cancel Buttons

X button might mean cancel or close. To

avoid confusion, ask users to con rm
their intention, use explicit text labels
instead of icons, or use Done/Close/Hide
for closing and Cancel/Clear for clearing.
fi
↬ Cancel vs Close: Design to Distinguish the Difference, https://www.nngroup.com/articles/cancel-vs-close/
↬ Cancel vs Close: Design to Distinguish the Difference, https://www.nngroup.com/articles/cancel-vs-close/
↬ Cancel vs Close: Design to Distinguish the Difference, https://www.nngroup.com/articles/cancel-vs-close/
↬ Cancel vs Close: Design to Distinguish the Difference, https://www.nngroup.com/articles/cancel-vs-close/
Inclusive design

Accessible Error Messages

Toasts are problematic. are usually
extremely large, many levels deep, are
made of many micro-websites and
many sub-sections, cater to many
audiences and have multiple entry
points.
Types of Errors
User error implies that the user is at
fault, but it’s rather a designer at fault
who is making it too easy for the user to
make a mistake. We need to design the
system to be less error-prone.

Page Laubheimer, Preventing User Errors, Nielsen Norman Group, 2015

Types of Errors
There are two types of errors. Slips occur
when users intend to perform one action,
but do another (e.g. on autopilot). Mistakes
occur when there is a mismatch between
the mental model of a user and the system.

Page Laubheimer, Preventing User Errors, Nielsen Norman Group, 2015

 Error Recovery
Slips (unconscious) Mistakes (conscious)
01 — Helpful constraints (date: 3 text boxes) 01 — Provide examples of correct input
02 — Recovery suggestions (ZIP autocorrect) 02 — Con rm a destructive action
03 — Good defaults (shipping = billing address) 03 — Warn before errors are made (ch count)
04 — Good presets (deposit type/amount) 04 — Forgiving formatting (phone number)
05 — Forgiving formatting (phone number) 05 — Set expectations early on ( le size)
06 — Be speci c what’s wrong (day, not year) 06 — Allow to change their mind (email)
07 — Verify and review complex input 07 — Always provide a way out
fi
fi
fi
Error Messages Are Disruptive
Disruptions of users focused on a
task often lead to forgetting the as-
left conditions (45%), forgetting to
return to the original task (25%)
and slowdown of task completion.

Fergus I. M. Craik, E ects of distraction on memory and cognition, 2014

ff
Disruption Is Expensive
When interrupted, users need 3–27% more
time to complete tasks, they commit 2× the
number of errors across tasks, and have 2×
the increase in anxiety compared to tasks
presented at the boundary between tasks.

Brian P. Bailey, Joseph A. Konstan, “On the need for attention-aware systems”, 2006
Web Forms UX

Error Messages
We show error messages to explain an
issue with the user input and guide users
to a solution. Both parts are important;
it’s not about telling users they are wrong,
but showing them how to get it right.
 American Press Institute on

Shorter Error Messages

“ Shorter sentences result in greater

understanding. If sentences contain
8 words or less, readers understand
100% of the information. With 43 words
or longer, the reader’s comprehension
drops to less than 10%.

American Press Institute, How to make your copy more readable

Accept All Formats
Always accept information in di erent
formats, as long as it’s not ambiguous.
Accept and automatically remove
spaces or invisible characters on user’s
behalf, e.g. when it’s copy-pasted.
ff
When Not To Accept
Validation shouldn’t accept
information that can’t be correct,
or is too ambiguous to use, or is
missing (if it’s required).
 Default Errors
01 — Always appear above the input.
02 — Mark the border of a wrong input.
03 — Show error summary at the top.
04 — Don’t explain that error occurred.
05 — Explain why the error happened.
06 — Style the error in red.
07 — Mark erroneous eld in red.
08 — No period at the end.
09 — Avoid generic messages.
fi
Default Errors
10 — No ‘syntax error’, ‘tech issue’.
11 — No ‘forbidden’, ‘illegal’, ‘not allowed’.
12 — No ‘you forgot’, ‘you made a mistake’.
13 — No dead-ends: ‘couldn’t be sent’.
14 — No blame: ‘you didn’t enter X.’
15 — No negatives: ‘failed’, ‘incompatible’.
16 — No uppercase or exclamation marks.
17 — No ‘valid’ or ‘invalid’: it doesn’t help.
18 — No ‘please’ or ‘sorry’: it doesn’t help.
 Default Errors
19 — Pre x “Error:” for screen reader users.
20 — Empty input: ‘Enter your [X]’.
21 — Too short: ‘[Y] must be at least…’.
22 — Too long: ‘[Y] must be at most…’
23 — Wrong chars: ‘[Y] must include…’
24 — Wrong type: ‘[Y] must be a number’.
25 — Format: ‘Enter [X] in a correct format’.
26 — ‘Select an option that applies to you.’
27 — ‘Select all options that apply to you.’
fi
 Default Errors
19 — Order errors by high priority.
20 — Auto-suggest correct input.
21 — More speci c is always better.
22 — Short, concise and actionable.
fi
 Luke Wroblewski on

Inline Validation

“ There are three types of inline validation:

premature validation (on input focus),
immediate validation (as a user types) and
late validation (user has left the eld, onblur).
They all interrupt users too early or too late.

“Inline Validation in Forms”, A List Apart

fi
 Adam Silver on

Input Order

“ An UI that relies on users doing things in a

speci c order is prone to error, and takes
control away unnecessarily. To validate
inline, we have to validate di erent elds at
di erent times. That often causes trouble.

“Live Validation is Problematic”, Adam Silver

ff
fi
ff
fi
 Inline Validation Issues
01 — Some people never look at the input eld when they type.
02 — A page often jumps with errors appearing/disappearing.
03 — Some elds can be validated immediately, others can not.
04 — Some input might be invalid even if it passes a validator.
05 — Switches between success/error states overwhelms screen readers.
06 — Validating on blur assumes a particular order of completion.
07 — Inline validation is never bulletproof.
fi
fi
 Mihael Konjević on

Inline Validation

“ There are three types of inline validation:

premature validation (on input focus),
immediate validation (as a user types) and
late validation (user has left the eld, onblur).
They all interrupt users too early or too late.

“Inline Validation in Forms: Designing The Experience”, Medium

fi
Mihael Konjević on

Reward Early, Punish Late

01 — For every input, set a min threshold of characters.

02 — Start validating only if that threshold is reached.

03 — If there is an error, show it immediately as you detect it.

04 — Show ‘success’ only if the the user has moved to the next eld.
05 — Editing a eld that was valid: validate after data entry.
06 — Editing a eld that was invalid: validate during data entry.

“Inline Validation in Forms: Designing The Experience”, Medium

https://medium.com/wdstack/inline-validation-in-forms-designing-the-experience-123 34088ce#. 86493cl
fi
fi
fb
fi
fl
Adam Silver on

Better Inline Validation

01 — Triggering errors while the user lls in a form is problematic.
02 — Avoid negative inline validation (e.g. email).

03 — Display positive inline validation (e.g. password).

04 — Avoid disabled “submit” buttons (with any validation).

05 — Validating forms on submit is the most reliable option.

06 — Always validate forms on the server as well.

07 — Display and focus on error summary at the top, linking to labels.

08 — Error messages should always appear above input elds.

08 — It’s a good idea to complement text msgs with warning icons.

“Web Forms Masterclass”, Adam Silver

fi
fi
Form Design Guidelines

When Inline Validation Works

Sometimes you might need inline validation:
e.g. to validate character count, VAT ID, magic
sign-in/SMS code etc. In such cases, inline
validation seems to be working, but test a
“Validate” button as well.
Form Design Guidelines

Inline Validation Isn’t Bulletproof

Sometimes you might need inline validation:
e.g. to validate character count, VAT ID, magic
sign-in/SMS code etc. In such cases, inline
validation seems to be working, but test a
“Validate” button as well.
When Live Validation Fails
01 — Too aggressive validators for address, phone number or email.
02 — Services requiring a non-Gmail email address.
03 — Input is optional, but empty strings don’t pass validation.
04 — Non-conforming or non-standardized TIN/VAT tax numbers.
05 — When anti-spam protection is blocked by an ad-blocker.
06 — When a tracking-blocker blocks a location input prompt.
07 — When the user doesn’t have all the data, but there is no “Save” button.
08 — When the UI is heavily tailored to a speci
c set of countries.
09 — When browser extensions (coupon codes) block the UI.
10 — We need to measure support inquiries caused by inline validation.
fi
 Avoid Error Msgs Under Fields
01 — Autocomplete features in browsers obscure them.
02 — On-screen keyboards can obscure them, too.
03 — Screen readers can announce them after the input.
04 — The messages might be out of view on narrow screens.
05 — They need to be complemented with an error summary on top.
06 — Pre x the word “Error:” to the document’s title.
07 — Style error messages in red and use a warning icon.
fi
↬ Illustrations by Jordan Moore, https://twitter.com/jordanmoore/status/1250026238762266624
↬ IBM’s Carbon Design System, https://www.carbondesignsystem.com/patterns/forms-pattern/
↬ Avoid Messages Under Fields, Adrian Roselli, https://adrianroselli.com/2017/01/avoid-messages-under- elds.html

fi
Form Design Guidelines

Better Error Messages

01 — Every message should drive user towards xing the error.
02 — It’s worth investing time in adaptive error messages.

03 — Upon submit, scroll the user to the label of the rst error.
04 — Display the error above the submit button on click.

05 — Display a summary of errors on the top.

06 — Display each error as a line on its own.

07 — Show the number of errors in the tab title as a pre x.

08 — To help x mistakes faster, use suggestions and buttons.
09 — Monitor error rates to track how often users experience errors.
fi
fi
fi
fi
Inclusive design

Accessible Copy-Paste
Toasts are problematic. are usually
extremely large, many levels deep, are
made of many micro-websites and
many sub-sections, cater to many
audiences and have multiple entry
points.
 I
r
I
f
a
fi
 I
r
I
f
a
fi
 I
r
I
f
a
fi
 I
r
I
f
a
fi
 I
r
I
f
a
fi
Auto-Masking Issues
Auto-masking makes it di cult to type a
number in a customer’s preferred way.
It’s also more di cult to copy-paste a
number from another place and verify it.
Also, masks need to be localized.
ffi
ffi
Auto-Masking Issues
Masks also need to be localized. There
are regional di erences in input
formatting and input structure for dates,
phone numbers, addresses etc. E.g. US:
MM/DD/YYYY, EU: DD/MM/YYYY,
Canada/Japan: YYYY/MM/DD.
ff
Separate Inputs Issues
Auto-masking makes it di cult to type a
number in a customer’s preferred way.
It’s also more di cult to copy-paste a
number from another place and verify it.
ffi
ffi
 I
r
I
f
a
fi
 Phone Input

01 — One single input eld.

02 — Accept browser’s auto ll.
03 — Accept hyphens, dashes, spaces.
03 — Accept brackets, periods, plus.
04 — Explain why phone is needed.
05 — No input masking.
06 — No auto-formatting.
fi
fi
 Phone Input Mask

01 — A feature for complex input.

02 — Separator is 1 empty space.
03 — We pre x “ xed” contents/units.
04 — We auto-format as users type.
05 — No punctuation autocorrect.
fi
fi
 I
r
I
f
a
fi
Error Messages
Do’s
01 — Empty input: “Enter your rst name”
02 — Too short: “ZIP code must be at least…”
03 — Too long: “Summary must be at most…”
04 — Wrong chars: “Policy ID must include…”
05 — Wrong type: “Policy ID must be a number”
06 — Format: “Enter date in the correct format”
07 — Radio: “Select an option that applies to you”
08 — Checkbox: “Select the options that apply to you”
09 — File: “The selected le must be PDF or JPG”
10 — T&C: “You must agree with T&C to proceed”
10 — Perspective: “We couldn’t gure out the expiry date”
fi
fi
fi
Error Messages
Don’ts
01 — No technical terms: “syntax error”, “tech issue”, “error”.
02 — No formal words: “forbidden”, “illegal”, “prohibited”.
03 — No blame: “you forgot”, “you entered a wrong date”.
04 — No dead-ends: “Your email could not be sent.”
05 — No negative words: “incorrect”, “incompatible”, “failed”.
06 — No uppercase or exclamation marks.
07 — No “valid”, “invalid”: they don’t add to the message
08 — No “please” or “sorry”: it isn’t helpful.
09 — Avoid generic errors; the more speci c, the better.
fi
Error Messages

Summary
01 — Make it more di cult for users to make mistakes.
02 — Consider di erent exceptions for every type of input.
03 — Error messages should be concise, speci c and actionable.
04 — Don’t tell users they are wrong; explain how to get it right.

05 — Avoid lengthy error messages.

06 — Accept information in di erent formats (if it’s not ambiguous).

07 — Show an error summary on the top of the page.

08 — Validate when a user moves to the next step of the process.

09 — If in doubt, always repeat the label in the error message.

ff
ffi
ff
fi
Inclusive Design

Building A
Strong Case
 UX Research

UX Without Users Is X
Stakeholders who won’t give you time
or resources to talk to users often are
the rst to demand evidence to
support your design work. Ask for
reasons for no access to users.
fi
UX Research

UX Without Users Is X
Typically users are hard to access,
too expensive to recruit, strict NDA,
lack of users, or the company blocks
access to maintain a relationship.
Mostly because they don’t trust you.
UX Research

UX Research Without Users

01 — Explain that you don’t need much to get started.

02 — Proxy test via colleagues who are the closest to users.

03 — Typically sales, customer success, support, QA.

04 — Ask to observe or shadow users at their workplace.

05 — Listen in to customer calls, interview call centre sta .

06 — Ask for access to analytics, CRM reports, support logs.

07 — Use Google Trends to nd product-related search queries.

08 — Scrap insights from logs, Jira backlog, support tickets.

09 — Map user sentiment on TrustPiplot, reviews, competitors.

10 — Recruit users via UserTesting.com, Maze, UserInterviews.

11 — Tiny but steady commitments: 5 users × 30 mins, 1× month.

fi
ff
Accessibility Research

Building Accessibility Research

01 — Start by gathering people interested in accessibility.

02 — Document what research was done, where the gaps are.

03 — Involve 5-12 users with disabilities in accessibility testing.

04 — Recruit via testing platforms, non-pro ts, communities.

05 — Add extra $25–$50 depending on disability transportation.

06 — Run a small accessibility initiative around key ows rst.

07 — Then tap into critical touch points and research them.

08 — Extend to components, patterns, ows, service design.

09 — Incorporate inclusive sampling into all research projects.

10 — At least 15% of usability testers should have a disability.

fl
fi
fl
fi
Getting a buy-in

Build A Strong Case

You can’t build empathy with facts,
charts or legal concerns. People often
dismiss concerns they can’t relate to.
Nothing is more impactful than
seeing real customers struggling.
Getting a buy-in

Strong Case For UX Research

Stakeholders value research. But:
they want to avoid disruptions,
delays and minimize risk. They
assume high costs and delays.
 Getting a buy-in

Strong Case For UX Research

And more often, they fear that you
might uncover failures, and costs of
xing them. Or discovering insights
that con ict with top-level decisions.
fi
fl
Getting a buy-in

Strong Case For UX Research

01 — Best timing for research is when risk is high, clarity is low.

02 — Ask for very small commitments, progress from there.

03 — Aim for impact: nd similar problems across teams.

04 — Explaining the high cost of retro tting research.
05 — Anticipate objections about costs, competition, slowdowns.

06 — Make a business case for reducing risk, preventing failures.

07 — Suggest an UXR roadmap with actions, timelines, roles, costs.

08 — Explain how you will use the outcomes to inform decisions.

09 — Establish regular small-scale research.

fi
fi
 If you
quad
ffi
 If you are in the Low Clarity / Low Risk
quadrant, it will be di cult to make a
decision, but cheap to experiment. But: you
won’t experiment if the risk is high unless
you are on tough timelines.

↬ Product Design Eisenhower matrix, Dragan Babic, https://draganbabic.com/blog/product-design-eisenhower-matrix/

ffi
Getting a buy-in

Strong Case For Accessibility

01 — Bring users with disabilities for testing.

02 — Ask for very small commitments, progress from there.

03 — Explaining the high cost of retro tting accessibility.

04 — Anticipate objections about costs, competition, slowdowns.

05 — Make a business case for lowering costs, boosting revenue.

06 — Suggest an a11y roadmap with actions, timelines, roles, goals.

07 — Establish regular testing (e.g. every 6–8 months).

fi
A Letter To A Stakeholder
🤨 ”Accessibility is an edge case, we can’t really invest in
it at this point of time. Let’s move it to next sprint.”

🙅 “I respectfully disagree. 1 in 6 people around the world

experience disabilities. In fact, our competitors [X, Y, Z]
have launched accessibility efforts ([references]), and we
seem to be lagging behind. Plus, it doesn’t have to be
expensive. But it will be expensive if we retrofit later.”

🤨 ”Accessibility? Uhm, from what we know according to our

data, we don’t have any disabled users at all. Why bother?”

🙅 “Well, if a product is inaccessible, disabled users can’t

and won’t be using it. But if we do make our product more
accessible, we open the door for prospect users for years to
come. Even small improvements can have a high impact. It
doesn’t have to be expensive nor time-consuming.”
A Letter To A Stakeholder
🤨 “Our application is very complex. Would it even work with
screen readers?”

🙅 “It’s not about designing only for screen readers.

Accessibility can be permanent, but it can also be temporary
and situational — e.g. when you hold a baby in your arms, or
if you had an accident. Actually it’s universally useful and
beneficial for everyone, including sighted and able users.”
Getting a buy-in

Strong Case Against Politics

Design has far-reaching impact on
many levels. It might a ect contracts,
funding, jobs,.internal processes,
supply chain, policy. Such changes
will be furiously rejected on spot.
ff
Getting a buy-in

Strong Case Against Politics

01 — UX strategy requires a good amount of change management.

02 — Start by visualizing the people impacted by your work.

03 — Study their political relations and in uence.

04 — Bring them in: they have a lot to o er and a lot to lose.
05 — Show your early work to stakeholders for their support.

06 — It’s not just their support, but their relationships you will need.

07 — Help them explain your work to others, e.g. with key points PDFs.

08 — It will give managers tools to push back on demands higher up.

09 — Always attach your decisions to a goal, metric or a problem.

10 — You need just enough in uence to initiate a change.

fl
ff
fl
“Building Accessibility Research Practices”,
Maya Alvarado, Medium
Inclusive Design

Front-End
Accessibility
Accessibility

Retaining Accessibility
Accessibility is not something we add
to a website, but something we start
with and risk losing with every
enhancement. It is to be retained.

Scott Jehl, https://twitter.com/scottjehl/status/411237303579721728

↬ Inclusive Design Toolkit, https://www.microsoft.com/design/inclusive/
 ↬ JAWS, https://www.freedomscienti c.com/products/software/jaws/
fi
↬ NVD, free, https://www.nvaccess.org/download/
Measuring usability

Design KPIs
Improve! WCAG AA Compliance Measure! Sales/marketing costs < $15K/w.
Reduce! Accessibility errors (HTML) Reduce! Service desk inquiries < 35/w.
Reduce! Accessibility errors (PDFs) Reduce! Confusing encounters < 3/visit.
Reduce! Captions for videos. Reduce! Time to release/update < 14 days.
Reduce! Respect dark mode. Reduce! Non-content on a page < 25%.
Improve! Use prefers-color-scheme. Reduce! Environmental impact < 0.3g/p.
Improve! Use prefers-contrast. Reduce! Onboarding time < 15 sec.
Improve! Use forced-colors. Improve! Flesch reading ease score > 60.
Improve! Support reduced motion. Improve! “Turn-around” score < 1 week.
Accessibility

Focus Styles
It’s common to remove focus styles as they get
in a way of design. But every interactive
element has to be focusable, so it needs focus
styles. With :focus-visible we can remove
focus styles for a mouse/pointer, but keep it
visible for keyboard users.
Bundling Strategy

Focus Styles
We tend to remove focus styles as they get in a
way of design. But every interactive element
has to be focusable (a, button, input, select,
details, tabindex-applied). With :focus-
within we can style the parent element of a
focused element. Acts as a “parent” selector.
Bundling Strategy

Focus Styles
We tend to remove focus styles as they get in a
way of design. But every interactive element
has to be focusable. With :focus-within we
can style the parent element of a focused
element. It acts as a parent selector in CSS.
Bundling Strategy

Focus Management
Most of the time, it’s a good idea to leave
focus order alone if we use <button> for
buttons, <input> for inputs and <a> for links.
No need to apply tabindex to interactive
elements that can receive keyboard focus,
and not for non-interactive elements.
Bundling Strategy

tabindex
tabindex allows an element to be focused. It
accepts an integer as a value. It’s never a
good idea to use a positive integer value as it
will override the expected tab order, causing
disorienting experiences.
Bundling Strategy

tabindex="-1"
We can use tabindex="-1" for focusing
with JavaScript. It will make an element
focusable via JavaScript or click/tap.
These elements are removed from the
tab sequence, but can still received
keyboard focus programatically.
Accessibility Strategy

Focus Trapping & Mechanics

01 — Determine the container elements of all focusable elements.

02 — Set the bounds of the trapped content, rst/last focusable item.

03 — Remove interactivity from focusable items outside the trap.

04 — Move focus into the trapped content (tabindex=“-1”).

05 — Listen for events that signals dismissing the trapped content

(save, cancel, dismissal/hitting the Esc key, etc.).

06 — Dismiss the trapped content area when triggered.

07 — Restore previously removed interactivity.

08 — Move focus back to the interactive element that triggered trap.

09 — Common for: dropdowns, layers, view changes, loading screens.

fi
↬ A11y Dialog, https://github.com/edenspiekermann/a11y-dialog
Bundling Strategy

Focus Management in JS
In JavaScript, we need to send focus to
changed views, modals, menus. E.g. we
can use React refs and FocusScope API,
for Vue.js there is Vue.js $refs.
↬ Accessible Contrast Ratios Explained, https://www.getstark.co/blog/accessible-contrast-ratios-and-a-levels-explained
↬ Accessible Contrast Ratios Explained, https://www.getstark.co/blog/accessible-contrast-ratios-and-a-levels-explained
↬ Accessible Contrast Ratios Explained, https://www.getstark.co/blog/accessible-contrast-ratios-and-a-levels-explained
 Avoid Error Msgs Under Fields
01 — Autocomplete features in browsers obscure them.
02 — On-screen keyboards can obscure them, too.
03 — Screen readers can announce them after the input.
04 — The messages might be out of view on narrow screens.
05 — They need to be complemented with an error summary on top.
06 — Pre x the word “Error:” to the document’s title.
07 — Style error messages in red and use a warning icon.
fi
↬ Illustrations by Jordan Moore, https://twitter.com/jordanmoore/status/1250026238762266624
↬ IBM’s Carbon Design System, https://www.carbondesignsystem.com/patterns/forms-pattern/
↬ Avoid Messages Under Fields, Adrian Roselli, https://adrianroselli.com/2017/01/avoid-messages-under- elds.html

fi
Form Design Guidelines

Better Error Messages

01 — Every message should drive user towards xing the error.
02 — It’s worth investing time in adaptive error messages.

03 — Upon submit, scroll the user to the label of the rst error.
04 — Display the error above the submit button on click.

05 — Display a summary of errors on the top.

06 — Display each error as a line on its own.

07 — Show the number of errors in the tab title as a pre x.

08 — To help x mistakes faster, use suggestions and buttons.
09 — Monitor error rates to track how often users experience errors.
fi
fi
fi
fi
 Disabled Interfaces
Disabled state is an indicator that
something is wrong. Speci cally with
disabled buttons, users have more
con dence that there is a problem that’s
directly related to their input.
fi
fi
 Disabled States
When encountering a disabled button,
users rst slow down massively. Then they
search for error messages. Then they look
for the usual suspects — wrong formatting,
accent chars etc. Then they scan the entire
form, up and down, eld by eld.
fi
fi
fi
 Adam Silver on

Disabled Submit Buttons

“ Disabled buttons don’t explain what’s wrong.

Sometimes users are left wondering what’s
missing. They are not focusable and hard to
read as they are greyed out. With enabled
buttons we can better highlight all the errors.

“Form Design Patterns”, published by Smashing Magazine

Useful Disabled Buttons
Disabled buttons work when they help avoid
double bookings or wrong purchases. They also
work to validate magic sign-in code. Either way,
stop listening to click/tap after the rst click/
tap (except: “Undo” buttons/steppers). Also, add
a spinner and change text to “Processing…”.
fi
 Adam Silver on

Disabled Submit Buttons

“ To avoid double bookings, sometimes it might

seem right to disable a submit button on
submit. Instead, we can include a spinning
indicator, or change the text to “waiting”.
Provide A Way Out
With disabled buttons, some customers
will never be able to proceed — we can
give them a way out. Also, by clicking on
a link, they can choose to be contacted by
customer support.
Provide A Way Out
If something goes wrong, explain what’s
wrong in an error summary. Obviously,
this doesn’t a ect disabling a submit
button when the button is activated
(and should be activated only once).
ff
↬ Buttons — UI component series, Taras Bakusevych, https://uxdesign.cc/button-design-user-interface-components-series-85243b6736c7
Inclusive Disabled Buttons
01 — On hover, change the cursor to cursor: not-allowed.
02 — Always keep disabled buttons focusable.
03 — On focus/tap/click, explain why the button is disabled.
04 — We can show a tooltip or a text message on focus/tap/click.
05 — To avoid double bookings, add a spinner/change the wording on tap/click.
06 — Prevent double click programmatically via JS with aria-disabled.
07 — Use ARIA live regions to announce dynamic content.
08 — Avoid pointer-events: none as it won’t prevent focus/key nav.
09 — Guide the user to error summary, or to form errors directly.
10 — Provide a “way-out”-link under the disabled button.
11 — Allow customers to overrule errors and continue despite them.
12 — Keep the “Continue” button accessible and validate on submit.
13 — Consider replacing disabled buttons with more actionable alternatives.
Disabled Buttons

Summary
01 — Avoid disabled buttons if you can.

02 — If not, make them focusable and inclusive.

03 — Explain what exactly is wrong, and how to x it.

04 — Allow customers to proceed despite errors.

05 — Show error summary above the “Submit” button.

06 — Disable buttons to prevent critical mistakes.

07 — One way or the other, always provide a way out.

fi
Inclusive Disabled Buttons
01 — On hover, change the cursor to cursor: not-allowed.
02 — Always keep disabled buttons focusable.
03 — On focus/tap/click, explain why the button is disabled.
04 — We can show a tooltip or a text message on focus/tap/click.
05 — To avoid double bookings, add a spinner/change the wording on tap/click.
06 — Prevent double click programmatically via JS with aria-disabled.
07 — Use ARIA live regions to announce dynamic content.
08 — Avoid pointer-events: none as it won’t prevent focus/key nav.
09 — Guide the user to error summary, or to form errors directly.
10 — Provide a “way-out”-link under the disabled button.
11 — Allow customers to overrule errors and continue despite them.
12 — Keep the “Continue” button accessible and validate on submit.
13 — Consider replacing disabled buttons with more actionable alternatives.
Accessibility Strategy

ARIA Live Regions

We need to notify assistive tech users
without moving focus for async savings,
updates, autocomplete usage, list ltering,
chat widgets, page changes, noti cations.
For React, we can use react-aria-live.
fi
fi
Accessibility Strategy

PDF Accessibility
When PDF is generated by MS Word or
Apple Pages, it often includes plenty of
accessibility issues. They need to be
reviewed in Adobe Acrobat PDC and PDF
Accessibility Checker (PAC) for PDF/UA
and WCAG compliance.
↬ PDF Accessibility Checker, https://www.access-for-all.ch/en/pdf-accessibility-checker.html
Accessibility Strategy

Client-Side Routing
For each view, we’d need to add a small UI
control (like a “skip” link), label with its
action (e.g. “skip to nav”). When a user
clicks on it, move focus to this control, then
use Live Region to announce page changes.
Media Queries for Accessibility

CSS Media Level 4

We can speci cally design experiences with
reduced motion, high contrast mode,
preferred color scheme, dark/light modes,
dimming modes, reduced data — and we
should be expecting more to come.
fi
Accessibility

Retaining Accessibility
Accessibility is not something we add
to a website, but something we start
with and risk losing with every
enhancement. It is to be retained.

Scott Jehl, https://twitter.com/scottjehl/status/411237303579721728

 Accessibility: The Foundation

• Most guidelines are rather about not making

things inaccessible than making things accessible.

• WAI-WCAG 2.1 (Web Content Accessibility Guidelines) Set

of general, basic accessibility recommendations.
• WAI-ARIA 1.1 (Accessible Rich Internet Applications)
Advanced, ambitious guide that takes a11y to a new level.

• Goal: keep the content usable by keyboard users and

screen readers users, e.g. buttons and widgets.
 Accessibility Techniques

• Accessibility is about de ning relationships,

properties and behaviors of elements explicitly.

• Buttons have di erent states; they control elements,

• Forms require concise and appropriate feedback,
• Widgets have complex properties and behaviors,
• Navigation requires appropriate sectioning.

• Problem: misconceptions about how users use

screen readers/keyboards—and browser support.
ff
fi
 Accessibility Techniques

• Problem: misconceptions about how users use

screen readers/keyboards—and browser support.

• Accessibility tools do have JavaScript support,

• Screen readers can’t predict structure or purpose,
• Accessibility builds on top of existing experience,
• ARIA is well-supported; native controls are better.
“
Semantic HTML is markup that makes
a positive contribution to the meaning
of the page in a standardized way
which can be understood by a maximal
range of user agents...

— Heydon Pickering
“Apps for All”
“
...As a result, screen readers can
understand the patterns and provide
an equivalent experience of the same
content both visually and aurally.
Semantics is embedded in attributes
and HTML elements.

— Heydon Pickering
“Apps for All”
 Accessibility Techniques

• Problem: misconceptions about how users use

screen readers/keyboards—and browser support.

• Accessibility tools do have JavaScript support,

• Screen readers can’t predict structure or purpose,
• Accessibility builds on top of existing experience,
• ARIA is well-supported; native controls are better.
 Accessibility Techniques

• Accessibility is about de ning relationships,

properties and behaviors of elements explicitly.

• Buttons have di erent states; they control elements,

• Navigation requires appropriate sectioning.
• Forms require concise and appropriate feedback,
• Widgets have complex properties and behaviors,

• Problem: misconceptions about how users use

screen readers/keyboards—and browser support.
ff
fi
 Accessible Buttons

• Only <button> should look like a button; classes on

<a>, <div>, <span> aren’t conducive to accessibility.

• HTML:
<button type="button">Read more…</button>
/* Beware: implicit type is ‘submit’, so be specific. */

<a class="button">Read more…</a>

<span class="button">Read more…</a>

• To activate a button, keyboard users must rst be able

to focus it. Screen readers rely on aural feedback.
fi
 Accessible Buttons

• To activate a button, keyboard users must rst be able

to focus it. Screen readers rely on aural feedback.

• <button> receives focus, can be operated via keyboard and

is announced as “button” by screen readers.

• Hint: perceived tactility of interactive controls helps

to communicate their utility. Big, bold, clickable.
fi
 Accessible Buttons

• <button> receives focus, can be operated via keyboard

and is announced as “button” by screen readers.

• Buttons can have di erent states:

— Pressed/unpressed buttons,
— Disabled buttons,
— Buttons which control other elements,
— Buttons that show/hide parts of the page.

• Hint: perceived tactility of interactive controls helps

to communicate their utility. Big, bold, clickable.
ff
• HTML:
<button type="button">Save</button>

• CSS:
button {
background-color: DarkSlateBlue;
border-radius: 0.25em;
box-shadow: 0 4px 0 #222; }

button:hover, button:focus {
/* Make it look like you can press it */ }
• CSS:
button:active {
position: relative;
top: 3px; /* 3px drop */
box-shadow: 0 0 0 #222; /* less by 3px (to zero) */
}

button[disabled] {
/* Styles for a disabled button */
pointer-events: none;
/* or cursor: not-allowed; */
}
• Nested text within <button> will be read out by
screen readers when the button is accessed.

• For <input> buttons, the value attribute will be

announced. Both should never be left empty.

• WAI-ARIA enhancements are always required

when dealing with non-textual content.
• HTML:
<button aria-label="Undo">&#xE000;</button>

<p class="tooltip hidden">You can restore defaults

with <strong id="undo-text">Undo</strong> button.</p>
<button aria-labelledby=“undo-text">&#xE000;</button>
 ARIA Roles, Properties, States

• WAI-ARIA is a gap- ller for HTML semantics.

It de nes three kinds of accessibility attributes:

— Roles de ne the meaning of an element

(role="tooltip", role="tablist", role="search"),

— Properties describe its characteristics

(aria-required, aria-controls, aria-label, aria-labelledby),

— States describe its current interaction states

(aria-checked, aria-expanded, aria-hidden, aria-required).
fi
fi
fi
• HTML:
<button aria-label="Undo">&#xE000;</button>

<p class="tooltip hidden">You can restore defaults

with <strong id="undo-text">Undo</strong> button.</p>
<button aria-labelledby=“undo-text">&#xE000;</button>
• HTML:
<div role="button" aria-label="Undo"><img
src="undo_icon.png" alt="Undo" /></div>

<p aria-hidden="true" class="tooltip hidden">Undo</p>

• Legacy code can be augmented with ARIA roles to
patch code that is otherwise unsemantic.

• Using ARIA-roles should be a method of last resort,

as it fully overrides native semantics.
• HTML:
<div role="toolbar"
aria-label="sorting options"
aria-controls="sortable">
<button aria-pressed="true">A to Z</button>
<button aria-pressed="false">Z to A</button>
</div>

<ul id="sortable" tabindex="-1">

<li>Fiddler crab</li> <li>Hermit crab</li> ...
</ul>
• CSS:
button:active,
button[aria-pressed="true"] {
position: relative;
top: 3px; /* 3px drop */
box-shadow: 0 0 0 #222; /* less by 3px (to zero) */
}
 Accessibility Techniques

• Accessibility is about de ning relationships,

properties and behaviors of elements explicitly.

• Buttons have di erent states; they control elements,

• Navigation requires appropriate sectioning.
• Forms require concise and appropriate feedback,
• Widgets have complex properties and behaviors,

• Problem: misconceptions about how users use

screen readers/keyboards—and browser support.
ff
fi
 • Links can be focused by screen readers; they can
distinguish between “Link” and “Same page link”.

• But grid is invisible to screen readers. Keyboard

users don’t bene t from it either, they have to
cover the same distance, sideways.
fi
 • But grid is invisible to screen readers. Keyboard
users don’t bene t from it either, they have to
cover the same distance, sideways.

• Solution: draw an invisible map of the page by

sectioning content and providing landmarks.
fi
• Sectioning conveys structure to screen readers and
keyboard users. But: avoid too much nesting!

• Meaningful, consistent headings and landmark roles

help users jump between sections seamlessly.
 — banner (role="banner") — search (role="search")
— contentinfo (role="contentinfo") — form (role="form")
— main (role="main") — complementary
— navigation (role="navigation") (role="complementary")

Applicable like <div role="search" … > to any HTML element.

• “Skip to content” links often coded incorrectly:
a.skip {
display: none; /* Nobody can see it. */
}
 • “Skip to content”
— banner (role=“banner”) links better pushed o -screen:
— contentinfo (role=“contentinfo”)
a.skip { a.skip:focus {
— main (role=“main”)
position: relative; top: 0;
top: -100px;
— navigation (role=“navigation”) }
}
ff
 Accessibility Techniques

• Accessibility is about de ning relationships,

properties and behaviors of elements explicitly.

• Buttons have di erent states; they control elements,

• Navigation requires appropriate sectioning.
• Forms require concise and appropriate feedback,
• Widgets have complex properties and behaviors,

• Problem: misconceptions about how users use

screen readers/keyboards—and browser support.
ff
fi
• HTML:
<form>
<fieldset><legend>Login form</legend>
<div>
<label for="username">Your username</label>
<input id="username" type="text"
aria-describedby="username-hint">
<div role="tooltip" id="username-hint">
&hellip; is your email address</div>
</div>
</fieldset>
<button type="submit">Enter site</button>
</form>
• CSS:
[role="tooltip"] {
background: orange;
color: white;
padding: 0.5em;
display: none;
}

input:focus + [role="tooltip"] {
display: block;
}
 Accessibility Techniques

• Accessibility is about de ning relationships,

properties and behaviors of elements explicitly.

• Buttons have di erent states; they control elements,

• Navigation requires appropriate sectioning.
• Forms require concise and appropriate feedback,
• Widgets have complex properties and behaviors,

• Problem: misconceptions about how users use

screen readers/keyboards—and browser support.
ff
fi
• HTML:
<h2>How do I change my password?</h2>
<p>…</p>

<h2>Is my data stored anywhere?</h2>

<p>…</p>

<h2>What is your contact number?</h2>

<p>…</p>
• HTML:
<h2 role="button">How do I change my password?</h2>
<p>…</p>

<h2 role="button">Is my data stored anywhere?</h2>

<p>…</p>

<h2 role="button">What is your contact number?</h2>

<p>…</p>
• HTML:
<h2>
<button aria-expanded=“false"
aria-controls=“change-pass”>
How do I change my password?
</button>
</h2>
<div id="change-pass" aria-hidden="true">
<p>…</p>
</div>
• CSS:
[aria-hidden] { [aria-expanded]:before {
display: none; content: '\25ba\0020';
} }

[aria-hidden="false"] { [aria-expanded="false"]:before {
display: block; content: '\25bc\0020';
} }
• HTML:
<a href=“#nav”>Menu</a>
<!—- other markup… —->
<nav id="nav" role="navigation">
<ul>
<li><a href="/">Home</a></li>
<li><a href="/about">About</a></li>
<li><a href="/blog">Blog</a></li>
</ul>
</nav>
• HTML:
<a href="#nav" role="button" aria-controls="nav"
aria-expanded="false">Menu</a>
<!—- other markup… —->
<nav id="nav" role=“navigation" aria-hidden="true">
<ul>
<li><a href="/">Home</a></li>
<li><a href="/about">About</a></li>
<li><a href="/blog">Blog</a></li>
</ul>
</nav>
• HTML:
<ul>
<li><a href="#sec1">Section 1</a></li>
<li><a href="#sec2">Section 2</a></li>
<li><a href="#sec3">Section 3</a></li>
</ul>

<section id="sec1">...</section>
<section id="sec2">...</section>
<section id="sec3">...</section>
• HTML:
<ul role="tablist">
<li><a role=“tab" href="#sec1">Section 1</a></li>
<li><a role=“tab" href="#sec2">Section 2</a></li>
<li><a role=“tab" href="#sec3">Section 3</a></li>
</ul>

<section id=“sec1" role=“tabpanel">...</section>

<section id="sec2" role=“tabpanel">...</section>
<section id="sec3" role=“tabpanel">...</section>
• HTML:
<ul role="tablist">
<li><a role=“tab" aria-controls=“panel1”
aria-selected=“true”
href="#sec1">Section 1</a></li>
<li><a role=“tab" aria-controls=“panel2”
href="#sec2">Section 2</a></li>
</ul>

<section id=“sec1" role=“tabpanel">...</section>

<section id="sec2" role=“tabpanel” aria-hidden=“true”>...</section>
• Accessible video includes captions, a transcript and
an audio description.

• HTML:
<video preload="auto" width="480" height="360"
poster="myvideo.jpg">
<source type=“video/mp4” src=“talk.mp4" />
<source type=“video/webm” src=“talk.webm" />
<track kind=“captions” src=“talk.vtt" />
</video>
• Accessible video includes captions, a transcript and
an audio description.

• Delivered in a fully accessible video player, incl.

accessible controls and playback options.
 Accessibility Techniques

• Accessibility is about de ning relationships,

properties and behaviors of elements explicitly.

• Buttons have di erent states; they control elements,

• Navigation requires appropriate sectioning.
• Forms require concise and appropriate feedback,
• Widgets have complex properties and behaviors,

• Problem: misconceptions about how users use

screen readers/keyboards—and browser support.
ff
fi
 Accessibility Strategy

• Accessibility is about de ning relationships,

properties and behaviors of elements explicitly.

• Writing HTML, prefer semantically sound elements,

• De ne explicit relationships (roles, properties, states),
• Check global properties rst, then local properties.
• Test keyboard and screen readers use.
• Re ne accessibility enhancements.
fi
fi
fi
fi
↬ Vocalizer.js, https://github.com/atifazam/vocalizer
↬ Vocalizer.js, https://github.com/atifazam/vocalizer
↬ A11Y Project, https://www.a11yproject.com/
↬ ModernCSS.dev, Stephanie Eckles, https://moderncss.dev/
↬ a11yphant, https://a11yphant.com/challenge/page-regions/level/01
↬ Inclusive Components, Heydon Pickering, https://inclusive-components.design/
 ↬ A11Resources, Web ow, https://a11yresources.web ow.io/
fl
fl
↬ A11ysupport.io, https://a11ysupport.io/
↬ axe, Deque, https://www.deque.com/axe/
 ↬ A11y.css, Extension, https:// oodd.github.io/a11y.css/
ff
↬ Accessibility Insights, https://accessibilityinsights.io
Front-End Accessibility

Summary
01 — Screen readers have great JavaScript support.

02 — Always keep interactive elements (e.g. buttons) focusable.

03 — ARIA-roles act as gap- llers for HTML semantics.

04 — Legacy code can be augmented with ARIA.

05 — Sectioning creates a structural map of the page.

06 — Forms require appropriate screen reader feedback.

07 — Focus on focus management and live regions in SPAs.

08 — Always avoid positive z-index values, but use -1 for JS.

09 — Target CSS Media Level 4 queries to create accessible UX.

10 — Always keep focus styles, but provide options for keys/mouse.

fi
Front-End Accessibility

Strategy
01 — Embed accessibility testing in your build process (axe).

02 — Set up accessibility pro les for designers and devs.

03 — Build an accessibility working group with your users.

04 — Visualize accessibility with inclusive design mapping.

05 — Teach the team how to test and use a screen reader.

06 — For EAA, comply with WCAG 2.2 AA success criteria.

07 — Compliance doesn’t guarantee a good experience.

fi
Designing AI Interfaces

Wrapping Up
 Smart Interface Design Patterns
20% off: SMARTUX
https://smart-interface-design-patterns.com
 Smart Interface Design Patterns
https://smart-interface-design-patterns.com
 Smart Interface Design Patterns
https://smart-interface-design-patterns.com/articles
Contact details

Meow! Thanks for

being smashing 🇺🇦

Checklists: www.smashed.by/checklists
Twitter: @smashingmag
Books, Magazine: www.smashingmagazine.com
Video course: www.smart-interface-design-patterns.com
Compliled and curated by Vitaly Friedman, 2012–2024.
Modals & Popovers

Cancel UX
Users need Cancel when they fear that
they’ve committed to something they
want to avoid. Best strategy is to
calibrate expectations with clear end
explicit labels — not the “X” icon.
↬ Cancel vs. Close UX, Aurora Harley, https://www.nngroup.com/articles/cancel-vs-close/
↬ Cancel vs. Close UX, Aurora Harley, https://www.nngroup.com/articles/cancel-vs-close/
↬ Cancel vs. Close UX, Aurora Harley, https://www.nngroup.com/articles/cancel-vs-close/
↬ Cancel vs. Close UX, Aurora Harley, https://www.nngroup.com/articles/cancel-vs-close/
↬ Clearing Input Fields, Jens Brandt
 ↬ Pattern y Design System, https://www.pattern y.org/2022.05/guidelines/ lters/
fl
fl
fi
Modals & Popovers

Reset vs. Cancel UX

Reset clears user’s current input, but
Cancel undoes the entire process.
Adding both is often a source of
confusion. Better: “Clear lters” and
“Cancel entire application”.
fi
Modals & Popovers

Cancel UX
Add Cancel Things To Note
01 — Especially for complex multi-step dialogs. 01 — Nothing is more ambiguous than X.
02 — When exiting the page doesn’t clear input. 02 — X can mean Cancel, Close, Ignore.
03 — When all data is automatically saved. 03 — Or also: Save, Back, Delete, Reset.
04 — To cancel radios/dropdown selections. 04 — Make destructive buttons hard to nd.
05 — Link if Cancel dismisses a modal. 05 — Explain what happens to data/settings.
06 — Button if it reverts a process or changes. 06 — Close large overlays with Back button.
07 — Explicit and clear labels work best. 07 — Avoid pre-selected radio buttons.
08 —“Apply and Continue”, “Close and Dismiss”. 08 — Add an option “None of the above”.
09 — Use con rm prompts to avoid data loss. 09 — Add Reset if users often restore defaults.
10 — On mobile, put a primary button last. 10 — …or they ll in the same form repeatedly.
fi
fi
fi
↬ Where To Place Buttons In Forms, Adam Silver, https://adamsilver.io/blog/where-to-put-buttons-on-forms/
↬ Improving Usability of Multi-Select, Zina Szőgyényi, https://medium.com/tripaneer-techblog/improving-the-usability-of-multi-selecting
Modals & Popovers

Multi-Select In Long Lists

Multi-Select Pills work when users are
familiar with the content of the list, or
know what they are looking for. If not, it
might cause 100% abandonment.
↬ Improving Usability of Multi-Select, Zina Szőgyényi, https://medium.com/tripaneer-techblog/improving-the-usability-of-multi-selecting
↬ Improving Usability of Multi-Select, Zina Szőgyényi, https://medium.com/tripaneer-techblog/improving-the-usability-of-multi-selecting
↬ Improving Usability of Multi-Select, Zina Szőgyényi, https://medium.com/tripaneer-techblog/improving-the-usability-of-multi-selecting
 Modals & Popovers

Con rm vs. Undo

Users need guardrails to prevent
critical mistakes. Con rm veri es user’s
intent to perform an action. Undo trust
users to do the right thing and reverse
later if needed.
fi
fi
fi
 Adam Silver on

Con rm vs. Undo

“ For critical actions, e.g. deleting an item, we

might need to provide an option to con rm
before the action is made, and undo once it
has been made. Di cult for repetitive tasks,
so we need to track how often it’s used.

“Form Design Patterns”, published by Smashing Magazine

fi
ffi
fi
 Jakub Linowski on

Con rm vs. Undo

“ Con rmation prompts question user’s intent

and are often con rmed instinctively, while
undos respect the initial intent by allowing
the action to happen smoothly rst, and
recover from mistakes quickly and easily.

GoodUI.org
fi
fi
fi
fi
 Alan Cooper on

Con rm vs. Undo

“ For con rmation dialog boxes to work, they

must only appear when a user will almost
de nitely click the “No” or “Cancel” button,
and they should never appear when a user is
likely to click the “Yes” or “OK” button.

“About Face”
fi
fi
fi
 Modals & Popovers

Con rm vs. Undo

Choice depends on frequency of use and
also level of severity. Con rm works for
rare mistakes and high impact. Undo
works for low impact but high frequency.
fi
fi
 Modals & Popovers

Con rm vs. Undo

Con rmation Types Things To Note
01 — Low impact, high freq -> No con rm. 01 — Users often instinctively Con rm.
02 — High impact, low freq -> Con rm + Undo. 02 — Users often overlook Undo.
03 — Max impact, low freq -> Type to con rm. 03 — Avoid ambiguity: Yes, Con rm, Cancel.
04 — Undo: mostly any impact + any frequency. 04 — Avoid double negatives: cancel “Cancel”.
05 — Only few user actions are irreversible. 05 — Better: Stay, Leave, Quit, Delete.
06 — Treat Undo as a general default behavior. 06 — Irreversible: add Forever, Permanently.
07 — Delay critical actions if you can’t undo them. 07 — Ask to type to prevent instinctive clicks.
08 — Low severity: Moving folders. 08 — Don’t show “Undo” as fading toasts.
09 — Medium severity: Re-arranging les. 09 — An “Undo” button often works better.
10 — High severity: Deleting entire project. 10 — Always test wording on Undo/Con rm.
fi
fi
fi
fi
fi
fi
fi
fi
fi
Complex Navigation

Showing What Matters

Organize relevant details to be
visible, so customers don’t have to
rely on navigation to nd these
details. Impacts conversion.
fi
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
M
s
p
e
s
a
↬ Mind The Gap, Luke Wroblewski, https://youtu.be/mAiNdU1go1A
 Psychology of eCommerce

Healthy Business Metrics Mix

Increase! Conversion rate. Measure! Sales and marketing costs.
Reduce! Time to repeat purchase. Reduce! Customer support inquiries.
Improve! Progressive privacy rate. Reduce! Confusing encounters per visit.
Reduce! Time to rst share. Reduce! Negative encounters per visit.
Reduce! Time to rst purchase. Reduce! Total cost and ratio of returns.
Reduce! Time to rst upgrade. Reduce! Ratio of negative reviews.
Improve! Custom perf metrics. Reduce! “Marked as spam” signal.
Increase! Life-time value. Increase! “Turn-around” score.
fi
fi
fi
 eCommerce UX

First Impression
The rst thing a customer is exposed to
has a disproportionate impact on how
they perceive, use and will think about
the product — in eCommerce, and in any
product or service.
fi
↬ Menu Icons, Alex Münch, https://twitter.com/alexmuench/status/1090550334286692352
↬ Google Conversions, Luke Wroblewski, https://twitter.com/lukew/status/1182314747997278209
Reducing The Gap
User-centric design works when there’s
no gap between a user and the maker.
As companies grow, gaps start forming:
more distance between decision makers
and the actual customers.

Luke Wroblewski, “Mind The Gap”

↬ Google Conversions, Anna Potanina, https://www.youtube.com/watch?v=XPH01OGrinQ
↬ Google Conversions, Anna Potanina, https://www.youtube.com/watch?v=XPH01OGrinQ
Test Clarity
With Banana Test
Replace all button microcopy with
the word “Banana”, to see, or test
with users, if it’s still completely
unambiguous which button is the
primary “Add to Cart” button.
Inclusive design

Design KPIs
With design KPIs, the design process
is always driven by constraints and
user-centric goals. The outcome is an
evidence-based design without
subjective and random decisions.
Measuring usability

Design KPIs
Improve! Accuracy of data ≈ 100%. Measure! Sales/marketing costs < $15K/w.
Reduce! Time to complete < 35s. Reduce! Service desk inquiries < 35/w.
Reduce! Time to relevance < 30s. Reduce! Search query iterations < 3/query.
Reduce! Frequency of errors < 3/v. Reduce! Time to release/update < 14 days.
Reduce! Error recovery speed < 7s. Reduce! Non-content on a page < 25%.
Improve! Top tasks success > 80%. Reduce! Environmental impact < 0.3g/p.
Improve! System Usability Scale > 70. Reduce! Onboarding time < 15 sec.
Improve! WCAG AA coverage ≈ 100%. Improve! Flesch reading ease score > 60.
Improve! Core Web Vitals ≈ 100%. Improve! “Turn-around” score < 1 week.