Informes de la Oficina de Atención a la Discapacidad

En Informes de la OADIS están disponibles los informes emitidos por la Oficina de Atención a la Discapacidad desde el año 2005 hasta la actualidad.

En el informe anual del año 2017, entre alguno de los expedientes podemos encontrar:

• Ausencia de accesibilidad a la pagina. web de la Asamblea de Madrid
• Ausencia de accesibilidad a la página web del Ayuntamiento de Madrid
• Ausencia de subtitulación en página web de la Guardia Civil
• Ausencia de subtitulación en canal YouTube y vídeos de la Policía Naciona
• Barreras identificadas en páginas web de organismos públicos-Ayuntamiento Burgos
• Barreras identificadas en páginas web de organismos públicos- Defensor del Pueblo Navarra

Y muchos otros.

Características de accesibilidad de los navegadores web

Las características que ofrecen los navegadores web para mejorar la experiencia de usuario relacionada con la accesibilidad:

• Internet Explorer
• Edge
• Chrome
• Firefox

Cómo navega una persona con un lector de pantalla

Muy interesante lo que se explica en How A Screen Reader User Accesses The Web: A Smashing Video. Incluye un vídeo con una sesión de navegación de una persona ciega con un lector de pantalla.

Conocer a las personas con discapacidad

Eso no se pregunta es un programa de Telemadrid que tiene como objetivo combatir los prejuicios y la discriminación de ciertos colectivos:

Ciegos, gitanos, musulmanes, negros, obesos, religiosos, transexuales, parados de larga duración, personas con Asperger, de baja estatura, síndrome de Down, en silla de ruedas... Doce colectivos marginados responden a preguntas anónimas ante la cámara en un tono desenfadado, sin dramatismo y con humor, para combatir los prejuicios y la discriminación.

Hay un vídeo sobre las personas ciegas:


Y otro sobre las personas en silla de ruedas:

Errores de accesibilidad en el sitio web de Apple

En How to learn from Apple's mistakes on website accessibility se explican algunos errores de accesibilidad del sitio web de Apple:

There were multiple difficulties noted. The key issues were:

