Saltar al contenido

Artículo

28 abril 2020

Portales webs de las principales aseguradoras españolas. 20 desafíos técnicos en la accesibilidad de contenidos

Mano señalando a una pantalla virtual con un lápiz

Como todos sabemos, la accesibilidad es la posibilidad de que un activo digital, ya sea un sitio web, App… pueda ser visitada y utilizada de forma satisfactoria por el mayor número de personas, independientemente de las limitaciones personales o físicas que tengan, o de aquellas limitaciones que vengan derivadas de su entorno.

Desde 2007 existe la ley 56/2007 que obliga, y no solo a la Administración Pública, a cumplir, en concreto, y entre otras, a gran parte de las grandes aseguradoras bajo sanción de hasta un millón de euros. En su artículo 2, la ley dice: “Obligación de disponer de un medio de interlocución telemática para la prestación de servicios al público de especial trascendencia económica.” Y cita: “Tendrán la consideración de empresas que presten servicios al público en general de especial trascendencia económica, las que agrupen a más de cien trabajadores o su volumen anual de operaciones… exceda de 6.010.121,04 euros y que, en ambos casos, operen en los siguientes sectores económicos”, y uno de estos sectores a los que se refiere es “Operaciones de seguros privados” y “Actividad de corredor de seguros”.

Como ya comentamos en un artículo anterior al pulsar el estado de las webs españolas del sector seguros en el plano de accesibilidad de contenidos, este artículo pretende ser continuación de aquel, pero con enfoque eminentemente técnico, por lo tanto, es un articulo enfocado y dirigido a los equipos de desarrollo de los departamentos IT.

Para dicho análisis se ha seguido la vigente norma WCAG 2.1, que es el estándar compartido de accesibilidad enfocada a contenido web para individuos, organizaciones y gobiernos, y que suponen tres niveles de cumplimiento A, AA y AAA. En este artículo nos hemos basado principalmente en el nivel AA que es el que exige la ley en la Unión Europea tanto a organismos públicos como privados.

Por tanto, pretendemos resaltar aquellos retos pendientes que tienen las compañías aseguradoras de España en sus canales online, para lo cual se ha realizado un análisis de experto, y donde se ha categorizado los resultados en 20 puntos.

Sin más dilación pasamos a detallar aquellos aspectos técnicos identificados en las diferentes webs analizadas.

Imagen con un ojo abierto, una pipeta, código css y una ventana con código .html

Fuente imagen aerolab.co

 

1. Contraste

​​​
Las personas con baja visión tienen dificultades para leer textos que no contrastan con su fondo, por lo que hay que proporcionar una relación de contraste de luminancia mínima entre el texto y su fondo. Lógicamente para comprobar esto debemos apoyarnos en herramientas como Contrast Checker.

2. Unidades de medida

  • No utilices medidas/unidades fijas para determinar tamaño de textos e interlineados; de esta forma conseguiremos que el usuario pueda customizar espacios y tamaños con sus propias fuentes y consumir el contenido en base a sus necesidades.
  • Asegura la legibilidad, evitando solapamientos y dificultando el consumo del contenido, aunque se modifique la presentación a un 200% de su tamaño mediante el empleo de zoom.
  • No limites el viewport.
  • Evita el scroll en 2 dimensiones si se utiliza el zoom en hasta un 200%.

​3. Saltar bloques de contenido​​​​

Crea mecanismos para saltar bloques de contenido como barras de navegación; si no lo haces, obligas a navegar a aquellos usuarios que utilizan teclado por todos los items hasta llegar a su contenido, por lo que dificultas a las personas con discapacidad alcanzar el contenido principal de la página de una manera rápida y fácil.

En este punto, plantéate también el uso de etiquetas ARIA landmarks. 

4. Encabezados

Respeta la jerarquía de encabezados (H1, H2, H3…), si no lo haces rompes la jerarquía de información e impides que los usuarios de lectores de pantalla puedan navegar al contenido específico mediante el uso de sus herramientas.

5. Propósito de los enlaces

