Análisis de los sitios web de las aerolíneas del Reino Unido

En Report calls for airlines to improve WCAG compliance and the digital user journey podemos leer:

A new report has reviewed the websites of the 11 largest airlines operating in the UK, rating them in terms of their technical accessibility as well as the ease of use for making bookings.

The ‘Airline Digital Accessibility’ report, commissioned by the UK Civil Aviation Authority (UK CAA) and undertaken by Hassell Inclusion, first gave websites a score for their compliance with Web Content Accessibility Guidelines (WCAG 2.1 AA), a technical set of recommendations designed to improve accessibility standards.

A focus group of consumers with accessibility needs then provided insights on digital consumer journeys. The group highlighted that accessibility goes beyond just technical compliance and raised examples of how booking flights on websites in an accessible manner often differed depending on their needs and expectations.

[...]

British Airways scored highest amongst the airlines for its technical accessibility and scored 7/10 on its ‘Digital Consumer Journey score’. At the other end of the scale, Jet 2, Ryanair, and TUI received technical accessibility ratings of 1/10 and Digital Consumer Journey scores of just 2/10.

Comentarios sobre WCAG 2.2

A raíz de la publicación de WCAG 2.2 se han publicado muchos artículos sobre las novedades que incorpora. Algunos ejemplos son:

• Demystifying WCAG 2.2
• Intopia launches WCAG 2.2 Map
• Obligatory WCAG 2.2 Launch Post
• Quick overview of "What's New In WCAG 2.2" explainer posts
• WCAG 2.2 Is Now A W3C Recommendation

Y en A Roundup Of WCAG 2.2 Explainers se recogen muchos más...

Un vídeo sobre las capas de accesibilidad

En What Are Accessibility Overlays?:

What Are Accessibility Overlays? from Heydon on Vimeo.

Cuatro criterios de WCAG 2 que son AAA, pero bien podrían ser AA o incluso A

En Four Reasons to Give WCAG AAA a Second Look se analizan cuatro criterios de éxito de WCAG 2 que son de nivel AAA, pero que por su impacto en la mejora de la accesibilidad web, bien podrían ser AA o incluso A:

• 1.3.6 Identify Purpose
• 1.4.8 Visual Presentation
• 2.4.9 Link Purpose (Link Only)
• 2.4.10 Section Headings

El Ministerio de Justicia dice que ha mejorado la accesibilidad de su web para personas con discapacidad

En Justicia mejora la accesibilidad de su web para personas con discapacidad se dice:

El Ministerio de Justicia que dirige Pilar Llop ha ampliado su página web con una sección de ‘Justicia accesible’ para personas con discapacidad. El objetivo de esta ampliación es facilitar el acceso a la información de los usuarios.

Según destacó la ministra de Justicia en funciones, “la estrategia de portales web del Ministerio, en su esfuerzo por consolidar y simplificar la presencia en línea del departamento, pone especial énfasis en mejorar la experiencia de los ciudadanos al interactuar con los servicios ministeriales”.

La sección ‘Justicia accesible’ para personas con discapacidad tiene como objetivo garantizar la igualdad de acceso a la información con la inclusión de temas de especial interés para las personas con discapacidad.

Dicha sección ofrece una serie de recursos, tales como modelos de resoluciones judiciales en lenguaje sencillo y en lectura fácil, para lograr que la redacción judicial y la comunicación legal sean accesibles para todos, con independencia del nivel de conocimiento en este ámbito o las capacidades cognitivas.

Una web de libros electrónicos accesibles

Benetech Accessible eBookstore es una empresa que ofrece libros electrónicos educativos que son accesibles.

Desgraciadamente, los libros que he buscado no son muy baratos.

Aniversario de la Directiva europea sobre accesibilidad web

La Directiva europea 2016/2102, también conocida como Web Accessibility Directive (WAD), entró en vigor el 22 de diciembre de 2016. En Web Accessibility Directive — Standards and harmonisation está disponible un resumen de esta directiva.

El 23 de septiembre es una fecha importante para esta directiva porque:

• 23 de septiembre de 2018: entra en vigor la Directiva.
• 23 de septiembre de 2019: fecha límite para que los nuevos sitios web sean accesibles.
• 23 de septiembre de 2020: fecha límite para que los sitios web existentes sean accesibles.

WCAG 2.1 ha sido actualizado

Ayer, 21 de septiembre de 2023, se actualizó WCAG 2.1. 

Mientras tanto, WCAG 2.2 sigue como "Proposed Recommendation".

Publicado el 2023 Digital Accessibility Index

Se acaba de publicar el 2023 Digital Accessibility Index:

We scanned almost 40,000 enterprise websites to measure the accessibility of the world’s largest brands. Then we worked with members of the disability community to test key pages on the top sites in industries like retail, finance, and travel.

Y los principales resultados:

56% of images are not accessible to people with visual impairments, which can prevent them from being able to understand or benefit from any information conveyed by the image.

64% of pages have links that are not clear to people with some visual and cognitive impairments, which can make it difficult for them to navigate between pages or find the information they need.

25% of forms are missing clear labels, which can make it difficult for people with disabilities to know what to enter into each field — impacting key tasks like checkout or account creation.

Historia de la accesibilidad web

En el vídeo Getting started – Understanding the history of web accessibility se resume la historia de la accesibilidad web:

El funcionamiento de las API de accesibilidad muy bien explicado

En los siguientes artículos, se explica muy bien el funcionamiento de las API de accesibilidad que emplean los productos de apoyo (por ejemplo, los lectores de pantalla) para acceder al contenido que muestra el ordenador y transmitirlo al usuario final:

