Adrian Roselli, experto en accesibilidad web, denunciado por hablar de las capas de accesibilidad (accessibility overlays)

Muy sorprendente todo lo que se cuenta en New Low in the Accessibility “Industry:” Overlay Company Sues Globally-Recognized Accessibility Expert:

This is an article about a lawsuit filed against a digital accessibility advocate named Adrian Roselli.  Adrian has been outspoken against a type of software called an overlay. This type of overlay promises to make websites accessible for disabled people with just one line of code. Lainey has criticized this software too. Adrian was sued by AudioEye, a company that sells overlays.  It is Lainey’s opinion that this lawsuit is a SLAPP suit. Those initials stand for “Strategic Lawsuit Against Public Participation.”  Adrian has been part of an urgent global dialogue about harms caused by overlays. And about their failure to meet the promise of website accessibility. Lainey urges AudioEye and its lawyers at a big global law firm called Akin to drop this lawsuit.

Accessible Perceptual Contrast Algorithm (APCA)

Accessible Perceptual Contrast Algorithm (APCA) es el nuevo método para calcular el contraste entre colores que va a sustituir al método actual que se emplea en WCAG.

En Why APCA as a New Contrast Method? explican:

Readability is a critically important aspect of web content, affecting 99% of internet users. For years, the WCAG 2.x contrast guidelines provided some guidance toward readability but are being replaced for the future WCAG 3.0. Here is an overview of the need for this change and discussion of the candidate replacement, the Accessible Perceptual Contrast Algorithm (APCA).

WCAG 2.x contrast and 1.4.3 and the related understandings and guidelines were born in an era before smart phones and iPads, when displays were mostly CRT type and websites used core web fonts. But that was a decade and a half ago. Today the contrast guidelines are in need of a complete overhaul due to the massive changes in computer display technology, web content, CSS functionality, and advances in vision science since 2005/2008, when WCAG 2.x was first introduced. For deeper background, see the author’s thread circa April 2019 in WCAG issue 695.

There are a number of reasons that WCAG 2.x contrast is faulty, one of which is the binary pass/fail nature of the SC for a property that does not apply in a binary way across perception nor impairments. Humans are not binary computers, and it is important to understand the non-linear aspects of perception, and to set guidelines that correctly model perception as opposed to “brute forcing” arbitrary values that ultimately do more harm than good.

Y APCA CONTRAST CALCULATOR es una herramienta online que permite calcular la diferencia de contraste según el nuevo algoritmo.

Lista de cosas relacionadas con la accesibilidad que Apple y Google hacen mal e insisten en hacer mal

Impresionante la lista recopilada por Adrian Roselli en I Don’t Care What Google or Apple or Whoever Did:

A very very quick selection of decisions that Google and Apple made that were counter to what experienced usability and UX experts recommended:

• Google Material Design told us form fields were better without boxes, until they tested it.
• Apple told us removing button outlines in iOS was better, until users complained.
• Google relies on color alone for links in search results, which is a WCAG violation.
• Apple went with super-thin typefaces in iOS, until finally making them thicker in subsequent releases.
• Google Chrome uses a default blue focus indicator, which is invisible on their own blue-background navigation.
• Apple thought animating apps on launch was cool, until users with vestibular orders got sick.
• Google deploys an update to its browser that can break the web for screen reader users, and lets it sit for for two releases.
• Apple for years has hidden the semantics of lists when they are styled, forcing developers to use hacks to reinsert them.
• Google shares lessons learned from its commendable Disability Support team in the form of an inaccessible PDF document that insists it cannot make accessible.
• Apple continues to fail to build VoiceOver support for an HTML element that has existed since the dawn of HTML and 2½ times longer than VoiceOver on iPhone.
• YouTube announces it is removing the ability for community members to contribute subtitles or captions to videos.
• Apple still does not send a focus event when a native button is clicked, an issue first reported in 2009, again in 2012, again in 2013, and yet again in 2013.
• Both Apple and Google are content to let crowd-funding efforts drive the addition of accessibility features (:focus-visible and inert) or CSS feature support (:not()) to their browsers.
• Apple makes a landing page touting its accessibility accomplishments, but the page itself has accessibility issues (not all are false positives, despite response).
• Google has a VPAT for Gmail that does not accurately describe its conformance, easily provable, and frustrating yet another claim of “but Google uses these colors”.
• Definitely do not follow YouTube as a good (or passable) example of how to build and use tabs.
• Google tweets a silent text-heavy video to promote its event for International Day of Persons with Disabilities, which is retweeted by the Google Accessibility account. I call them out, show how to do it accessibly, and Google deletes the tweet without acknowledgment while the Google Accessibility account never speaks of it.
• Google launches Designcember to promote its work on container queries and other technologies, but fails to support the developers and ensure the site is accessible. Which I call out. And for which my free labor is requested to QA fixes.
• Apple claims not once, not twice, but three times to have fixed CSS display property accessibility bugs, finally requiring a change in how Can I Use reports support.
• Google Chrome’s developer outreach site, Web.dev, shared how to build an accessible <tool-tip> custom element. Sadly, if you follow its advice you are guaranteed a SC 1.4.13 WCAG violation. Never mind translation issues, misunderstanding of how <abbr> is exposed, a conflation of accessible name and description, and an enforced inability to select text.
• Apple demonstrates Safari in visionOS by using a WCAG-failing site to show Apple’s bespoke low-contrast focus styles. For good measure, Apple also promotes problematic HTML structures.

