Is it an evil overlay? How can you tell? 🔗 **Source:** [Is it an evil overlay? How can you tell?](https://www.joedolson.com/2025/12/is-it-an-evil-overlay-how-can-you-tell/) > [!note]+ Document Notes > ```markdown > > --- > tags: [accessibility, WordPress, overlays] > author: Joe Dolson > source: joedolson.com > reference: [https://www.joedolson.com/2025/12/is-it-an-evil-overlay-how-can-you-tell/] > date created: 2025-12-15 10:30 > > --- > > # 🏷️ Title: Is it an evil overlay? How can you tell? > <!-- 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. - Dolson defines concrete criteria to distinguish harmful “accessibility overlays” from more defensible tools, using WP Accessibility and Elementor’s A11y plugin as case studies. - Why it matters. - Site owners are misled by promises of “instant compliance,” while disabled users face risky, untested changes and paternalistic UX. - Key stakeholders. - Disabled users, site owners, accessibility professionals, WordPress plugin authors, overlay vendors. - Risks and tradeoffs. - Generalized automated fixes can introduce new barriers; toolbar UX can be ableist; deceptive marketing shifts liability and wastes budgets. - Bottom line. - An “evil overlay” combines: (1) tools that presume how disability works, (2) untargeted automated remediation, and/or (3) claims of legal/standards compliance. ## 📖 Main Content - Core arguments (plain language) - Dolson starts from the premise that overlays are generally a problem, then asks: where is the line between “overlay-ish” tools and truly harmful overlays? - He identifies three dimensions: - Toolbar presentation: is it marketed as “for people with X disability” vs. simply “this does Y (e.g., increase font size)”? - Automated remediation: is it purpose-built for known issues or generalized, unvalidated auto-fixing? - Marketing: does it promise compliance or lawsuit immunity? - Toolbars are not inherently bad; the harm comes from targeting disabilities and implying they “fix” people instead of describing features. - Automated remediation is acceptable when: - A specific problem is identified by an expert. - A targeted script is implemented because the source cannot be fixed. - The fix is validated by testing. - Generalized remediation (e.g., scripts that modify many elements dynamically) can create more problems than it solves and is hard to audit. - Ethical marketing must clearly state limitations and avoid implying legal or full WCAG compliance. - Context & definitions - “Overlay”: tools that sit on top of existing sites, adding toolbars and scripts that automatically change markup/CSS/behavior in the name of accessibility. - “Purpose-built vs. generalized remediation”: - Purpose-built: custom, site-specific fix for a known issue. - Generalized: generic script that tries to detect and fix a wide range of issues automatically. - Uncertainties / contested areas - Even conservative automated fixes might still be wrong in some contexts. - Determining “safe enough” automated behavior is non-trivial and requires ongoing review. - Dolson is explicit that passing his criteria doesn’t mean a tool is recommended—only that it isn’t condemnable as a deceptive overlay. ### 🗒️ Notes - Starting assumptions - Overlays are generally problematic; debate over their existence is out of scope. - Baseline: any such tool itself must be accessible. - Motivation - He maintains WP Accessibility (WordPress plugin) which “smells like an overlay” (toolbar + automatic changes). - WP Accessibility Day has an explicit anti-overlay stance; Elementor’s A11y sponsorship forced the org to sharpen its definitions. - Overlay characteristics - Three traits that make something look like an overlay: 1. Toolbar with “accessibility” features. 2. Automated accessibility remediation scripts. 3. Unethical or misleading marketing. - Technical traits (1 & 2) are not inherently bad; ethics and implementation detail matter. - Toolbars - Concern: *targeting* and *framing*. - “Feature-first” presentation (e.g., “Increase font size”, “Pause animations”) is acceptable. - “Disability-first” presentation (“For people with visual impairments”, “For dyslexics”) is problematic and paternalistic. - Users need to know what a tool *does*, not that it “solves their disability.” - Assistive tech should travel with users, not be site-by-site; but toolbar existence alone is not enough to condemn a tool. - WP Accessibility & Elementor A11y (toolbar dimension) - WP Accessibility: only two toolbar tools (Increase Font Size, High Contrast), described as features → passes the toolbar framing test. - Elementor’s A11y: more features but similarly described by function (“Pause animations”, “Hide images”, “Outline focus”) → also passes. - Automated accessibility fixes - Distinguishes: - Purpose-built remediation: - Identified issue by an accessibility specialist. - Scripted fix targeted to that issue. - Follow-up testing confirms it works. - Used when fixing source is not feasible (e.g., vendor code). - Generalized remediation: - Script tries to discover and fix accessibility errors automatically with no per-site validation. - Purpose-built: “necessary evil” but acceptable. - Generalized: high risk; extends limitations of automated testing into the domain of automated fixing. - Many accessibility issues aren’t deterministic, so machines cannot safely decide how to fix them. - Example of risky remediation - Script that finds `role="button"` links and adds spacebar handlers: - May cause duplicate events, override existing handlers, or break patterns. - Hard to audit across all variations. - WP Accessibility (automation dimension) - Dolson knows exactly what WP Accessibility changes, but still questions his own assumptions. - He suggests a key safety measure: - All generalized remediation paths must be: - Clearly identified, and - Disable-able or customizable by site owners/developers. - By his own standard, WP Accessibility *currently fails* because some remediations can’t be controlled. - He plans to update settings so all overlay-like features are clearly labeled and can be disabled. - He hasn’t fully analyzed Elementor’s A11y automation behavior. - Marketing - Major red flag: claims like “install X and you’re fully compliant & safe from lawsuits.” - Sites use weasel words and hide limitations in fine print; that’s not acceptable. - The key: - Users should not have to dig into fine print to learn that the tool does *not* guarantee accessibility. - If marketing implies it substitutes for professional testing and remediation, it’s disqualifying. - WP Accessibility & Elementor A11y (marketing dimension) - WP Accessibility: - Clearly states: “WP Accessibility is not intended to make your site compatible with any accessibility guidelines.” - Dolson notes he might add explicit reference to legislation, but overall it’s honest. - Elementor’s A11y: - Plugin page states it is “NOT intended to completely make your website legally compliant.” - FAQ notes “no automated tool can promise full accessibility” and encourages hiring professionals. - Dolson finds this fair and transparent. - Negative example: accessiBe - Marketing headline: “Meet legal requirements under the ADA and win more business” with no clear qualification. - FAQ claims their widget audits code, identifies problems, and remediates them “so that your website is accessible based on WCAG.” - While text technically mentions “many of the issues”, it still strongly implies overall accessibility/compliance. - Dolson considers this misleading and an overlay red flag. - Final criteria summary - Harmful overlay combines any/all of: 1. Tools that assume how disability affects users (ableist targeting). 2. Untargeted, potentially risky generalized automated remediation. 3. Marketing that explicitly or implicitly promises standards/legal compliance. - Passing these checks: - Does *not* equal endorsement. - Only means the tool shouldn’t automatically be condemned as an “evil overlay.” - Each failure has different impact: - (1) Ableist framing but possibly useful features. - (2) Can introduce new accessibility errors. - (3) Actively deceives customers. ## 📚 References - Original article: [Is it an evil overlay? How can you tell?](https://www.joedolson.com/2025/12/is-it-an-evil-overlay-how-can-you-tell/) - WP Accessibility plugin: <https://wordpress.org/plugins/wp-accessibility/> - Elementor’s Accessibility (A11y) plugin/info: <https://elementor.com/> (search “Accessibility” / “A11y” docs) - accessiBe WordPress plugin listing: <https://wordpress.org/plugins/accessibe-accessibility/> ## 🗣️ Paraphrase - Paragraph A paraphrase. - Dolson, an accessibility plugin author and WP Accessibility Day organizer, wants to clearly define when a tool that “looks like an overlay” becomes ethically or technically unacceptable, focusing on toolbar design, automated fixes, and marketing. - Paragraph B paraphrase. - He argues that toolbars and scripts are not inherently bad; harm arises when tools claim to solve disabilities, apply broad unvalidated code changes, or promise compliance and lawsuit protection, misleading site owners and endangering users. ## 📰 Newsletter In this week’s WordPress accessibility spotlight, Joe Dolson digs into a thorny question: when does a helpful-looking accessibility plugin cross the line into “evil overlay” territory? Rather than debating overlays in general, Joe offers pragmatic tests: - Does your toolbar describe **features** (“Increase font size”) or claim to solve **disabilities**? - Are your automated fixes **purpose-built and tested**, or generalized scripts that silently rewrite markup? - Does your marketing promise **instant WCAG/ADA compliance** or “lawsuit-proof” status? Joe also turns the lens on his own WP Accessibility plugin and Elementor’s A11y tools, showing that transparency and configurability matter as much as technical capability. If you build or recommend WordPress accessibility tooling, this is essential reading for responsible product design and honest marketing: - WP Accessibility: <https://wordpress.org/plugins/wp-accessibility/> - Core accessibility docs: <https://developer.wordpress.org/block-editor/how-to-guides/accessibility/> ## ✅ Action Items #### DevRel - Developer advocacy - Prepare a talk/demo: “From overlays to honest accessibility tooling” using WP Accessibility and Elementor A11y as case studies. - Define metrics for adoption of safer patterns (e.g., % of plugins with clear limitations in readme). - Education - Create a workshop for plugin authors on: - Purpose-built vs. generalized remediation. - Writing non-ableist UI copy for toolbars. - Offer office hours for teams refactoring existing overlay-style features. - Developer experience - Add examples in docs showing safe remediation patterns (toggleable, narrowly scoped, testable). - Provide templates for “limitations” sections in plugin readmes. - Developer marketing - Audit marketing copy for any compliance/lawsuit claims; replace with accurate, scoped promises. - Track click-through and support tickets related to “compliance” expectations. - Community management - Run a survey on how site owners understand “accessibility plugins” and overlays. - Update community guidelines to discourage deceptive compliance claims. - Internal/external/cross-project - Align product, legal, and marketing on accessibility claims and disclaimers. - Establish a feedback loop with accessibility practitioners for plugin reviews. #### OSPO - Policy & Governance - Add a policy discouraging generalized auto-remediation in official/org-endorsed plugins. - Define decision rights for approving marketing language around compliance. - License Compliance - Ensure external overlay SDKs/libraries meet organizational accessibility standards before adoption. - Security Management - Treat generalized DOM mutation scripts as a risk surface requiring review. - Software Inventory - Track which sites use overlay-style tooling; maintain an up-to-date inventory. - Developer Support - Provide consultation hours on replacing overlays with proper remediation. - Community Engagement - Support upstream efforts in WordPress core/accessibility teams to document overlay risks. - Strategic Alignment - Add accessibility integrity KPIs (e.g., “0 official tools making compliance guarantees”). #### Community - Maintainers - Host roadmap clinics on deprecating risky auto-fix features and adding configuration toggles. - Contributors - Mark overlay-related issues as “good first issue” where they’re small, reversible changes (e.g., copy changes to avoid compliance claims). - Sponsors - Require honest accessibility positioning as a condition for sponsorships (mirroring WP Accessibility Day). - Ecosystem - Run joint incident drills: what happens if an overlay breaks navigation for screen readers across multiple properties? #### WordPress - Core - Document a stance on overlays and auto-remediation in official handbooks. - Core Performance - Analyze overlay performance overhead where present (extra scripts, DOM rewrites). - Core AI - If AI is used for accessibility suggestions, enforce “assist, don’t auto-fix silently” patterns. - **Core Program Team** - Coordinate with Accessibility, Plugins, and Marketing teams to keep messaging consistent. - Mobile - Ensure mobile apps don’t add overlay-style “accessibility” layers that conflict with OS assistive tech. - Playground - Provide sandbox examples of good vs. bad accessibility plugins for training. - Community - Include overlay/marketing topics in WordCamp accessibility talks and contributor days. - Training - Add a learning path: “Accessibility beyond overlays: how to do it right.” - Marketing - Avoid promoting plugins that promise instant compliance. - Support - Build canned responses explaining overlay limitations and pointing to remediation resources. - Design - Offer design patterns for feature-based, non-ableist toolbar UIs. - Documentation - Add a HelpHub article: “Why overlays are not a silver bullet.” - Photos / TV / Polyglots / Meta / CLI / Hosting / Tide / Openverse / Themes / Plugins - For each, ensure: - Accessibility guidance discourages overlays. - Plugin/theme review processes flag risky automated remediation and misleading claims. #### The WPOCC - Programs - Offer microgrants to maintainers refactoring away from generalized auto-remediation. - Projects - Host documentation sprints on ethical accessibility tooling. - Funding experiments - Pilot matched-grant programs for projects that improve accessibility without overlays. ### FAIR - Technical independence - Encourage local, open remediation tooling (scripts that can be audited, forked, and disabled) instead of opaque third-party overlays. - Policies and covenants - Codify “no compliance guarantees” as a norm for funded tools. - Productized governance artifacts - Provide standard charters and scorecards for evaluating accessibility tools on Dolson’s three criteria. ## 🧪 Hypotheses - H1: Plugins that explicitly disclaim compliance (“not intended to fully comply”) produce fewer legal/compliance-related support tickets than those that imply compliance. - H2: Generalized automated remediation introduces more new accessibility errors than it fixes, compared to purpose-built fixes. - H3: Feature-based toolbar copy (describing actions, not disabilities) results in higher user satisfaction among disabled users than disability-targeted copy. - H4: Site owners using overlay tools are more likely to believe their site is fully accessible without further remediation. ### 📊 Methodology - For H1 - Compare support ticket categories across plugins with/without compliance disclaimers over a defined period. - For H2 - Controlled A/B tests: run generalized scripts vs. targeted fixes on test sites; audit with manual testing and automated tools. - For H3 - UX study with disabled participants using two versions of the same toolbar (feature-based vs. disability-based copy); measure perceived respect and usefulness. - For H4 - Survey site owners, segmented by overlay usage, about their beliefs regarding accessibility completeness and legal risk. ### ❓ Questions - How much automated remediation can be considered “safe enough” before it becomes overlay-like risk? - Can we design generalized scripts that are conservative and transparent enough to be broadly acceptable? - What minimum disclosure should be required for accessibility plugins in marketplaces like WordPress.org? ### 🔮 Future Research - Develop and test guidelines for “safe automation” in accessibility tooling. - Longitudinal studies of sites before/after overlay adoption to track actual user impact. - Explore patterns for site-level vs. user-level assistive tools in the web ecosystem. ### 💡 Implications - Practice - Teams should favor source-level fixes and treat automated remediation as last-resort, well-documented patches. - Policy - Marketplaces and foundations can set standards against compliance promises in plugin listings. - Security - Generalized DOM mutation should be threat-modeled, as it affects both UX and integrity. - Education - Training should teach how to read and interpret accessibility marketing critically. - Funding - Grants and sponsorships can prioritize transparent, non-overlay-based accessibility work. ### 🧠 Learning Styles Assessment - Reading level estimate - Approx. high-school to early college (Flesch-Kincaid grade ~10–12): some technical terms but mostly plain language. #### 👀 Visual learners - Present - Minimal visuals; text descriptions dominate. Mention of a screenshot but primarily explanatory text. - Improve - Diagrams of overlay architecture; before/after code snippets; flowcharts for decision criteria. #### 🔊 Aural learners - Present - None indicated. - Improve - 3–5 minute audio summary or podcast-style discussion of the article. #### 🗣️ Verbal learners - Present - Clear definitions (e.g., purpose-built vs. generalized remediation), concrete examples, and careful wording analysis. - Improve - Glossary of key terms (overlay, remediation, WCAG, etc.), plus more analogies. #### 🧩 Kinesthetic learners - Present - Implicit experiments (e.g., try adding a script to role="button" links). - Improve - Step-by-step exercises: audit a plugin’s marketing, test a toolbar’s behavior, toggle features. #### 🧠 Logical learners - Present - Structured breakdown into three criteria; reasoning through cases and counterexamples. - Improve - Decision tree or checklist to classify tools as “overlay-like” vs. acceptable. #### 🧑‍🤝‍🧑 Social learners - Present - Reference to community stance (WP Accessibility Day), sponsor debates. - Improve - Discussion prompts for meetups; panel formats exploring overlay ethics. #### 🧘‍♀️ Solitary learners - Present - Reflective reasoning; readers can think through their own tooling. - Improve - Reflection questions at the end; self-check lists for assessing one’s own plugins. #### 🌿 Naturalistic learners - Present - None explicitly. - Improve - Analogies to ecosystems: overlays as invasive species vs. native remediation. ### 📊 Accessibility Assessment #### Screen reader semantics - Present - Article structure appears logically sectioned with headings; no complex widgets. - Improve - Ensure proper heading hierarchy and descriptive alt text for the referenced screenshot. #### Keyboard navigation - Present - Likely standard article flow without custom interactions. - Improve - Confirm robust focus styles and skip links at site level. #### Contrast and readability - Present - Depends on theme; text-heavy article suggests importance of good contrast. - Improve - Verify at least 4.5:1 contrast, comfortable line-height, and font size. #### Text resizing and reflow - Present - Standard responsive behavior expected. - Improve - Validate at 200% zoom with no horizontal scrolling for main content. #### Media and captions - Present - One screenshot; no audio/video. - Improve - Ensure screenshot has descriptive alt text or caption. #### Forms and interactions - Present - Likely none in the article body. - Improve - N/A for this specific piece; site-level forms should follow labeling and error-handling best practices. #### Standards reference - Map gaps to WCAG 2.2 AA - 1.4.x (contrast, resizing), 2.4.x (navigation), and 1.1.1 (image alt text) are main criteria to verify. ### 🌍 DEIB Assessment #### Cultural breadth - Present - Focused on web accessibility and legal frameworks (WCAG, ADA). - Improve - Include more global references (e.g., EN 301 549, regional laws) and diverse user examples. #### Inclusive language - Present - Generally respectful, emphasizes user needs and rejects ableist assumptions. - Improve - Add more explicit person-first or identity-first examples, clarify why disability-targeted marketing is harmful. #### Neurodiversity support - Present - Acknowledges tools like “Pause animations” that can help some neurodivergent users. - Improve - Discuss overlays’ impact on cognitive load and predictability. #### Representation - Present - Disabled users are referenced as core stakeholders, not afterthoughts. - Improve - Include more direct user perspectives or quotes from disabled practitioners. #### Psychological safety - Present - Critiques vendors, not users; validates confusion site owners may feel. - Improve - Offer more guidance on how to recover if you’ve previously relied on overlays. ### ✅ Logical Validity #### Strong reasoning - Type - Mostly inductive and causal reasoning with concrete examples (e.g., script that modifies `role="button"` links). - Strengths - Clear separation of dimensions (toolbar, automation, marketing) avoids overgeneralization. - Uses self-critique (of WP Accessibility) to show consistency and reduce bias. #### Fallacies - Not obvious - No clear strawmen; accessiBe is quoted directly. - No slippery slope; risks are tied to specific mechanics and examples. - Possible minor gaps - Some claims about generalized remediation risk could be supported with more empirical data but are still plausible. #### Tone of voice - Tone - Reflective, candid, and mildly humorous (e.g., “SupremoA11y…give it 10 minutes.”). - Critical of deceptive practices, but fair and specific in its critiques. ### 🛡️ DARVO Analysis - Deny - The article does not deny harm; it foregrounds potential harms of overlays. - Attack - Criticism is aimed at marketing tactics and technical choices, not at users. - Reverse victim/offender - No evidence of positioning vendors as victims; rather, it highlights how vendors exploit vulnerable site owners and disabled users. - Overall - No DARVO patterns present; rhetoric is accountability-focused. ## 🎯 Conclusion - Bottom line - An “evil overlay” isn’t defined by the presence of a toolbar or scripts alone, but by (1) ableist, disability-targeted tooling, (2) broad, unvalidated auto-remediation, and (3) misleading claims of compliance or legal protection. - Practical next steps for readers - Audit your plugins and services against these three criteria. - Prefer source-level fixes and purpose-built, testable scripts. - Ensure any accessibility marketing clearly states limitations and does not promise full compliance. --- ## 🧱 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] Overlays require ethical design and marketing > [!quote] [Is it an evil overlay? How can you tell?](https://www.joedolson.com/2025/12/is-it-an-evil-overlay-how-can-you-tell/) by [[Joe Dolson]] via [[joedolson.com]]. Published 2025-12-15. > “The ‘accessibility overlay’ we talk about and condemn is a combination of three possible problems.” Two lines: context and use. Cite data if relevant. [view highlight](https://www.joedolson.com/2025/12/is-it-an-evil-overlay-how-can-you-tell/#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] Generalized remediation creates new accessibility risks > [!quote] [Is it an evil overlay? How can you tell?](https://www.joedolson.com/2025/12/is-it-an-evil-overlay-how-can-you-tell/) > “Generalized remediation…can cover a vast array of possibilities, with wide ranging degrees of risk.” Two lines: context and use. [view highlight](https://www.joedolson.com/2025/12/is-it-an-evil-overlay-how-can-you-tell/#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] Ethical overlays avoid compliance promises - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Accessibility-Overlays]] [[Ethical-Marketing]] #### [Z2] Generalized remediation demands strict configurability - Scope/condition in one line. - Pointer to page/time or dataset. - Links: [[Accessibility-Tooling]] [[Automated-Remediation]] --- ### ✏️ 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] Audit my plugins for implied compliance claims—https://www.joedolson.com/2025/12/is-it-an-evil-overlay-how-can-you-tell/ #fleeting #inbox - [F2] Design a decision tree for classifying accessibility tools as overlays—https://www.joedolson.com/2025/12/is-it-an-evil-overlay-how-can-you-tell/ #fleeting #inbox - [F3] Add configuration toggles for all auto-remediation paths in my code—https://www.joedolson.com/2025/12/is-it-an-evil-overlay-how-can-you-tell/ #fleeting #inbox --- <!-- deep-read:sections end -->