Las cinco reglas de ARIA

En Using ARIA:

1. First Rule of ARIA: If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
2. Second Rule of ARIA Use: Do not change native semantics, unless you really have to.
3. Third Rule of ARIA Use: All interactive ARIA controls must be usable with the keyboard.
4. Fourth Rule of ARIA Use: Do not use role="presentation" or aria-hidden="true" on a focusable element.
5. Fifth Rule of ARIA Use: All interactive elements must have an accessible name.

Y en español:

1. Primera regla de ARIA: si puede usar un elemento o atributo HTML nativo con la semántica y el comportamiento que ya necesita, en lugar de reutilizar un elemento y agregar un rol, estado o propiedad de ARIA para hacerlo accesible, entonces hágalo.
2. Segunda regla de ARIA: no cambie la semántica nativa, a menos que realmente tenga que hacerlo.
3. Tercera regla de ARIA: todos los controles interactivos de ARIA deben poder utilizarse con el teclado.
4. Cuarta regla de ARIA: no use role="presentation" o aria-hidden="true" en un elemento enfocable.
5. Quinta regla de ARIA: todos los elementos interactivos deben tener un nombre accesible.

Una excelente crítica de las capas de accesibilidad (accessibility overlay)

Karl Groves, un experto internacional en accesibilidad web, ha escrito What would an ethical overlay look like?:

Accessibility overlays have existed on the market since at least around 2004. Companies such as Readspeaker offered products that displayed a widget on customers’ websites that were best described as “add-on assistive technologies”. The primary feature offered by such products was the ability to read the page content aloud to a website’s users.

The benefit to such a feature would seem obvious to the layperson: If you have problems seeing the page or have problems reading, then a feature that reads the content for you would certainly be a significant improvement.  To people with deep knowledge of the Web and accessibility, the shortcomings of a per-site read-aloud widget are glaring. After all: if a user needs to have the content read-aloud to them on one site, they’ll need it on all websites and all applications they use.  In other words, such software is best deployed on the user’s computer, not on individual websites.

[...]

It is simply impossible to examine the claims made by overlay vendors against what their products actually do and come up with a conclusion that differs from the following: 

Overlay vendors overstate their products’ capabilities. They deceive their customers and, as a result, are actively harming the field of accessibility and doing a severe disservice to end users with disabilities. This, in turn, is a waste of money and delays active improvement to a website. These products will not make your site compliant with the ADA, Section 508, EN 301 549, or any other regulation based on WCAG.

La importancia de la revisión manual de la accesibilidad web

En The Importance Of Manual Accessibility Testing se analiza la importancia de realizar revisiones manuales de la accesibilidad web y no confiar ciegamente en las herramientas automáticas:

Automation really shines here. It can repeatedly and tirelessly pour over these details with perfect memory, at a rate far faster than any human is capable of.
However…
Automated accessibility tests aren’t a turnkey solution, nor are they a silver bullet. There are some limitations to keep in mind when using them.

Accesibilidad de los programas de videoconferencia

En Which Video Conferencing Tools Are Most Accessible? han analizado la accesibilidad de los programas de videoconferencia, parece que el mejor es Zoom.

accessiBe, la herramienta mágica

accessiBe es una herramienta mágica por todo lo que promete:

accessiBe is transforming web accessibility by replacing a costly, manual process with automated, state-of-the-art AI technology.
Using the contextual understanding and image recognition, acessiBe’s AI scans and analyzes websites to learn what elements and functionality they include, and adjusts them to blind users’ screen-readers.

¿Será verdad?

Dyslexic.com

Dyslexic.com es un sitio web dedicado a la venta de productos de apoyo para las personas con dislexia.

Tiene una página dedica a los tipos de letra para las personas con dislexia.

CSS para mejorar la legibilidad de los textos

En el artículo Modern CSS Techniques To Improve Legibility de Smashing Magazine explican cómo mejorar la legibilidad de los textos con CSS.

Juego ganador del concurso Disability Serious Game

Hace un mes se publicó la nota de prensa ‘Able Center, idea ganadora del concurso ‘Disability Serious Game’.

En el sitio web del concurso Disability Serious Game se puede encontrar más información. Hay una guía básica de conceptos de discapacidad, accesibilidad y videojuegos.

Y relacionado con este concurso, muy interesante todo el análisis que se realiza en Cómo pueden los videojuegos potenciar la vida de las personas con discapacidad.

Las distintas formas de esconder el contenido en el navegador

En Inclusively Hidden:

There are various ways to hide content in web interfaces, but are you aware of the different effects they have on the accessibility of that content? While some might think it’s strange to have multiple different ways to hide content, there are certain benefits that each method provides.

There have been many articles written about hiding content, and this post will cover some of the noted methods, and purposefully ignore others. This article will highlight the methods of hiding content that are most appropriate for modern web development, and note the accessibility impacts of each.

[...]

To wrap this all up…

Let’s do a quick recap:

1. There are three categories of hidden content:
1. Completely Hidden.
2. Visually Hidden.
3. Only Hidden from Assistive Technology.
2. Depending on the type of content, you will need to use an appropriate technique to hide it, via:
1. Using CSS or [hidden] to hide content completely.
2. Using visually-hidden / sr-only classes to visually hide content, but keep it available for assistive technologies.
3. Or using aria-hidden="true" to hide content specifically from screen readers.

Going back to my initial question “why are we hiding content?”, it’s apparent that there are some elements of a UI that truly need to be hidden. And while we have techniques to hide content, but still make it accessible for assistive technology users, I wouldn’t necessarily jump to these techniques as design solutions.

The goal should be to craft interfaces and experiences that are accessible and understandable to as many people as possible. Not to create interfaces where we can shoe horn in additional context by visually hiding it by default.

Si no sabes esto, mejor cambia de trabajo

Un tuit interesante de Web Axe:

Hey #webdev, if you don't know at least 3 reasons why this code is bad, please learn why. #a11y

Accesibilidad de páginas web: WordPress

Accesibilidad de páginas web: WordPress, webinar organizado por la Unidad Académica de Tecnologías de la Información y la Comunicación de la Universidad Católica de Cuenca (Ecuador) el 19 de junio de 2020:

II parte Conferencia Implementación de cursos en línea masivos y abiertos accesibles

Conferencia impartida en la Universidad Estatal a Distancia (UNED) de Costa Rica.

Contenido:

Cómo diseñar y ofertar cursos masivos y abiertos accesibles, y la importancia de elaborar recursos accesibles, a partir de la experiencia del Dr. Sergio Luján Mora en la Universidad de Alicante, España.

I parte Conferencia Implementación de cursos en línea masivos y abiertos accesibles

Conferencia impartida en la Universidad Estatal a Distancia (UNED) de Costa Rica.

Contenido:

Cómo diseñar y ofertar cursos masivos y abiertos accesibles, y la importancia de elaborar recursos accesibles, a partir de la experiencia del Dr. Sergio Luján Mora en la Universidad de Alicante, España.

Curso sobre desarrollo de aplicaciones web accesibles con React

El curso Develop Accessible Web Apps with React es de pago ($99), pero es el primero que veo que trate este tema. La descripción dice que en este curso se aprende:

• The impact of in-accessible web apps different disability groups
• How to access web sites in the same way impaired users do
• Inspecting & testing tools for accessibility
• Write accessible and extensible UI elements & widgets
• Iteratively refactor & test accessibility issues

Otro artículo sobre los problemas que causan los "accessibility overlays"

No es que yo busque estos artículos, ellos me encuentran a mí.

Una "web accessibility overlay" es la capa que se añade a un sitio web mediante un software que promete mejorar la accesibilidad de los sitios web.

Muchos sitios web usan los "accessibility overlays" como solución rápida para decir que un sitio web es accesible, pero no es verdad al 100%: sí que es verdad que pueden resolver ciertos problemas, pero no todos. Y el principal problema, la falta de conocimiento de los desarrolladores del sitio web no lo resuelven: los desarrollos futuros seguirán teniendo problemas de accesibilidad y existirá una dependencia de estas soluciones.

En Overlays and Plugins Aren’t the Answer to Accessibility, que incluye un podcast, explican más cosas sobre los "accessibility overlays":

Website accessibility overlays and plugins aren’t the answer to accessibility and compliance, despite being touted as an easy, automated solution for web designers and developers and their clients. They present a plethora of problems.
What Is an Accessibility Overlay 

But first, let’s talk about what an accessibility overlay is. Like some accessibility plugins, an overlay is used to detect and fix accessibility issues on a website. An accessibility overlay is installed by simply adding one or a few lines of code—javascript—to the site. It modifies the site usually only at the browser level, not touching the site’s code.
The site gets analyzed and—poof!—the site is now magically fully accessible and compliant within a day or two, and it performs regular checks and fixes to ensure ongoing compliance. Sounds great, right?
Claims Made by Accessibility Overlay Vendors 

Many of the claims made by the vendors of these accessibility overlays sound way too good to be true. Let’s take a look at some of them:

• “Just insert this code, and your site will be accessible.”

• Scanning and fixing your site will be done every 24 hours (or other timeframe).

• Overlays have a higher success rate than accessibility services.

• They provide compliance to many laws, including ADA, Section 508, EN 301549 and WCAG 2.1 AA guidelines. I noticed some touting “100% compliance,” and others said “up to 50% compliance” for x price, then “up to 95% compliance” for higher rates. What if the site ends up being in 25% compliance? Sounds like it would still be what they are promising, so your client will get screwed.

And just a side note… Ironically, a lot of these overlay vendors have accessibility issues on their own sites that are using their own overlays!
Problems With Accessibility Overlays 

Now, there are some things an automated tool can check for and fix. Industry experts estimate that about 25% to 30% of accessibility issues can be detected. Those are the more cut-and-dry issues. Some other issues may be able to be found but not fixed properly or at all.
About 70% to 75% need to be dealt with manually, reviewed by a person, not an automated tool.
So let’s get into some of the specific problems with accessibility overlays.