Procura indicar el propósito de los enlaces en los anchor text de los links, y complementa la información, si es necesario, con el atributo title. Evitemos repetir textos que no aportan valor y generan incomodidad al usuario. Ojo, no es un atributo para imágenes. Evita también enlaces del tipo “+ info” o “más información.

6. Imágenes

Asegúrate de utilizar en ellas las etiquetas alt, y siempre, con una descripción adecuada de la imagen. Las imágenes son una fuente de tráfico a tu web “importante”. Forma a tus equipos de edición de contenidos acerca de esta regla básica, es una pieza básica para la accesibilidad de contenidos.

Cuando utilices imágenes svg si son decorativas utiliza el atributo aria-hidden=»true», y si son svg de fuente utiliza el atributo role=»img». 

7. Alineación de textos

No justifiques los textos, producen “ríos blancos” que dificultan la lectura; Se recomienda siempre textos alineado a la izquierda.

8. Consistencia visual

Genera homogeneidad visual en todos los elementos interactuables que utilices, enlaces, botones; por accesibilidad, pero también por usabilidad se recomienda que sean fácilmente identificables por color y forma (ej. Rojo y subrayados) para conseguir una navegación intuitiva.

9. Foco

Asegura que aquellos elementos susceptibles de recibir el foco, éste sea claramente visible (:focus). Utiliza aquellos elementos semánticos como checks, radiobuttons… capaces de recibir el foco. Evita simularlos con código html.

Consigue hacer una navegación secuencial y preserva el orden en el foco cuando se navega. Intenta no modificar el orden mediante tabindex.

Cuidado con su uso indiscriminado también de los accesskey, ya que los accesos directos de los lectores de pantalla pueden crear conflictos. Intenta evitarlos.

10. Contenidos

Utiliza un lenguaje sencillo y entendible por todos en la medida de los posible.

Evita el uso de editores de contenido tipo wysiwig, donde un editor con delirios de grandeza y dosis creativas puede introducir formatos diversos (colores, tamaños, formas… de textos) que rompan la consistencia y homogeneidad visual; además evitarás generar código hardcodeado rompiendo la premisa básica de accesibilidad de separar contenido y presentación.

11. Control al usuario​​​​​​

Da control al usuario sobre la interfaz. Si hay aperturas de páginas en ventanas nuevas indícalo, deja que decida si quiere movimiento o no, cuando realizar las acciones… No se las impongas.

12. Idioma

Identifica el idioma de la página en el html, ya que si no se especifica puede no presentarse el contenido de forma correcta. Asimismo, permites a los lectores de pantalla interpretar el contenido adecuadamente facilitando la traducción automática de los textos.

13. Uso de estándares y semántica

​​Sigue las pautas a nivel de estándares y semántica de la W3C. Prueba a validar con https://validator.w3.org/ y https://jigsaw.w3.org/css-validator/, si no, te arriesgas a una mala interpretación a través de las diversas ayudas técnicas.

14. Carruseles

Sin entrar en el debate de si es correcto su uso, (Aquí puedes leer más información sobre usabilidad en carruseles) conviene saber que los carruseles deben tener un mecanismo de control (pausa, play, adelante y atrás), así como un indicador del los ítems que lo componen, indicando el actual, y permitiendo la navegabilidad. Así mismo, asegúrate que el contenido es textual, y si no, implementa su equivalente a través de la etiqueta alt.

15. Tablas

Utiliza las tablas para datos tabulados/estructurados que ayudan a comprender relaciones entre diferentes tipos de información; indica los encabezados (th), y dependiendo de su complejidad, considerar el uso de scope=”col” y scope =”row”. También es necesario añadir títulos de tabla (caption) con el objetivo de describir la información y complementar con el summary (permite definir una descripción larga de la tabla que complementa al título).

Un error frecuente, sobre todo en webs no actualizadas desde hace años, es el uso de tablas para mostrar una estructura de maquetación.

16. Cambios de contexto

Evítalo. Sucede en muchos procesos, como simuladores, compra, en la cumplimentación de formularios, apertura de ventanas nuevas… se produce generalmente sin control por parte del usuario y sin previo aviso.