Una entrevista a un experto sobre inteligencia artificial y accesibilidad

En Axi – Accessibility Intelligence, an interview with David O’Neill podemos leer:

There is a lot of optimism,  enthusiasm and trepidation on the interwebs about the transformative effect Artificial Intelligence (AI) will have on everything from marketing to the creative arts.

I often say that I am not an expert, but I know people who are. This is very much the case in terms of AI. Fortuitously, I have direct access to someone who is steeped in both accessibility knowledge and AI — or should I say Machine Learning (ML)? I am referring to David O’Neill, a Research Fellow at Vispero  (the parent company of TPGi). He has a low social media profile but has quietly been driving improvements in automated accessibility testing, and accessibility testing in general, for decades.

In the following interview, we will learn about David, and how he envisions AI/ML to be a force for major improvements in how we tackle the thorny problems of making technology work better for people — all people.

Y explica un caso concreto:

First off, it is a common misconception that AI/ML can solve all problems. That simply is not the case. The efficacy of AI/ML is a function of the use-case, availability of applicable models and tasks, and the volume/quality of available data for training and/or semantic search. So, evaluating these use-cases involves fitting it with proven ML tasks and inventorying your data.

Detecting Accessibility Issues is largely a classification task. Today, we perform accessibility issue detection in a highly deterministic manner.  We have functions that accept code as an input and use rule-based logic to assert a “pass or fail” outcome. We can say that the following code snippet is not accessible because it is an image with no ALT text attribute: <img src=”someimage.jpg”>. The lack of ALT text is easy to detect which allows us to classify the <img> element as “Inaccessible” with 100% confidence.

Can we do that specific test better with ML using a probabilistic model? And if so, is it worth it? The answer is probably not. We can train a classifier on a million code examples of images that are not accessible but have no guarantee that it will learn enough to predict “Inaccessible” on future examples with 100% accuracy. A simple rule of thumb is to use conventional deterministic algorithms whenever you can – provided the algorithms work, of course! The reasoning is simple: why trade in a sure, easy thing for a hard and costly result that only has some “probability” of being correct?

The key point here is that there is no benefit in using ML with fuzzy results and <100% accuracy on tasks that already have 100% accuracy with a traditionally programmed, non-learned algorithm.

Aplicaciones de la inteligencia artificial para la accesibilidad

En  Accessibility and Artificial Intelligence comentas algunas aplicaciones de la inteligencia artificial para la accesibilidad.

Básicamente, las dos situaciones que comenta son de sobra conocida: la generación automática de subtítulos en los vídeos y la generación automática de texto alternativo en las imágenes.

Los peligros de la inteligencia artificial para la accesibilidad web

En Five accessibility bugs GitHub Copilot offers to create explican los peligros de confiar en la inteligencia artificial en cuanto a la accesibilidad de una página web:

I like GitHub Copilot, at least for the narrow range of purposes I mentioned earlier. At the time I'm writing this up, there have been announcements about the next version of Copilot. Perhaps the next version will be fix some of these issues.

The danger here is that developers accept code suggestions, assuming that they're good. The 'wisdom of the crowd' could suggest that code based on millions of lines of code won't contain bugs. As demonstrated, this is not true.

Filtering the output, as it currently does to remove "offensive output", is possible. That probably wouldn't work better than current automatic accessibility testing and linting. So it would be an improvement, but not an absolute fix.