1. Swinging Through the Accessibility Tree Like a Ring-Tailed Lemur
2. The Road to Good Intentions Is Paved with Hell
3. Your Browser May Be Having a Secret Relationship with a Screen Reader

ARIA puede ayudar a la accesibilidad web, pero también la puede dañar

En ARIA can hurt or help web accessibility: How to review your website’s ARIA se advierte de los peligros que tiene el mal uso de ARIA:

Not all HTML elements have accessibility built into them. So, we use ARIA to add accessibility when a native HTML element cannot do the job.

When used correctly, ARIA can help people with disabilities access and use your website – when used correctly. Unfortunately, it’s misused all over the web.

Using ARIA incorrectly can actually make your website more inaccessible. It can unintentionally hide content from assistive technology, announce the wrong label, and cause functionality confusion for assistive tech users.

To actually make a more accessible web experience for all users, ARIA needs to be used correctly. A great place to start is looking at the ARIA your own website already uses.

Going through your own website’s ARIA can make it more accessible while also giving you a chance to learn more about ARIA (nothing like a hands-on learning experience).

La accesibilidad de los números

En Making Numbers in Web Content Accessible se explican los problemas que los números presentan para la accesibilidad del contenido web:

Numbers are a key part of how we express ourselves and communicate with each other. They are often used to express concepts that are critical to our way of life: cultural, financial, medical, legal … numbers play an enormously important role in our lives.

It makes sense, then, that when we use numbers in web content, they must be made accessible to all people. In this article, we’re going to explore what the major issues are for number accessibility in web content, who it affects and how, and what web creators can do about it.

Actualización de WCAG 3

Ayer (24/07/2023) se publicó una actualización de W3C Accessibility Guidelines (WCAG) 3.0. 

En WCAG 3 Introduction se proporciona una introducción de WCAG 3.

Reglamento de las condiciones de utilización de la lengua de signos española y de los medios de apoyo a la comunicación oral para las personas sordas, con discapacidad auditiva y sordociegas

El 19/07/2023 se publicó en el BOE el Real Decreto 674/2023, de 18 de julio, por el que se aprueba el Reglamento de las condiciones de utilización de la lengua de signos española y de los medios de apoyo a la comunicación oral para las personas sordas, con discapacidad auditiva y sordociegas.

En el Artículo 4. Definiciones se define la sordoceguera de la siguiente forma:

m) Sordoceguera: discapacidad única con entidad propia que resulta de la combinación de dos deficiencias sensoriales, la auditiva y la visual, que genera barreras de comunicación únicos y necesidades específicas y heterogéneas en las personas sordociegas, que hacen que puedan ser usuarias, alternativa o simultáneamente, de la lengua de signos española, del braille y de los diversos medios de apoyo a la comunicación oral, aumentativos y alternativos, con servicios especializados de comunicación y acompañamiento prestados por personal específicamente formado para su atención para hacer frente a las actividades de la vida diaria.

En el Artículo 4. Definiciones aparecen algunas definiciones interesantes sobre la comunicación de las personas sordociegas:

d) Lengua de signos táctil o apoyada: adaptación al tacto de la lengua de signos española que hacen las personas sordociegas que utilizan esta lengua para comunicarse cuando su visión ya no les permite seguir el movimiento de las manos de quien se comunica con ellos en esta lengua. Las personas sordociegas colocan sus manos sobre las de la persona interlocutora signante para percibir a través del tacto y la propiocepción las distintas configuraciones de las manos y los movimientos de estas y así seguir lo que le dice y comprender el mensaje.

4.º Sistemas alfabéticos: sistemas que se apoyan en el deletreo del mensaje como el sistema dactilológico o alfabeto manual, el dactilológico en palma, el uso de tablilla de comunicación y el uso de mayúsculas sobre la palma. El sistema dactilológico o alfabeto manual es aquel donde cada letra se corresponde con una configuración de la mano y dedos del interlocutor, que se puede realizar en el aire y que se capta de forma visual; el dactilológico en palma, en el que cada letra es representada sobre la palma de la mano de la persona sordociega, para que pueda captarlas táctilmente; el uso de una tablilla de comunicación, donde el interlocutor señala junto con la persona sordociega las letras en relieve para formar una palabra, o las mayúsculas sobre la palma, donde el interlocutor escribe con su dedo índice las letras en mayúsculas que componen las palabras una sobre otra, en el centro de la palma de la mano de la persona sordociega.

5.º Sistema Dactyls: sistema alternativo de comunicación táctil de carácter mixto. Consiste en transmitir el mensaje, combinando el uso del alfabeto dactilológico táctil con la incorporación de signos táctiles y otros recursos propios del sistema, sobre la base de unas reglas gramaticales que regulan su funcionamiento

6.º Sistema de signos Haptic: es un método de comunicación complementario que sirve para conocer toda la información del contexto que se suele proporcionar en la espalda, o en el brazo. De este modo, la persona sordociega recibe una información completa que le proporciona más independencia y, además, puede tomar decisiones de forma autónoma, conociendo todo lo que ocurre a su alrededor.

WCAG 2.2 posiblemente será una recomendación en agosto 2023

Según la nota WCAG 2.2 final web standard expected in August 2023, es posible que WCAG 2.2 se publique como recomendación, es decir, la versión final, en agosto 2023.

A la espera de WCAG 2.2

Mientras seguimos a la espera de la publicación definitiva de Web Content Accessibility Guidelines (WCAG) 2.2, podemos leer algunos de los artículos que resumen las novedades de WCAG 2.2 como, por ejemplo, WCAG 2.2, quick and simplified, que se lee en 2 minutos.

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.