En los formularios sucede que hay saltos entre campos cuando se van cumplimentando, y además sin control por parte del usuario, o que se pasa a pantallas nuevas.  También sucede en los procesos de compra, donde se aísla al usuario para conseguir la conversión, y donde se le quitan mecanismos de huida como el menú de navegación, enlaces en el pie… y por tanto, se cambia el contexto sin haber sido provocado por el usuario. Cuando la estructura de un sitio cambia desorienta al usuario, debiéndose informar correctamente. 

17. Formularios

Deben construirse de manera adecuada y semántica. Utiliza etiquetas semánticas para los mismos como legend, fieldset, labels…

  • Un error de lo más común es la falta de información y relaciones; generalmente en los controles/campos; no se asocian estos con la etiqueta label (mediante id y for); si una etiqueta está asociada incorrectamente, no proporciona funcionalidad o información sobre el campo al usuario.
  • También se suele mostrar Información de ayuda a modo de placeholders en los propios controles y campos, sin embargo, muchos lectores de pantalla no los identifican, y, además, al pulsar sobre el campo, el placeholder desaparece perjudicando el recuerdo.
  • Tampoco se identifican campos opcionales respecto a los obligatorios, ni tampoco se indican los formatos a introducir en los controles para anticiparse a los errores.
  • Errores. Al validar los formularios, los errores sólo son interpretados, en parte, mediante lector de pantalla, y en muchos casos se validan de uno en uno, lo que unido a la no anticipación de errores hace que el proceso pueda resultar tedioso. En raras ocasiones se muestran los errores en la parte superior ni se identifica claramente el error en el campo. Cuando se indican en ocasiones es sólo a través del color, dando lugar a situaciones problemáticas en las personas con baja visión, las cuales no son capaces de identificarlas, por lo que se hace necesario redundarlo mediante forma, añadiendo por ejemplo un icono.
  • Se recomienda también favorecer el autocompletado de los datos.

18. WAI Aria​​​

Aunque no obligatorias, aportan información complementaria; se recomienda el uso de los atributos y etiquetas WAI Aria para completar y complementar la accesibilidad. Algunos de los componentes identificados que necesitarían atributos WAI-ARIA son los cuadros modales, carruseles, áreas interacticas en las que se recarga el contenido dinámicamente, menús desplegables, etc. 

19. Contenidos multimedia

​​No se tiene todavía interiorizado del todo. Por tanto:
  • Evita la reproducción automática de vídeos y audios. (son molestos y pueden producir trastornos convulsivos).
  • Da control al usuario para que decida. Ofrece mecanismos de pausa y reproducción que sean operables independientemente del dispositivo (teclado, ratón…).
  • Subtitula tu material multimedia, generalmente no se hace, y cuando se tira de Youtube para ello, los subitítulos automáticos no suelen ser de los más acertados.
  • Evita las animaciones, o en su defecto, establece un mecanismo de pausado (las animaciones con más de tres parpadeos por segundo pueden ser posibles causantes de ataques epilépticos).

20. Por último, las versiones responsive
  • Presenta el contenido sin pérdida de información o funcionalidad, y sin requerir desplazamiento en dos dimensiones; se hace necesario apoyar a las personas con baja visión que necesitan ampliar el texto y leerlo en una sola columna sin desbordamiento, sin superposición de elementos y sin tener que desplazarse en más de una dirección.
  • Asegura un suficiente espacio entre los elementos en los que se puede hacer tap, así como favorecer la legibilidad en interlineados, interletrados…
Este artículo ha pretendido evaluar y listar aquellos aspectos mejorables a nivel de accesibilidad, y que suelen ser los más habituales en las webs de las principales aseguradoras; nuestro objetivo, mostrar que todavía existe margen de mejora en este ámbito, y que todavía pueden ser más inclusivas, favoreciendo la igualdad de todos los usuario en el acceso a los contenidos, a la vez que se mejorar la imagen de marca. Si aún así esto no te convence, quizá la necesidad de cumplir con la ley (ley 56/2007) bajo sanciones de hasta un millón de euros lo haga. Tú decides.
José Luis  García López
José Luis García López

Head of UX. Manager del área Servicios en Babel.

logo linkedin compartir en Linkedin Contacto

Otros artículos destacados