In my opinion, the responsibility always rests with the developer using the tool.

You shouldn't accept code suggestions from GitHub Copilot if you don't understand them. If you're expecting a certain type of suggestion, and you get one with extra attributes, you need to look them up. Don't use the code until you understand what every part of it does.

This could have a positive side. Maybe. It's possible that Copilot suggests accessibility considerations that people would otherwise have missed. Making people consider how to incorporate accessibility into their work normalizes it.

Adrian Roselli tampoco confía mucho en la inteligencia artificial para resolver los problemas de accesibilidad. En  No, ‘AI’ Will Not Fix Accessibility explica:

Large language models are habitual liars. Meanwhile, automated image descriptions aren’t much better. To give them the benefit of the doubt, perhaps these tools simply lack context.

As image tools get better at describing every detail of a picture, as language models do a better job of conveying an emoji-laden tweet in actual words, they are still not the authors of that content. They have no sense of why it was created. They cannot tell you that a series of vertical lines is meant to signify a wall in a meme.

Publicada la actualización de os títulos de la formación profesional del sistema educativo de Técnico Superior en Desarrollo de Aplicaciones Multiplataforma y Técnico Superior en Desarrollo de Aplicaciones Web

El 3 de junio de 2023 se publicó en el BOE el Real Decreto 405/2023, de 29 de mayo, por el que se actualizan los títulos de la formación profesional del sistema educativo de Técnico Superior en Desarrollo de Aplicaciones Multiplataforma y Técnico Superior en Desarrollo de Aplicaciones Web, de la familia profesional Informática y Comunicaciones, y se fijan sus enseñanzas mínimas.

Este Real Decreto modifica el Real Decreto 450/2010, de 16 de abril, por el que se establece el título de Técnico Superior en Desarrollo de Aplicaciones Multiplataforma y se fijan sus enseñanzas mínimas y el Real Decreto 686/2010, de 20 de mayo, por el que se establece el título de Técnico Superior en Desarrollo de Aplicaciones Web y se fijan sus enseñanzas mínimas..

En la definición de los contenidos del Módulo profesional Diseño de interfaces web aparece:

Diseño de webs accesibles:

− El Consorcio World Wide Web (W3C).

− Principios y Pautas de Accesibilidad al Contenido en la Web (WCAG).

− Criterios de conformidad. Niveles de conformidad.

− Técnicas para satisfacer los requisitos definidos en las WCAG.

− Prioridades. Puntos de verificación.

− Métodos para realizar revisiones preliminares y evaluaciones de adecuación o conformidad de documentos web.

− Herramientas de análisis de accesibilidad web.

− Chequeo de la accesibilidad web desde diferentes navegadores y dispositivos.

− Posicionamiento en buscadores. Mejora de la visibilidad de un sitio web en diferentes buscadores.

WAI-ARIA 1.2 ya es una recomendación

El 6 de junio de 2023 se publicó la versión definitiva de Accessible Rich Internet Applications (WAI-ARIA) 1.2.

Las diferencias respecto a WAI-ARIA 1.1 están recogidas en B. Substantive changes since the WAI-ARIA 1.1 Recommendation.

Accesibilidad de EPUB

El pasado 25 de mayo de 2023 se publicó al mismo tiempo EPUB 3.3 y EPUB Accessibility 1.1, que define los requisitos de accesibilidad de EPUB.

En EPUB Accessibility 1.1 podemos leer:

The primary source for producing accessible web content is the W3C's Web Content Accessibility Guidelines (WCAG) [wcag2], which establish benchmarks for accessible content. WCAG defines four high-level content principles — that content be perceivable, operable, understandable, and robust. These principles are also central to creating accessible EPUB publications, so it is no surprise that this specification builds on the extensive work done in WCAG.

Y después en 3.2 Relationship to WCAG dice:

WCAG [wcag2] and its associated techniques provide extensive coverage of issues and solutions for web content accessibility, covering everything from multimedia to interactive content to structured markup and more. They represent the foundation that this specification builds upon.

This specification does not repeat the requirements or techniques introduced in those documents, as it risks breaking compatibility between the two standards (e.g., putting guidance out of sync, or in conflict). At the same time, although this specification does not call out those requirements, it does not diminish their importance in creating EPUB publications that are accessible.

