WCAG 2.0 - Perceivable

CSS Speech

Interesante el artículo Let’s Talk About Speech CSS:

The CSS 3 Speech Module, the evolved version of the aural Media Type, looks the most promising. Like display: none;, it is part of the small subset of CSS that has an impact on screen reader behavior. It uses traditional CSS property/value pairings alongside existing declarations to create an audio experience that has parity with the visual box model.

La realidad actual es que el soporte por parte de los productos de apoyo es muy reducido.

Uso de un magnificador de pantalla (2)

Uso de un magnificador de pantalla (1)

Generador de paletas de colores accesibles

A11y Color Palette es un generador de paletas de colores accesibles. Lo que hace es comprobar que el color del texto y el color del fondo cumplen los umbrales fijados en WCAG 2.0:

AA texto normal / grande: 4.5:1 / 3:1
AAA texto normal / grande: 7:1 / 4.5:1

Manejar el ordenador con la mirada

En el artículo Tecnología para manejar el ordenador con precisión con la mirada se presenta el sistema Irisbond:

La tecnología que permite interactuar con dispositivos digitales a través de la mirada no es nueva. En 2005 la empresa sueca Tobii, una de las más importantes del mundo en este terreno, lanzó el primer ordenador que incorporaba el seguimiento ocular y desde entonces distintos científicos, universidades y compañías de todo el mundo no han dejado de innovar. En este escenario, altamente competitivo y en constante evolución, Irisbond se ha posicionado como una de las iniciativas con mejores perspectivas de futuro. Así lo reconoció la revista Forbes, que en el Mobile World Congress del pasado año, les dedicó un artículo titulado “Esta compañía quiere cambiar la forma en que utilizamos la tecnología del eye-tracking”. Y es que aunque Irisbond está centrada en la tecnología asistencial, no es este el único campo en el que sus soluciones pueden ser aplicadas, ya que el eye-tracking tiene grandes posibilidades de desarrollo en la medicina, la industria o la automoción.

Ejemplo de uso de una línea braille

Corto e interesante el siguiente vídeo, La línea Braille explicada por Luis Palomares (Analista I+D CIDTA, ONCE):

 

Sistema para que los sordociegos puedan leer los subtítulos

En Un sistema para que los sordociegos puedan ‘ver’ la televisión se explica:

En España hay alrededor de 20.000 personas sordociegas que a las dificultades diarias de no poder ver y oír tienen que sumar otra barrera: la del acceso a la información. Gracias a la tecnología presentada hoy por el equipo del profesor Ángel Crespo, de la Universidad Carlos III, los sordociegos podrían acceder a los contenidos de televisión mediante una sencilla aplicación que les traduce los contenidos al lenguaje Braille de forma simultánea y sea cual sea la cadena que quieran sintonizar.

Cómo las tendencias actuales de diseño afectan a la accesibilidad web

Muy bueno el artículo How Current Design Trends Affect Web Accessibility:

In this post, we'll explore some of the design trends we increasingly run into on the Web today, and how decisions made during the design phases can have a hugely detrimental effect on anyone who uses the web in a slightly differently way.

Las tres tendencias que se analizan son:

Three such examples of current design trends that have a tremendously negative impact on people with disabilities are: placeholder text labels, parallax scrolling and conversational interfaces (chatbots). As we'll see in the next few paragraphs, each of these trends are likely to create significant barriers for some of us, if basic accessibility concepts are not taken into consideration.

Listas desplegables personalizadas y accesibles

El artículo Accessible Custom Select Dropdowns proporciona algunos enlaces a ejemplos de listas desplegables personalizadas que son accesibles.

IBM Dynamic Assessment Plugin

IBM Dynamic Assessment Plugin es un plugin para las herramientas de desarrollador de Google Chrome que permite automatizar el proceso de evaluación de la accesibilidad web.

Criterios de conformidad de WCAG 2.0

Los Criterios de conformidad de WCAG 2.0 organizados por los tres niveles A (25 criterios), AA (13 criterios) y AAA (23 criterios).

Revés para la accesibilidad web en Estados Unidos

En The ADA, Websites and the Decision in Robles v. Dominos Pizza LLC nos cuentan el resultado de una denuncia contra Dominos por falta de accesibilidad web.

Básicamente, la sentencia dice que sí que se puede aplicar ADA para la accesibilidad de un sitio web, pero como no existen unas pautas aprobadas por el Department of Justice (DOJ) que indiquen los requisitos técnicos para que un sitio web sea accesible, no se puede obligar a alguien a hacer algo accesible si no sabe cómo hacerlo accesible:

The court framed the key question as "whether and to what extent the ADA, a statute enacted before the widespread adoption of the Internet, regulates the manner in which companies can permissibly engage in e-commerce." For purposes of the analysis, the court assumed the applicability of Title III of the ADA and rejected Domino's argument that the suit should be dismissed because the ADA was not drafted with the specific regulation of virtual spaces in mind. 

[...] 

However, the court sided with Domino's on its due process challenge. Domino's had argued that "the DOJ has not promulgated concrete guidance regarding the accessibility standards an e-commerce webpage must meet, much less required that companies operating such webpages comply with the specific standards Plaintiff references in his Complaint." The court found merit in this challenge and rejected the plaintiff's attempt to impose specific technical requirements on all regulated entities without specifying a particular level of technical compliance and without the DOJ offering meaningful guidance on the topic.

Accesibilidad web (conferencia completa)

V Conferencia Internacional sobre Aplicación de Tecnologías de la Información y Comunicaciones para mejorar la Accesibilidad

La V Conferencia Internacional sobre Aplicación de Tecnologías de la Información y Comunicaciones para mejorar la Accesibilidad se celebrará del 25 al 27 de octubre de 2017 en Medellín (Colombia).

