You Can't Opt-Out of Accessibility 🔗 **Source:** [You Can't Opt-Out of Accessibility](https://vale.rocks/posts/accessibility-importance) > [!note]+ Document Notes > ```yaml > > --- > tags: [accessibility, web, inclusion] > author: Declan Chidlow > source: vale.rocks > reference: [https://vale.rocks/posts/accessibility-importance] > date created: 2025-12-24 12:00 > > --- > ``` > > # 🏷️ Title: You Can't Opt-Out of Accessibility > <!-- 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 - The author vents deep frustration at widespread neglect of digital accessibility, from standards bodies to product teams. - It matters because inaccessible products are effectively broken, excluding billions and often harming those with the least energy and agency. - Key stakeholders: disabled users, designers/devs, accessibility pros, standards bodies, and companies bound by laws like ADA/EAA. - Risks/tradeoffs: legal risk, reputational damage, human suffering vs. perceived extra effort and cost of accessible practices. - Bottom line: “Accessibility is everyone’s responsibility, always” and must be baked into every step, not treated as an afterthought or checkbox. --- ## 📖 Main Content - Core argument: After years of abstraction and “developer convenience” focus, the web routinely sacrifices user survival and agency for shiny features: “Innovation that excludes people isn’t innovation; it’s just shiny exclusion.” The author rejects treating accessibility as optional, niche, or negotiable. - On attitudes: They describe being treated like a nuisance for insisting on accessible work, even losing clients when refusing to compromise. This reflects a culture that sees accessibility as a nerdy add‑on rather than a baseline of professional craft. - On standards & industry: They criticise examples like the CSS carousel debate and Chrome team responses, arguing standards and browser vendors sometimes prioritise convenience over inclusion, even resisting feedback from accessibility experts. - Universality of benefit: Using captions, sidewalk curb cuts, and alt text, they show that features meant for disabled people improve experiences for everyone, concluding: “Accessibility is to the benefit of all.” - Law vs. checkbox culture: Laws like the European Accessibility Act and ADA force minimum compliance, but many organisations treat these as the ceiling, not floor, resulting in “technically” compliant but poor experiences. - Human cost: Through a story of a man with motor neurone disease using eye‑tracking tech, the article illustrates how every extra click or friction point is physically exhausting when life and energy are limited. Neglect is framed as a direct betrayal of billions of people. - Responsibility & action: The author insists that accessibility must be integrated from concept through design, development, and testing; no “bystander effect.” They urge hiring and properly paying accessibility professionals, educating teams, and testing with real assistive tech users instead of relying on overlays and automation. - Conclusion: Accessibility is hard but necessary work; we may never be perfect, but we must “give a damn, embrace it, and start enacting change.” --- ### 🗒️ Notes - Anger and fatigue: The author is “fucking pissed off” about the state of web accessibility and the cumulative effect of constant small barriers, describing “death by a thousand cuts.” - Social sneer: They capture a common reaction when raising accessibility concerns: a silent “Who cares?” and a sense that accessibility is immature or off‑topic in “serious” work. - Professional sacrifice: They’ve lost clients due to a non‑negotiable stance on accessibility, treating inaccessible work as a strict blocker, not something to “fix later.” - Standards critique: They cite the CSS carousel controversy as emblematic of standards bodies and implementers valuing developer ergonomics over accessible patterns, even when experts like Alice Boxhall document harms. - Shiny exclusion: Layers of abstraction have shifted focus from the lived experience of users to developer comfort. The phrase “shiny exclusion” encapsulates fancy features that leave people behind. - Everyone’s job: Accessibility must be ingrained “in every fibre of every step” of product creation; no team gets to assume “someone else” will handle it. - Myth of “ugly” accessibility: They reject the idea that accessible designs are inherently boring or unattractive, calling it an excuse that reveals poor skill rather than any limitation of accessibility itself. - Curb‑cut effect: Closed captions, sloped footpaths, and alt text exemplify features designed for specific disabilities that end up helping travellers, parents with strollers, people in noisy environments, and more. - Legal minimums: Laws like EAA and ADA are good but have spawned a culture of “checkbox compliance” where the bare minimum is treated as enough—even when experiences remain exhausting or confusing. - Business case vs human cost: They argue it’s “nigh impossible” to make uncompassionate people care, and that constant appeals to ROI are morally misplaced when the human price is so high. - Eye‑tracking story: A man with motor neurone disease uses only his eyes to operate a device. Every click is slow and draining; suboptimal interfaces are not minor annoyances but direct causes of exhaustion. - Gratitude moment: After a session, he painstakingly types “thank you Declan.” This moment anchors the moral urgency: telling him accessibility doesn’t matter is unconscionable. - Universality of vulnerability: Six months before, this man was fully able. Anyone can become disabled through age or illness; we are designing the future environment we ourselves might inhabit. - Difficulty acknowledged: Accessibility is not trivial—there is “so very much to learn,” and nothing will be perfectly accessible to everyone—but difficulty is not an excuse for apathy. - Concrete actions: - Hire and pay accessibility professionals fairly. - Bake accessibility into every phase, not as paint on a rusty frame. - Educate yourself and your team using existing resources. - Test with actual disabled users and learn to use assistive technologies like screen readers properly. - Final imperative: “Accessibility matters, so give a damn, embrace it, and start enacting change.” --- ## 📚 References - Original article: [You Can’t Opt-Out of Accessibility](https://vale.rocks/posts/accessibility-importance) - W3C WAI: [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/) - EU: [European Accessibility Act](https://commission.europa.eu/publications/european-accessibility-act-2019_en) - US: [Americans with Disabilities Act (ADA) Overview](https://www.ada.gov/resources/web-guidance/) --- ## 🗣️ Paraphrase - Accessibility on the web is routinely treated as optional or annoying, but inaccessible products are fundamentally broken and cause real harm—especially to people with the least energy and power to fight back. - Everyone involved in building digital products is responsible for accessibility from the start; we must move beyond legal checkbox compliance, invest in expertise, and choose compassion-driven design that welcomes all users, including our future selves. --- ## 📰 Newsletter Accessibility isn’t a plugin you bolt onto WordPress at the end—it’s a design constraint and a moral baseline. In “You Can’t Opt-Out of Accessibility,” Declan Chidlow reminds us that inaccessible sites are simply broken. For WordPress teams, that means: - Treating WCAG as a starting point, not a ceiling. - Choosing themes and plugins with real accessibility chops (start with the [Accessibility Ready theme tag](https://wordpress.org/themes/tags/accessibility-ready/)). - Testing flows with screen readers and keyboard only, not just Lighthouse scores. - Budgeting for a11y audits just like you budget for performance or security. If you’re levelling up your skills, check out: - [WordPress Accessibility Handbook](https://make.wordpress.org/accessibility/handbook/) - [WPCampus Accessibility Resources](https://wpcampus.org/accessibility/) Shiny features that lock people out aren’t innovation—they’re shiny exclusion. Let’s build WordPress sites we’d still be able to use if our abilities changed tomorrow. --- ## ✅ Action Items #### DevRel - Publish accessible code examples and patterns (forms, dialogs, navigation) in docs and demo apps. - Run workshops on testing with screen readers and keyboard-only navigation. - Add accessibility acceptance criteria and checklists to all SDKs, templates, and quickstarts. - Track adoption of accessible components and docs via analytics and feedback surveys. - Host community office hours focused on remediating real projects’ accessibility issues. #### OSPO - Add accessibility review to open source contribution guidelines and governance docs. - Require license and policy reviews to include digital accessibility expectations for adopters. - Ensure upstream projects critical to your stack document and test accessibility. - Fund accessibility-focused upstream contributions and audits as part of OSPO budgets. #### Community - Offer “a11y triage clinics” where maintainers get live feedback on their projects. - Create contributor-friendly “good first issue” accessibility tickets with mentoring. - Encourage sponsors to earmark funding for accessibility work and audits. - Run cross-project incident drills for critical accessibility regressions. #### WordPress - Core: enforce accessibility acceptance criteria for new features before merge. - Core Performance: ensure performance work doesn’t regress semantics or focus handling. - Core AI: mandate accessible outputs and UIs; avoid overlays marketed as magic fixes. - Core Program Team: include accessibility champions in release squads and retros. - Mobile: test with system accessibility features (VoiceOver/TalkBack, larger text). - Playground: provide preconfigured accessibility testing sandboxes. - Community: add a11y tracks to WordCamps and speaker training. - Training: publish learning paths for “Accessibility for WP devs/designers/content editors.” - Marketing: highlight accessible sites and case studies as success stories. - Support: document accessible troubleshooting steps and common antipatterns. - Design: adopt an accessibility-first design system with tokens for contrast, focus, spacing. - Documentation: include accessibility sections in every dev and editor guide. - Photos: require meaningful alt text patterns and examples. - TV: ensure captions and transcripts are required, with clear quality guidelines. - Polyglots: support localized accessibility terminology and glossaries. - Accessibility: run regular audits, maintain an issue heatmap, and track fix SLAs. - Meta: ensure .org properties model best-practice accessibility. - CLI: provide commands and scaffolds that encourage semantic, accessible markup. - Hosting: offer accessibility-friendly defaults and checklists. - Tide: incorporate accessibility checks transparently and avoid false confidence. - Openverse: ensure search and media browsing are fully accessible. - Themes: enforce accessibility-ready guidelines in theme review. - Plugins: prioritize accessibility in security and UX reviews; flag overlays and dark patterns. #### The WPOCC - Fund accessibility fellowships and stipends for maintainers doing a11y work. - Sponsor documentation sprints focused on accessible patterns and anti-patterns. - Pilot matched grants for accessibility upgrades in high-impact plugins/themes. - Publish transparent reports on accessibility improvements funded and their impact. ### FAIR - Require open, inspectable accessibility testing setups and scripts. - Bake accessibility expectations into funding covenants and sunset clauses. - Offer reusable, productized governance artefacts for accessibility reviews and scorecards. --- ## 🧪 Hypotheses - Teams that integrate accessibility from project inception ship fewer a11y-related regressions and spend less on remediation. - Emphasising human stories of disability increases developer willingness to invest in accessibility more than ROI arguments alone. - Accessible interfaces measurably reduce task completion time and error rates for both disabled and non-disabled users. - Legal mandates framed as floors (not ceilings) correlate with higher practical accessibility, beyond checkbox compliance. - Direct testing with assistive technology users surfaces more critical issues than automated tooling alone. --- ### 📊 Methodology - Run longitudinal studies comparing projects with accessibility baked into sprint definitions versus those treating it as a late QA step; track bug counts and remediation costs. - Conduct controlled experiments where developers read either human-impact stories or pure business-case documents, then measure stated and revealed preferences (e.g., tasks they choose to prioritise). - Run usability tests with diverse participants (including screen reader and switch users) to compare accessible vs. non-accessible variants on time-on-task and error rates. - Analyse legal environments and guidance (e.g., regulator statements) across regions, correlating with independent accessibility audit scores of major sites. - Compare results of automated audits (e.g., axe-core) with moderated sessions using real assistive tech users on the same interfaces. --- ### ❓ Questions - How can teams best maintain accessibility quality under rapid-release and experimentation cultures? - What forms of storytelling most effectively shift product leaders from checkbox compliance to genuine care? - How can we embed accessibility into popular component libraries and design systems so that “doing the right thing” is the default? - What regulatory or industry incentives reduce reliance on low-value accessibility overlays? - How should we measure accessibility beyond pass/fail checklists to reflect lived experience? --- ### 🔮 Future Research - Develop metrics that capture accessibility quality as experienced by real users (e.g., fatigue, error recovery), not just WCAG success criteria. - Study the long-term effects of “shiny exclusion” patterns (like inaccessible widgets) on disabled users’ trust in digital services. - Explore training programs that reliably upskill generalist engineers in practical accessibility skills. - Investigate sustainable funding models for independent accessibility professionals and auditors. - Examine effective governance patterns in orgs where accessibility is genuinely everyone’s responsibility. --- ### 💡 Implications - Practice: Accessibility must be part of every definition of done, code review, and design critique. - Policy: Regulators should clarify that laws like ADA/EAA set minimums and encourage industry to go beyond checkbox compliance. - Security: Inaccessible security flows (2FA, CAPTCHAs) can effectively lock out disabled users, undermining equitable protection. - Education: Curricula for designers and developers should treat accessibility as foundational, not an elective. - Funding: Grants and procurement should reward demonstrably accessible products and penalise harmful shortcuts like overlays. --- ### 🧠 Learning Styles Assessment - Reading level estimate: Approx. 10th–11th grade (Flesch–Kincaid) due to complex sentences, strong rhetoric, and specialised terms. #### 👀 Visual learners - Present: Vivid mental imagery (boulder up a mountain, curb cuts, “coat of paint over a rusty frame”). - Improve: Add diagrams of accessible vs. inaccessible flows, contrast examples, and component-level before/after screenshots. #### 🔊 Aural learners - Present: Strong rhetorical rhythm and emotional tone that would translate well to audio. - Improve: Offer an audio narration or short podcast-style summary, plus TTS for the article. #### 🗣️ Verbal learners - Present: Rich, emotive language, analogies (cake without flour, shiny exclusion), and concrete examples. - Improve: Add a glossary for key accessibility and legal terms, plus sidebars with plain-language summaries. #### 🧩 Kinesthetic learners - Present: Implicit prompts to “bake accessibility into every phase” and test with real users. - Improve: Provide step-by-step checklists, small exercises (e.g., keyboard-only audit), and sandbox tasks. #### 🧠 Logical learners - Present: Clear causal links (neglect → exhaustion, laws → checkbox compliance) and categorical statements (inaccessible = broken). - Improve: Include tables mapping patterns to WCAG criteria and decision trees for accessibility triage. #### 🧑‍🤝‍🧑 Social learners - Present: Emphasis on shared responsibility and working with accessibility professionals and users. - Improve: Add discussion prompts, group audit activities, and guidance for running inclusive user tests. #### 🧘‍♀️ Solitary learners - Present: Reflective questions about one’s future disability risk and moral responsibility. - Improve: Provide journaling prompts and self-assessment checklists for personal accessibility practice. #### 🌿 Naturalistic learners - Present: Limited explicit nature analogies beyond curb cuts and physical environment design. - Improve: Tie digital accessibility to broader ecosystem thinking—urban design, public infrastructure, and sustainability. --- ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Conceptual emphasis on semantics over misused ARIA; criticism of ARIA-first guidance. - Improve: Explicitly demonstrate proper HTML structures, headings, regions, and when ARIA is appropriate. #### Keyboard navigation - Present: Implicit in references to user agency and interaction difficulty. - Improve: Provide concrete guidance on logical tab order, focus management, and avoiding keyboard traps. #### Contrast and readability - Present: Mentions good contrast and themes (light/dark) improving usability for all. - Improve: Reference specific contrast ratios and show examples of compliant vs. non-compliant UI. #### Text resizing and reflow - Present: General call for accessible experiences and flexibility. - Improve: Call out zoom, reflow, and reduced motion support explicitly, with recommended practices. #### Media and captions - Present: Closed captions highlighted as a universal benefit. - Improve: Discuss caption quality, transcripts, audio descriptions, and avoiding autoplay. #### Forms and interactions - Present: Broader focus on “suboptimal interfaces” causing exhaustion. - Improve: Provide specific guidance on labels, error messages, touch targets, and accessible notifications. #### Standards reference - Present: Mentions laws and standards debates but not detailed WCAG mapping. - Improve: Explicitly map typical issues and patterns to WCAG 2.2 AA success criteria. --- ### 🌍 DEIB Assessment #### Cultural breadth - Present: Focus on disability as a global issue, referencing “billions of people.” - Improve: Include concrete multi-region examples and recognition of differing legal frameworks and access conditions. #### Inclusive language - Present: Direct, person-centred language about disabled people; avoids euphemism. - Improve: Add explicit definitions for terms that may be unfamiliar, ensure consistent people-first or identity-first phrasing per community norms. #### Neurodiversity support - Present: Acknowledgement of cognitive accessibility and intuitive experiences. - Improve: Offer more examples of supports for neurodivergent users (predictability, reduced clutter, options to reduce stimuli). #### Representation - Present: Deep narrative about one disabled man; references “billions” more. - Improve: Broaden representation to different disability types, ages, and contexts; note that disability intersects with other identities. #### Psychological safety - Present: Strong emotional content and explicit profanity; could be intense for some readers. - Improve: Add a brief content note about emotional material related to illness/disability, and emphasise supportive community practices. --- ### ✅ Logical Validity #### Strong reasoning - Causal: Inaccessible interfaces → increased cognitive/physical load → exhaustion for disabled users. This is grounded in a concrete eye-tracking example and matches broader HCI research. - Inductive: Curb cuts, captions, and alt text ↦ general claim that accessibility benefits all users. Multiple everyday examples support this generalisation. - Ethical: Claim that business-case arguments should not overshadow human cost is a value judgment but logically consistent with the described harms. #### Fallacies - Potential overgeneralisation: Some language implies “the industry” as a whole is cynical or malicious; many individuals and teams are exceptions. Could be tempered by acknowledging positive counterexamples while still criticising dominant trends. #### Tone of voice - Tone is passionate, confrontational, and morally urgent, with explicit profanity (“don’t you fucking dare”) and direct address (“Look me in the eyes and tell me that accessibility doesn’t matter”). --- ### 🛡️ DARVO Analysis - Deny: The article criticises denial by others but does not itself engage in denial of harm; it emphasises acknowledging responsibility. - Attack: The author attacks harmful behaviours and systems (“shiny exclusion,” “checkbox compliance”), not individual victims or accusers. Critique is aimed at institutions and complacency. - Reverse victim/offender: The piece explicitly refuses to cast neglectful actors as victims; instead, it centres disabled users and those excluded. There is no attempt to portray critics of accessibility as persecuted. --- ## 🎯 Conclusion Accessibility is not optional decoration; it is a core property of whether a product works at all for billions of people. Laws and business cases help only so far—real change requires compassion, shared responsibility, early integration, and respect for accessibility professionals and disabled users. For readers, the next step is to adopt accessibility as a non-negotiable part of your craft and begin changing your own processes accordingly. --- ## 🧱 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] Accessibility neglect betrays billions of users > [!quote] [You Can't Opt-Out of Accessibility](https://vale.rocks/posts/accessibility-importance) by [[Declan Chidlow]] via [[vale.rocks]]. Published 2025-12-18. Accessed 2025-12-24. > “Look each one of the billions of people you’re betraying in the face and tell them that they don’t matter enough for you to give them the slightest modicum of dignity or care.” Two lines: context and use. Cite data if relevant. [view highlight](https://vale.rocks/posts/accessibility-importance#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] Inaccessible products are fundamentally broken > [!quote] [You Can't Opt-Out of Accessibility](https://vale.rocks/posts/accessibility-importance) > “An inaccessible product is a broken product.” Two lines: context and use. [view highlight](https://vale.rocks/posts/accessibility-importance#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] Inaccessible products are broken products - In any digital context, if disabled users cannot operate a product, it is functionally broken. - Links: [[Accessibility-as-quality]] [[Failure-modes-of-digital-products]] #### [Z2] Accessibility investments benefit all users - Features built for disabled users (captions, curb cuts) improve usability for wider audiences. - Links: [[Curb-cut-effect]] [[Universal-design]] --- ### ✏️ 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] Add “inaccessible = broken” language to internal product quality definitions/{ARTICLE_URL} #fleeting #inbox - [F2] Design a team workshop around the eye-tracking story to build empathy/{ARTICLE_URL} #fleeting #inbox - [F3] Create a WordPress accessibility review checklist for themes and plugins/{ARTICLE_URL} #fleeting #inbox --- <!-- deep-read:sections end -->