This specification instead defines how to apply WCAG to an EPUB publication — which is a collection of web documents as opposed to a single page — and adds an additional set of requirements. These requirements are no more or less important than those covered in WCAG; they are simply necessary to follow for EPUB publications. (Each requirement explains its relationship to WCAG in its respective section.)

The same is true of the techniques in the EPUB Accessibility Techniques document [epub-a11y-tech-11]. It provides coverage of techniques that are unique to EPUB publications, or that need clarification in the context of an EPUB publication. It does not mean that the rest of the WCAG techniques are not applicable.

As a result, although EPUB creators can read this section without deep knowledge of WCAG conformance, to implement the accessibility requirements of this specification requires an understanding of WCAG.

Because this specification adds requirements that are not a part of WCAG, an EPUB publication can conform to WCAG without conforming to this specification.

En EPUB 3.3 becomes a W3C Recommendation podemos leer:

Accessibility of EPUB publications was an essential part of the group’s activity. As a result, the EPUB Accessibility specification has been updated and, for the first time in the history of EPUB, is now an integral part of the EPUB Standard. Furthermore, the EPUB Accessibility specification is compatible with the European Accessibility Act whose influence will be significant on Digital Publishing in the years to come.

WCAG 2.2 un poco más cerca

Ayer (17/05/2023) el W3C publicó la nota de prensa  W3C WAI UPDATES FOR GAAD 2023, en la que se anuncia una actualización de WCAG 2.2 y también que a WCAG 3.0 le faltan años:

• An updated draft of WCAG 2.2 is being published in May 2023.
• WCAG 3.0 is exploring a different approach. It is years away from being completed.

Efectivamente, ayer también se publicó una actualización de WCAG 2.2, pero sigue como Candidate Recommendation Draft.

¿Cuándo se publicará la versión definitiva? En What's New in WCAG 2.2 Draft podemos leer:

WCAG 2.2 is scheduled to be completed and published in 2023 Q3 (July, August, September)

Y también podemos consultar los cambios experimentados desde la última versión publicada en enero de 2023:

Changes from the January 2023 CR to the May 2023 update include:

• 2.4.7 Focus Visible — Changed from Level A back to Level AA, as it is in WCAG 2.1.
• 2.4.11, 2.4.12, 2.4.13 — Changed numbering.
• 2.4.13 Focus Appearance — Changed to Level AAA. Edited to simplify and be more rigorous.
• 2.5.8 Target Size (Minimum) — Changed the “Spacing” exception and the “Inline” exception.
• 2.4.12 Focus Not Obscured (Minimum) — Changed the Notes.
• 3.3.8 Understanding Accessible Authentication (Minimum) — Added “(Minimum)”.

Día Mundial para Promover la Concienciación sobre la Accesibilidad Web

Mañana se celebra el Global Accessibility Awareness Day:

Thursday, May 18, 2023, help us celebrate the 12th Global Accessibility Awareness Day (GAAD)! The purpose of GAAD is to get everyone talking, thinking and learning about digital access and inclusion, and the more than One Billion people with disabilities/impairments.

Este día se celebra el tercer jueves de cada mes de mayo.

En el sitio web existe la traducción al español, Día Mundial para Promover la Concienciación sobre la Accesibilidad Web:

El 18 de mayo, le invitamos a participar en el Día Mundial para Promover la Concienciación sobre la Accesibilidad Web, conocido en inglés como Global Accessibility Awareness Day (GAAD). Cuando hablamos de la accesibilidad Web nos referimos a el contenido, la navegación y la interacción. El propósito de este día es para hablar, pensar y aprender sobre la accesibilidad de las tecnologías digitales (web, software, dispositivos móviles, etc.) y los diferente tipos de usuarios, incluyendo las personas con discapacidades. La audiencia que queremos atraer para GAAD son las comunidades de diseño, desarrollo, usabilidad y también los que crean, dan forma, apoyan financieramente e influencian la industria de tecnología y su uso. Aunque una persona este interesada en el tema de hacer la tecnología mas accesible y usable para las personas con discapacidades, la realidad es que muchas veces no saben como y donde comenzar. El conocimiento sobra la accesibilidad Web es el primer paso. Lea a continuación la entrada de un blog escrito por Joe Devon que inspiró esta campaña mundial.

La European Accessibility Act sigue retrasada en España

El próximo jueves 18 de mayo se celebra el Día Mundial para Promover la Concienciación sobre la Accesibilidad Web y quizás sea el mejor momento para recordar que España todavía no ha traspuesto la European Accessibility Act (EAA) a la legislación española.

