miércoles, 16 de agosto de 2017

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.

lunes, 14 de agosto de 2017

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).

viernes, 11 de agosto de 2017

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.

miércoles, 9 de agosto de 2017

Accesibilidad web (conferencia completa)

lunes, 7 de agosto de 2017

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)

viernes, 4 de agosto de 2017

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":


miércoles, 2 de agosto de 2017

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

lunes, 31 de julio de 2017

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.

viernes, 28 de julio de 2017

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.




miércoles, 26 de julio de 2017

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