Wishcessibility 🔗 **Source:** [Wishcessibility](https://www.nicchan.me/blog/wishcessibility/) > [!note]+ Document Notes > ```yaml > tags: [accessibility, web-development, ai] > author: nicchan.me > source: nicchan.me > reference: [https://www.nicchan.me/blog/wishcessibility/] > date created: 2026-02-15 00:00 > > --- > > # 🏷️ Title: Wishcessibility > <!-- 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) - [🧱 Refactor Appendix (append after 🎯 Conclusion)](#-refactor-appendix-append-after--conclusion) --- ## 📝 Summary - The article introduces “wishcessibility,” drawing an analogy to “wishcycling”: well‑intentioned but harmful attempts to improve accessibility. - It argues that checklists, scores, overlays, and untested patterns can worsen access when they replace lived‑experience testing and systemic support. - Key stakeholders: disabled users, developers, accessibility practitioners, and org leadership. - Risks: overreliance on standards/LLMs, box‑ticking cultures, organizational underinvestment. - Bottom line: real accessibility needs messy, people-centered practice and long-term systemic investment, not just wishful tools and scores. --- ## 📖 Main Content - The author coins “wishcessibility” to name accessibility work that unintentionally harms disabled users despite good intentions, similar to how “wishcycling” contaminates recycling streams. - Examples include: - Blindly following ARIA patterns without testing in real assistive tech. - Misusing `tabindex="0"` everywhere after learning about keyboard users. - Trusting LLM accessibility explanations (e.g., about `aria-controls`) even when real-world support is poor, as shown by [a11ysupport.io’s weak `aria-controls` support data](https://read.readwise.io/read/01kh3v1fxtcs5fxfc5p6xgkqnr?endLexposition=0000I_00000-0070&startLexposition=0000E_00001_00004_00003&emphasizeText=A+screenshot+from+a11ysupport.io+that+shows+aria-controls+is+poorly+supported). - Wishcessibility is distinguished from overt corporate neglect: layoffs and under-resourcing are framed as greed and ableism, not “good intentions gone wrong.” - The author notes many accessibility practitioners start in this wishcessibility phase and only improve because they are allowed to fail repeatedly until the net impact of their work becomes positive ([“the net good of our work became greater than our failures”](https://read.readwise.io/read/01kh3v1fxtcs5fxfc5p6xgkqnr?endLexposition=0000M_00000-003a&startLexposition=0000K&emphasizeText=Some+of+us+were+luck+enough+to+be+allowed+to+fail)). - Combatting wishcessibility is hard because: - The legal/compliance frame drives demand for scores, grades, and one-size-fits-all guidance. - Standardization (e.g., WCAG, vendor checklists) necessarily flattens nuance, echoing Sherri Byrne‑Haber’s warning about “accessibility grade/score traps.” - Developers without organizational support resort to shallow content and can’t build deep expertise before “ship faster” pressures take over ([“they can only do so much before the pressures to ship faster inevitably cause harm”](https://read.readwise.io/read/01kh3v1fxtcs5fxfc5p6xgkqnr?endLexposition=0000W_00000-008e&startLexposition=0000O&emphasizeText=they+can+only+do+so+much+before+the+pressures+to+ship+faster+inevitably+cause+harm)). - The core difficulty: accessibility is about “the inherent messiness of human beings.” Disabled users often give feedback that conflicts with standards, showing that standards are derived from lived experience—not the other way around. - The author critiques orgs that would reject $200 for real user testing but happily fund $200 for LLM access to generate personas—preferring “answer‑shaped” averages to messy feedback. - The article concludes that “perfect accessibility is actually impossible”; the closest we can get is through systemic buy‑in that funds ongoing, human‑centered, in‑the‑trenches work. Standards and scores are a baseline, not the finish line. - The author hopes the term “wishcessibility” gives language to talk about why teams must think beyond pixels, code, standards, and law to the actual humans they’re solving problems for ([“think beyond the pixels, the code, the standards and the law, about the actual humans we are solving problems for”](https://read.readwise.io/read/01kh3v1fxtcs5fxfc5p6xgkqnr?endLexposition=0000g_00000-009s&startLexposition=0000c&emphasizeText=why+the+work+of+accessibility+needs+us+to+think+beyond+the+pixels)). --- ### 🗒️ Notes - The concept of **wishcycling** is introduced via an anecdote: at a party, someone “optimistically” recycles a dirty pizza box, contaminating the entire batch so it ends up in landfill anyway. This frames how good intentions can undermine the desired outcome. - Accessibility is compared to recycling: widely seen as “net positive,” but frequently attempted by people who lack expertise or support, leading to counterproductive efforts the author names **wishcessibility** ([“anything that inadvertently hurts accessibility when you’re trying to improve it”](https://read.readwise.io/read/01kh3v1fxtcs5fxfc5p6xgkqnr?endLexposition=0000E_00001_00004_00001_00001-002I&startLexposition=00004&emphasizeText=Wishcessibility+isn%E2%80%99t+a+single+specific+bad+practice)). - Concrete wishcessibility examples: - Unpaid OSS maintainers copying ARIA Authoring Practices patterns as “best practice” without testing. - Junior devs adding `tabindex="0"` to every heading/text node after learning about keyboard-only users, with no senior review or guardrails. - Teams trusting LLM answers about ARIA attributes like `aria-controls`; the LLM asserts it “plays an important role in accessibility” by defining relationships and aiding navigation, but this clashes with real‑world support where [most screen readers don’t expose `aria-controls` well](https://read.readwise.io/read/01kh3v1fxtcs5fxfc5p6xgkqnr?endLexposition=0000I_00000-0070&startLexposition=0000E_00001_00004_00003&emphasizeText=is+poorly+supported+across+all+screen+readers). - Installing accessibility overlays because “everyone else does” and vendors promise quick wins—another wishful, marketing‑driven shortcut. - Intent vs. impact: - Corporate decisions to cut accessibility teams to a token role are framed as greed and ableism, distinct from wishcessibility, which is *by definition* made by people trying to help. - The author still prioritizes impact, but argues that cultivating good intent is vital because it encourages learning and failure on the path to net‑positive outcomes. - Career trajectory: - Many practitioners start in wishcessibility—making clumsy mistakes—but some are fortunate enough to keep iterating until they produce more good than harm ([“allowed to fail, over and over again, until the net good of our work became greater than our failures”](https://read.readwise.io/read/01kh3v1fxtcs5fxfc5p6xgkqnr?endLexposition=0000M_00000-003a&startLexposition=0000K&emphasizeText=allowed+to+fail%2C+over+and+over+again)). - Despite this hopeful arc, inaccessible code and design still dominate, indicating systemic issues. - Compliance culture: - Laws and litigation push organizations into a compliance mindset where nuance‑flattening metrics (grades, scores) dominate. - The piece quotes Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure,” aligning with Byrne‑Haber’s critique of “accessibility grade/score traps.” - Marketing-oriented, one-size-fits-all guidance proliferates; devs “lap up surface-level accessibility content” because it’s what they have. - Organizational constraints: - Without sponsorship, devs can’t deepen their knowledge and eventually succumb to “ship fast” pressures, which tend to harm accessibility. - Accessibility is portrayed as fundamentally about dealing with conflicting, idiosyncratic human feedback, not just clean specs. Standards come *from* messy user stories, not the other way around. - LLM vs user research: - Leadership is more willing to fund LLM tools than user testing; “answer-shaped” persona outputs feel safe and tidy compared to raw, sometimes contradictory user interviews. - Limits of perfection: - The author calls “perfect accessibility” a lie we tell ourselves; we chase perfect scores, closed tickets, and polished reports instead of focusing on actual experiences. - WCAG and similar standards are defended as “an important baseline (and an achievement!), a necessary starting point before the even harder work begins.” - Closing note: - The author sees their own blog post as a “drop in the ocean,” but hopes the term wishcessibility helps people communicate why accessibility must center humans over tools, laws, or vanity metrics. --- ## 📚 References - Sherri Byrne-Haber – “Don’t Fall Into the ‘Accessibility Grade/Score’ Trap” (blog; referenced as an “excellent recent piece” on score pitfalls). - a11ysupport.io – empirical data on `aria-*` support (used to counter LLM claims about `aria-controls`). - WAI-ARIA Authoring Practices Guide – cited as a source developers may over-trust when untested. - WCAG (Web Content Accessibility Guidelines) – referenced as a baseline standard and legal anchor. - Waste Not Why Not podcast – source of the “wishcycling” metaphor. - Article: “Wishcessibility” – https://www.nicchan.me/blog/wishcessibility/ --- ## 🗣️ Paraphrase - The author coins “wishcessibility” to describe accessibility work that, despite good intentions, ends up making things worse—similar to how misguided recycling (“wishcycling”) ruins a whole batch. They illustrate this with examples like misapplied ARIA patterns, indiscriminate keyboard-focus hacks, and uncritically following LLM advice or installing overlays. They argue that compliance‑driven scores and one-size-fits-all guidance flatten nuance, leaving unsupported developers to adopt shallow practices that rarely help disabled users. - They further claim that accessibility is irreducibly human and messy, shaped by conflicting user feedback and lived experiences rather than clean standards alone. Organizational reluctance to fund real user testing, contrasted with enthusiasm for LLM-generated personas, typifies a preference for neat “answer-shaped” outputs over reality. Since perfect accessibility is impossible, they advocate for systemic, long-term support that treats WCAG as a starting baseline while investing in ongoing, human-centered practice. --- ## 📰 Newsletter In this week’s accessibility‑meets‑WordPress spotlight, we’re looking at “wishcessibility”—the pattern where teams do *more* harm than good while trying to help. The article is a sharp reminder that passing automated checks, copying ARIA patterns, or pasting LLM‑generated snippets doesn’t guarantee a usable experience for disabled visitors. For WordPress builders, this means: - Treat WCAG and automated scores as a floor, not a ceiling. Pair Lighthouse/axe audits with real user testing wherever budgets allow. - Be wary of accessibility overlays and miracle plugins that promise instant compliance. Prefer focused tools that help you fix source markup, such as linting in your theme or CI, and follow reputable guidance like the official W3C WAI docs. - Use LLMs as brainstorming aides, not oracles. Always verify ARIA usage in current documentation and with actual assistive tech (NVDA, JAWS, VoiceOver). - Make accessibility a routine part of your workflow: theme reviews, plugin QA, pattern libraries, and design reviews. If you’re looking to level up, pair this piece with the W3C’s WCAG-EM report guidance and community talks from accessibility practitioners who test with real users. The big takeaway: think beyond pixels and scores, and prioritize the lived experience of the people using your sites. --- ## ✅ Action Items #### DevRel - Launch a talk/blog series on “wishcessibility” aimed at developers, showing common anti-patterns (e.g., overlay use, naive ARIA) and better alternatives. - Add accessibility labs and office hours where devs can bring components for live assistive technology testing and feedback. - Expand SDK and starter template examples that demonstrate robust accessibility patterns with documented tradeoffs and tested AT behavior. - Run campaigns explaining how to interpret accessibility scores and how not to overfit to them; include funnels from introductory content to deeper training. - Facilitate a moderated community forum for sharing tested patterns, screen reader test matrices, and lessons learned. #### OSPO - Incorporate accessibility contribution expectations into project charters and governance docs; specify decision rights for accessibility signoff. - Integrate accessibility checks into license/compliance scanning, ensuring open-source dependencies’ accessibility status is visible. - Coordinate with security teams so vulnerability and accessibility fixes are prioritized together, with clear disclosure and remediation policies. - Maintain an SBOM-style inventory that also tags components with accessibility maturity and test coverage. - Provide guidance and consultation hours for maintainers on choosing licenses and governance that encourage accessible contributions. - Prioritize funding and MoUs for upstream projects that demonstrate strong accessibility practices and user-testing commitments. - Report accessibility KPIs alongside other strategic metrics to executives, framing them as core quality and risk indicators. #### Community - Offer maintainers templates for accessibility roadmaps, including deprecating wishcessible patterns and introducing tested replacements. - Curate contributor onboarding paths that teach accessible coding and reviewing as a first-class skill, including “first issue” accessibility bugs. - Provide sponsors with reports showing accessibility outcomes (e.g., user testing, reduced support tickets) for funding transparency. - Run cross-project incident drills where accessibility regressions are treated similarly to outages, including coordinated disclosures. #### WordPress - **Core:** Prioritize issues where core patterns encourage wishcessible behavior; improve defaults for focus handling, semantics, and form markup. - **Core Performance:** Include accessibility regressions as part of perf changes review (e.g., no ARIA hacks that break AT for micro-gains). - **Core AI:** Set guardrails for any AI-assisted tooling so it cannot silently introduce unsupported ARIA; require evaluation against real AT. - **Core Program Team:** Regularly sync on cross-team accessibility dependencies and run retrospectives whenever a release ships with accessibility regressions. - **Mobile:** Audit gestures, focus order, and labels; ensure offline flows stay accessible, not just the online “happy path.” - **Playground:** Provide prebuilt scenarios to test themes/plugins with screen readers, keyboard navigation, and high-contrast modes. - **Community:** Add “avoid wishcessibility” modules to WordCamp and meetup kits, with live testing demos. - **Training:** Ship lesson plans on accessibility debugging, user-testing basics, and interpreting automated scores responsibly. - **Marketing:** Avoid promoting overlays or “one-click compliance” tools; instead, highlight real accessibility work and case studies. - **Support:** Maintain SLAs for accessibility-related tickets and create escalation paths to specialized reviewers. - **Design:** Add accessibility checkpoints to design reviews, emphasizing copy, interaction states, and motion sensitivity. - **Documentation:** Expand examples-first patterns in DevHub/HelpHub for forms, dialogs, and navigation that have been AT-tested. - **Photos/TV:** Ensure captioning and alt text practices align with WCAG and avoid tokenistic representation. - **Polyglots:** Coordinate terminology for accessibility across locales; avoid mistranslations of key concepts like ARIA roles. - **Accessibility:** Maintain an issues heatmap that highlights recurring wishcessibility patterns; schedule periodic audits. - **Meta:** Improve `.org` tools for plugin/theme authors to self-audit accessibility with guidance, not just scores. - **CLI:** Provide commands to scaffold accessible plugin/theme skeletons and to run basic accessibility checks. - **Hosting:** Encourage hosts to adopt sane defaults (e.g., no forced overlays) and surface accessibility docs in control panels. - **Tide:** Make scoring logic transparent, and provide remediation guidance so scores foster learning, not just target-chasing. - **Openverse:** Ensure ingestion UI and content browsing work well with screen readers and keyboard-only users. - **Themes:** Offer mentoring and linting to reduce common accessibility anti-patterns in submissions. - **Plugins:** Improve review coverage for ARIA usage and overlays; partner with security liaisons to address malicious/false claims. #### The WPOCC - Design fellowship programs for accessibility maintainers and educators, providing stipends for sustained work. - Run governance clinics that help projects encode accessibility responsibilities in their charters and decision structures. - Pilot funding experiments that link microgrants to concrete accessibility outcomes (e.g., user tests, docks improvements), with transparent ledgers. ### FAIR - Ensure AI-assisted accessibility tooling runs locally or with clear privacy guarantees; verify provenance and model documentation. - Publish policies for funding, conflicts of interest, and sunset clauses for accessibility tooling pilots to avoid vendor capture. - Provide reusable governance artifacts (accessibility charters, scorecards) that projects can adapt and adopt. --- ## 🧪 Hypotheses - H1: Teams relying primarily on automated scores and overlays will ship more accessibility regressions than teams that incorporate real user testing. - H2: Developers exposed to the “wishcessibility” framing will be more likely to question shallow accessibility advice and LLM outputs. - H3: Organizational investment in recurring disabled-user testing sessions leads to higher long-term accessibility outcomes than equivalent spend on compliance tooling. - H4: LLM-generated accessibility guidance about ARIA attributes diverges significantly from actual assistive technology support patterns. - H5: Providing nuanced, context-rich accessibility education reduces misuse of ARIA and `tabindex` compared to checklist-only training. --- ### 📊 Methodology - For H1/H3: - Compare cohorts of projects: those primarily using overlays/scores vs those funding recurring user tests. - Track issues, user complaints, and WCAG conformance over time. - For H2: - Run a controlled study where one group of developers reads the article and another doesn’t. - Give both groups similar accessibility tasks; measure reliance on shallow advice and error rates. - For H4: - Sample LLM responses about ARIA attributes and compare them against current AT support matrices (e.g., a11ysupport.io). - Rate discrepancies and potential harm. - For H5: - Deliver different training modules (checklist vs narrative/case-based) and test participants on practical ARIA and keyboard navigation tasks. --- ### ❓ Questions - How can organizations practically balance legal compliance demands with the need for nuance and experimentation in accessibility? - What lightweight user-testing practices are realistic for small teams and open-source projects? - How can LLMs be constrained or fine-tuned to avoid recommending wishcessible patterns? - What incentives would make leadership choose real user research over “answer-shaped” personas? - How can accessibility standards better incorporate and surface conflicting user feedback? --- ### 🔮 Future Research - Longitudinal studies on the impact of overlays and compliance-grade tools on actual disabled-user satisfaction. - Frameworks for integrating conflicting user feedback into evolving accessibility standards. - Best-practice patterns for using AI to *support*—not replace—accessibility experts and user testing. - Governance models that embed accessibility responsibilities and fail-safes into product lifecycles. - Methods for measuring “wishcessibility” incidents inside organizations. --- ### 💡 Implications - **Practice:** Developers should treat scores and ARIA recipes as hypotheses to test with real users, not end goals. - **Policy:** Regulators might emphasize qualitative evidence (user research, issue resolution) alongside quantitative conformance. - **Security:** Overlays and unvetted scripts may introduce security risks on top of questionable accessibility gains. - **Education:** Curricula must incorporate case studies of failed “good intentions,” teaching students to value impact over checklists. - **Funding:** Grants and budgets could prioritize user testing and practitioner time, not just tools and audits. --- ### 🧠 Learning Styles Assessment - **Reading level estimate:** Roughly high school/early college; conversational but with domain-specific jargon (ARIA, WCAG, LLMs). #### 👀 Visual learners - Present: Conceptual metaphors (recycling, party cleanup); implicit mental imagery. - Improve: Diagrams showing flows from standards → tools → users; before/after code comparisons; AT support tables. #### 🔊 Aural learners - Present: None explicitly (text article only). - Improve: Short audio narration or podcast-style reading; 2–5 minute summary with examples. #### 🗣️ Verbal learners - Present: Strong analogies (“wishcycling”), clear definitions, narrative examples. - Improve: Glossary of key terms (ARIA, overlays, WCAG) and side-by-side comparisons of good vs bad practices. #### 🧩 Kinesthetic learners - Present: Mostly conceptual; no interactive tasks. - Improve: Hands-on exercises (e.g., test a component with a screen reader, fix issues, re-test). #### 🧠 Logical learners - Present: Argument chaining (good intentions → shallow advice → harm); quote of Goodhart’s Law. - Improve: Explicit causal diagrams, decision trees for when to use ARIA or AI tools. #### 🧑‍🤝‍🧑 Social learners - Present: Emphasis on community of practitioners and organizational dynamics. - Improve: Discussion prompts, group labs, peer review of accessibility work. #### 🧘‍♀️ Solitary learners - Present: Reflective tone; readers can introspect on their own practices. - Improve: Reflection questions at the end; self-checklists. #### 🌿 Naturalistic learners - Present: Environmental analogy (recycling, landfill) to connect with sustainability thinking. - Improve: More explicit connections between digital accessibility and broader social/ecological systems. --- ### 📊 Accessibility Assessment #### Screen reader semantics - Present: The article’s argument notes ARIA and support matrices but doesn’t describe its own HTML structure. - Improve: Ensure semantic headings, proper landmark roles, and descriptive alt text where screenshots appear. #### Keyboard navigation - Present: Not described. - Improve: Verify tab order, focus visibility, and absence of traps; ensure skip links are available. #### Contrast and readability - Present: Unknown from text alone. - Improve: Maintain at least 4.5:1 contrast, sufficient line spacing, and readable font sizes. #### Text resizing and reflow - Present: Not specified. - Improve: Test at 200% zoom and with responsive layouts; support prefers-reduced-motion and reduced data modes. #### Media and captions - Present: References to screenshots, but no explicit mention of alt text or captions. - Improve: Add alt text, long descriptions where needed, and avoid autoplaying media. #### Forms and interactions - Present: N/A (article content only). - Improve: For any site forms, ensure labels, error hints, and touch target sizes are accessible. #### Standards reference - Map site-level gaps against WCAG 2.2 AA, especially 1.4.* (perceivable), 2.1.* (keyboard), 2.4.* (navigable), and 3.3.* (input assistance). --- ### 🌍 DEIB Assessment #### Cultural breadth - Present: Focuses primarily on disabled users; limited geographic or cultural examples. - Improve: Include scenarios from multiple regions, languages, and assistive technology ecosystems. #### Inclusive language - Present: Generally respectful, using “disabled people” and clear explanations of concepts. - Improve: Add brief clarifications for technical jargon and avoid assuming prior knowledge of ARIA/WCAG. #### Neurodiversity support - Present: Structured into clear sections and arguments but without explicit calls to neurodiverse needs. - Improve: Use consistent heading patterns, summaries, and optional low-stimulation reading modes. #### Representation - Present: Speaks about disabled users but does not include direct quotes or case studies from them. - Improve: Incorporate voices and examples from diverse disabled individuals. #### Psychological safety - Present: Acknowledges failure as part of learning, encouraging practitioners not to give up. - Improve: Explicitly normalize discussing past mistakes and provide guidance on accountability without shame. --- ### ✅ Logical Validity #### Strong reasoning - Uses a clear analogy (wishcycling ↔ wishcessibility) to explain the gap between intent and impact—strong analogical reasoning that makes the concept memorable. - Cites Goodhart’s Law to support the critique of overreliance on scores, a robust causal argument about metrics and behavior. - Distinguishes categories (wishcessibility vs corporate greed) to avoid conflating different types of harm, which strengthens conceptual clarity. #### Fallacies - The article leans anecdotal, but does not clearly commit to overgeneralization; it acknowledges nuance and limitations. - Potential implicit hasty generalization: suggesting many orgs would prefer LLM budgets over user testing, though not backed by data. This could be improved with surveys or concrete examples. #### Tone of voice - Tone is reflective, conversational, and gently critical—empathic to both disabled users and well-intentioned practitioners. - Uses humor and metaphor (pizza boxes, “Resident Sisyphus”) to soften critique while still highlighting systemic problems. --- ### 🛡️ DARVO Analysis - **Deny:** The article does not deny harm; it foregrounds it, especially in corporate decisions that sideline accessibility. - **Attack:** It criticizes practices and systems (overlays, score-chasing, under-resourcing) rather than attacking individuals or disabled users. - **Reverse victim/offender:** The author avoids casting organizations as victims; instead, it centers disabled users and acknowledges the risks of good intentions. - Overall, the piece does not exhibit DARVO patterns; it encourages accountability and learning rather than defensiveness. --- ## 🎯 Conclusion The article argues that “wishcessibility” captures a widespread problem: earnest but shallow accessibility work that can harm the very users it seeks to help. Legal compliance, scores, and AI answers are useful only as starting points; meaningful accessibility requires systemic support, real user testing, and a willingness to grapple with human messiness. Next steps for readers include questioning shortcut solutions, investing time in learning and testing with disabled users, and treating standards as baselines rather than final goals. --- ## 🧱 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] Wishcessibility names harmful good-intent accessibility > [!quote] [Wishcessibility](https://www.nicchan.me/blog/wishcessibility/) by [[nicchan.me]] via [[nicchan.me]]. Published 2026-02-09. > “Wishcessibility is anything that inadvertently hurts accessibility when you’re trying to improve it.” Two lines: Defines a concept that distinguishes intent from impact in accessibility work. Useful for framing discussions about misguided practices. [view highlight](https://www.nicchan.me/blog/wishcessibility/#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] Compliance scores flatten accessibility nuance > [!quote] [Wishcessibility](https://www.nicchan.me/blog/wishcessibility/) > “An inherent part of creating standards involves flattening nuance into something reproducible in different contexts.” Two lines: Explains why grades and scores can mislead; essential for designing healthier accessibility metrics. [view highlight](https://www.nicchan.me/blog/wishcessibility/#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] Wishcessibility harms users despite good intent - Applies to teams doing accessibility changes without sufficient expertise or testing. - Pointer: core definition section of “Wishcessibility”. - Links: [[Accessibility-Practice]] [[Intent-vs-Impact]] #### [Z2] Accessibility scores encourage target-chasing behavior - Hold when organizations prioritize numeric grades over real user feedback. - Pointer: discussion referencing Goodhart’s Law and accessibility grades. - Links: [[Metrics-and-Incentives]] [[Accessibility-Governance]] --- ### ✏️ 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] Map common “wishcessible” patterns in our codebases and prioritize fixes/education — context/https://www.nicchan.me/blog/wishcessibility/ #fleeting #inbox - [F2] Design a workshop comparing LLM accessibility advice vs real AT behavior — context/https://www.nicchan.me/blog/wishcessibility/ #fleeting #inbox - [F3] Draft a metrics framework that complements accessibility scores with user-testing evidence — context/https://www.nicchan.me/blog/wishcessibility/ #fleeting #inbox --- <!-- deep-read:sections end -->