La EAA, que realmente tiene por nombre Directiva (UE) 2019/882 del Parlamento Europeo y del Consejo, de 17 de abril de 2019, sobre los requisitos de accesibilidad de los productos y servicios, se publicó el 7 de junio de 2019 en el Diario Oficial de la Unión Europea. Esta Directiva establecía que debía ser transpuesta a la legislación nacional antes del 28 de junio de 2022.

España todavía no lo ha hecho.

Pero bueno, parece que España no es el único país. En Deadline for EAA transposition period missed by many EU Member States (30/09/2022) podemos leer:

For those Member States that have missed the transposition deadline, namely – Bulgaria, Czechia, Ireland, Greece, Spain, France, Cyprus, Lithuania, Luxembourg, Hungary, Netherlands, Poland, Portugal, Slovenia, Slovakia, and Sweden – EUD is calling on the corresponding National Associations of the Deaf to take immediate action accordingly.

El EAA se debe cumplir a partir del 28 de junio de 2025, solo quedan 2 años. Por si el Gobierno de España necesita ayuda para realizar la trasposición, el European Disability Forum proporciona una guía de ayuda, European Accessibility Act - Toolkit for transposition.

ACTUALIZACIÓN (17/5/2023)

Esta entrada la escribí y programé a principios de mayo y antes de publicarse ya estaba desactualizada. Por fin de ha publicado la trasposición de la Directiva 2019/882 sobre los requisitos de accesibilidad de los productos y servicios: Ley 11/2023, de 8 de mayo, de trasposición de Directivas de la Unión Europea en materia de accesibilidad de determinados productos y servicios, migración de personas altamente cualificadas, tributaria y digitalización de actuaciones notariales y registrales; y por la que se modifica la Ley 12/2011, de 27 de mayo, sobre responsabilidad civil por daños nucleares o producidos por materiales radiactivos.

Esta ley es un verdadero franskestein legislativo que comentaré en otra entrada.

Tamaño mínimo de los elementos de interacción

Web Content Accessibility Guidelines (WCAG) 2.1 tiene el criterio 2.5.5 Target Size (Level AAA):

The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:

• Equivalent: The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;
• Inline: The target is in a sentence or block of text;
• User Agent Control: The size of the target is determined by the user agent and is not modified by the author;
• Essential: A particular presentation of the target is essential to the information being conveyed.

Además, Web Content Accessibility Guidelines (WCAG) 2.2, que todavía está en el estado Candidate Recommendation Draft, incluye nueve nuevos criterios. Uno de ellos es 2.5.8 Target Size (Minimum) (Level AA):

The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:

• Spacing: The target does not overlap any other target and has a target offset of at least 24 CSS pixels to every adjacent target;
• Equivalent: The function can be achieved through a different control on the same page that meets this criterion.
• Inline: The target is in a sentence, or is in a bulleted or numbered list, or its size is otherwise constrained by the line-height of non-target text;
• User agent control: The size of the target is determined by the user agent and is not modified by the author;
• Essential: A particular presentation of the target is essential or is legally required for the information being conveyed;

En Accessible Target Sizes Cheatsheet aclaran todo esto con varios ejemplos.

Día Mundial para Promover la Concienciación sobre la Accesibilidad Web

El jueves 18 de mayo se celebra el Global Accessibility Awareness Day:

Thursday, May 18, 2023, help us celebrate the 12th Global Accessibility Awareness Day (GAAD)! The purpose of GAAD is to get everyone talking, thinking and learning about digital access and inclusion, and the more than One Billion people with disabilities/impairments.

Este día se celebra el tercer jueves de cada mes de mayo.

En el sitio web existe la traducción al español, Día Mundial para Promover la Concienciación sobre la Accesibilidad Web:

El 18 de mayo, le invitamos a participar en el Día Mundial para Promover la Concienciación sobre la Accesibilidad Web, conocido en inglés como Global Accessibility Awareness Day (GAAD). Cuando hablamos de la accesibilidad Web nos referimos a el contenido, la navegación y la interacción. El propósito de este día es para hablar, pensar y aprender sobre la accesibilidad de las tecnologías digitales (web, software, dispositivos móviles, etc.) y los diferente tipos de usuarios, incluyendo las personas con discapacidades. La audiencia que queremos atraer para GAAD son las comunidades de diseño, desarrollo, usabilidad y también los que crean, dan forma, apoyan financieramente e influencian la industria de tecnología y su uso. Aunque una persona este interesada en el tema de hacer la tecnología mas accesible y usable para las personas con discapacidades, la realidad es que muchas veces no saben como y donde comenzar. El conocimiento sobra la accesibilidad Web es el primer paso. Lea a continuación la entrada de un blog escrito por Joe Devon que inspiró esta campaña mundial.