Una pequeña introducción a la discapacidad cognitiva

En An Introductory Guide to Understanding Cognitive Disabilities se muestra algunos ejemplos de las diferentes discapacidades cognitivas:

• Aphasia Speaking (finding words), writing or understanding language
• Autism May have difficulty understanding some communications or social interactions
• Attention-Deficit/Hyperactivity Disorder Focusing and Keeping Attention
• Dyslexia Recognizing letters and words
• Dyscalculia Recognizing numbers and symbols
• Intellectual “intellectual functioning (such as learning, problem-solving, judgment) and/or adaptive functioning (activities of daily life such as communication and independent living)” – American Psychiatric Association
• Memory Loss Difficult time remembering past events, new events, or both

Y los problemas que pueden experimentar:

• Attention – ability to focus and keep focused on the current task
• Processing Speed – the rate at which the brain handles information
• Short-Term Memory – the ability to retain information for short periods of time
• Long-Term Memory – the ability to store and recall information for later use
• Logic & Reasoning – the ability to reason, prioritize and plan
• Language Processing – the ability to recognize letters and words and the ability to understand written or spoken language
• Math Processing – the ability to recognize numbers and symbols and the ability to understand and calculate simple math

Cómo diseñar para personas ciegas y con visión parcial

Muy interesante el artículo How to design websites for blind and partially sighted people:

According to the World Health Organization, an estimated 253 million people live with vision impairment across the globe. 36 million are blind and 217 million have moderate to severe vision impairment.

As of 2014, there are around 360,000 people registered as blind or partially sighted in the UK. But these are just the people who are registered. According to the RNIB the figure doesn’t take into account, “those who are waiting for treatment, those whose sight could be improved, those who have not registered for whatever reason and people whose sight loss is not at a level that allows them to register.”

RNIB estimates that a truer figure is roughly two million people living with significant sight loss in the UK.

[...]

In November 2016, Gov.uk published the results of their assistive technology survey, in which the Government Digital Service asked 712 users about what devices, web browsers and assistive technology they used to access GOV.UK.

These are the results:

• Screen magnifier 30%
• Screen reader 29%
• Speech recognition 18%
• Readability 15%
• Other 8%

[...]

Do you run user testing with blind and partially sighted people? If so, what are the most common issues they find navigating the web?

Andreas: Yes, we run user testing with blind and partially sighted people. Here are some of the more frequent problems found by blind users:

• Areas not accessible via the screen reader
• Page content not structured with headings
• Headings do not follow logical sequence
• Images without alternative text
• Inputs without associated labels
• Links without accessible description
• Buttons without accessible description
• Interactive elements not properly marked using the appropriate HTML element
• We often find that the problems reported by blind and partially sighted people differ a lot.

Estudios masivos sobre la accesibilidad de las páginas web

Dos estudios recientes (tienen menos de 6 meses) sobre la accesibilidad de las páginas web:

• The WebAIM Million - An annual accessibility analysis of the top 1,000,000 home pages
• We Analyzed 10,000,000 Pages and Here’s Where Most Fail with ADA and WCAG 2.1 Compliance

Inclusión de la accesibilidad universal en los currículos formativos de las universidades en España

Ayer se presentó el estudio Inclusión de la accesibilidad universal en los currículos formativos de las universidades en España, estudio elaborado por el Real Patronato sobre Discapacidad y la Fundación ONCE, con el objetivo de conocer el grado implantación en los estudios universitarios del Diseño para Todas las Personas y la Accesibilidad Universal.

Está disponible el vídeo de la presentación:

Así ve Twitter un ciego, así oye Youtube un sordo

Muy interesante el artículo Así ve Twitter un ciego, así oye Youtube un sordo:

Juanjo Montiel convive con dos perros guía porque su mujer también es ciega. "Pero no somos endogámicos", me dice entre risas. Hay diez ojos en casa y solo cuatro no funcionan, los de los adultos. Juanjo tiene 32 años, es de Málaga pero vive en Barcelona con su mujer y su hijo de dos años. 

Cuando llamo a Juanjo para charlar yo soy el ciego y tengo que interpretar el contexto. Está caminando por la calle y se oyen de fondo los jadeos de Whost, su perro guía. Mientras hablamos le da instrucciones y le regaña cariñosamente por algo que no consigo entender. Coge el ascensor, deja pasar a una vecina y llega a casa. Todo esto a la vez que me cuenta cómo manipula la API de Twitter para adaptar la aplicación y poder entenderla. Un figura. 

Conozco a Juanjo de casualidad por las redes. @kastwey ya es mi ciego de cabecera. Alguna vez me ha pedido que le describa una foto que circula por ahí o un meme que es chungo de entender incluso para los que conservamos la vista. Le observo mucho. Es normal verle pidiendo ayuda para que alguien le resuelvan un captcha o le lea un código de alguna etiqueta ilegible por OCR. Siempre he sentido curiosidad por saber cómo se desenvuelve en Twitter un ciego que lleva usándola desde 2009. Este es el momento.