Si los componentes de Polymer son accesibles, ¿lo será mi aplicación?


El sábado 22 de Octubre se celebró PolymerDay en Madrid. Se trató de una jornada dedicada exclusivamente a Polymer, la librería innovadora que permite crear y utilizar componentes web customizados de forma fácil y rápida, así como integrarlos en el diseño de aplicaciones para mejorar la experiencia de usuario, maximizando el potencial de las plataformas web.

Participé en esta jornada impartiendo la charla “¿Es mi aplicación accesible?”. Mi ponencia formaba parte de una agenda que incluía temas muy variados relativos a Polymer: performance, casos prácticos, hojas de estilos, buenas prácticas, políticas de offline, etc.

Cuando me ofrecieron la oportunidad de participar en este evento como ponente, me acordé de inmediato del Polymer Summit que hubo el año pasado en Ámsterdam, en especial de la charla que se impartió sobre accesibilidad, y pensé en hablar sobre ello porque, por algún motivo, en el programa de Polymer Summit de Londres de este año no se había incluido ninguna conferencia sobre este tema.

 

cvw2o-rweaa1_rr-jpg-large

 

No obstante, hay que decir que el equipo de Polymer de Google ha hecho y sigue haciendo un gran esfuerzo a la hora de tratar de concienciar sobre la accesibilidad, ya sea a través de sus charlas en Google IO o mediante pequeños videos.

Por qué hay que tener en cuenta la accesibilidad

La respuesta es muy sencilla: porque es un derecho de las personas. En ocasiones, la falta de accesibilidad se justifica por temas de “target objetivo de usuarios” o incluso porque la accesibilidad se considera un privilegio. Pero, al final, no deja de ser un tipo de discriminación.

En España, la legislación dice:

Estas leyes fijan por fin el nivel de adecuación obligatorio de los portales de Internet, no ya sólo de la Administración Pública sino de las empresas que reciben financiación pública y de las empresas privadas con más de 100 trabajadores o que facturen más de 6 millones de euros (especialmente entidades bancarias, agencias de viaje, aseguradoras, empresas de transporte, suministradoras de electricidad, gas y agua, etc.) en el nivel de conformidad AA de la Norma UNE 139803, a partir del 31 de diciembre de 2008. La Norma fue actualizada en 2012 y actualmente es equivalente a las WCAG 2.0.

¿Puede tener un proyecto en Polymer fallos de accesibilidad?

Durante la charla descubrimos cómo un proyecto implementado con Polymer puede tener fallos automáticos de accesibilidad, ya sea por falta de conocimiento o simplemente por descuido. Hay que tener en cuenta siempre que la revisión de accesibilidad no sólo debe ser automática sino también manual. Nunca debemos dar por hecho que una herramienta automática es infalible: aunque nos indique que no hay fallos, esto no significa que nuestra página carece de ellos. Por ejemplo, cualquier herramienta automática puede detectar si existe o no un atributo alt pero no podrá comprobar si el texto introducido es el adecuado.

Estos fallos, al igual que puede ocurrir con AngularJs o con React, no pueden atribuirse a la librería o framework de turno, sino a cómo se ha abordado su desarrollo. Por desgracia, de un tiempo a esta parte se están dejando de lado algunas técnicas fundamentales a la hora de utilizar HTML; técnicas que podrían considerarse de primero de clase de HTML. El hecho de no conocerlas puede ocasionar más de un error en nuestro código siempre.

captura-de-pantalla-2016-10-27-a-las-10-24-11

En el repositorio de Github del proyecto Polymer analizado, se encuentran las pull requests realizadas para tratar de subsanar los fallos que se detectaron. Estos cambios se agrupan principalmente en:

  • resolución de los atributos alt de las páginas. No existía ninguno de ellos.
  • modificación del contraste de color utilizado en la página.
  • reemplazo de la imagen utilizada de fondo como logo para usarla como imagen de HTML.
  • inclusión de descripciones y textos para botones y enlaces.

Existen también otras pull requests relacionadas con la accesibilidad, que se efectuaron gracias a la revisión manual:

  • revisión de los encabezados de página utilizados.
  • incorporación del elemento label que faltaba.

A la hora de hablar de componentes web y accesibilidad, y dadas las nuevas especificaciones, tendremos que realizar siempre una revisión cuidadosa con las herramientas a nuestra disposición para evitar pasar por alto ciertos fallos.

Tras la charla surgieron algunas preguntas sobre las maneras de hacer o implementar estas revisiones. La herramienta de test de Polymer web component tester incluye una suite relacionada con la accesibilidad que nos permitirá realizar una batería de pruebas automáticas sobre nuestro componente.

Otra cuestión que se trató fue cómo podemos abordar la accesibilidad en un equipo de desarrollo. En este sentido, siempre será recomendable la formación e involucración de todo el equipo de desarrollo en lugar de esperar hasta el último momento y solicitar una revisión posterior a un consultor.