La fecha límite de envío de artículos es el 17 de septiembre de 2017.

Las áreas de interés son:

• Accesibilidad del Software
• Accesibilidad Web
• Accesibilidad del Hardware
• Ingeniería del software accesible
• Herramientas de evaluación de la accesibilidad
• Estándares de accesibilidad y TIC
• Legislación sobre accesibilidad y TIC
• Recursos digitales accesibles
• Accesibilidad de la educación virtual
• Accesibilidad de dispositivos móviles
• Accesibilidad de medios audiovisuales
• Accesibilidad de la Administración electrónica
• Accesibilidad de las Redes Sociales
• Sistemas adapatativos
• Experiencias/Estudio de casos
• Modelado de usuario
• Plataformas de aprendizaje accesibles (LMS, LCMS, MOOC)

Máster en Gestión del Diseño para Todos

La Universitat Central de Catalunya organiza el Máster en Gestión del Diseño para Todos. Los datos básicos son:

Modalidad: Presencial
Lugar: Barcelona
Inicio: 02-10-2017
Fin: 15-06-2018
septiembre 2018 (TFM)
Edición: 1ª
Créditos: 60
Precio: 4 950€
Idioma: inglés

Curiosamente, si se quiere realizar una consulta se debe emplear un formulario con un CAPTCHA visual, lo cual no es muy "diseño para todos":

Los cambios que presenta WCAG 2.1

Recomiendo la lectura de WCAG 2.1, medida provisional hasta las WCAG 3.0, que explica con mucho detalle las novedades que incorpora el último borrador de WCAG 2.1:

• 1.4.10 Zoom content (AA)
• 1.4.11 Graphics Contrast (AA)
• 1.4.12 User Interface Component Contrast (Minimum) (AA)
• 1.4.13 Adapting Text (AA)
• 2.2.6 Interruptions (minimum) (AA)
• 2.2.7 Accessible Authentication (A)
• 2.4.11 Character Key Shortcuts (A)
• Guideline 2.5 Pointer Accessible
• Guideline 2.6 Additional sensor inputs
• 2.6.1 Orientation (AA)
• Guideline 2.7 Speech
• 2.7.1 Accessible Name (A)
• 3.2.6 Accidental Activation (A)
• 3.2.7 Change of Content (AA)
• Requisito 5.1.2 Full Pages, nota adicional
• Nuevos términos en el glosario
• Corrección de errata en los criterios actuales 1.3.3 y 1.4.1

Siete cosas que todo diseñador debe saber sobre accesibilidad

En 7 Things Every Designer Needs to Know about Accessibility es un fantástico artículo en el que se comentan las siguientes siete cosas:

1. Accessibility is not a barrier to innovation.
2. Don’t use color as the only visual means of conveying information.
3. Ensure sufficient contrast between text and its background.
4. Provide visual focus indication for keyboard focus.
5. Be careful with forms.
6. Avoid component identity crises.
7. Don’t make people hover to find things.

Tremendo error en el periódico El País

En las galerías del periódico El País, el texto que acompaña una imagen se repite en la imagen como texto alternativo. Por tanto, un lector de pantallas lee lo mismo dos veces.

Por ejemplo, MEMENTO’, ‘BATMAN’, ‘DUNKERQUE’...: LAS PELÍCULAS DE CHRISTOPHER NOLAN, DE LA PEOR A LA MEJOR:

Al desactivar las imágenes aparece el texto alternativo.

Efectivamente, el texto alternativo es la repetición del texto que acompaña a la imagen.

Los botones deshabilitados apestan

Hace unas semanas escribí la entrada ¿Los botones deshabilitados? en la que hablaba del contraste de los botones deshabilitados. Mi consejo final fue:

Por tanto, yo creo que aquí la recomendación de WCAG 2.0 es discutible y sí que se  debería cumplir el requisito mínimo de contraste en los elementos deshabilitados.

Ahora he encontrado el artículo Disabled buttons suck:

Showing buttons as disabled until a form is complete might seem like a good idea. It is not. They usually create a lousy user experience and exclude many people with disabilities. Here’s why disabled buttons suck and what to do instead.

El artículo comenta varios de los problemas que suelen ocasionar:

• They fool users into clicking.
• They are hard to see.
• They don’t give any feedback.
• They give design teams a reason to rush through error handling.
• They make users think.
• Disabled buttons disable disabled users.

[Actualización 1/8/2017]

Un comentario adicional en Disabled buttons don’t have to suck!:

Didn’t read the article? Well, this sums it up:

Disabled buttons often suck because,

• often you can’t really tell if they are disabled, or you won’t be able to read / see the button due to lack of contrast;
• when you (accidentally) click them, you don’t get any feedback, leaving you in the dark;
• assistive technologies like screen readers often won’t be able to navigate to disabled buttons, so they won’t get any feedback on why they can’t find the submit button when they think they are done;

Disabled buttons are useful

What happens when you accidentally press Enter while in a form, if the submit-button is not disabled? Right, it will submit with all kinds of unnecessary errors and messages thrown at the user. Leaving them in confusion and anger. It’s in our muscle memory to press buttons we shouldn’t press.

They also convey useful visual information to (at least some) users that the form is not yet completed or the option is not yet available.

Just make disabled buttons better already

There is no technical boundary for us to improve disabled buttons in order to convey meaning to all (inclusive design). So,

get better contrast by using bigger font and/or darker colors;

Give assistive technologies, like screen readers, some information at the end of the form (visually hidden), since they won’t read information inside the button-tag (it’s often skipped).

give users information when they tap, hover or click the disabled button. Preferably give them directions to the first field that needs input or correction;

Remove the “disabled-attribute” from the button as soon as the last field has