Accessible Design Patterns for 2025  🔗 **Source:** [Accessible Design Patterns for 2025](https://www.youtube.com/watch?v=9vjntLrQ6z0) > [!note]+ Document Notes > tags: [accessibility, inclusive-design, ux-design-patterns, color-accessibility, ui-states] > author: Vitaly Friedman > source: WordPress Accessibility Day 2025 > reference: https://www.youtube.com/watch?v=9vjntLrQ6z0 > date created: 2026-09-08 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: Accessible Design Patterns for 2025 > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [whocanuse.com](https://www.whocanuse.com/) — palette contrast/colorblindness simulator Vitaly cites directly. - [Viz Palette](https://projects.susielu.com/viz-palette) by Elijah Meeks and Susie Lu — data-viz color tool cited for chart palettes. - Carbon Design System (IBM) — cited for shape/outline overlays on colorblind-safe charts. - WordPress Accessibility Day — [wpaccessibility.day](https://wpaccessibility.day/) — the event hosting this talk. - Smashing Magazine — [smashingmagazine.com](https://www.smashingmagazine.com/) — Vitaly's publication, co-founded 2006. ## 📝 Summary - **What happened.** Vitaly Friedman, co-founder of Smashing Magazine and UX lead at the European Parliament, delivered a 48-minute keynote at WordPress Accessibility Day 2025, walking through concrete UI patterns for colorblindness, motion sickness, navigation, and component states (disabled/hidden/read-only). - **Why it matters.** Friedman argues accessibility gets treated as a compliance checklist tied to laws like the European Accessibility Act, and companies stop once they clear the legal bar rather than building an ongoing practice — his talk supplies specific, shippable patterns instead of another audit checklist. - **Key stakeholders.** WordPress Accessibility Day organizers (emcee Jessica Sams of SWCA Environmental Consultants; Joe Dolson, who stepped in as emergency emcee), event sponsors (Gravity Forms, WP Engine, Woo, Ally Web Accessibility, Equalize Digital, GoDaddy, GreenGeeks, Yoast, and ~20 more), and the design-system teams at Visa, Goldman Sachs, IBM, Intercom, and Carbon (IBM) whose work Friedman uses as worked examples. - **Risks and tradeoffs.** The session ended without live Q&A — Friedman "was unable to attend for Q&A at the last minute" per Dolson, and the scheduled emcee also dropped out mid-session, so none of the audience's submitted Zoom Q&A questions got answered on record. - **Bottom line.** Three specific, non-decorative moves carry most of the weight: (1) treat colorblind-safe charting as a first-class design constraint (blue + orange/red, never same-lightness pairs), (2) respect vestibular/motion-sickness triggers by mapping animation to scroll physics instead of hijacking scroll direction, and (3) stop conflating disabled, hidden, and read-only states — they are not interchangeable and Friedman gives a decision tree for choosing among them. ## 📖 Main Content Friedman opens by rejecting the "accessibility as compliance checklist" frame: companies do enough to satisfy the European Accessibility Act, then stop, running annual audits instead of building a standing practice. He borrows a line from Scott Jehl — accessibility isn't added at the end, it's something you start with and risk losing with every change — and structures the rest of the talk around Microsoft's Inclusive Design Toolkit, which maps five senses (touch, seeing, hearing, speaking, thinking) against permanent, temporary, and situational impairment. His own example: a one-armed person (permanent), an arm injury (temporary), a new parent holding a baby (situational). He also cites the UK Ministry of Justice's courtroom personas and Gov.uk's dedicated accessibility personas, then reframes the core idea: "disability is not a personal health condition, but it's a mismatched human interaction" — not something that happens to other people. From there the talk moves through four concrete pattern clusters: **Color and colorblindness.** With ~300 million people affected by some form of color vision deficiency, Friedman recommends blue as the safest hue, pairing blue with orange/red, and avoiding same-lightness red/green/brown, pink/turquoise/gray, or purple/blue combinations. He walks through Nick Desbarats' colorblind-safe dashboard dot-voting technique, the Carbon Design System's shape/outline overlays on line charts, and Visa's product design system, which pairs every chart type with keyboard navigation instructions (entering/exiting bar groups, list-view alternatives) — demoed live on a "Where do cardholders spend more per interaction?" chart. **Motion sickness.** Around 30% of people are susceptible to motion sickness from a mismatch between what they see and what their vestibular system expects. Friedman shows a horizontal-scroll slider (Van Gogh Museum site) that visually reads as vertical, and argues the fix isn't zero motion — it's respecting scroll physics, avoiding parallax, offering a way to skip animated sequences, and (his own example) using the iOS feature that counters car-motion mismatch for people reading on a phone in a moving vehicle. **Navigation.** Nested mega-dropdowns (he cites a WTO site with three to four stacked levels) cause frequent "wrong boundary" errors. Amazon's early-2000s triangle-pattern hover menu — tracking the cursor's path to the content boundary rather than using a flat delay — solves this, and Friedman shows a hybrid pattern that adds click-to-pin on top of the triangle. He also demos "navigation queries" — City of Düsseldorf's two-dropdown "what do you want to do here?" homepage and ao.com's guided washing-machine finder (type, size, price → 25 relevant products with four filters) — as a faster alternative to search or category browsing. For dense multi-level app navigation he uses Intercom's four-stacked-level sidebar, arguing icon-only navigation should default to pinned labels since people relearn icons quickly but also forget them quickly. **Component states.** The most detailed section: disabled, hidden, and read-only states are "not interchangeable." Disabled buttons are "the most expensive buttons out there" because users don't know how to make them enabled — his example is an address-validator that rejects a real 10-year address, risking near-total cart abandonment. He recommends aria-disabled plus explicit messaging over the plain disabled attribute, or keeping buttons enabled and blocking only on click. Hidden removes an option from the UI entirely (used for insufficient permissions or rarely-active features) and always costs discoverability. Read-only is informative but not interactive, focusable, and screen-reader accessible — and should look neither like disabled nor like static text. Friedman closes this section with a decision tree (can the user ever interact with it → hidden if no; mostly informational vs. interactive → read-only vs. disabled) built from a Goldman Sachs progress-bar state model, Scott Hurff's "UI stack" (ideal/error/partial/loading/blank), and Eric Bailey's research cataloging UI states. He ends on a list of what user research shows people actually want: fast, legible experiences; large checkboxes and radio buttons that look like checkboxes and radio buttons; visible focus states; simple password rules; predictable tabbing; form input that survives an accidental refresh; dropdowns that open on tap/click, not only hover; easy undo; a predictable Back button; and transparent pricing. ### 🗒️ Notes #### ⏱️ [00:01:35](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=95s) Introduction — Jessica Sams - Jessica Sams (Virtual Public Engagement Specialist and UX Designer, SWCA Environmental Consultants) introduces the session. - Bio detail: Friedman was born in Minsk, Belarus, studied computer science and mathematics in Germany, freelanced as a designer/developer for six years, then co-founded Smashing Magazine in 2006. He's UX lead at the European Parliament and Smashing Magazine, runs Measure UX and Smart Interface Design Patterns video courses, and does live UX training. #### ⏱️ [00:03:56](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=236s) Accessibility as compliance vs. practice - Friedman opens by saying accessibility has 20-25 years of articles, tools, and techniques behind it, yet integrating it stays hard. - Names the failure mode directly. > [!quote] > It's really rarely that it actually has an established-- Companies actually have an established accessibility practice, accessibility research, or anything related to that. #### ⏱️ [00:08:02](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=482s) Microsoft Inclusive Design Toolkit — five senses - Breaks inclusive design across touch, seeing, hearing, speaking, thinking, each crossed with permanent, temporary, and situational impairment. - Examples: one arm (permanent), arm injury (temporary), new parent holding a baby (situational). #### ⏱️ [00:09:15](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=555s) UK Ministry of Justice and Gov.uk personas - Same touch/seeing framework applied to courtrooms (carrying paperwork, dark courtroom). - Gov.uk built a dedicated set of accessibility personas; Friedman says extending existing personas instead is also fine — the debate isn't the point. #### ⏱️ [00:09:55](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=595s) Reframing disability > [!quote] > disability is not a personal health condition, but it's a mismatched human interaction. - Argues subtitles, SMS, and eyeglasses all originated as accessibility inventions people no longer notice as such. #### ⏱️ [00:11:17](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=677s) Colorblindness — scale and palette rules - 300 million people have some form of color weakness or colorblindness. - Palette rule: blue is the safest hue; pair blue with orange/red; avoid same-lightness red/green/brown, pink/turquoise/gray, purple/blue. #### ⏱️ [00:11:41](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=701s) Dashboards and charts — Desbarats, Carbon, Visa - Nick Desbarats' colorblind dot-voting dashboard technique. - Carbon Design System adds shapes/outlines to line-chart series. - Visa's product design system pairs every chart with keyboard navigation (enter/exit bar groups) and a list-view fallback, demoed on "Where do cardholders spend more per interaction?" #### ⏱️ [00:14:55](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=895s) Color tooling resources - whocanuse.com, accessible palettes from Venngage and Figma Community, Viz Palette (Elijah Meeks and Susie Lu), and Lisa Charlotte Muth's colorblindness/color-weakness article series. #### ⏱️ [00:15:37](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=937s) Motion sickness — mechanism and scale - Around 30% of people are susceptible; tied to vestibular disorders and migraines from a mismatch between perceived and actual motion. - Example: a horizontal-scroll slider (unnamed site) and the Van Gogh Museum site, both of which read visually as vertical navigation but require horizontal swipe/scroll. #### ⏱️ [00:17:36](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=1056s) Fixing motion — physics, not silence - Recommends respecting reduced-motion without deleting all motion: map scrolling to animation, avoid flashing images and parallax, offer a skip/consent option. - Cites an iOS feature (released roughly two years before the talk) that counters the visual/vestibular mismatch of reading on a phone in a moving car. #### ⏱️ [00:19:47](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=1187s) Aging and unpredictable onset — Elizabeth Buie - Cites Elizabeth Buie's overview of how senses, movement, cognition, and attitude change with age, at unpredictable timing and severity. - Friedman's own example: hearing damage in his left ear at age 32 from an unprotected Prodigy concert; he was 40 at the time of the talk. #### ⏱️ [00:20:52](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=1252s) Mega dropdown menus - Nested hover menus cause repeated "wrong boundary" errors; cites a World Trade Organization site with three to four stacked navigation levels shown at once. #### ⏱️ [00:22:54](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=1374s) Amazon's triangle pattern - Early-2000s Amazon pattern: track the cursor path as a triangle to the content boundary instead of a flat hover delay, so people can cross diagonally without losing the menu. - Friedman shows a hybrid version combining the triangle with click-to-pin. #### ⏱️ [00:25:01](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=1501s) Navigation queries — Düsseldorf and ao.com - City of Düsseldorf homepage: two dropdowns ("what do you want to do here?" → "book an appointment" → "consultation") route directly to the right page. - ao.com (UK e-commerce): washing machine → front-loader → size → price range → 25 relevant products with the four most common filters exposed on the front page. #### ⏱️ [00:26:22](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=1582s) Multi-level app navigation — Intercom - Intercom's sidebar stacks four navigation levels; Friedman recommends pinning labels next to icons since people relearn icons fast but forget them fast too. - Intercom's plus-button-plus-accordion pattern for adding/browsing people and companies, which Friedman had "never seen before." #### ⏱️ [00:28:55](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=1735s) Icons vs. labels > [!quote] > scanning 10 words might be faster and easier than scanning 10 icons, especially if they're confusing - Says he's "allergic to tooltips" and prefers inline explanation or accordions for anything that needs real explanation. #### ⏱️ [00:29:31](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=1771s) Drag-and-drop keyboard support - Pattern: Tab to focus, Space to lift, Arrow keys to move, Space to drop. - Mobile alternative: a checkbox-based reorder menu instead of touch drag. #### ⏱️ [00:31:24](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=1884s) UI states — framing the problem - Introduces disabled, hidden, and read-only as commonly confused states, citing the Goldman Sachs design system's progress-bar states (complete, active, incomplete, disabled, error, warning), Scott Hurff's "UI stack" (ideal/error/partial/loading/blank), and Eric Bailey's UI-states research. #### ⏱️ [00:33:24](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=2004s) Disabled state > [!quote] > disabled buttons, especially disabled buttons, are the most expensive buttons out there - Example: an address validator rejects an address the user has "been living there for 10 years," risking near-total checkout abandonment. - Recommends aria-disabled with explicit messaging over the plain disabled attribute, or keeping the button enabled and blocking only on click. #### ⏱️ [00:36:29](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=2189s) Hidden state - A hidden component can't be located at all — used for insufficient permissions or rarely-active features (his example: a video stream that runs once a month). - Always costs discoverability; recommends showing hidden-item toggles near the control that hides them. #### ⏱️ [00:38:30](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=2310s) Read-only state - Informative but not interactive; content stays focusable and screen-reader accessible. - Should look neither like disabled (which implies it could become enabled) nor like plain static text; cites an IBM GitHub repo discussion on read-only form controls as a reference implementation. #### ⏱️ [00:41:41](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=2501s) Decision tree - Walks a flowchart: can the user ever interact with it → if no, hidden; if yes, is it mostly informational or interactive → read-only vs. static text, or default/disabled based on whether it prevents a critical mistake like a double order. #### ⏱️ [00:45:21](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=2721s) What people actually want > [!quote] > People like fast and accessible experiences. - List: legible text, large checkboxes/radio buttons, visible focus states, simple password rules, predictable tabbing, helpful error messages, autocomplete, form data surviving accidental refresh, dropdowns on tap/click as well as hover, easy undo, a predictable Back button, snooze/pause options, transparent pricing. #### ⏱️ [00:46:39](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=2799s) Session ends without Q&A - Joe Dolson unexpectedly takes over as emcee after the scheduled host "unexpectedly frozen"; announces Friedman "was unable to attend for Q&A at the last minute," so none of the submitted Zoom questions get answered live. - Next session flagged: "Being a Colorblind Designer" with Matt Roberts, 16:00 UTC. ## 📚 References - [whocanuse.com](https://www.whocanuse.com/) — colorblindness/contrast palette simulator. - [Viz Palette](https://projects.susielu.com/viz-palette) — Elijah Meeks and Susie Lu's data-visualization color tool. - Carbon Design System (IBM) — [carbondesignsystem.com](https://carbondesignsystem.com/) — shape/outline overlay pattern for colorblind-safe charts. - Accessible color palettes — Venngage and Figma Community (named in talk, no specific URL given). - Lisa Charlotte Muth's colorblindness/color-weakness article series (named in talk, no specific URL given). - Elizabeth Buie's overview of age-related sensory, motor, and cognitive change (named in talk, no specific URL given). - Eric Bailey's UI-states research (named in talk, no specific URL given). - Scott Hurff's "UI stack" concept (ideal/error/partial/loading/blank states). - IBM GitHub repo discussion on read-only form controls (named in talk, no specific URL given). - Visa product design system — accessible, keyboard-navigable data visualization. - Goldman Sachs design system — progress-bar state model. - WordPress Accessibility Day — [wpaccessibility.day](https://wpaccessibility.day/). - Smashing Magazine — [smashingmagazine.com](https://www.smashingmagazine.com/). ## 🗣️ Paraphrase Friedman spends the first ten minutes arguing that accessibility work stalls out at legal compliance — teams do the minimum the European Accessibility Act requires, run an annual audit, then stop — and that this happens because organizations still frame disability as something abstract that happens to other people rather than a mismatch between a person and an interface in a given moment. He roots this in Microsoft's five-sense inclusive-design framework and his own hearing-loss story to make the point that impairment is often temporary, situational, and unpredictable rather than a fixed label. The middle of the talk is a tour of specific, shippable patterns: colorblind-safe charting (blue-based palettes, shape overlays, keyboard-navigable data views from Visa), motion-sickness-safe interaction (map animation to scroll physics instead of hijacking scroll direction), triangle-pattern hover menus and guided "navigation query" homepages (Düsseldorf, ao.com) that skip search entirely, and icon-plus-label navigation for dense apps like Intercom. He closes on the most technical section — disabled, hidden, and read-only component states are not interchangeable, each has a distinct accessibility contract, and he offers a decision tree plus a direct claim that disabled buttons are the most expensive UI element a team can ship because users can't tell how to fix what's wrong. ## 📰 Newsletter If your team still treats accessibility as a once-a-year audit, Vitaly Friedman's WordPress Accessibility Day 2025 talk is worth the 48 minutes. He skips the checklist and goes straight to patterns you can lift into a design system this sprint: colorblind-safe chart palettes (blue plus orange/red, never same-lightness pairs) from Visa and Carbon's design systems, Amazon's triangle-pattern hover menu for mega-navigation, "navigation query" homepages that route people straight to a task the way City of Düsseldorf and ao.com do, and — the most useful 15 minutes in the talk — a decision tree for when a component should be disabled, hidden, or read-only, with the blunt claim that disabled buttons are "the most expensive buttons out there" because nobody knows how to fix what's wrong with them. Bonus: Friedman's own hearing-loss story (age 32, an unprotected Prodigy concert) is a sharp reminder that impairment shows up on its own schedule, not just in your persona docs. ## ✅ Action Items #### DevRel - Developer advocacy: model a talk on this one — pair one research citation (Eric Bailey's UI-states catalog) with one shippable artifact (the disabled/hidden/read-only decision tree) per session instead of a general accessibility overview. - Education: build a workshop module around the decision tree from 00:41:41, with live examples of aria-disabled markup. - Developer experience: publish a starter snippet library for aria-disabled + inline messaging, matching Friedman's "keep it enabled, block on click" alternative. - Developer marketing: reuse the "what people actually want" list (00:45:21) as campaign copy — it names concrete, testable UX wants instead of abstract accessibility values. - Community management: not directly addressed — the talk has no moderation or code-of-conduct content. - Internal/external/cross-project: Friedman's cross-org work (Smashing Magazine plus European Parliament UX) is a model for someone doing accessibility consulting across community and enterprise contexts simultaneously. #### OSPO - Policy & Governance: the talk names the European Accessibility Act by name as the compliance driver that produces "just enough" accessibility work — useful primary-source framing for an OSPO writing its own accessibility policy language to avoid the same trap. - License Compliance: not applicable to this source — no license-scanning content. - Security Management: not applicable to this source — no vulnerability-intake or embargo content. - Software Inventory: not applicable to this source — no SBOM content. - Developer Support: Friedman's Smart Interface Design Patterns courses and live UX training are a reference model for structured, ongoing (not one-off) developer consultation hours on accessibility. - Community Engagement: WordPress Accessibility Day's tiered sponsor list (Platinum: Gravity Forms, WP Engine, Woo; Gold: Ally, Equalize Digital, GoDaddy, GreenGeeks, Yoast; plus ~15 Silver/Bronze sponsors) is a working transparent-funding example. - Strategic Alignment: not applicable to this source — no KPI/OKR content. #### Community - Maintainers: Scott Jehl's line, quoted by Friedman, that accessibility "is something we start with initially, and then risk losing with every single change," is a usable maintainer-facing principle for release-hygiene checklists. - Contributors: not directly addressed — no onboarding-path content in the talk. - Sponsors: the event's own four-tier sponsor structure (Platinum/Gold/Silver/Bronze, ~20 named organizations) demonstrates a transparent, budget-visible sponsorship model worth citing when designing sponsor tiers elsewhere. - Ecosystem: not applicable to this source — no cross-project incident-drill content. #### WordPress - Core: adopt aria-disabled plus explicit messaging (00:33:24) instead of the native `disabled` attribute on wp-admin buttons that block on validation. - Core Performance: not applicable to this source — no runtime profiling content. - Core AI: not applicable to this source — no AI feature content. - **Core Program Team:** the "retain accessibility throughout the design process, don't audit once a year" framing (00:03:56–00:09:57) is a useful cross-team coordination principle for release planning. - Mobile: the drag-and-drop mobile alternative (checkbox-based reorder menu, 00:29:31) directly informs how the Gutenberg mobile app could handle block reordering without touch drag. - Playground: not applicable to this source — no browser-sandbox content. - Community: WordPress Accessibility Day is itself a WordCamp-style community event; Friedman's talk is a directly reusable case study for future meetup/WordCamp accessibility tracks. - Training: Friedman's decision-tree teaching approach (state the rule, then a flowchart) is a reusable curriculum pattern for a WP Training accessibility module. - Marketing: the closing "what people actually want" list (00:45:21) gives WP Marketing concrete, non-jargon language for an accessibility campaign. - Support: the disabled-button/address-validator example (00:33:24) maps directly onto the most common WP Support pattern — users stuck on a greyed-out button with no explanation of what to fix. - Design: the entire talk is design-system source material — colorblind palette rules, the states decision tree, and the navigation patterns are all directly actionable for WP Design's token and component library. - Documentation: the hidden/disabled/read-only decision tree (00:41:41) is exactly the kind of worked example DevHub/HelpHub should carry with code snippets. - Photos: not applicable to this source — no photo-taxonomy content. - TV: WordPress.tv hosts recordings like this one; the session's own caption gap (no live Q&A captioning, since Q&A didn't happen) is a small but real reminder to check caption coverage on submitted talks. - Polyglots: not applicable to this source — no localization content. - Accessibility: core relevance — the colorblind palette rules, motion-sickness guidance, and WCAG-mappable states decision tree are direct source material for WP Accessibility team audits and pattern documentation. - Meta: not applicable to this source — no .org roadmap content. - CLI: not applicable to this source — no CLI content. - Hosting: not applicable to this source — despite GoDaddy and GreenGeeks appearing as event sponsors, the talk itself has no hosting-infrastructure content. - Tide: not applicable to this source — no plugin-scoring content. - Openverse: not applicable to this source — no media-ingestion content. - Themes: the colorblind-safe palette rule (blue + orange/red, avoid same-lightness pairs) is directly actionable for default and block-theme color palette defaults. - Plugins: Gravity Forms, a platinum sponsor building accessible WordPress forms, is a natural pilot for Friedman's "let people override the validator" recommendation (00:33:24) on address/contact-form validation. #### The WPOCC - Programs: not applicable to this source — no fellowship or stipend content, though the event's open sponsor-funded model is a loosely relevant funding pattern (see Funding experiments below). - Projects: not applicable to this source — no governance-clinic or documentation-sprint content specific to the WPOCC's mission. - Funding experiments: the event's four-tier, ~20-sponsor funding model (Platinum through Bronze, transparently listed at the top of the recording) is a concrete example of a matched, milestone-free but publicly visible funding structure worth studying for WPOCC grant design. ### FAIR - Technical independence: not applicable to this source — no local metadata, provenance, or signature-verification content. - Policies and covenants: not applicable to this source — no funding-transparency or sunset-clause content specific to federated governance. - Productized governance artifacts: Friedman's compliance-vs-practice distinction (accessibility as a standing effort, not a checklist you clear once) is directly relevant framing for FAIR's own governance artifacts — the same trap (checkbox compliance replacing genuine practice) applies to any certification-style scorecard. ## 🧪 Hypotheses - Replacing a disabled-until-valid checkout button with an always-enabled button plus inline validation messaging reduces cart abandonment versus the disabled-button pattern Friedman critiques at 00:33:24. - Colorblind-safe palettes (blue + orange/red, no same-lightness pairs) improve chart-reading accuracy for users with color vision deficiency versus red-green-brown palettes, measurable via task-based comprehension tests. - Amazon's triangle-pattern hover menu produces fewer accidental menu-exit errors than a flat hover-delay menu, measurable via click-path/error-rate logging. - Mapping animation to scroll physics (vs. horizontal-scroll-as-vertical-navigation, as critiqued at 00:15:37) reduces self-reported motion-sickness symptoms among users who identify as susceptible. - Adding text labels to icon-only multi-level app navigation (Intercom-style) reduces mis-navigation or support-ticket volume versus icon-only navigation. - Marking read-only fields with a distinct badge (vs. visually identical to disabled fields, as shown at 00:38:30) reduces user confusion, measurable via task-completion time in moderated usability tests. ### 📊 Methodology - A/B test checkout completion rates for disabled-button vs. always-enabled-with-inline-validation button designs on a live form. - Run colorblind-participant chart-reading accuracy tests (task-based comprehension, time-to-answer) comparing Friedman's recommended palette against a naive red-green palette. - Log click-path and menu-exit error rates for triangle-pattern vs. flat-delay hover menus in a controlled prototype. - Use a validated instrument (e.g., a simulator-sickness-style self-report questionnaire) pre/post exposure to scroll-hijacked vs. physics-respecting animated pages. - Compare support-ticket volume and moderated usability-test error rates before and after adding labels to an icon-only navigation sidebar. - Run moderated usability tests asking participants to distinguish disabled/hidden/read-only fields under Friedman's proposed visual treatment vs. a status-quo (visually identical) treatment. ### ❓ Questions - What specific study or dataset backs the closing "when we look at the data" claims (00:45:21) about legible text, checkbox size, and predictable Back-button behavior — Friedman names no source? - How does the Amazon triangle-hover pattern perform on hybrid touch/pointer devices where hover isn't consistently available? - Does aria-disabled plus inline messaging measurably reduce abandonment versus a true disabled attribute, and by how much, in a live checkout flow? - Does building a dedicated accessibility-persona set (Gov.uk's approach) produce better design outcomes than extending existing personas, or is Friedman right that the choice doesn't matter much? - What fraction of the sites Friedman critiques for scroll-hijacking (Van Gogh Museum, the unnamed slider example) actually violate `prefers-reduced-motion` versus simply having no reduced-motion path at all? ### 🔮 Future Research - A longitudinal study of conversion-rate change after teams redesign disabled-state checkout buttons using Friedman's aria-disabled-plus-messaging pattern. - A cross-cultural study of "navigation query" homepages (Düsseldorf, ao.com) to see whether the pattern transfers outside Europe or depends on specific service-catalog structures. - A systematic comparison of dedicated accessibility personas (Gov.uk) versus baseline-persona extension across multiple product teams. ### 💡 Implications - **Practice:** design-system teams should document a disabled/hidden/read-only decision tree (00:41:41) as a first-class component-library artifact, not a one-off blog post. - **Policy:** regulatory frameworks like the European Accessibility Act risk producing the exact "just enough to comply, then stop" behavior Friedman describes at 00:04:56 — a signal worth surfacing to WCAG working groups and to teams writing internal accessibility policy. - **Security/robustness:** aria-disabled patterns require careful focus and keyboard-trap management; adopting them without testing keyboard flow can trade one accessibility bug for another. - **Education:** the decision tree and the states taxonomy (Goldman Sachs progress bar, Scott Hurff's UI stack, Eric Bailey's research) are ready-made curriculum material for a hands-on training module. - **Funding:** WordPress Accessibility Day's transparent, tiered sponsor list is a reusable model for community events funding ongoing (not one-off) accessibility education. ### 🧠 Learning Styles Assessment - **Reading level estimate:** Flesch-Kincaid Grade Level 8.5, Flesch Reading Ease 64.7 (Standard/fairly easy), computed from the full transcript (9,100 words, 532 sentences, 13,426 syllables) using the standard Flesch-Kincaid formula: 0.39×(words/sentences) + 11.8×(syllables/words) − 15.59. #### 👀 Visual learners - Present: the talk is slide-heavy (dashboards, charts, menu screenshots, the states decision tree) but the transcript alone carries no image, so a visual learner reading only this note loses most of the content — the charts and screenshots exist only in the video. - Improve: pair this note with slide screenshots or a static PNG export of the decision tree at 00:41:41 for anyone working from text alone. #### 🔊 Aural learners - Present: the source is audio-first — a live conference talk with real captions available (confirmed manual English captions on the YouTube video). - Improve: a 2-3 minute audio recap of just the decision tree and the "most expensive buttons" claim would serve aural learners who don't have 48 minutes. #### 🗣️ Verbal learners - Present: Friedman defines terms as he goes (disabled vs. hidden vs. read-only, situational vs. temporary vs. permanent) and uses concrete analogies (the address-validator story, the Prodigy-concert hearing story). - Improve: a short glossary of the three states plus the three impairment types would help verbal learners scan for definitions without watching the full talk. #### 🧩 Kinesthetic learners - Present: the drag-and-drop keyboard pattern (Tab/Space/Arrow/Space) and the aria-disabled recommendation are step-by-step enough to try directly. - Improve: a small CodePen or Playground demo of the aria-disabled-plus-messaging pattern would let a kinesthetic learner build the pattern instead of reading about it. #### 🧠 Logical learners - Present: the decision tree at 00:41:41 is exactly the kind of causal, branching structure logical learners want. - Improve: a rendered flowchart diagram (not just a described one) would make the decision tree scannable without watching the video segment. #### 🧑‍🤝‍🧑 Social learners - Present: the talk was delivered live with a Zoom Q&A channel, though the Q&A never happened due to Friedman's last-minute absence. - Improve: a moderated async discussion thread on the decision tree (disabled vs. hidden vs. read-only) would recover the missed Q&A value for social learners. #### 🧘‍♀️ Solitary learners - Present: the note's timestamped structure lets a solitary learner jump straight to any pattern (colorblindness, motion sickness, states) without watching linearly. - Improve: a self-check quiz ("is this component disabled, hidden, or read-only?") built from the decision tree would give solitary learners a way to test retention. #### 🌿 Naturalistic learners - Present: not addressed — the talk has no sustainability or environmental-systems content. - Improve: not applicable to this source; no natural tie-in exists without stretching the material. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: the video carries real closed captions (confirmed via manual English subtitle track on YouTube), and this note's headings give a screen-reader-navigable outline of the talk's structure. - Improve: the source video's slides (charts, menu screenshots) have no described alt-text equivalent beyond what Friedman narrates aloud — maps to WCAG 2.2 SC 1.1.1 (Non-text Content). #### Keyboard navigation - Present: not directly assessable from a transcript-only capture; YouTube's own player supports standard keyboard control. - Improve: not applicable to this source's transcript — this criterion applies to the player, not the content captured here. #### Contrast and readability - Present: this note's text carries no color-dependent meaning. - Improve: not applicable — no visual contrast to assess in a text-only capture. #### Text resizing and reflow - Present: this markdown note reflows naturally in any Obsidian/Reader view. - Improve: not applicable to this source. #### Media and captions - Present: the video has a manual (non-auto-generated) English caption track, confirmed directly against YouTube — this is above the auto-caption baseline most conference recordings ship with. - Improve: the color-palette and chart examples (00:11:17–00:14:55) rely on the viewer seeing the slide; a fuller audio description of specific hues shown (not just "green will be replaced by blue") would close a WCAG 2.2 SC 1.4.1 (Use of Color) gap for a blind or low-vision viewer following audio only. #### Forms and interactions - Present: not applicable to this source — a recorded talk has no interactive form for the viewer. - Improve: not applicable to this source. #### Standards reference - Non-text chart content narrated but not fully alt-texted → WCAG 2.2 SC 1.1.1 (Non-text Content). - Color-dependent chart distinctions (e.g., "green will be replaced by blue") described verbally without full hue detail → WCAG 2.2 SC 1.4.1 (Use of Color). - Manual captions present → satisfies WCAG 2.2 SC 1.2.2 (Captions, Prerecorded). - No live Q&A occurred, so no assessment applies to interactive Q&A accessibility. ### 🌍 DEIB Assessment #### Cultural breadth - Present: examples span Germany (Düsseldorf), the UK (Ministry of Justice, Gov.uk, ao.com), the US (Visa, Goldman Sachs, IBM, Intercom, Amazon), and Belarus/Germany (Friedman's own background). - Improve: no Global South or non-Western examples appear; a future edition could add examples from outside Europe/North America. #### Inclusive language - Present: Friedman explicitly rejects "edge cases" and "average users" framing and reframes disability as "a mismatched human interaction" rather than a personal condition — a direct, named critique of common ableist framing. - Improve: the talk doesn't define terms like "vestibular disorder" or "aria-disabled" for a lay audience; a glossary would extend the inclusive-language work into the technical vocabulary. #### Neurodiversity support - Present: cognitive-load scenarios appear throughout (mega-dropdown frustration, the "stressed over cancelled flight" thinking-impairment persona) without being labeled neurodiversity content explicitly. - Improve: the talk never names ADHD, autism, or other neurodivergent conditions directly — an explicit connection between the cognitive-load patterns shown and neurodivergent users would strengthen this section. #### Representation - Present: the speaker is one man, but the cited sources include several named women researchers — Elizabeth Buie, Lisa Charlotte Muth, Susie Lu — giving the citation list gender range even where the stage doesn't. - Improve: a solo-keynote format inherently limits on-stage representation; a panel or paired-speaker format would broaden perspectives directly in the session. #### Psychological safety - Present: Friedman discloses his own hearing loss (00:19:47) and frames the talk as sharing "things I wish I'd known earlier" rather than lecturing, explicitly saying "I'm not trying to be this grumpy person." - Improve: the abrupt, unexplained cancellation of Q&A (00:46:39) leaves audience questions unanswered with no stated follow-up channel — a posted follow-up path (email, forum thread) would restore psychological safety for attendees who prepared questions. ### ✅ Logical Validity #### Strong reasoning - **Causal + concrete example (00:33:24):** Friedman connects a general claim ("disabled buttons are the most expensive buttons out there") to a specific, verifiable mechanism — a checkout validator rejecting a real address the user has held for 10 years, with no path to override or understand the block. The mechanism (users can't diagnose or fix a disabled-but-unexplained control) is stated, not just asserted. - **Mechanism-based reasoning (00:15:37–00:17:36):** the motion-sickness section explains *why* horizontal-scroll-as-vertical-navigation causes distress (a mismatch between visual perception and vestibular expectation) before prescribing the fix (map animation to scroll physics), which is stronger than a bare "avoid parallax" rule. #### Fallacies - **Vague/unnamed appeal to authority, at 00:45:21:** the closing list of "what people want" is introduced with "when we look at the data, what people are complaining, and when we look at the data of what people do" — no study, sample, or source is named for any item on the list (legible text preference, checkbox size preference, Back-button predictability, etc.). This borrows research-backed credibility without giving the audience a way to verify it. **Fix:** cite specific sources (e.g., named usability research from NN/g, Baymard Institute, or Friedman's own client work) for at least the more surprising claims, such as the Back-button and refresh-persistence preferences. #### Tone of voice - Conversational and first-person throughout, with self-deprecating humor ("What a magical, wonderful moment in life, right? ... Unless you don't.") and direct address to the audience ("dear friends," "please write in the plus, in the chat if you can"). The register stays practitioner-to-practitioner rather than lecturing — rhetorical questions ("Why would you keep it, if somebody will never be able to use it?") do most of the persuasive work instead of formal argument. ### 🛡️ DARVO Analysis - **Deny:** not applicable to this source — the talk contains no accusation being denied; it's a solo instructional presentation. - **Attack:** not applicable to this source — Friedman critiques design patterns and industry habits generically, not any named accuser or individual. - **Reverse victim/offender:** not applicable to this source — there is no conflict framing between an accused and an accuser anywhere in the talk. ## 🎯 Conclusion - **Bottom line:** Friedman's strongest and most actionable claim is the disabled/hidden/read-only distinction — these three states get treated as interchangeable, they carry different accessibility contracts (interactivity, discoverability, screen-reader behavior), and mixing them up is expensive: "disabled buttons ... are the most expensive buttons out there" because users can't diagnose what's blocking them. - **Practical next steps:** adopt the decision tree at 00:41:41 as a design-system rule, not a one-off; audit any checkout or form flow for the address-validator failure mode described at 00:33:24; and apply the blue-plus-orange/red colorblind palette rule to chart defaults before the next release. ## 🔄 Refactor Appendix — Accessible Design Patterns for 2025 > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] Disabled, hidden, and read-only states are not interchangeable > [!quote] > They are not interchangeable, and I think I want to emphasize that. **Context & use**: - [00:33:13](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=1993s) — the states section of the talk. - Directly actionable for any component-library or design-token decision on how to represent restricted UI. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H2] Disabled buttons are the most expensive UI element to ship > [!quote] > disabled buttons, especially disabled buttons, are the most expensive buttons out there **Context & use**: - [00:33:41](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=2021s) — tied directly to the address-validator abandonment example. - Feeds the aria-disabled-plus-messaging recommendation later in the same segment. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H3] Blue is the safest hue for colorblind-accessible palettes > [!quote] > we know that blue is the safest hue for users to perceive colors as we do **Context & use**: - [00:14:11](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=851s) — grounds the entire colorblindness palette-rules segment (avoid same-lightness red/green/brown, pink/turquoise/gray, purple/blue). - Directly usable as a default-palette rule for any chart or theme color system. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H4] Accessibility must be retained throughout design, not audited once > [!quote] > accessibility is not something that we add to the website when we're done **Context & use**: - [00:07:36](https://www.youtube.com/watch?v=9vjntLrQ6z0&t=456s) — Friedman quoting Scott Jehl to open the talk's thesis. - Frames every later pattern as a "retain, don't audit" discipline. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] A component's restriction type determines its accessibility contract **Claim** (one sentence, Courtney's voice): Whether a UI element should be hidden, disabled, or read-only depends on one question — can the user ever interact with it — and that answer, not visual convenience, should drive the markup and styling choice. **Evidence pointer**: [[#H1]] [[#H2]] **Scope & conditions**: Holds for form controls, buttons, and data-display components in web and app UI; doesn't extend cleanly to purely decorative or non-interactive content, where the distinction is moot. **Links** (≥1 with annotation): - [[WCAG 2.2 AA]] — because evidence-for (SC-level backing for making restriction states screen-reader legible) - [[Design system component states]] — because applies-in (any design-token library defining disabled/read-only variants) <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Check whether courtneyr.dev or client projects use plain `disabled` attributes anywhere a validator can block a valid input — cross-reference against the address-validator failure mode at 00:33:24. #xref - [F2] Look up Eric Bailey's UI-states research directly — cited but not linked in the talk; worth sourcing for the full state taxonomy beyond disabled/hidden/read-only. #xref ### → Things 3 (max 2 actions) - [ ] Audit any WordPress plugin or theme project with disabled checkout/submit buttons against the aria-disabled-plus-messaging pattern from 00:33:24 — context: accessibility backlog #things - [ ] Pull the colorblind palette rule (blue + orange/red, no same-lightness pairs) into the current design-token reference — context: design system #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Accessible Design Patterns for 2025.md|Accessible Design Patterns for 2025 by Vitaly Friedman]] ## Highlights - So, that's a really nice way of having-- Where we actually could be going. Right? So, in general, I think, what I always keep in mind is that whenever we're dealing with colorblindness, we know that blue is the safest hue for users to perceive colors as we do. You can use any two colors as long as they vary significantly by lightness. Colorblind users might tell red and green apart, but not necessarily which is which. Right? Colorblind's safest palette is the mix of blue with orange and red. We should forget about pastel colors only. ([View Highlight](https://read.readwise.io/read/01m21ead1ve5wgwqyj0fq35c2h)) - Note: Practical palette rule: blue is the safest hue, any two colors work if they differ enough in lightness, and blue+orange+red is the safest combination. Pairs with Roberts' pattern-versus-solid fix in the colourblind designer talk. - Tags: inclusive-design, color-accessibility, atom/literature/h3 - Disabled, hidden, read-only. Now, all these variants indicate the same thing, but do so very differently. They indicate restrictions and unavailability, but they do so really quite differently. They are not interchangeable, and I think I want to emphasize that. They are not interchangeable, and they can apply to both content, and to actions as well. So, let's go through them to understand what it means. First of all, when a component is disabled, it means that people are not, or users are not allowed to interact with it in some way. ([View Highlight](https://read.readwise.io/read/01m21ea5k5dg22e18ytmq3h6h4)) - Note: Friedman's core distinction, emphasized twice: disabled, hidden, and read-only signal restriction but are not interchangeable, and they apply to both content and actions. Most design systems conflate them. - Tags: ux-design-patterns, atom/literature/h1, ui-states