• Insufficiently labelled input fields (meaning screenreaders are left unsure of what information is needed in the boxes they're asked to enter information into)

• Links with identical text, that lead to different locations. While this is not a failure of WCAG (Web Content Accessibility Guidelines), it is not good practise.

• Dynamic content not made accessible to screenreader users, e.g. auto-suggest search results

Further difficulties noted in the complaint were:

• Unable to browse and purchase electronics such as the iPhone, iPad, and MacBook Pro laptop

• Inability to make service appointments online

• Trouble finding a store

Curso gratuito "Discapacidad y envejecimiento activo. Soportes tecnológicos" segunda edición

Ya está abierta la inscripción a la segunda edición del curso Discapacidad y envejecimiento activo. Soportes tecnológicos. en el que participó con el módulo sobre accesibilidad web. El curso comienza el 18 de marzo de 2019 y tiene una duración estimada de 8 semanas.

El contenido del curso es:

1. Módulo 1. Accesibilidad e inclusión social
2. Módulo 2. Accesibilidad en la Web y Participación social
3. Módulo 3. Educación para la salud, intervención social y TIC
4. Módulo 4. TIC y vida independiente
5. Módulo 5. TIC y tratamiento de la memoria
6. Módulo 6. Las TIC en los Recursos Sociales
7. Módulo 7. Aplicaciones de la Telemedicina
8. Módulo 8. Experiencias internacionales y TIC

En España se tiene que aplicar WCAG 2.1

En Las guías del Observatorio de Accesibilidad Web se actualizan a WCAG 2.1, del Portal Administración Electrónica del Gobierno de España, se confirma que en España se debe aplicar WCAG 2.1:

El 20 de septiembre de 2018 entró en vigor el Real Decreto 1112/2018, de 7 de septiembre, sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público(Abre en nueva ventana) , que traspone al ordenamiento jurídico español la Directiva (UE) 2016/21022(Abre en nueva ventana) .

En el Real Decreto se establecen como requisitos de accesibilidad a cumplir los indicados en la norma armonizada que la Comisión Europea ha publicado el 21 de diciembre de 2018 mediante la Decisión de Ejecución (UE) 2018/2048. Este estándar armonizado está basado en la última versión de la norma EN 301 549 V2.1.2 (2018-08)(Abre en nueva ventana) “Requisitos de accesibilidad de productos y servicios TIC” que a su vez, a un nivel técnico, converge en última instancia con las nuevas WCAG 2.1(Abre en nueva ventana) del W3C (Pautas de Accesibilidad para el Contenido Web).

Bajo este nuevo marco, el Ministerio de Política Territorial y Función Pública, a través del Observatorio de Accesibilidad Web, ha adaptado las guías previamente existentes que se ven afectadas por los nuevos requisitos del estándar armonizado y, por consiguiente, por las WCAG 2.1.

Inclusive Components

El sitio web Inclusive Components es un blog con patrones de diseño accesibles. Se define como:

A blog trying to be a pattern library. All about designing inclusive web interfaces, piece by piece.

Los problemas de las personas sordas y algunos consejos

Muy interesante el artículo Inclusive Design and Deafness que proporciona los siguientes consejos:

• Caption for video and spoken sounds and/or provide transcripts for podcasts.
• Provide (colored) light when using sound to give an alert or action. (E.g. public transport check- in and -out terminals.)
• Make screens readable with good use of colors, e.g, red for warning, yellow for notice, green for good, etc. (E.g. public transport check- in and -out terminals.)
• Don’t require a phone number unless you provide text and/or WhatsApp service.
• Don’t be available only by phone, provide email, WhatsApp and/or live chat.
• Provide a ‘Comments’ text field so people can indicate for example if they are deaf and prefer to not communicate by phone.
• Avoid the use of a donotreply@yourdomain.com email. Especially with important emails.
• Make sure your digital form/database takes into account if a client is deaf, blind, uses a wheelchair, etc. This way people can keep track and not make mistakes with their clients. E.g. a doctor office or hospital must be able to register such things with general patient information. (I know for a fact those systems don’t make that possible.)
• I’ve been informed that the new privacy laws make this difficult. As long as this is an optional field filled in per request of the client it should not be a problem. I rather have they register I’m deaf than get phone calls I can’t do anything with. We shouldn’t use GDPR laws as an easy way out of being inclusive.
• When organizing a congress, provide live captions. They are not only useful for deaf and HoH people. But also for hearing people who might have missed something or are not fluid at the language being spoken. Reading it at their pace helps.
• In the Netherlands, there is only a handful of text transcribers that can transcribe in English for me. It has happened that I had to miss a congress last minute because the transcriber was sick. Also going to congresses abroad is not really viable for me. I would have to pay myself for the plane ticket, hotel, etc. for the transcriber. Imagine if all congresses had live transcription as a standard. I would be able just like everybody else, to decide last minute if I want to attend, what I want to attend and where I want to go to attend. That is being deaf inclusive.

Relación entre accesibilidad y usabilidad

En el siguiente vídeo se explica la relación que existe entre estas dos dimensiones que son factores esenciales para la calidad de un sitio web:

Los captchas apestan

Los captchas son una gran barrera de accesibilidad. Incluso los captchas que se anuncian como accesibles suelen ser no accesibles.

En Catpchas Suck se muestran algunos ejemplos reales de lo terribles que pueden llegar a ser los captchas, tanto desde el punto de vista de la usabilidad como de la accesibilidad.

Además, se ofrecen algunas alternativas:

Check out these articles on Captcha alternatives:

9 Captcha Alternatives That Won’t Wreck Your UX (dtelepathy.com)
Not all of the 9 methods are accessible, so focus your attention on number 3 – “Biometric security”, number 4 – “Text message verification” and number 6 – “The honeypot method”.

Think Your Site Needs A CAPTCHA? (usertesting.com)
Same as with the previous article: not all alternatives they suggest are accessible. Focus your attention on “Honeypots”, “Timestamps” and “Verified sign in”.

Análisis de la accesibilidad de los sitios web de los colegios en Estados Unidos

En Accessibility in mind? A nationwide study of K-12 Web sites in the United States se ha publicado un estudio de la accesibilidad de los sitios web de los colegios en Estados Unidos.

El resumen del artículo dice:

Web site accessibility is a serious civil rights concern that has historically been difficult to measure and to establish success criteria for. By conducting automated accessibility analyses via the WAVE tool, we calculated accessibility norms of a statistically appropriate, random sample of K–12 school Web sites across the U.S. (n = 6,226) and merged results with national datasets to determine how school demographics influence accessibility. Results indicated that schools across all demographic groups generally struggle to make their Web sites fully accessible to their universe of diverse users and revealed that the concrete, highest-impact steps that schools nationwide need to take to improve accessibility include improving poor contrast between text and backgrounds, providing alternative text to images and other visual elements, and labeling form controls.

La importancia de usar etiquetas (labels) en los formularios

El artículo Labels Required explica por qué es importante identificar los controles de los formularios:

Using the label element checks all of the boxes for inclusivity when properly formatted: it's directly associated with a form element (either with the for attribute or by nesting the element inside the label), displayed as text by standard browsers, and spoken by screen readers. Clicking or tapping on a label will focus the associated element (or select the checkbox or radio option), and when you focus directly on the element, screen readers will read the label. Ensuring that both visual and auditory cues are present and intelligible are critical when you consider that in WebAIM's annual screen reader study screen reader users report relying on a mix of both, with the majority using audio exclusively.

Hay otras alternativas a label, pero en este artículo se explica que no siempre funcionan:

It's possible to use markup other than label, but when you do, users may see or hear blank form elements and have no idea what to enter. 

At first glance, placeholder does a very similar job to label: it's displayed as text (within text inputs, specifically) and read aloud by screen readers. The placeholder has a purpose, though, that diverges from that of a label. It's meant to be a suggestion, formatting guideline, or hint that is ultimately replaced by user input. So while a placeholder may seem like a worthy label alternate on the first pass through a form, once a data value is entered, that label is gone. And that's just one of several reasons why placeholder is an inadequate substitute label. It's much more valuable when used as a guide. 

The aria-label attribute provides label text to screen readers for identifying interactive elements, or elements with ARIA roles, and it produces the same audio feedback as the label element. There's no reason to use both on the same form field, and we actually recommend against trying.

La conclusión es clara:

Out of the box, the label element is all we need to indentify fields in an accessible way. Used in combination with accessible hiding and other helper elements, like placeholder or icons, we can ensure that a form element's purpose is clearly communicated to all users.

Consejos para el rediseño de la web de Renfe

Renfe ha sacado a contratación el rediseño de su sitio web.

En Twitter podemos encontrar muchas sugerencias para su mejora, por ejemplo, este hilo:

La noticia de que Renfe invertirá 700.000€ en mejorar su web nos ha alegrado tanto a @marcborras y a mi que hemos decidido hacer un hilo con 17 predicciones de cosas que esta vez, ya sí que sí, seguro que van a arreglar. Empezamos 👇 pic.twitter.com/y4SR7fFSgZ

— Carlos Sánchez (@chocotuits) 3 de febrero de 2019

La web de Renfe será accesible... o quizás no

La semana pasada se publicó la noticia Renfe invertirá 700.000 euros para arreglar su web de una vez por todas:

Renfe ha pisado el acelerador nada más aprobar su plan estratégico. Si el mismo día en el que se puso en marcha la operadora anunció la licitación del primer paquete de trenes para renovar su flota, hoy es el día de su página web. La operadora ferroviaria ha licitado el contrato, valorado en 700.000 euros, para renovar su principal canal digital de contacto con sus clientes.
La mejora de la web de Renfe es una de las medidas más demandadas por sus usuarios desde hace años. Esto ha provocado que esta licitación haya sido una de las primeras en ponerse en marcha. Una decisión muy simbólica que tanto el presidente de la compañía, Isaías Táboas, como su director de estrategia, Manel Villalante, han querido priorizar para ponerla en marcha lo antes posible.
El proyecto licitado tiene por objetivo mejorar la usabilidad de la web de Renfe. Uno de los elementos más destacados en el plan estratégico de la operadora. En el caso de la web la intención es desterrar todos los actuales problemas que genera la actual y dotarla de las capacidades que permitan mejorar el rendimiento y el posicionamiento de los contenidos.
Hay que recordar que la última gran renovación del principal canal digital de Renfe se realizó hace 10 años. Un periodo en el que regularmente se han ido introduciendo mejoras pero que el tiempo ha dejado anticuado.

Y sorprendente este dato:

En concreto, entre enero y agosto el 46,8% del total de billetes se vendió a través de la web. Renfe comercializó 16,8 millones de plazas de tren a través de su portal de Internet.

Y todo ello, a pesar de los problemas de usabilidad y accesibilidad que tiene la web de Renfe.

Accesibilidad web y discapacidad cognitiva

La discapacidad cognitiva es una de las menos tratadas en la información sobre accesibilidad web. Por ejemplo, con la publicación de WCAG 2.1 se ha empezado a contemplar en WCAG, antes "se olvidaba" porque es más difícil.

El artículo Web accessibility for cognitive, learning and neurological impairment ofrece una lista de condiciones que se engloban dentro de la discapacidad cognitiva:

• ADHD (Attention Deficit Hyperactivity Disorder) — difficulty focusing (e.g., on a single task, for longer periods, easy to be distracted etc.).
• Autism — difficulty in interacting with social communication.
• Mental health disabilities (mood disorder, anxiety, schizophrenia, delirium) — people with this disabilities can be affected in their day-by-day activities by the medications’ side effects (e.g., blurred vision, memory impairments, tremors etc.).
• Memory impairments — both short and long-term memory impairment.
• Perceptual disabilities (learning disabilities) — difficulty in processing sensory information (auditory, tactile and visual information).
• Seizure disorders (migraines, epilepsy) — reaction to audio and visual stimulation.

Y ofrece unos consejos para mejorar la accesibilidad web:

1. Using headings, subheadings, and lists for structuring the information. Structuring information in this way will help people to easily scan the page, to see the essential information of that all content and, in the same time, will help the machine to skim a page with a screen reader. What does it mean to skim a page? Is to jump from heading to heading, in this way reading just the main information presented in that whole.
2. Make sure that the line length doesn’t exceed 70–80 characters. Short sentences are easy to read by any kind of users.
3. Using more white space in your Webpage. Having a spatiality in your Webpage will help users with different cognitive, learning and neurological impairment to structure the information and to understand it easier.
4. Consistency in colors, font, and locations of the elements in the Webpage. Consistency is one of the principles of user experience and it’s very important that your product has it. A lot of users are following a pattern while navigating on a Website, and changing their pattern can put them into the difficulty of using it.
5. Implementing keyboard support. For those people with impairment it easy to have implemented the keyboard navigation (through shortcuts, commands) than the mouse navigation because, in that way, they will not need to follow the cursor of the mouse on the screen, an activity that for their condition requires a lot of focus. Also, this method will help not just this category of people, but users in general because the keyboard using while navigation increased in the last couple of years.
6. Offering alternatives for multimedia content. Having a description for non-text content, it will not only help the screen-reader software to transmit de correct information to the user (to not skip an image, just because it does not have a description) but the users, too. When a Web page can’t open all the images, it’s recommended that in that place to have a short description, in this way, the user will know what that image is about. Also, this behavior needs to be implemented for video and audio elements, too.

¿Sitio web accesible para las personas ciegas?

Me he topado con el sitio web Paths to Literacy. Se supone que debe ser accesible para las personas ciegas porque pone "for students who are blind or visually impaired". Sin embargo, me encuentro esto:

Las tres imágenes debajo de "Latest Posts" son enlaces a los respectivos artículos publicados. El texto alternativo de esas imágenes es:

• Collage of book covers showing characters who are blind
• Male adult's hands reading braille
• Blurred image of cars on a street

El texto alternativo representa el contenido de la imagen, pero para nada representa la función de la imagen que en este caso es enlazar con cada uno de los artículos. Ese texto artículo es inútil.

Enseñando a programar a niños ciegos

En Microsoft's pods teach blind children how to code se comenta una experiencia de programación con niños ciegos y un sistema  llamado Code Jumper desarrollado por Microsoft.

Newsletters para estar al día sobre accesibilidad web

En Digital Accessibility Newsletters se recogen algunos de los newsletters sobre accesibilidad web que conozco. Para mí, los mejores son:

WebAIM
Accessibility Weekly
Frontend Focus

También recomiendo el siguiente, que no aparece en esa lista:

https://mediaaccess.org.au/

Cómo escribir un buen texto alternativo

En Considerations when writing alt text se dan algunos consejos para escribir un buen texto alternativo.