Guide to the Inclusive Design Principles
🔗 **Source:** [Guide to the Inclusive Design Principles](https://tetralogical.com/blog/2025/10/07/guide-to-the-inclusive-design-principles/)
> [!note]+ Document Notes
> tags: [inclusive-design, accessibility, UX-design]
> author: [Henny]
> source: [TetraLogical]
> reference: [https://tetralogical.com/blog/2025/10/07/guide-to-the-inclusive-design-principles/]
> date created: 2026-01-19 10:00
>
> # 🏷️ Title: Guide to the Inclusive Design Principles
>
<!-- 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
- Include links cited in or relevant to the article.
## 📝 Summary
- What happened: The article explains the Inclusive Design Principles (IDP), why they exist alongside WCAG, and how to apply them throughout product work.
- Why it matters: IDP shift teams from box-ticking accessibility to people-centred, inclusive design that improves usability for everyone.
- Key stakeholders: Designers, developers, writers, product managers, QA, researchers, and people with disabilities using digital products.
- Risks and tradeoffs: Novel features or visual “delight” can undermine inclusion; prioritising inclusion may constrain some design choices but reduces remediation cost.
- Bottom line: Use IDP plus WCAG to embed inclusion from research to testing, focusing on comparable experiences, context, control, prioritised content, and added value.
## 📖 Main Content
- IDP were created to fill gaps left by WCAG, covering design decisions that shape whether interfaces feel inclusive, usable, and welcoming.
- Core principles described include: providing a comparable experience, considering situational context, being consistent, giving people control, offering choice, prioritising content, and adding genuine value.
- The principles apply across many interfaces (websites, apps, kiosks, automotive, voice, wearables) and to flows, blueprints, content strategy, and design systems.
- They support teams by embedding inclusion from the start, guiding trade-offs, reducing rework, and going beyond compliance to user experience.
- They support users by prioritising disabled people, improving usability for all, and building a culture of inclusion.
- IDP can shape research questions, requirements (e.g., dashboard control and customisation), design reviews (e.g., prominent donate/support actions, voice input), development choices, and QA when usability testing with disabled people isn’t possible.
- Used alongside WCAG, IDP provide a design lens, helping teams move from compliance to an accessibility culture.
### 🗒️ Notes
- IDP were first published in 2016 by Henny, Ian Pouncey, Léonie Watson, and Heydon Pickering to address design aspects beyond WCAG that still determine inclusiveness.
- They offer people-centred guidance that avoids unnecessary complexity and help teams make better design decisions across a wide range of digital interfaces.
- **Provide a comparable experience:** ensure alternatives (alt text, captions, audio description, transcripts) are high quality and treated as primary content for those who rely on them; different ways of consuming/navigating must be equally usable and enjoyable.
- **Consider situation:** design for diverse environments and states (crowded train, low signal, fatigue, temporary or permanent changes in ability); interfaces should adapt so tasks remain achievable.
- **Be consistent:** use familiar internal patterns (design system, keyboard behaviours, language guidelines) and external web conventions to reduce cognitive load and support confident navigation.
- **Give control:** respect user preferences for how content is experienced; allow pausing animations/video, stopping carousels, zooming without layout breakage, and adjusting fonts/colours; avoid one-size-fits-all.
- **Offer choice:** provide multiple ways to complete tasks, especially complex or unfamiliar ones (e.g., drag-and-drop and standard form fields, online or offline forms, live chat or help articles).
- **Prioritise content:** put key tasks and information early in the content order; support scanning with clear headings, front-loaded link text, concise copy, and removal of distractions—especially important for non-mouse users, people with limited time, lower literacy, or attention-related disabilities.
- **Add value:** ensure new features genuinely improve inclusion and don’t introduce barriers (e.g., show-password toggles, voice input for search/forms, configurable notifications).
- IDP apply to automotive UIs, biometrics, chatbots, kiosks, mobile apps, QR-code experiences, smart home and voice interfaces, wearables, websites, and also to journeys, blueprints, content strategy, and design systems.
- They are “for everyone involved” in designing, building, and delivering digital products: UX/UI/service designers, developers, content designers, PMs/POs, QA, researchers, and UX specialists.
- For product teams, IDP: provide shared language; help weigh trade‑offs; reduce late-stage fixes; and keep focus on people rather than checkbox compliance.
- For people using products, especially disabled people, IDP: prioritise their needs, improve usability for all users, and foster a mindset of inclusion.
- IDP can frame research by posing questions such as whether a screenreader or voice-input user has a comparable experience, or how to offer multiple ways to complete a task.
- They translate into requirements, e.g., dashboards that let people control update timing and which content appears, helping those with thinking, seeing, or movement disabilities reduce overload and distraction.
- In design reviews, IDP help assess layouts, patterns, and language; examples include prioritising “donate” and “get support” buttons on a charity site and adding voice input to search.
- During development, IDP help choose between implementations by asking which better supports diverse needs and more comparable experiences, even when both are technically functional.
- During testing/QA, IDP can guide experience reviews and scenario-based checks (e.g., can animations be paused, is content clearly prioritised for touch or voice navigation) when direct testing with disabled people isn’t available.
- Paired with WCAG, IDP cover the subjective and contextual aspects of design, making experiences more inclusive and shifting accessibility from compliance to culture.
- The article notes broad adoption of IDP in design systems, accessibility programmes, and training worldwide, and that TetraLogical uses them in consulting to embed accessibility into strategies, processes, and products.
## 📚 References
- Inclusive Design Principles (original site): https://inclusivedesignprinciples.org
- Web Content Accessibility Guidelines (WCAG) overview: https://www.w3.org/WAI/standards-guidelines/wcag/
- TetraLogical WCAG primer (mentioned in article): https://tetralogical.com/blog/tag/wcag/
## 🗣️ Paraphrase
- Paragraph A paraphrase: The Inclusive Design Principles extend beyond WCAG by guiding design choices that determine whether digital products are truly inclusive and pleasant to use, not just technically compliant.
- Paragraph B paraphrase: Teams can use these principles at every stage—from research to QA—to frame questions, set requirements, review designs, and choose implementations that provide comparable, context-aware, controllable, and valuable experiences for all users.
## 📰 Newsletter
Inclusive design goes beyond passing WCAG checklists. In this week’s spotlight, we’re diving into TetraLogical’s “Guide to the Inclusive Design Principles,” which shows how to design for real people in real contexts—crowded trains, low bandwidth, assistive tech and all.
From prioritising core tasks in your layouts to giving users control over motion and live updates, these principles are a great lens for WordPress product teams: theme authors, plugin devs, and site builders alike. Consider how your next feature can offer genuine choice (mouse, keyboard, touch, voice) while keeping experiences consistent and comparable for everyone.
Want to go deeper? Pair these ideas with the WCAG docs and your favourite auditing tools, and run an “IDP review” on one key flow (like checkout or donations). Small improvements—like better headings, voice input for search, or show-password toggles—can have outsized impact on accessibility and user happiness.
## ✅ Action Items
#### DevRel
- Document example integrations of IDP for plugin and theme authors (e.g., “comparable experience” checklists for common WP flows).
- Run workshops on designing for context (low bandwidth, screen readers, keyboard-only) using WordPress demos.
- Add IDP-aligned code samples and patterns to SDKs, starter themes, and block examples.
- Publish blog posts and talks showing before/after UX when applying “prioritise content” and “give control.”
- Survey developer community about their biggest accessibility design trade-offs to inform future guidance.
#### OSPO
- Incorporate IDP references into open source contribution guidelines and design review charters.
- Add accessibility and inclusive design checks to license/compliance review workflows where UI is involved.
- Align security-related UX (e.g., 2FA flows) with IDP principles like offering choice and considering context.
- Track accessibility and inclusion improvements in SBOM-adjacent inventories for key UI components.
- Promote training materials on IDP for internal maintainers and community contributors.
#### Community
- Support maintainers with templates for inclusive roadmaps and decision logs that explicitly reference IDP.
- Create contributor onboarding paths that include short primers on inclusive design.
- Communicate sponsorship impact by highlighting accessibility and inclusion outcomes in reports.
- Coordinate cross-project incident drills that include accessibility regressions (e.g., broken keyboard navigation).
#### WordPress
- Core: Apply “prioritise content” to wp-admin and key front-end flows; standardise heading and landmark patterns.
- Core Performance: Ensure performance improvements don’t break zoom/reflow or introduce motion-heavy UI without controls.
- Core AI: Bake in controls, transparency, and accessible outputs into AI-assisted features; avoid inaccessible UI gimmicks.
- **Core Program Team:** Embed IDP checks into cross-team review rituals and release criteria.
- Mobile: Ensure gestures have keyboard/alternative inputs; respect system accessibility settings (text size, motion).
- Playground: Provide accessible example scenarios to test IDP (screen reader, keyboard-only, low bandwidth).
- Community: Update WordCamp and meetup materials to model inclusive slide design and demo flows.
- Training: Incorporate IDP into lesson plans and learning paths for site builders and developers.
- Marketing: Use clear, plain language and accessible layouts in campaigns; avoid motion-heavy content without controls.
- Support: Update knowledge base with IDP-aligned guidance (e.g., how to fix common accessibility issues in themes).
- Design: Run UX audits focusing on comparable experience, content priority, and user control.
- Documentation: Add examples-first patterns that demonstrate IDP in forms, navigation, and media.
- Photos: Ensure imagery reflects diverse users and has meaningful alt text supporting inclusive narratives.
- TV: Enforce quality captions and transcripts; consider audio description guidance for key educational content.
- Polyglots: Make sure translated UIs preserve consistent patterns and accessible language.
- Accessibility: Map IDP to WCAG issues to prioritise the most impactful fixes; visualise hot spots.
- Meta: Ensure .org tools (trac, plugin/theme directories) follow IDP, especially for search and submission flows.
- CLI: Provide accessible help text and examples; ensure messages are clear and prioritise key information.
- Hosting: Encourage default configurations that respect zoom, reflow, caching for low-bandwidth, and motion reduction.
- Tide: Surface signals related to inclusive design (e.g., heading structure, focus trapping) in scoring where feasible.
- Openverse: Prioritise filters and controls; ensure media has pathways for alt text and captions.
- Themes: Provide starter patterns that already embody the principles (e.g., clear hierarchy, keyboard-friendly menus).
- Plugins: Promote accessible UI patterns in approval criteria; provide guidance for complex widgets/components.
#### The WPOCC
- Launch microgrants for maintainers improving accessibility and inclusive design in high-impact plugins/themes.
- Offer governance clinics that help projects formalise accessibility review as part of decision-making.
- Fund documentation and training sprints focused on IDP-aligned UX practices.
### FAIR
- Encourage independent, open tools that can assess both WCAG and IDP-style inclusive design aspects.
- Adopt transparent funding and governance commitments for accessibility-related initiatives.
- Provide reusable governance artifacts (e.g., “accessibility charter” templates) that projects can adopt.
## 🧪 Hypotheses
- Teams that systematically apply IDP will produce interfaces with fewer accessibility issues than teams focused only on WCAG.
- Prioritising content in layout and structure will significantly reduce task completion time for users with cognitive or attention-related disabilities.
- Providing user control over motion and live updates will decrease error rates and abandonment in complex dashboards.
- Offering multiple ways to complete tasks (choice) will improve success rates for users with motor or language-related barriers.
- Using IDP as a lens in design reviews will reduce the number and severity of accessibility bugs discovered in late QA.
### 📊 Methodology
- Run A/B studies comparing WCAG-only vs WCAG+IDP design processes; measure accessibility findings and user satisfaction.
- Conduct usability tests with disabled participants focusing on flows designed with and without explicit content prioritisation.
- Instrument dashboards to compare behavioural metrics before/after adding user controls over updates and motion.
- Log task completion and error rates when users can choose between alternative interaction methods (drag-and-drop vs forms, text vs voice input).
- Analyse design review notes from teams using IDP checklists vs control teams to see defect patterns.
### ❓ Questions
- How can teams quickly introduce IDP into existing, legacy-heavy design systems?
- Which IDP principle tends to deliver the largest usability gains across diverse disabilities?
- How can small teams with limited resources prioritise which principles to focus on first?
- What metrics best capture “comparable experience” in practice?
- How can community contributions be guided so they don’t regress existing inclusive patterns?
### 🔮 Future Research
- Develop standardised evaluation frameworks for “comparable experience” across assistive technologies.
- Explore automation and tooling that highlight IDP-related issues (e.g., content priority, control over motion).
- Study long-term organisational impact of framing accessibility as culture rather than compliance.
- Investigate how IDP work across non-visual or low-screen environments (voice-only, automotive, wearables).
### 💡 Implications
- Practice: Teams need to embed IDP into design systems, reviews, and QA to ensure inclusion is routine, not exceptional.
- Policy: Organisations can reference IDP in internal standards and procurement to raise accessibility expectations.
- Security: Inclusive flows for authentication and consent must balance safety with user control and multiple access paths.
- Education: Training programs for designers and developers should teach IDP as a complement to WCAG.
- Funding: Grants and sponsorships can prioritise projects that demonstrably adopt inclusive design principles.
### 🧠 Learning Styles Assessment
- Reading level estimate: Around grade 10–11 (Flesch-Kincaid) due to professional vocabulary and multi-clause sentences.
#### 👀 Visual learners
- Present: Conceptual structure through headings and bullet lists; implicit hierarchy in examples.
- Improve: Add diagrams of user journeys, before/after layouts showing content priority, and control/choice matrices with annotations.
#### 🔊 Aural learners
- Present: None explicitly mentioned.
- Improve: Provide an audio narration of the article and a short 2–5 minute audio summary; add speaker notes for talks based on the piece.
#### 🗣️ Verbal learners
- Present: Clear definitions (e.g., comparable experience, prioritise content) and concrete examples.
- Improve: Include a short glossary of key terms, plus story-driven case studies illustrating each principle.
#### 🧩 Kinesthetic learners
- Present: Implicit tasks (e.g., review flows against principles) but not step-by-step.
- Improve: Add checklists and small “apply this to one page today” exercises with clear, repeatable steps.
#### 🧠 Logical learners
- Present: Structured arguments, lists of applications, and clear cause-effect statements (principle → benefit).
- Improve: Include decision trees for trade-offs, tables mapping IDP to WCAG criteria and user needs.
#### 🧑🤝🧑 Social learners
- Present: Framing for teams and collaboration.
- Improve: Offer discussion prompts for design critiques and team workshops, plus sample agendas.
#### 🧘♀️ Solitary learners
- Present: Article suitable for quiet reflection.
- Improve: Add self-check questions and reflection prompts (“Where does my product fail to offer choice?”).
#### 🌿 Naturalistic learners
- Present: Limited explicit environment analogies.
- Improve: Draw analogies to physical-world accessibility (ramps, signage, noise) and relate to sustainability of inclusive products.
### 📊 Accessibility Assessment
#### Screen reader semantics
- Present: Strong emphasis on headings, content order, and comparable alternatives; implies good semantics as a goal.
- Improve: Explicitly call out the need for correct landmark roles, lang attributes, and descriptive alt text patterns.
#### Keyboard navigation
- Present: References to non-mouse users and consistent keyboard behaviour.
- Improve: Stress avoiding keyboard traps, ensuring all controls are focusable, and documenting keyboard patterns.
#### Contrast and readability
- Present: Focus on readability and reducing cognitive load; not specific about contrast ratios.
- Improve: Recommend minimum contrast, line-height, spacing, and avoiding low-contrast decorative elements.
#### Text resizing and reflow
- Present: Zoom support without layout breakage is explicitly mentioned.
- Improve: Encourage testing at 200–400% zoom, supporting reflow, and honouring reduced-motion preferences.
#### Media and captions
- Present: Strong emphasis on high-quality captions, transcripts, and audio descriptions as primary content.
- Improve: Recommend downloadable transcripts, no autoplay by default, and optional audio description tracks.
#### Forms and interactions
- Present: Examples like show-password toggles, voice input, multiple ways to complete tasks.
- Improve: Explicit guidance on labels, error messaging, validation timing, and target sizes.
#### Standards reference
- Present: Clear that WCAG is essential but not sufficient; IDP complement it.
- Improve: Map each principle to relevant WCAG 2.2 AA success criteria to guide audits.
### 🌍 DEIB Assessment
#### Cultural breadth
- Present: Mentions global adoption and varied interface types; some implicit breadth.
- Improve: Add multi-region examples, translation considerations, and localisation case studies.
#### Inclusive language
- Present: Consistent, people-first, disability-positive language; jargon is moderate and mostly defined in context.
- Improve: Provide a brief plain-language summary for non-specialists and avoid subtle specialist terms where unnecessary.
#### Neurodiversity support
- Present: Emphasis on cognitive load, attention-related disabilities, and content prioritisation.
- Improve: More guidance on predictable patterns, icon+text combinations, and reducing sensory overload.
#### Representation
- Present: Focuses on “people with seeing, hearing, moving, and thinking disabilities” explicitly.
- Improve: Use examples that reflect varied identities, regions, and socio-economic contexts in imagery and scenarios.
#### Psychological safety
- Present: Respectful framing of disability and inclusion, no blame.
- Improve: Suggest community guidelines or team norms for accessible design reviews and feedback.
### ✅ Logical Validity
#### Strong reasoning
- The article uses strong causal reasoning: applying IDP leads to fewer barriers, reduced remediation work, and better usability for everyone; links are plausible and supported by concrete examples.
- It employs inductive reasoning from practical patterns (e.g., voice input, show password, dashboard controls) to general principles, making the guidance actionable and credible.
#### Fallacies
- None obvious; claims are moderate and framed as guidance, not absolute guarantees. Where impacts are stated, they are reasonable and align with common UX findings.
#### Tone of voice
- Tone is professional, practical, and inclusive, focusing on collaboration and continuous improvement rather than blame or compliance fear.
### 🛡️ DARVO Analysis
- Deny: No denial or minimisation of accessibility problems; the piece acknowledges existing gaps and limitations of WCAG-only approaches.
- Attack: No attacks on users, regulators, or non-compliant teams; the tone is supportive.
- Reverse victim/offender: No attempt to recast organisations as victims; instead, it frames inclusive design as an opportunity and responsibility.
## 🎯 Conclusion
The article positions the Inclusive Design Principles as a practical, people-centred companion to WCAG. By focusing on comparable experiences, situational context, consistency, user control, choice, content priority, and added value, teams can design more inclusive products across platforms and life cycles. Next steps: weave IDP into your design system, use them to frame research and reviews, and pair them with WCAG in audits to shift from compliance to an accessibility culture.
## 🧱 Refactor Appendix (append after 🎯 Conclusion)
### 📚 Literature Split Pad
- Purpose: Stage Konik CEE units that become per-source Literature notes.
- Split level: **H3**.
- Include verbatim quotes under 25 words and a [view highlight] link.
### [H1] 5–10-word present-tense claim
> [!quote] [Guide to the Inclusive Design Principles](https://tetralogical.com/blog/2025/10/07/guide-to-the-inclusive-design-principles/) by [[Henny]] via [[TetraLogical]]. Published 2025-10-07.
> “The principles don’t replace WCAG or other standards; they provide a lens for good design that includes everyone.”
Two lines: context and use. Cite data if relevant.
[view highlight](https://tetralogical.com/blog/2025/10/07/guide-to-the-inclusive-design-principles/#H1) #xref #articleseed ID:rw_[MISSING]
### [H2] 5–10-word present-tense claim
> [!quote] [Guide to the Inclusive Design Principles](https://tetralogical.com/blog/2025/10/07/guide-to-the-inclusive-design-principles/)
> “Providing a comparable experience is more than just adding alternatives for images, video, and audio.”
Two lines: context and use.
[view highlight](https://tetralogical.com/blog/2025/10/07/guide-to-the-inclusive-design-principles/#H2) #xref ID:rw_[MISSING]
---
### 🔖 Atomic Split Pad (Zettel Candidates)
- Purpose: Promote reusable claims into Atomic notes.
- Split level: **H4**.
- Each item: one idea, present tense, specific, testable.
#### [Z1] Inclusive design extends beyond WCAG compliance
- Scope/condition in one line.
- Pointer to page/time or dataset.
- Links: [[Inclusive-Design]] [[Accessibility-Guidelines]]
#### [Z2] Comparable experiences require high-quality alternatives
- Scope/condition in one line.
- Pointer to page/time or dataset.
- Links: [[Assistive-Technology]] [[Media-Accessibility]]
---
### ✏️ Fleeting Queue (Extract by Selection)
- Purpose: Capture quick actions or sparks for Fleeting notes.
- Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).”
- Keep each line short and self-contained.
- [F1] Run an IDP-based review of our main onboarding flow—compare with current WCAG-only checklist./https://tetralogical.com/blog/2025/10/07/guide-to-the-inclusive-design-principles/ #fleeting #inbox
- [F2] Prototype voice input for search to offer choice alongside keyboard./https://tetralogical.com/blog/2025/10/07/guide-to-the-inclusive-design-principles/ #fleeting #inbox
- [F3] Update design system docs with “prioritise content” guidelines and examples./https://tetralogical.com/blog/2025/10/07/guide-to-the-inclusive-design-principles/ #fleeting #inbox
---
<!-- deep-read:sections end -->
[[3. Resources/Readwise/Full Document Contents/Articles/Guide to the Inclusive Design Principles|Full Document Contents]]
## Document Notes
---
tags: #inclusive-design #accessibility #UX-design
author: [Henny]
source: [TetraLogical]
reference: [https://tetralogical.com/blog/2025/10/07/guide-to-the-inclusive-design-principles/]
date created: 2026-01-19 10:00
---
# 🏷️ Title: Guide to the Inclusive Design Principles
## 🧭 Table of Contents
- [[#📝 Summary]]
- [[#📖 Main Content]]
- [[#🗒️ Notes]]
- [[#📚 References]]
- [[#🗣️ Paraphrase]]
- [[#📰 Newsletter]]
- [[#✅ Action Items]]
- [[#🧪 Hypotheses]]
- [[#📊 Methodology]]
- [[#❓ Questions]]
- [[#🔮 Future Research]]
- [[#💡 Implications]]
- [[#🧠 Learning Styles Assessment]]
- [[#📊 Accessibility Assessment]]
- [[#🌍 DEIB Assessment]]
- [[#✅ Logical Validity]]
- [[#🛡️ DARVO Analysis]]
- [[#🎯 Conclusion]]
### 🔗 References
- Include links cited in or relevant to the article.
## 📝 Summary
- What happened: The article explains the Inclusive Design Principles (IDP), why they exist alongside WCAG, and how to apply them throughout product work.
- Why it matters: IDP shift teams from box-ticking accessibility to people-centred, inclusive design that improves usability for everyone.
- Key stakeholders: Designers, developers, writers, product managers, QA, researchers, and people with disabilities using digital products.
- Risks and tradeoffs: Novel features or visual “delight” can undermine inclusion; prioritising inclusion may constrain some design choices but reduces remediation cost.
- Bottom line: Use IDP plus WCAG to embed inclusion from research to testing, focusing on comparable experiences, context, control, prioritised content, and added value.
## 📖 Main Content
- IDP were created to fill gaps left by WCAG, covering design decisions that shape whether interfaces feel inclusive, usable, and welcoming.
- Core principles described include: providing a comparable experience, considering situational context, being consistent, giving people control, offering choice, prioritising content, and adding genuine value.
- The principles apply across many interfaces (websites, apps, kiosks, automotive, voice, wearables) and to flows, blueprints, content strategy, and design systems.
- They support teams by embedding inclusion from the start, guiding trade-offs, reducing rework, and going beyond compliance to user experience.
- They support users by prioritising disabled people, improving usability for all, and building a culture of inclusion.
- IDP can shape research questions, requirements (e.g., dashboard control and customisation), design reviews (e.g., prominent donate/support actions, voice input), development choices, and QA when usability testing with disabled people isn’t possible.
- Used alongside WCAG, IDP provide a design lens, helping teams move from compliance to an accessibility culture.
### 🗒️ Notes
- IDP were first published in 2016 by Henny, Ian Pouncey, Léonie Watson, and Heydon Pickering to address design aspects beyond WCAG that still determine inclusiveness.
- They offer people-centred guidance that avoids unnecessary complexity and help teams make better design decisions across a wide range of digital interfaces.
- **Provide a comparable experience:** ensure alternatives (alt text, captions, audio description, transcripts) are high quality and treated as primary content for those who rely on them; different ways of consuming/navigating must be equally usable and enjoyable.
- **Consider situation:** design for diverse environments and states (crowded train, low signal, fatigue, temporary or permanent changes in ability); interfaces should adapt so tasks remain achievable.
- **Be consistent:** use familiar internal patterns (design system, keyboard behaviours, language guidelines) and external web conventions to reduce cognitive load and support confident navigation.
- **Give control:** respect user preferences for how content is experienced; allow pausing animations/video, stopping carousels, zooming without layout breakage, and adjusting fonts/colours; avoid one-size-fits-all.
- **Offer choice:** provide multiple ways to complete tasks, especially complex or unfamiliar ones (e.g., drag-and-drop and standard form fields, online or offline forms, live chat or help articles).
- **Prioritise content:** put key tasks and information early in the content order; support scanning with clear headings, front-loaded link text, concise copy, and removal of distractions—especially important for non-mouse users, people with limited time, lower literacy, or attention-related disabilities.
- **Add value:** ensure new features genuinely improve inclusion and don’t introduce barriers (e.g., show-password toggles, voice input for search/forms, configurable notifications).
- IDP apply to automotive UIs, biometrics, chatbots, kiosks, mobile apps, QR-code experiences, smart home and voice interfaces, wearables, websites, and also to journeys, blueprints, content strategy, and design systems.
- They are “for everyone involved” in designing, building, and delivering digital products: UX/UI/service designers, developers, content designers, PMs/POs, QA, researchers, and UX specialists.
- For product teams, IDP: provide shared language; help weigh trade‑offs; reduce late-stage fixes; and keep focus on people rather than checkbox compliance.
- For people using products, especially disabled people, IDP: prioritise their needs, improve usability for all users, and foster a mindset of inclusion.
- IDP can frame research by posing questions such as whether a screenreader or voice-input user has a comparable experience, or how to offer multiple ways to complete a task.
- They translate into requirements, e.g., dashboards that let people control update timing and which content appears, helping those with thinking, seeing, or movement disabilities reduce overload and distraction.
- In design reviews, IDP help assess layouts, patterns, and language; examples include prioritising “donate” and “get support” buttons on a charity site and adding voice input to search.
- During development, IDP help choose between implementations by asking which better supports diverse needs and more comparable experiences, even when both are technically functional.
- During testing/QA, IDP can guide experience reviews and scenario-based checks (e.g., can animations be paused, is content clearly prioritised for touch or voice navigation) when direct testing with disabled people isn’t available.
- Paired with WCAG, IDP cover the subjective and contextual aspects of design, making experiences more inclusive and shifting accessibility from compliance to culture.
- The article notes broad adoption of IDP in design systems, accessibility programmes, and training worldwide, and that TetraLogical uses them in consulting to embed accessibility into strategies, processes, and products.
## 📚 References
- Inclusive Design Principles (original site): https://inclusivedesignprinciples.org
- Web Content Accessibility Guidelines (WCAG) overview: https://www.w3.org/WAI/standards-guidelines/wcag/
- TetraLogical WCAG primer (mentioned in article): https://tetralogical.com/blog/tag/wcag/
## 🗣️ Paraphrase
- Paragraph A paraphrase: The Inclusive Design Principles extend beyond WCAG by guiding design choices that determine whether digital products are truly inclusive and pleasant to use, not just technically compliant.
- Paragraph B paraphrase: Teams can use these principles at every stage—from research to QA—to frame questions, set requirements, review designs, and choose implementations that provide comparable, context-aware, controllable, and valuable experiences for all users.
## 📰 Newsletter
Inclusive design goes beyond passing WCAG checklists. In this week’s spotlight, we’re diving into TetraLogical’s “Guide to the Inclusive Design Principles,” which shows how to design for real people in real contexts—crowded trains, low bandwidth, assistive tech and all.
From prioritising core tasks in your layouts to giving users control over motion and live updates, these principles are a great lens for WordPress product teams: theme authors, plugin devs, and site builders alike. Consider how your next feature can offer genuine choice (mouse, keyboard, touch, voice) while keeping experiences consistent and comparable for everyone.
Want to go deeper? Pair these ideas with the WCAG docs and your favourite auditing tools, and run an “IDP review” on one key flow (like checkout or donations). Small improvements—like better headings, voice input for search, or show-password toggles—can have outsized impact on accessibility and user happiness.
## ✅ Action Items
#### DevRel
- Document example integrations of IDP for plugin and theme authors (e.g., “comparable experience” checklists for common WP flows).
- Run workshops on designing for context (low bandwidth, screen readers, keyboard-only) using WordPress demos.
- Add IDP-aligned code samples and patterns to SDKs, starter themes, and block examples.
- Publish blog posts and talks showing before/after UX when applying “prioritise content” and “give control.”
- Survey developer community about their biggest accessibility design trade-offs to inform future guidance.
#### OSPO
- Incorporate IDP references into open source contribution guidelines and design review charters.
- Add accessibility and inclusive design checks to license/compliance review workflows where UI is involved.
- Align security-related UX (e.g., 2FA flows) with IDP principles like offering choice and considering context.
- Track accessibility and inclusion improvements in SBOM-adjacent inventories for key UI components.
- Promote training materials on IDP for internal maintainers and community contributors.
#### Community
- Support maintainers with templates for inclusive roadmaps and decision logs that explicitly reference IDP.
- Create contributor onboarding paths that include short primers on inclusive design.
- Communicate sponsorship impact by highlighting accessibility and inclusion outcomes in reports.
- Coordinate cross-project incident drills that include accessibility regressions (e.g., broken keyboard navigation).
#### WordPress
- Core: Apply “prioritise content” to wp-admin and key front-end flows; standardise heading and landmark patterns.
- Core Performance: Ensure performance improvements don’t break zoom/reflow or introduce motion-heavy UI without controls.
- Core AI: Bake in controls, transparency, and accessible outputs into AI-assisted features; avoid inaccessible UI gimmicks.
- **Core Program Team:** Embed IDP checks into cross-team review rituals and release criteria.
- Mobile: Ensure gestures have keyboard/alternative inputs; respect system accessibility settings (text size, motion).
- Playground: Provide accessible example scenarios to test IDP (screen reader, keyboard-only, low bandwidth).
- Community: Update WordCamp and meetup materials to model inclusive slide design and demo flows.
- Training: Incorporate IDP into lesson plans and learning paths for site builders and developers.
- Marketing: Use clear, plain language and accessible layouts in campaigns; avoid motion-heavy content without controls.
- Support: Update knowledge base with IDP-aligned guidance (e.g., how to fix common accessibility issues in themes).
- Design: Run UX audits focusing on comparable experience, content priority, and user control.
- Documentation: Add examples-first patterns that demonstrate IDP in forms, navigation, and media.
- Photos: Ensure imagery reflects diverse users and has meaningful alt text supporting inclusive narratives.
- TV: Enforce quality captions and transcripts; consider audio description guidance for key educational content.
- Polyglots: Make sure translated UIs preserve consistent patterns and accessible language.
- Accessibility: Map IDP to WCAG issues to prioritise the most impactful fixes; visualise hot spots.
- Meta: Ensure .org tools (trac, plugin/theme directories) follow IDP, especially for search and submission flows.
- CLI: Provide accessible help text and examples; ensure messages are clear and prioritise key information.
- Hosting: Encourage default configurations that respect zoom, reflow, caching for low-bandwidth, and motion reduction.
- Tide: Surface signals related to inclusive design (e.g., heading structure, focus trapping) in scoring where feasible.
- Openverse: Prioritise filters and controls; ensure media has pathways for alt text and captions.
- Themes: Provide starter patterns that already embody the principles (e.g., clear hierarchy, keyboard-friendly menus).
- Plugins: Promote accessible UI patterns in approval criteria; provide guidance for complex widgets/components.
#### The WPCC
- Launch microgrants for maintainers improving accessibility and inclusive design in high-impact plugins/themes.
- Offer governance clinics that help projects formalise accessibility review as part of decision-making.
- Fund documentation and training sprints focused on IDP-aligned UX practices.
### FAIR
- Encourage independent, open tools that can assess both WCAG and IDP-style inclusive design aspects.
- Adopt transparent funding and governance commitments for accessibility-related initiatives.
- Provide reusable governance artifacts (e.g., “accessibility charter” templates) that projects can adopt.
## 🧪 Hypotheses
- Teams that systematically apply IDP will produce interfaces with fewer accessibility issues than teams focused only on WCAG.
- Prioritising content in layout and structure will significantly reduce task completion time for users with cognitive or attention-related disabilities.
- Providing user control over motion and live updates will decrease error rates and abandonment in complex dashboards.
- Offering multiple ways to complete tasks (choice) will improve success rates for users with motor or language-related barriers.
- Using IDP as a lens in design reviews will reduce the number and severity of accessibility bugs discovered in late QA.
### 📊 Methodology
- Run A/B studies comparing WCAG-only vs WCAG+IDP design processes; measure accessibility findings and user satisfaction.
- Conduct usability tests with disabled participants focusing on flows designed with and without explicit content prioritisation.
- Instrument dashboards to compare behavioural metrics before/after adding user controls over updates and motion.
- Log task completion and error rates when users can choose between alternative interaction methods (drag-and-drop vs forms, text vs voice input).
- Analyse design review notes from teams using IDP checklists vs control teams to see defect patterns.
### ❓ Questions
- How can teams quickly introduce IDP into existing, legacy-heavy design systems?
- Which IDP principle tends to deliver the largest usability gains across diverse disabilities?
- How can small teams with limited resources prioritise which principles to focus on first?
- What metrics best capture “comparable experience” in practice?
- How can community contributions be guided so they don’t regress existing inclusive patterns?
### 🔮 Future Research
- Develop standardised evaluation frameworks for “comparable experience” across assistive technologies.
- Explore automation and tooling that highlight IDP-related issues (e.g., content priority, control over motion).
- Study long-term organisational impact of framing accessibility as culture rather than compliance.
- Investigate how IDP work across non-visual or low-screen environments (voice-only, automotive, wearables).
### 💡 Implications
- Practice: Teams need to embed IDP into design systems, reviews, and QA to ensure inclusion is routine, not exceptional.
- Policy: Organisations can reference IDP in internal standards and procurement to raise accessibility expectations.
- Security: Inclusive flows for authentication and consent must balance safety with user control and multiple access paths.
- Education: Training programs for designers and developers should teach IDP as a complement to WCAG.
- Funding: Grants and sponsorships can prioritise projects that demonstrably adopt inclusive design principles.
### 🧠 Learning Styles Assessment
- Reading level estimate: Around grade 10–11 (Flesch-Kincaid) due to professional vocabulary and multi-clause sentences.
#### 👀 Visual learners
- Present: Conceptual structure through headings and bullet lists; implicit hierarchy in examples.
- Improve: Add diagrams of user journeys, before/after layouts showing content priority, and control/choice matrices with annotations.
#### 🔊 Aural learners
- Present: None explicitly mentioned.
- Improve: Provide an audio narration of the article and a short 2–5 minute audio summary; add speaker notes for talks based on the piece.
#### 🗣️ Verbal learners
- Present: Clear definitions (e.g., comparable experience, prioritise content) and concrete examples.
- Improve: Include a short glossary of key terms, plus story-driven case studies illustrating each principle.
#### 🧩 Kinesthetic learners
- Present: Implicit tasks (e.g., review flows against principles) but not step-by-step.
- Improve: Add checklists and small “apply this to one page today” exercises with clear, repeatable steps.
#### 🧠 Logical learners
- Present: Structured arguments, lists of applications, and clear cause-effect statements (principle → benefit).
- Improve: Include decision trees for trade-offs, tables mapping IDP to WCAG criteria and user needs.
#### 🧑🤝🧑 Social learners
- Present: Framing for teams and collaboration.
- Improve: Offer discussion prompts for design critiques and team workshops, plus sample agendas.
#### 🧘♀️ Solitary learners
- Present: Article suitable for quiet reflection.
- Improve: Add self-check questions and reflection prompts (“Where does my product fail to offer choice?”).
#### 🌿 Naturalistic learners
- Present: Limited explicit environment analogies.
- Improve: Draw analogies to physical-world accessibility (ramps, signage, noise) and relate to sustainability of inclusive products.
### 📊 Accessibility Assessment
#### Screen reader semantics
- Present: Strong emphasis on headings, content order, and comparable alternatives; implies good semantics as a goal.
- Improve: Explicitly call out the need for correct landmark roles, lang attributes, and descriptive alt text patterns.
#### Keyboard navigation
- Present: References to non-mouse users and consistent keyboard behaviour.
- Improve: Stress avoiding keyboard traps, ensuring all controls are focusable, and documenting keyboard patterns.
#### Contrast and readability
- Present: Focus on readability and reducing cognitive load; not specific about contrast ratios.
- Improve: Recommend minimum contrast, line-height, spacing, and avoiding low-contrast decorative elements.
#### Text resizing and reflow
- Present: Zoom support without layout breakage is explicitly mentioned.
- Improve: Encourage testing at 200–400% zoom, supporting reflow, and honouring reduced-motion preferences.
#### Media and captions
- Present: Strong emphasis on high-quality captions, transcripts, and audio descriptions as primary content.
- Improve: Recommend downloadable transcripts, no autoplay by default, and optional audio description tracks.
#### Forms and interactions
- Present: Examples like show-password toggles, voice input, multiple ways to complete tasks.
- Improve: Explicit guidance on labels, error messaging, validation timing, and target sizes.
#### Standards reference
- Present: Clear that WCAG is essential but not sufficient; IDP complement it.
- Improve: Map each principle to relevant WCAG 2.2 AA success criteria to guide audits.
### 🌍 DEIB Assessment
#### Cultural breadth
- Present: Mentions global adoption and varied interface types; some implicit breadth.
- Improve: Add multi-region examples, translation considerations, and localisation case studies.
#### Inclusive language
- Present: Consistent, people-first, disability-positive language; jargon is moderate and mostly defined in context.
- Improve: Provide a brief plain-language summary for non-specialists and avoid subtle specialist terms where unnecessary.
#### Neurodiversity support
- Present: Emphasis on cognitive load, attention-related disabilities, and content prioritisation.
- Improve: More guidance on predictable patterns, icon+text combinations, and reducing sensory overload.
#### Representation
- Present: Focuses on “people with seeing, hearing, moving, and thinking disabilities” explicitly.
- Improve: Use examples that reflect varied identities, regions, and socio-economic contexts in imagery and scenarios.
#### Psychological safety
- Present: Respectful framing of disability and inclusion, no blame.
- Improve: Suggest community guidelines or team norms for accessible design reviews and feedback.
### ✅ Logical Validity
#### Strong reasoning
- The article uses strong causal reasoning: applying IDP leads to fewer barriers, reduced remediation work, and better usability for everyone; links are plausible and supported by concrete examples.
- It employs inductive reasoning from practical patterns (e.g., voice input, show password, dashboard controls) to general principles, making the guidance actionable and credible.
#### Fallacies
- None obvious; claims are moderate and framed as guidance, not absolute guarantees. Where impacts are stated, they are reasonable and align with common UX findings.
#### Tone of voice
- Tone is professional, practical, and inclusive, focusing on collaboration and continuous improvement rather than blame or compliance fear.
### 🛡️ DARVO Analysis
- Deny: No denial or minimisation of accessibility problems; the piece acknowledges existing gaps and limitations of WCAG-only approaches.
- Attack: No attacks on users, regulators, or non-compliant teams; the tone is supportive.
- Reverse victim/offender: No attempt to recast organisations as victims; instead, it frames inclusive design as an opportunity and responsibility.
## 🎯 Conclusion
The article positions the Inclusive Design Principles as a practical, people-centred companion to WCAG. By focusing on comparable experiences, situational context, consistency, user control, choice, content priority, and added value, teams can design more inclusive products across platforms and life cycles. Next steps: weave IDP into your design system, use them to frame research and reviews, and pair them with WCAG in audits to shift from compliance to an accessibility culture.
## 🧱 Refactor Appendix (append after 🎯 Conclusion)
### 📚 Literature Split Pad
- Purpose: Stage Konik CEE units that become per-source Literature notes.
- Split level: **H3**.
- Include verbatim quotes under 25 words and a [view highlight] link.
### [H1] 5–10-word present-tense claim
> [!quote] [Guide to the Inclusive Design Principles](https://tetralogical.com/blog/2025/10/07/guide-to-the-inclusive-design-principles/) by [[Henny]] via [[TetraLogical]]. Published 2025-10-07.
> “The principles don’t replace WCAG or other standards; they provide a lens for good design that includes everyone.”
Two lines: context and use. Cite data if relevant.
[view highlight](https://tetralogical.com/blog/2025/10/07/guide-to-the-inclusive-design-principles/#H1) #xref #articleseed ID:rw_[MISSING]
### [H2] 5–10-word present-tense claim
> [!quote] [Guide to the Inclusive Design Principles](https://tetralogical.com/blog/2025/10/07/guide-to-the-inclusive-design-principles/)
> “Providing a comparable experience is more than just adding alternatives for images, video, and audio.”
Two lines: context and use.
[view highlight](https://tetralogical.com/blog/2025/10/07/guide-to-the-inclusive-design-principles/#H2) #xref ID:rw_[MISSING]
---
### 🔖 Atomic Split Pad (Zettel Candidates)
- Purpose: Promote reusable claims into Atomic notes.
- Split level: **H4**.
- Each item: one idea, present tense, specific, testable.
#### [Z1] Inclusive design extends beyond WCAG compliance
- Scope/condition in one line.
- Pointer to page/time or dataset.
- Links: [[Inclusive-Design]] [[Accessibility-Guidelines]]
#### [Z2] Comparable experiences require high-quality alternatives
- Scope/condition in one line.
- Pointer to page/time or dataset.
- Links: [[Assistive-Technology]] [[Media-Accessibility]]
---
### ✏️ Fleeting Queue (Extract by Selection)
- Purpose: Capture quick actions or sparks for Fleeting notes.
- Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).”
- Keep each line short and self-contained.
- [F1] Run an IDP-based review of our main onboarding flow—compare with current WCAG-only checklist./https://tetralogical.com/blog/2025/10/07/guide-to-the-inclusive-design-principles/ #fleeting #inbox
- [F2] Prototype voice input for search to offer choice alongside keyboard./https://tetralogical.com/blog/2025/10/07/guide-to-the-inclusive-design-principles/ #fleeting #inbox
- [F3] Update design system docs with “prioritise content” guidelines and examples./https://tetralogical.com/blog/2025/10/07/guide-to-the-inclusive-design-principles/ #fleeting #inbox
---
## 🧰 Template Library (paste into Note Refactor → Refactored Note Template)
<!-- Copy ONE template at a time into the plugin before running each batch. -->
### 📝 Fleeting — Refactored Note Template (Konik-ready)
---
type: fleeting
status: inbox
created: {{date:YYYY-MM-DD}} {{time:HH:mm}}
process_by: {{date:YYYY-MM-DD}} # review within 24–48 hrs
source_title: [MISSING]
source_link:
author: [MISSING]
source_type: article|paper|video|podcast|thread
reading_stage: inspectional|analytical|syntopical
project:
tags: #fleeting #inbox
---
# 📝 Fleeting Note — {{title}}
## 🧠 One-liner (my words)
- State the single idea in one short sentence.
## 🧭 Context & cue
- Where did this arise? Page/timecode/speaker.
- Trigger: quote, data point, claim, or question.
## 🧪 Adler checks (quick)
- What is this about as a whole?
- What is said in detail, and how?
- Is it true? Evidence for or against?
- So what? Impact or next move.
## 🔎 Bias & reliability snapshot
- Possible bias or framing?
- What evidence would change my view?
## 🧩 Konik bridge
- Draft a claim header for promotion.
### [H1] 5–10-word present-tense claim
> [!quote] [{{source_title}}]({{source_link}}) by [[{{author}}]]. Accessed {{date:YYYY-MM-DD}}.
> “Short quote under ~25 words.”
One line on why this matters.
[view highlight]({{source_link}}) #xref ID:rw_[MISSING]
## 🧰 Next moves (pick 1–2)
- [ ] Promote to *Literature* with citation.
- [ ] Draft *Atomic* claim from [H1].
- [ ] Park as testable question.
## ✅ Processing checklist
- [ ] Rewrote in my words.
- [ ] Decided: trash | keep | convert.
- [ ] Linked to at least one related note.
- [ ] Tagged and moved out of inbox.
---
### 📚 Literature — Refactored Note Template (Konik-ready)
---
type: literature
status: draft
created: {{date:YYYY-MM-DD}} {{time:HH:mm}}
adler_level: inspectional|analytical|syntopical
reading_stage: inspectional|analytical|syntopical
source_title: [MISSING]
author: [MISSING]
year:
publisher_or_journal:
edition_or_volume:
doi:
url:
accessed: {{date:YYYY-MM-DD}}
citekey:
project:
tags: #literature #reading
---
# 📚 Literature Note — {{title}}
## 🧰 Action Inbox
- [H1] Short action — context/{{url}} #articleseed
- [H2] Short action — context/{{url}} #xref
- [H3] Short action — context/{{url}} #share
## 🧭 Bib Capsule
- Title, author, year, venue, and link.
- One-line scope: what the work attempts.
## 🧠 Author’s Thesis (their words)
- Core claim briefly. Include page/timecode.
## 🧩 Key Arguments
- Argument A — method/evidence — page/time.
- Argument B — method/evidence — page/time.
- Argument C — method/evidence — page/time.
## 🧪 Evaluation (Adler)
- What is this about as a whole?
- How is it argued? Fairly and clearly?
- Is it true or plausible? Why?
- So what? Practical or theoretical impact.
## 🗒️ Notes (Konik CEE units)
### [H1] 5–10-word present-tense claim
> [!quote] [{{source_title}}]({{url}}) by [[{{author}}]] via [[{{publisher_or_journal}}]]. Published {{year}}. Accessed {{accessed}}.
> “Verbatim highlight under ~25 words.”
Two lines: context and use. Link to data if relevant.
[view highlight]({{url}}#H1) #xref #articleseed ID:rw_[MISSING]
### [H2] 5–10-word present-tense claim
> [!quote] [{{source_title}}]({{url}}) by [[{{author}}]] via [[{{publisher_or_journal}}]]. Published {{year}}. Accessed {{accessed}}.
> “Verbatim highlight under ~25 words.”
Two lines: context and use.
[view highlight]({{url}}#H2) #xref ID:rw_[MISSING]
## 🔖 Zettel Candidates
#### [Z1] 5–10-word present-tense claim
- One-line context and page/time.
#### [Z2] 5–10-word present-tense claim
- One-line context and page/time.
## 🏷️ Tag Coverage
#articleseed: 0 • #xref: 0 • #share: 0 • #bmf: 0 • #addendum: 0
## ✅ Processing Checklist
- [ ] Thesis captured in my words.
- [ ] 1–3 Zettel candidates drafted.
- [ ] Action Inbox pruned to high-signal items.
- [ ] Cross-links added and filed.
---
### 🔖 Atomic (Zettel) — Refactored Note Template (Konik-ready)
---
type: atomic
id: {{date:YYYYMMDDHHmm}}-{{title}}
status: evergreen
created: {{date:YYYY-MM-DD}} {{time:HH:mm}}
origin: reading|thinking|experiment
proof_state: conjecture|working|supported|refuted
source_literature: [[Source-Literature-Note]]
citekey:
project:
tags: #zettel #idea
---
# 🔖 {{title}} <!-- 5–10 words, present tense, specific -->
## 🧠 Claim
- One idea only. Clear and testable.
## 🧾 Evidence & Pointers (Konik)
- [H#] from [[{{source_literature}}]] — page/time — brief rationale.
- ID:rw_[MISSING] — link to highlight or dataset.
> [!quote] Evidence snippet (≤25 words) if essential.
> Cite page/time. Keep it minimal.
## 🔍 Scope & Conditions
- When this holds. Boundaries and exceptions.
## 🔗 Links
- Broader: [[Parent-Concept]]
- Narrower: [[Specific-Case]]
- Related: [[Parallel-Idea]]
## 🧪 Tests / Falsifiers
- One check that could disconfirm the claim.
- Simple study or observation plan.
## 🧰 Implications
- Practice, policy, or design moves in one line each.
## 🔙 Backlinks
- From: [[{{source_literature}}]] • Context line.
## ✅ Maintenance
- [ ] Links in and out.
- [ ] Title still precise?
- [ ] Proof state updated.
## Highlights
- Providing a comparable experience is more than just adding alternatives for images, video, and audio. Those alternatives need to be high quality so that people who experience the web in different ways have content that is just as effective. After all, [text descriptions](https://tetralogical.com/blog/2022/01/24/text-descriptions/), [captions, audio description, and transcripts](https://tetralogical.com/blog/2021/06/23/an-inclusive-approach-to-video-production/) are not supplementary, they are primary content for many of us. ([View Highlight](https://read.readwise.io/read/01kfbfjw4e0af9awq8vxc76mvp))
- Tags: 👻 ai highlighted