Resultados del estudio The WebAIM Million

Este es el quinto año que WebAIM publica The WebAIM Million. Los resultados son similares a los años anteriores.

Esta vez, el porcentaje de páginas web que presentan algún error es 96.3%. Este porcentaje solo ha bajado 1.5% desde el 97.8% del primer año:

96.3% of home pages had detected WCAG 2 failures! This improved very slightly from 96.8% in 2022. Over the last 4 years, the pages with detectable WCAG failures has decreased by only 1.5% from 97.8%. These are only automatically detected errors that align with WCAG conformance failures with a high level of reliability. Because automatic testing cannot detect all possible WCAG failure types, this means that the actual WCAG 2 A/AA conformance level was certainly lower.

Los errores más comunes siguen siendo los mismos que otros años:

• Low contrast text
• Missing alternative text
• Empty links
• Missing form labels
• Empty buttons
• Missing document language

El informe dice:

96.1% of all errors detected fall into these six categories. These most common errors have been the same for the last 5 years. Addressing just these few types of issues would significantly improve accessibility across the web.

Sobre el contenido oculto

Un análisis interesante sobre las consecuencias de emplear contenido oculto: Visually hidden content is a hack that needs to be resolved, not enshrined.

Comentarios en Twitter sobre las capas de accesibilidad (accessibility overlay)

Hace unos pocos días pude leer la siguiente discusión en Twitter:

Dios mío, qué puto timo. Una web que dice que con un widget que metes con Javascript en tu página, la conviertes en WCAG 2.1 AA Compliance. Y nadie les cierra el chiringuito ni nada: https://t.co/0vcDMzfG7L
Lo peor es que las empresas se lo creen, y el usuario lo sufre 🤢🤢

— Juanjo (kastwey@mastodon.cat) (@kastwey) March 26, 2023

Sobre la automatización de los tests de accesibilidad

Muy interesante la reflexión que Karl Groves, uno de los gurús de la accesibilidad web, realiza en su artículo Automation is not the enemy.

Sobre la desaparición del criterio 4.1.1 en WCAG 2.2

Web Content Accessibility Guidelines (WCAG) 2.2 está a punto de ser aprobado y una novedad "extraña" es que el criterio 4.1.1 Parsing se considera obsoleto y, por tanto, se elimina. Esto va a originar una situación confusa, porque ya no se cumplirá lo de la compatibilidad con versiones anteriores. WCAG 2.2 avisa de ello en Comparison with WCAG 2.1, donde podemos leer:

WCAG 2.2 builds on and is backwards compatible with WCAG 2.1, meaning web pages that conform to WCAG 2.2 are at least as accessible as pages that conform to WCAG 2.1. Requirements have been added that build on 2.1 and 2.0. WCAG 2.2 has removed one success criterion, 4.1.1 Parsing. Authors that are required by policy to conform with WCAG 2.0 or 2.1 will be able to update content to WCAG 2.2, but may need to continue to test and report 4.1.1.

La industria responde a las críticas contra las capas de accesibilidad

Las capas de accesibilidad (accessibility overlays) es una tecnología que promete solucionar los problemas de accesibilidad de un sitio web con muy poco esfuerzo. Claro, para el propietario de un sitio web que necesite ser accesible, este tipo de soluciones son una maravilla. Pero es como las dietas milagro: pierde peso rápidamente, a veces poniendo en riesgo tu salud, para luego en unos pocos meses volver a recuperarlo.

En el sitio web Overlay False Claims se desmontan varias de las afirmaciones que emplean los fabricantes de este producto para anunciarlo y venderlo.

Ahora alguno de los fabricantes, o quizás varios que se han unido, han montado OverlayFacts para contrarrestar el sitio web Overlay False Claims.

Según un tuit de Karl Groves, uno de los máximos gurús de la accesibilidad web, es posible que detrás de OverlayFacts esté AccessiBe, una de esas empresas que vende accessibility overlays: