"Accessibility (also translated as barrier-free design)" sounds like "adding an accessibility ramp for people with disabilities" — serving only a small group of people. These notes break apart this misunderstanding: it actually divides into three concepts with distinct boundaries (accessibility / universal / inclusive), and the high-frequency implementation scenarios where people really stumble are dark mode(which everyone encounters, but is full of pitfalls) and research for assistive technology users(which is most easily skipped).
One main thread runs through the whole text:Accessibility is not "giving special treatment to a minority", but a design discipline of "taking care of everyone"— vision decline from aging, low light at night, cataracts, mixed-race identity, cross-cultural names, telephone users who can only rely on hearing… these are not marginal groups, but "any user at a certain moment".
The full text has five sections: ① How to distinguish the three easily confused concepts (accessibility / universal / inclusive) → ② Inclusive design implementation checklist (forms / illustrations / filters) → ③ Visual science of dark mode (which should be the default after all) → ④ 8 major dark mode design pitfalls + when to prioritize it → ⑤ How to conduct research with screen reader users + 16 guidelines for telephone voice trees.
1. The three most easily confused concepts: Accessibility / Universal / Inclusive
Many people treat "Accessibility", "Universal Design", and "Inclusive Design" as synonyms, but in fact their coverage scope, whether multiple design sets are allowed, and application scenarios are all different. First use a table to distinguish them clearly, then explain why below.
| Concept | Who it serves | Are multiple design variants allowed? | Typical applications | Anchoring standard |
|---|---|---|---|---|
| Accessibility | Only targets people with disabilities(auditory/cognitive/physical/visual impairments) | Does not emphasize variants, focuses on technical adaptation | Specific adaptations for digital interfaces (screen reader compatibility, keyboard accessibility) | Has clear standards WCAG(Web Content Accessibility Guidelines) — therefore easy to evaluate, can be checked off for acceptance |
| Universal Design | Everyone, one design works for all scenarios | Not allowed— one design satisfies everyone, no variants are made | Mostly used for physical/environmental design(because modifying physical products is costly, making multiple versions is not cost-effective) | —— |
| Inclusive Design | People of all backgrounds and abilities (age/economy/region/language/race/ability…) | Allows multiple design variants, as long as all can achieve the expected effect | Mostly used for digital products(digital interface modification costs are low and flexible, making multiple versions feasible) | —— |
Core principle: The three are "concentric circles + different philosophies". Accessibility is the narrowest, most quantifiable circle (with WCAG as the measuring stick); Universal Design pursues "one design universally suitable for all" but rejects branching; Inclusive Design is the broadest, and actively embraces "multiple design variants"— the goal is not "serving the largest number of people", but "satisfying the differentiated needs of different users as much as possible" to build a sense of belonging.
Why (digital products should choose inclusive design): Making multiple versions of physical products (such as three sizes of door handles) is costly, so the physical world tends toward "universal design" — finding a compromise that works passably for everyone. But modifying a variant on a digital interface has almost zero marginal cost (adding a dark mode switch, adding a filter dimension), so digital products are in a position to "accommodate differences without sacrificing any group", which is exactly the home field of inclusive design.
Counterexamples / exclusion phenomena: When many websites let users select "race", they provide mutually exclusive single-choice options— mixed-race users have no option to choose, and are invisibly excluded by the design. The inclusive fix: add a "two or more races" option, or simply change it to checkboxes. This is a typical action of "identifying exclusion → adjusting design to reflect the real user group".
Tradeoffs for PMs: When you need to give the team/compliance a hard metric that can be accepted, talk about "accessibility + WCAG" (can be checked off); when you want to build product differentiation and improve the sense of belonging for different groups, talk about "inclusive design" (can tell a story, can be implemented in specific features). The two do not conflict — accessibility is the baseline, inclusion is the upper limit.
2. Inclusive design implementation checklist: from forms to illustrations
No matter how clear the concept is, it is empty talk if it cannot be applied to specific controls. All the patterns NNGroup provides can be copied directly.
| Implementation point | Exclusionary writing (counterexample) | Inclusive writing | Who it accommodates |
|---|---|---|---|
| Name/surname field | Restrict character count, ban hyphens, ban special characters | Do not set limits on surname length/hyphens/special characters | Users from different cultural backgrounds (name formats vary widely) |
| Race options | Mutually exclusive single choice | "Two or more races" option / checkboxes | Mixed-race users |
| Gender options | Male/female binary choice | Tinder provides 30+ gender identities, and allows custom input; users can choose whether to display it on their profile (off by default) | Gender-diverse users |
| Filters | Only generic filter dimensions | Pinterest filters images by hairstyle type(curly/straight hair); Sephora filters skincare products by age group filters skincare products by age group | Users with personalized needs, improves engagement |
| Illustration style | Minimalist but highly uniform characters, ignoring racial diversity | Airbnb and Atlassian updated illustrations to incorporate diverse character features | Lets users "see themselves" in the product, without being excluded |
| Text for elderly users | Small text, low contrast | Large font, high contrast, clear typeface; provide font size adjustment button + dark mode option | Elderly users with presbyopia, vision decline |
Core principle: The workflow of inclusive design is a closed loop —inclusive research (understand differences) → identify exclusion (who is blocked out by the existing design) → adjust design to reflect the real user group. It is not adding options on a whim, but first seeing how "different" your real users are.
Why: A uniform, minimalist design style looks "premium", but when it defaults to one appearance, one name format, one identity, it quietly tells some users "this product is not made for you". A sense of belonging is a hidden variable for retention.
3. The visual science of dark mode: should the default be light or dark after all?
Dark Mode (light text on dark background) is the accessibility topic closest to "daily use + vision differences". Intuition often says "dark mode is eye-friendly", but research conclusions are more nuanced:For most people, Light Mode (dark text on light background) actually delivers better visual performance.
First understand the pupil mechanism (this is the physical root cause of all conclusions): The pupil is the "door" for light to enter the eye. Bright environment → pupil constricts and becomes smaller → less sensitive to spherical aberration (image blur), depth of field increases → easier to focus on text, eyes are less tired. Dark environment → pupil dilates → focusing becomes harder. A light-mode screen is bright, which artificially makes the pupil constrict, so focus is better.Age factor: As people age, pupils become smaller, making it harder for light to enter in low light, so elderly people struggle more to read low-contrast/dark-light text, and are more easily disturbed by strong glare (which is actually disadvantageous for light-mode web browsing).
Research evidence (all with numbers, don't rely on gut feeling):
| Study / Source | Task | Conclusion |
|---|---|---|
| 2013“Ergonomics” | Visual acuity (finding the gap position of Landolt C letters) + proofreading for errors; tested two groups aged 18–33 and 60–85 | Light mode won across all dimensions(regardless of age); but in visual acuity tests, the benefit of light mode for elderly people was smaller than for young people |
| “Human Factors” | Font size × contrast polarity | The smaller the font size, the greater the linear advantage of light mode— the smaller the text, the more readable light mode is. But subjectively users felt the two modes were about the same → confirms the UX golden rule: "Don't over-rely on users' subjective feedback" |
| 2017 MIT AgeLab | Quick browsing (analogous to glancing at directions while driving, on a watch, or notifications) | No significant difference between the two modes during the day; light mode outperformed dark mode at night, especially for small text, light mode significantly reduced error rates and reaction times. Large text (4mm) was more readable than small text (3mm) |
| 2018“Nature Scientific Reports” | Long-term effects: measured choroidal thickness (thinning is associated with myopia) | Long-term light mode reading → choroidal thinning (associated with myopia); dark mode reading → choroidal thickening; thinning was more pronounced in people who were already myopic. That is, light mode has better short-term visual performance, but may carry long-term vision risks |
| Users with visual impairments (less literature available) | —— | Users with "cloudy ocular media" such as cataracts read faster in dark mode— dark mode reduces screen glow, lowers scattering and glare. Note: these early studies were mostly based on old-style CRT monitors, modern LED screen performance has improved greatly, so conclusions may not fully apply |
Core principles / design recommendations: Default to light mode, but must provide a dark mode option, and automatically switch following system settings.
Why (default to light, but must provide dark):
- If the target audience includes general users → light mode has better short-term visual performance (pupil constriction, smaller aberration, greater depth of field, better focus), so default to light.
- But a dark mode option must be provided because: ① Long-term light mode may harm vision (choroidal thinning/myopia); ② Some users with visual impairments (cataracts) do better in dark mode; ③ A subset of users simply prefer dark mode (especially at night).
- Frequently used applications should especially provide dark mode; if the operating system provides a dark mode API, it must be integrated to let users choose for themselves.
4. 8 major dark mode design pitfalls + when to prioritize it
Building dark mode is not "inverting the colors". NNGroup's survey: among 115 mobile users, roughly one third each used dark mode / light mode / both respectively. The top three reasons users choose dark mode —reduce eye fatigue(especially in dim environments; but studies have not confirmed it significantly reduces headaches, and screen brightness + ambient light affect eye fatigue just as much as color mode),save battery(OLED screens: Purdue research found that at 100% brightness dark mode saves 67% power, but at 30% brightness it only saves 14%; Apple Watch simply does not offer a light mode at all, purely for battery life),aesthetics(Spotify only offers dark mode, comparing it to a "dark cinema" — secondary UI elements fade into the black background to highlight colorful content such as album covers).
Two key user expectations: ① After enabling dark mode in system settings, apps/websites should automatically follow the switch; ② Users usually do not pay much attention to which designs lack dark mode, and will not abandon a product because of it — so dark mode is a "nice-to-have bonus" rather than a "make-or-break requirement", but if you implement it, you must do it correctly.
8 Major Design Pitfalls (all are places where "simply inverting colors breaks everything"):
| # | Pitfall | How it fails | Correct solution |
|---|---|---|---|
| 1 | Graphics/image transparency | In dark mode, the white background of images becomes exposed and looks rough (house images look good in light mode, but reveal their white background in dark mode) | Use SVG / WEBP / PNG SVG/WEBP/PNG (which support transparency), do not use JPG |
| 2 | Using shadows to create depth | Light mode relies on shadows to create layering, but in dark mode, light-colored shadows fail to convey layering and instead make upper-layer elements look like they are "glowing" | Use the darkest color for the bottom layer, and the lightest color for the top layer closest to the user(examples include Duolingo modals and Google Keep cards) |
| 3 | Overly thin fonts | Thin text on a dark background tends to disappear, especially for users with poor vision | Add strokes, halos, shadows, or gradients to text/logos |
| 4 | Overly bold fonts | Bold text on a dark background will "bleed" into the background | Same as above, ensure clear boundaries |
| 5 | Insufficient color contrast | In dark mode, contrast between text and background is insufficient, making text hard to read | Follow WCAG: minimum 4.5:1 contrast for normal text. Counterexample: the contrast between iOS Coinbase blue UI elements and the dark gray background is 4.59:1, barely compliant, but still visually hard to distinguish— compliance ≠ good usability |
| 6 | Highly saturated colors | Highly saturated colors on dark backgrounds have poor visibility and fail accessibility requirements | Reduce saturation in dark mode |
| 7 | Cross-channel consistency | The app supports dark mode, but web pages opened via links are still in light mode, creating a fragmented experience | Keep the mode consistent between the app and its official website/emails (counterexample: the iOS TSA App uses dark mode, but the linked mobile web page is in light mode) |
| 8 | Page structure/dividers disappear | In dark mode, dividing lines and card boundaries become invisible, so users cannot understand the layout | Do not rely solely on dividing lines; also use color differences to distinguish elements(Trello uses light gray background blocks for separation; counterexample: Yahoo Fantasy cards/titles/lists blur into a single mass in dark mode) |
| (+) | Floating components | Floating buttons/components blend into the dark background and are almost invisible | Make floating components clearly distinguishable from the background (counterexample: National Geographic floating components are almost invisible vs. Lime floating buttons that stand out) |
| (+) | Scannable codes (QR codes/barcodes) | Dark mode inverts the colors of codes, and many scanning devices cannot recognize inverted codes(devices by default expect "dark foreground + light background") | Use the same foreground and background colors in both modes to ensure scannability (counterexample: email QR codes are inverted in dark mode and cannot be scanned; positive example: Delta boarding passes added to Apple Wallet use the same background color in both modes to ensure scannability) |
When to prioritize investing in dark mode (four scenarios):
| Scenario | Why dark mode is important | Examples |
|---|---|---|
| Long sessions | Dark mode reduces eye fatigue and saves battery during extended use | News apps, e-book readers |
| Frequent usage | Reduces visual fatigue when opened frequently | Messaging apps |
| Low-light environments | Bright screens are glaring in darkness; dark mode is more comfortable | Streaming apps |
| Little use of media | With few images/videos, dark mode has less negative impact and is easier to implement | Text-centric apps |
Three implementation recommendations:① Automatically adapt to system settings— do not make users manually enable it in every app; ② Test dark mode— confirm that all elements (especially transparent background images and floating elements) are clearly visible in dark mode; ③ Check emails— confirm that fonts, logos, and images display normally in dark-mode email clients.
V. Research for Assistive Technology Users + 16 Guidelines for Phone Voice Trees
Accessibility cannot rely solely on "expert self-checks + running WCAG tools"; you must let real assistive technology users use the product. This section covers methodology.
5.1 How to Conduct Mobile Research with Screen Reader Users
A screen reader = assistive technology that reads screen content aloud, allowing visually impaired users to operate devices via hearing + gestures. Such users are very hard to find in standard recruitment databases— but there are low-cost, high-efficiency methods.
| Stage | Practice | Why |
|---|---|---|
| Recruitment | Word-of-mouth recruitment: contact local blind organizations (such as the National Federation of the Blind in the US NFB); for regular testing, build long-term relationships with organizations/users,build a user panel available for scheduling at any time | Low cost, and can build meaningful collaborative relationships; such users are almost impossible to find in standard databases |
| Test format | Choose in-person, not remote | Participants are more relaxed in familiar environments; researchers can observe more details — how they use external braille keyboards, body language, and facial expression feedback.Do not ask participants to come to the lab, go to places they are familiar with whenever possible |
| Research planning | Use printed research plans and notes; reserve extra setup time; researchers must be familiar with screen reader operation | Participants may not have multiple monitors at home; printed materials reduce distractions; helping people set up devices in unfamiliar environments takes more time |
| Recording | Dual-channel recording: document camera to capture gestures + screen recording to capture the screen; and provide audio feedback and time announcements | Fully capture key behaviors; participants cannot see the time, so researchers need to regularly verbally announce progress + give brief audio confirmations of "I am paying attention to you" |
Five-element recording correspondence table (copy directly):
| Session elements to record | What technology to use for recording |
|---|---|
| Participant's screen | Participant joins the video call on their mobile device and shares their screen |
| Participant's hands holding the device | Document camera |
| Participant's comments | Document camera microphone |
| Facilitator's comments | Document camera microphone |
| Screen reader audio output | Document camera microphone |
Key insight: Research with screen reader users requires more planning and flexibility(participants frequently change their device-holding posture, so the camera must be constantly re-aimed), but this is a critical link to truly improving accessibility — tool-based detection alone cannot identify real-world usage barriers.
5.2 Phone Voice Tree (IVR / Phone-Tree) Systems: 16 Usability Guidelines
Phone voice navigation (IVR, Interactive Voice Response) is an overlooked accessibility scenario — it relies entirely on hearing, and humans obtain 83% of information through vision and only 11% through hearing, so purely auditory navigation inherently increases memory and cognitive load. (NNGroup notes that the IRS phone tree can be as deep as 10 levels, just like a maze.)
Four fundamental problems(understand these to know why the guidelines are designed this way):
- Unclear responsibility allocation: Users often call because they cannot find information on the website, but some IVRs instead route them back to the website, adding fuel to the fire.
- Conflicting goals: Users want to reach a real person, while companies want to save money and reduce staff — a fundamental conflict of interest.
- Users have no other choice: The phone is often the last channel, so encountering obstacles makes users feel especially frustrated and helpless.
- Auditory disadvantage: See above (83% vs 11%).
16 Guidelines (essentially applying Nielsen's 10 Usability Heuristics to the "ears-only" context):
| # | Guideline | Corresponding usability principle |
|---|---|---|
| 1 | Prioritize offering language selection | Do not force users to listen to lengthy information they cannot understand |
| 2 | Help users record information | Slow down speech for technical information, allow replay, or send it to the user's phone (reduces memory load) |
| 3 | Use consistent terminology and controls | For example, uniformly use the "#" key to go back (consistency) |
| 4 | Always allow undoing selections | Allow returning to the previous decision point at every menu level (user control and freedom) |
| 5 | Allow immediate selection | Do not force users to listen to all options before acting (efficiency) |
| 6 | Use distinct language | Make each option distinct to avoid confusion (recognition) |
| 7 | Provide an alternative to voice input | Offer keypad selection as a backup in addition to voice prompts (flexibility) |
| 8 | Provide useful off-hours information | Announce business hours, website, and emergency contact information |
| 9 | Keep it concise | Cut lengthy promotions/explanations |
| 10 | Provide clear feedback | Give a brief confirmation after the user makes a selection (visibility of system status) |
| 11 | Give users time to find information | Allow ample time when requesting information such as identity verification |
| 12 | Give examples of required information | Clearly state the format of numbers/information |
| 13 | Front-load menu options | State the task information first, then which key to press(reduces memory load — don't make users hold the "task" in memory while waiting for the "keypress" instruction) |
| 14 | Use human voice recordings | More friendly and better aligned with expectations than mechanical synthetic voices |
| 15 | Provide regular status updates | Announce queue progress and estimated wait time during holds |
| 16 | Offer a callback option during waits | Allow users to keep their place and receive a callback later during long waits, reducing frustration |
Key insight: The usability of phone voice trees and any interface follows the same set of fundamental principles— it is not a special category, just an extreme version of an interface with "narrower input/output channels (only ears and keypad left)". Translating principles from visual interfaces — feedback, consistency, undo, recognition over recall, etc. — to the auditory channel yields these 16 guidelines.
Sourced from NNGroup Topics / Accessibility (5 articles). For the 10 Usability Heuristics (which share the same origin as the 16 IVR guidelines in this article), see NNGroup Usability Testing and the 10 Usability Heuristics (complete table of 10 heuristics · complex application scenarios · user pleasure hierarchy · testing methods: 5-user rule/recruitment/remote testing/task scenarios/step-by-step tasks/attitude vs behavior/4-step analysis/small-sample error/competitive evaluation); for extensions of inclusive design to globalization/ethics, see NNGroup Interaction Patterns · Ethics · Globalization · Emerging Technologies (15 patterns · deceptive patterns/sneaking/dangerous UX · inclusive design · globalization cross-cultural issues/language switching/sizing/omnichannel · VR-AR/GenAI prompt controls · user autonomy · UX copy length/recommended content); for principles of color/contrast/visual hierarchy in dark mode, see NNGroup Visual Design Principles · Gestalt Grouping · Visual Hierarchy · Typography · Color · Imagery (19 articles · five major visual principles/Gestalt proximity-similarity-closure-common region/visual hierarchy-grid-golden ratio/font terminology-pairing-reading fonts/color 60-30-10/picture superiority effect-photos-imagery/aesthetic-usability effect/glossary); for accessibility and dark mode implementation on Apple platforms, see Apple HIG Accessibility & Ethics (nine principles/inclusivity/privacy/copy/RTL); for screen reader user recruitment and qualitative research methods, see NNGroup Qualitative Research and Research Methods Toolbox (method landscape/interviews/empathy maps/sample size/task design/facilitation/expert evaluation/workshops/ethics). Images and original documents (including Tinder/Pinterest/Sephora/Airbnb screenshots, iOS light/dark mode comparisons, IRS phone tree illustrations, screen reader research site photos) are retained in sources.
Sources and related materials
- NNGroup Interaction Patterns · Ethics · Globalization · Emerging Technologies (15 patterns · deceptive patterns/sneaking/dangerous UX · inclusive design · globalization cross-cultural issues/language switching/sizing/omnichannel · VR-AR/GenAI prompt controls · user autonomy · UX copy length/recommended content)
- NNGroup Visual Design Principles · Gestalt Grouping · Visual Hierarchy · Typography · Color · Imagery (19 articles · five major visual principles/Gestalt proximity-similarity-closure-common region/visual hierarchy-grid-golden ratio/font terminology-pairing-reading fonts/color 60-30-10/picture superiority effect-photos-imagery/aesthetic-usability effect/glossary)
- Apple HIG Accessibility & Ethics (nine principles/inclusivity/privacy/copy/RTL)