Real Decreto 1112/2018 sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público

En diciembre de 2016 se publicó la «Directiva (UE) 2016/2102» cuyo objetivo es armonizar a nivel europeo los requisitos de accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público.

rd 1112_2018

La legislación española sobre accesibilidad web previa al Real Decreto 1112/2018

España ya cuenta con una legislación que regula la accesibilidad web. Se puede leer en la entrada: Día de la Discapacidad: Normativa en general.

Como ya sabemos, en España los sitios web deben ser accesibles desde 2009, y deben ser accesibles:

  • la Administración Pública y las empresas y entidades que gestionan servicios públicos (Ley 56/2007). Esto incluye, como así se refleja en la legislación, todos los portales web, incluidas las sedes electrónicas (Ley 11/2007); el registro y notificaciones telemáticas; los portales de transparencia (Ley 19/2013); o los entornos de aprendizaje de centros docentes sostenidos con fondos públicos (Ley 8/2013)
  • las empresas que reciben financiación pública (Ley 56/2007)
  • las empresas privadas con más de 100 trabajadores o que facturan más de 6 millones de euros de especial transcendencia económica, como las entidades bancarias, aseguradoras, empresas de transporte, agencias de viaje, suministradoras de electricidad, gas y agua, las grandes superficies y las empresas de telecomunicaciones (Ley 56/2007)
  • las redes sociales desarrolladas por entidades que facturen más de 6 millones de euros (Ley 26/2011)
  • las Universidades públicas y privadas (Ley 4/2007)
  • los instrumentos de cooperación internacional: campañas de divulgación, servicios de información, programas formativos, etc. (Ley 26/2011)
  • los prestadores de servicios de comunicación audiovisual: páginas web, guías electrónicas de programas y demás canales o vías de comunicación (Ley 7/2010)

 

Los requisitos de accesibilidad que debían cumplir hasta ahora era el nivel AA de la Norma UNE 139803 equivalente al nivel AA de las WCAG 2.0.

¿Quiénes están obligados a cumplir con el RD 1112/2018?

El ámbito de aplicación del nuevo Real Decreto 1112/2018 es exclusivamente el sector público:

  • La Administración General de Estado
  • Las Administraciones de las comunidades autónomas
  • Las entidades que integran la Administración Local
  • El sector público institucional
  • Las asociaciones constituidas por las Administraciones, entes, organismos y entidades que integran el sector público.
  • La Administración de Justicia.

 

En la disposición adicional primera y segunda se específica además que también están obligados:

  • Las entidades que reciban financiación pública para el diseño o mantenimiento de sus sitios o apps móviles.
  • Los sitios web y apps móviles vinculados a la prestación de servicios públicos; así como de entidades y empresas que se encarguen de gestionar servicios públicos, en especial, los que tengan carácter educativo, sanitario, cultural, deportivo y de servicios sociales.
  • Los centros privados educativos, de formación y universitarios, sostenidos, total o parcialmente, con fondos públicos.
  • Se indica que su aplicación incluye, para que no quepa duda, los sitios web y apps móviles de los órganos competentes del Congreso de los Diputados, del Senado, del Consejo de Estado, del Consejo Económico y Social, del Consejo General del Poder Judicial, del Tribunal Constitucional, del Tribunal de Cuentas, del Defensor del Pueblo, del Banco de España, de las Asambleas legislativas de las comunidades autónomas, así como a las instituciones autonómicas que realicen funciones análogas.

 

Es decir, el sector público en el sentido más amplio, donde no se excluye ninguna entidad, como sí se hacía en la Directiva. Por tanto, en este sentido, el Real Decreto es más exigente que la Directiva.

Por tanto, el ámbito de aplicación de lo que se dice en este Real Decreto, es la Administración Pública; pero no implica que anule la obligatoriedad de otros portales reflejados en otras leyes.

Sí que implica que la obligatoriedad de las apps móviles, cuya accesibilidad no estaba legislada hasta ahora, solo es aplicable a las apps del sector público, y NO es aplicable a las apps móviles de las empresas con más de 100 trabajadores o que facturen más de 6 millones de euros.

¿A qué tipo de contenido aplica?

El ámbito de aplicación del Real Decreto 1112/2018 es:

  • Sitios web, independientemente del dispositivo empleado para acceder a ellos.
  • Aplicaciones para dispositivos móviles (apps nativas).

Los contenidos a los que aplica son:

  • Información textual y no textual.
  • Documentos y formularios que se puedan descargar.
  • Los contenidos multimedia pregrabados de base temporal (como vídeos y audios).
  • Las formas de interacción bidireccional.
  • El tratamiento de formularios digitales.
  • La cumplimentación de los procesos de identificación, autenticación, firma y pago, con independencia de la plataforma tecnológica que se use para su puesta a disposición del público

Están EXCLUIDOS del ámbito de este Real Decreto los siguientes tipos de contenido:

  • Archivos de ofimática publicados antes de la entrada en vigor del RD, salvo que sean necesarios para tareas administrativas activas relativas a las funciones de la entidad obligada por el RD.
  • Contenido multimedia pregrabado de base temporal, es decir, vídeos o audios, publicados antes de la entrada en vigor de este RD.
  • Contenido multimedia en directo de base temporal salvo lo dispuesto en otra legislación específica que obligue al respecto.
  • Servicios de mapas y cartografía en línea, siempre y cuando la información esencial se proporcione de manera accesible digitalmente en el caso de mapas destinados a fines de navegación.
  • Contenidos de terceros que no estén financiados ni desarrollados por el sujeto obligado ni estén bajo su control.
  • Reproducciones de bienes de colecciones del patrimonio que no puedan hacerse plenamente accesibles por alguna de las siguientes causas:
    • Incompatibilidad de los requisitos de accesibilidad con la conservación del bien de que se trate o con la autenticidad de la reproducción
    • Indisponibilidad de soluciones automatizadas y rentables que permitan extraer el texto de manuscritos u otros bienes de colecciones del patrimonio y transformarlos en contenidos compatibles con los requisitos de accesibilidad.
  • Extranet e intranets (sitios para un grupo restringido de personas) publicados antes del 23 de septiembre de 2019, hasta que dichos sitios web sean objeto de una revisión sustancial.
  • Contenidos que sean archivos, o herramientas de archivo, por contener únicamente contenidos no necesarios para el desarrollo de tareas administrativas activas, siempre que no hayan sido actualizados ni editados con posterioridad a la entrada en vigor del RD.

 

Están excluidos, y se regularán por su normativa específica, los contenidos multimedia en directo y pregrabado de base temporal del servicio público de radiodifusión y sus filiales, así como los de otros organismos o sus filiales que cumplan un mandato de servicio público de radiodifusión.

Nueva normativa y nivel exigido

Los contenidos deben ser accesibles para todos los usuarios, y en especial para las personas mayores y con discapacidad, de acuerdo a la norma publicada en el «Diario Oficial de la Unión Europea», sino se presumirá que es la EN 301 549.

Se aplicarán directamente las actualizaciones de referencia a la norma EN 301 549. El órgano encargado de realizar el seguimiento y presentación de informes ante la Comisión Europea (que en nuestro caso va a ser el Ministerio de Política Territorial y Función Pública) mantendrá disponible en su sitio web la referencia concreta a las normas y especificaciones que sean de aplicación en cada momento.

Puesto que el artículo del Real Decreto 1494/2007 que deroga es el que indicaba también el nivel y normativa a aplicar a los portales de empresas privadas con más de 100 trabajadores o que facturan más de 6 millones de euros, se entiende que estos también deben a partir de ahora cumplir con la EN 301 549.

En el nuevo Real Decreto 1112/2018 se indica además que:

  • La accesibilidad debe tenerse presente de forma integral en todo el proceso de diseño, gestión, mantenimiento y actualización del sitio o app.
  • Las entidades adoptarán medidas, siempre que sea posible, para aumentar la accesibilidad más allá del nivel mínimo exigido.
  • Al igual que se indicaba en el RD 1494/2007, en la disposición adicional tercera del nuevo RD también se referencia la Ley 27/2007 que reconoce las lenguas de signos, de manera que los sitios web y las aplicaciones móviles deberán tenerla en cuenta. Acerca, de este tema, se puede leer más información en la entrada «Accesibilidad web: Diversidad funcional auditiva».

 

Usabilidad web: ¿Qué es UI y UX? Diferencias

He decidido hacer esta entrada porque todavía hay mucha gente que suele confundir dos términos que son parecidos, pero que no significan lo mismo.

UI, que se le conoce como Interfaz de usuario y UX, que es Experiencia de Usuario.

ux y ui: diferencias

¿Qué es UI? (Interfaz de usuario)

La interfaz del usuario hace referencia al conjunto de elementos de la pantalla que hacen que el usuario interactúe con el sitio web. El experto en usabilidad y uno de los mayores referentes en UI, Jakob Nielsen ha desarrollado una serie de mejoras. Según él, los elementos más importantes de una IU son:

  • Propósito del sitio: tiene que quedar claro a quién pertenece la web y qué funciones permite realizar.
  • Ayuda al usuario: el sistema de navegación tiene que estar a la vista, y también tiene que incluir un sistema de búsqueda adicional.
  • Mostrar el contenido: tiene que estar explicado de manera clara y con elementos de texto que ayuden a su lectura (como títulos, negritas, etc.).
  • Diseño gráfico funcional: los elementos gráficos deben ir dirigidos a ayudar al usuario en encontrar lo que quiere, y no solamente como adorno.

 

Componentes de la UI (Interfaz de Usuario)

La UI, principalmente presenta las posibilidades de interacción junto con el diseño visual. Esto quiere decir, que las decisiones de la Arquitectura de Información y el Diseño de Interacción se reflejan en la interfaz.

La arquitectura establece la estructura, además se piensa en cómo se comporta el sistema en respuesta al usuario y por último tiene una serie de características: colores, texturas y gráficos que lo hacen estético.

Según Usability.gov, los elementos que generalmente se presentan en una UI son los siguientes:

  • Controles de Input: botones, campos de texto, casillas de verificación, botones de radio, listas drop down, campos de fecha…
  • Componentes de Navegación: migas de pan, sliders, formularios de búsqueda, paginación, tags, iconos…
  • Componentes de Información: ayudas adicionales, iconos, barras de progreso, notificaciones, cajas de mensajes.
  • Contenedores

Principios del Diseño de UI (Interfaz de Usuario)

Según Larry Constantine y Lucy Lockwood, existen ciertos principios para el diseño de interfaz centrado en el usuario. Estos principios son:

  1. Estructura: El diseño debe organizar la interfaz de usuario a propósito, de manera significativa y útil basada en modelos claros y consistentes que son evidentes y reconocible para los usuarios, poniendo cosas relacionadas entre sí y que separa las cosas no relacionadas, diferenciando cosas diferentes y hacer cosas similares se parecen entre una y otra. El principio de estructura concierne a la arquitectura general de la interfaz de usuario.
  2. Simplicidad: El diseño debe facilitar las tareas sencillas y comunes, comunicarse de forma clara y sencilla en el propio idioma del usuario y proporcionar buenos accesos directos que estén significativamente relacionados con procedimientos más largos.
  3. Visibilidad: El diseño debe hacer visibles todas las opciones y materiales necesarios para una tarea determinada sin distraer al usuario con información superflua o redundante. El buen diseño no abruma a los usuarios con alternativas o confunde con información innecesaria.
  4. Retroalimentación: El diseño debe mantener a los usuarios informados de las acciones o interpretaciones, los cambios de estado o condición, y los errores o excepciones que son relevantes y de interés para el usuario a través de un lenguaje claro, conciso y claro que sea familiar para los usuarios.
  5. Tolerancia: El diseño debe ser flexible y tolerante, reduciendo el costo de los errores y el mal uso al permitir deshacer y rehacer, y al mismo tiempo evitar los errores siempre que sea posible, tolerando entradas y secuencias variadas e interpretando todas las acciones razonables.
  6. Reuso: El diseño debe reutilizar los componentes y comportamientos internos y externos, manteniendo la coherencia con el objetivo en lugar de consistencia meramente arbitraria, reduciendo así la necesidad de los usuarios a repensar y recordar.

 

¿Qué es la UX? Experiencia de usuario.

La experiencia de usuario hace referencia a las sensaciones que experimenta el usuario antes, durante y después de interactuar con un sitio, es decir, son las sensaciones que percibe y hace que el usuario se sienta satisfecho y feliz. Si esto ocurre, estaremos hablando de que ha producido una buena buena experiencia, que hemos hemos aplicado la accesibilidad y hemos hecho el sitio web lo más usable posible.

La experiencia de usuario, como se refiere al análisis del comportamiento del usuario, tiene actitudes relacionadas con la psicología:

  • La percepción. Tenemos que saber qué nos llama la atención, cómo nos afectan los colores y cómo desplazamos la mirada por la pantalla.
  • Las emociones. Las emociones no son reacciones automáticas, y por lo tanto hay que entender cómo se generan y qué implicaciones tienen. Las personas nos dejamos guiar más por las emociones que por cualquier otra cosa, y precisamente por eso es tan importante tenerlas en cuenta.
  • La memoria. Cuando diseñamos una web tenemos que pensar en las limitaciones de las personas para recordar. Muchas veces no se tienen en cuenta los caminos para que el usuario vuelva al punto de partida, y eso puede hacer que se sienta confuso.
  • La mentalidad. El usuario tendrá creencias, estereotipos, su interpretación de la sociedad y de las personas que lo rodean. Siguiendo en esta línea, vemos por qué cada vez más los usuarios buscan valoraciones de otras personas acerca de un producto en la red: no es solamente desconfianza, también implica qué prejuicios y creencias tiene.
  • La motivación. El usuario tiene que estar motivado durante todo el tiempo que esté en una web, no solamente al principio (de lo contrario, puede irse). Actualmente existen muchas empresas que usan el Gaming para tener a sus usuarios motivados y entretenidos.
  • El aprendizaje. Desde el momento en que un usuario entra en una página web se convierte en un aprendiz y eso significa que tenemos que enseñarle los pasos que tiene que dar para que consiga su objetivo. Además, se tiene que estructurar la información para que el usuario entienda fácilmente todo el contenido de la web.

Principios de la UX. (Experiencia de usuario)

 

  1. Esté fuera del camino de las personas: En diseño, mucho puede ser excesivo. En realidad las personas saben lo que desean y es mucho mejor hacer esa experiencia de la manera más fácil posible, sin complicaciones.
  2. Cree jerarquías que vayan de acuerdo con lo que las personas necesitan: si el principio 1 es hacerlo todo más simple, es importante que lo que las personas encuentren tenga una organización similar a sus necesidades.
  3. Limite las distracciones: si usted tiene una idea clara de qué desea que los usuarios hagan, tenga cuidado con lo que pone al lado, pues puede lograr resultados contraproducentes. Un diseño limpio y sin distracciones es un buen aliado.
  4. Provea de manera fuerte la esencia de la información: lo que más puede limitar una buena experiencia es no tener todo el conocimiento o contenido adecuados. Por ello, el diseño debe incluir lo necesario para la navegación y los contenidos prometidos o esperados por el usuario.
  5. Provea signos y pistas: hay que aprovechar todos los elementos a la mano, en especial los visuales, lo cual generalmente es un excelente complemento de la información adecuada.
  6. Es necesario el contexto: piense que no todos tienen el mismo nivel de conocimiento e información, por lo que muchas veces el contexto es parte importante para el desarrollo de la experiencia. Casi siempre todo necesita un porqué.
  7. Use el contenido constantemente: crear alertas y comunicar todo el tiempo en qué parte del proceso o del sitio se encuentra el usuario es vital para la buena experiencia.
  8. Haga reversibles las acciones: si hay algo que puede ser difícil de asumir para un usuario es que lo que hizo en el sitio web no pueda cambiarse o requiera muchos pasos para lograrlo. Por ello, es necesario dar la posibilidad de deshacer algunas decisiones, desde la simple de regresar a la página anterior hasta cancelar un pedido en una tienda en línea.
  9. Establezca un canal de retroalimentación: este puede ser uno de los canales más eficientes para saber lo que está sucediendo en su sitio web con la experiencia de usuario. Mantenga siempre una comunicación abierta. Si muchos usuarios ‘están equivocados’ o ‘no captan’ lo que usted está tratando de ofrecer o comunicar, lo más probable es que no sean ellos los del error.
  10. Es importante generar una primera buena impresión: lo que hace que los usuarios vuelvan y se conviertan en usuarios, lectores o visitantes fieles de un sitio es su experiencia. Generar buenos momentos y de tal forma buenos recuerdos impulsa esa fidelidad, y también el que comparta el sitio con otros.

Conclusión entre UI y UX

Por lo tanto la experiencia de usuario es lo que siente el usuario de interactuar con un producto, mientras que la interfaz de usuario es una capa visual de colores, texturas, formas y elementos. Por eso es algo que muchas personas suelen confundir con facilidad, porque digamos que una se integra dentro de la otra.

Es decir, la diferencia entre la interfaz de usuario y la UX o experiencia de usuario sería esta: El diseño de interacción se ocupa de decidir cuál será el recorrido y dónde se deberán situar los botones que desencadenarán las diferentes acciones, es la parte de estrategia y la experiencia de usuario trata sobre los aspectos relativos a esos procesos o acciones que se desencadenan, se ocupa de qué es lo que sucede cuando se activan los botones o mecanismos, y sería la parte mecánica del proceso.

Entradas relacionadas:

Accesibilidad y usabilidad web: Diferencias

Usabilidad web: Principios de diseño inclusivo

Introducción

Los principios de diseño inclusivo toman como elemento principal a los usuarios.

La base es diseñar teniendo en cuenta las necesidades de las personas con diversidad funcional permanente, temporal o contextual.

Van dirigidos a toda aquella persona que tenga que ver con el mundo del diseño y el de desarrollo de sitios web: diseñadores, profesionales de la experiencia del usuario, programadores, managers de productos, innovadores, artistas, pensadores…

Principios del diseño inclusivo

Los principios

Proporciona experiencias comparables

Asegúrate que la interfaz permite hacer tareas de manera conveniente para todos, sin perder la calidad del contenido.

Sea por circunstancias, contexto, o decisión propia, las personas son diversas. Usan métodos y herramientas distintas para interactuar con una aplicación. Lo que la interfaz ofrece a cada uno debe ser comparable en valor y calidad.

Ejemplos:

  • Contenido alternativo: Un alternativo básico, sea texto «alt» o una transcripción, descripción auditiva, o lenguaje de signos, hacen contenido accesible.
  • Caracteristicas de ergonomía: Proporcionar subtítulos sincronizados y poder personalizarlo hace un video accesible.
  • Establecer notificaciones y mensajes: Por ejemplo, para los usuarios ciegos aplicar los atributos ARIA

 

Considera la situación del usuario

Asegúrate de que la interfaz proporcione una una buena experiencia de usuario en cualquier situación.

Hay usuarios principiantes, los hay expertos, en el trabajo, en casa, viajando o bajo presión. Cada situación tiene su impacto. Para los que ya tienen dificultad en interactuar, por ejemplo por personas con diversidad funcional motriz, o si existen problemas con el uso del teclado, este impacto puede hacer la interfaz aún más difícil de usar.

Ejemplos:

  • Contraste de colores: Usar contrastes altos.
  • Ayuda contextual: La ayuda contextual es importante para los usuarios. Siempre es bueno esa información adicional que nos ayuda a saber qué estamos haciendo, por ejemplo, cuando estamos ante un formulario de inscripción y especificamos que el campo de «Contraseña» tenga 8 caracteres. Es muy importante para los usuarios que usen lector de pantalla.
  • Subtítulos: Cuando estemos en un lugar público y no queremos molestar a nadie es importante poner subtítulos y quitar el volumen.

Sé consistente

Usa convenciones, de manera consistente.

Los componentes de la interfaz reflejan patrones establecidos y conocidos que resultan obvios en funcionalidad, comportamiento, aparencia y estilo escrito. Se deben decir las cosas de la misma manera y los usuarios deben poder realizar acciones similares.

  • Patrones de diseño coherentes: Usa patrones de diseño consistentes para reforzar la comprensibilidad y familiaridad.
  • Consistencia de lenguaje: Usa lenguaje sencillo de manera consistente, incluso texto importante para usuarios de lectores de pantalla como el texto alternativo, encabezados, y etiquetas de controles. También es importante usar elementos del estilo como un resumen, bien señalado como tal, al principio de secciones, o destacar términos definidos en listados.
  • Arquitectura consistente: Usa arquitectura consistente en plantillas de paginas, para facilitar navegación y comprensión rápida.

 

El usuario manda

El usuario es que el manda. Debe poder interactuar con el contenido de la manera que le convenga.

Tiene que tener la posibilidad de trabajar para cambiar las características de la interfaz, como orientación de la pantalla, tamaño del texto y el contraste de colores.

Ejemplos:

  • Desplazamiento: El ‘Desplazamiento Infinito’ (cuando se agrega contenido automáticamente) puede implicar problemas para usuarios que usan el teclado, porque nunca pueden pasar el flujo de contenido. Permite desactivarlo poniendo un botón para actualizar.
  • No ponga animaciones: Para algunos usuarios pueden distraer y marear. Si empiezan automáticamente, deben de poder pararlas.
  • Permite hacer zoom: Hay muchas razones para querer hacer zoom en una pagina. Asegúrate de que el contenido no se esconde cuando se hace zoom.

 

Ofrece opciones

Proporciona diferentes maneras de cumplir las tareas.

Normalmente hay más de una manera de cumplir una tarea, y no se puede saber cual será la preferida por un usuario. Proporciona alternativas para la maquetación de información, y los procesos para cumplir tareas. Ofrece opciones que permita al usuario elegir la que le conviene en cada contexto.

Ejemplos:

  • Diversas maneras para hacer una acción: Ofrece maneras distintas para hacer una acción. Por ejemplo para borrar un objeto,se puede permitir una interacción directa, sea un gesto en pantalla táctil o una tecla de atajo, así que seleccionar objetos y tocar una botón de borrar – cómo se ve en clientes de correo.
  • Maquetación:  Hay usuarios quienes prefieren imágenes grandes, o contenido en bloques pequeños.
  • Alternativas accesibles: Hay muchas maneras de presentar la información. Esta información que presentamos, debe favorecer y debe estar disponible para todos los usuarios. Esas alternativas pueden ayudar a todos los usuarios, no sólo a un grupo determinado, (por ejemplo a los usuarios que usan lector de pantalla).

 

Prioriza el contenido

Ayuda al usuario a enfocarse en tareas, funciones y contenidos importantes para destacarlos en el contenido y la maquetación.

Puede ser más difícil entender una interfaz si las partes más importantes no se destacan. Un sitio puede ofrecer mucha información y funcionalidad, pero debe permitir al usuario enfocarse en una cosa a la vez. Identifica la función clave de la interfaz, el contenido y los controles que se dirigen a esta función.

Ejemplos:

  • Enfoque en la tarea actual: Muestra funcionalidades y contenido cuando son relevantes, no todos al principio.
  • Prioriza tareas: Ejemplo: Una app de correo permite principalmente leer y escribir mensajes. Entonces, haz que el botón para enviar un nuevo correo este siempre disponible. Igualmente, pon la bandeja de entrada antes de otros listados como los correos enviados o el spam. Es decir, dar prioridad a las acciones más importantes.
  • Ordenar el contenido: Es muy importante ordenar el contenido, tanto visualmente como en el orden del contenido en el código fuente.
  • Usa un lenguaje claro: En el texto de los enlaces, encabezados, y botones usa un lenguaje sencillo y claro, poniendo primero la información más importante. Eso facilita el escaneo del texto, sea visualmente o por audio, por ejemplo con un lector de pantalla.

 

Agrega valor

Considera el valor de funciones y características, y cómo mejoran la experiencia de usuarios diversos.

Funciones y características deben mejorar la experiencia del usuario, proporcionando maneras eficaces de encontrar e interactuar con el contenido. Considera funcionalidades de dispositivo cómo interreacción por voz, géolocalizacion, la camera, o vibración, y cómo integración con dispositivos conectados pueden ofrecer opciones más convenientes.

Ejemplos:

  • Integración con dispositivos conectados, o «pantalla segunda»: Usa la interacción por voz para controlar contenido multimedia o buscar contenido, que ayuda a la gente que puedan tener dificultades con otras interfaces.
  • Integración con funcionalidades de la plataforma: Utiliza la vibración para que salten las notificaciones para personas con dificultades auditivas, y geolocalización para facilitar el uso de servicios locales para usuarios con dificultades para moverse.
  • Facilita tareas: Permite ver contraseñas para que los usuarios sepan si las han escrito bien. Permite la identificación por huella digital así como por contraseña.

 

 

 

 

 

Accesibilidad web: Marcador de posición en los formularios

Los marcadores de posición en los campos de formulario son perjudiciales

El texto del marcador de posición dentro de un campo de formulario dificulta que las personas recuerden qué información pertenece a un campo, así como verificar y corregir los errores.
También plantea cargas adicionales para los usuarios con dificultades visuales y cognitivas.
Las descripciones o consejos ayudan a aclarar qué se incluye dentro de cada campo de formulario y, por lo tanto, mejorar las tasas de finalización y conversión.

marcador de posición en los formularios

Desafortunadamente, los marcadores de posición en los campos de formulario a menudo perjudican la usabilidad.

Etiquetas y marcadores de posición

Las etiquetas le dicen a los usuarios qué información pertenece a un campo de formulario determinado y generalmente se ubican fuera del campo de formulario. El texto del marcador de posición, ubicado dentro de un campo de formulario, es una sugerencia, descripción o ejemplo adicional de la información requerida para un campo en particular. Estas sugerencias generalmente desaparecen cuando el usuario escribe en el campo.

Marcadores de lugar que reemplazan etiquetas

Algunos formularios reemplazan las etiquetas de campo con texto de marcador de posición en el campo para reducir el desorden en la página o acortar la longitud del formulario.

A continuación, voy a enumerar 7 razones principales por las que los marcadores de posición no deben usarse como reemplazos de etiquetas de campo.

1. El texto de marcador de posición que desaparece afecta a la memoria a corto plazo

Si el usuario olvida la pista, lo que la gente suele hacer al completar formularios largos, debe borrar lo que escribió y, en algunos casos, hacer clic fuera del campo para volver a mostrar el marcador de posición. En un mundo ideal, los usuarios estarían completamente enfocados al completar un formulario.

En formularios simples, de uso frecuente, con uno o dos campos, como un cuadro de búsqueda o un formulario de inicio de sesión, los usuarios pueden adivinar a qué se deben ingresar.

2. Sin etiquetas, los usuarios no pueden verificar su trabajo antes de enviar un formulario.

La falta de etiquetas hace que sea imposible para los clientes mirar el formulario y asegurarse de que sus respuestas sean correctas.

Del mismo modo, los navegadores que completan automáticamente los campos de formulario pueden completar la información de forma incorrecta. Si no hay etiquetas, o si las instrucciones especiales ya no están visibles, los clientes deben revelar el texto del marcador de posición eliminando el texto de cada campo uno por uno para verificar que coincida con la descripción.

3. Cuando se producen mensajes de error, las personas no saben cómo solucionar el problema.

Si el formulario se ha completado, pero no hay etiquetas o instrucciones visibles fuera de los campos del formulario, los usuarios tienen que volver a cada campo para revelar la descripción a fin de corregir el error.

4. El texto del marcador de posición que desaparece cuando el cursor se coloca en un campo de formulario es irritante para los usuarios que navegan con el teclado.

Las personas que usan la tecla Tab se mueven rápidamente de un campo a otro, y no se detienen a estudiar el siguiente campo antes de buscarlo.

5. Los campos con cosas en ellos son menos perceptibles.

Los estudios de seguimiento de ojos muestran que los ojos de los usuarios se sienten atraídos por los campos vacíos.

6. Los usuarios pueden confundir un marcador de posición con los datos que se completaron automáticamente.

Algunos usuarios suponen que el texto del marcador de posición es un valor predeterminado y saltean el campo por completo. Lo más cómodo es dejar el campo vacío.

7. Ocasionalmente, los usuarios tienen que eliminar manualmente el texto del marcador de posición.

A veces, los marcadores de posición no desaparecen cuando los usuarios mueven el foco de entrada al campo. Si el marcador de posición permanece en el campo como texto editable, los usuarios se ven obligados a seleccionarlo manualmente y eliminarlo. Esto crea una carga innecesaria para los usuarios y aumenta el costo de interacción de rellenar el formulario.

A veces, el marcador de posición se atenúa cuando el cursor se coloca en un campo de texto. Desafortunadamente, este patrón de interacción es raro y los usuarios no están familiarizados con él: algunos todavía piensan que tienen que eliminar el texto manualmente. A menudo se requieren algunos intentos fallidos y muchos clics para darse cuenta de que pueden comenzar a escribir sobre el texto atenuado.

Texto de marcador de posición además de etiquetas

Usar texto de marcador de posición en combinación con etiquetas de formulario es un paso en la dirección correcta. Las etiquetas fuera de los campos del formulario hacen que la información esencial esté visible en todo momento, mientras que el texto de marcador dentro de los campos del formulario se reserva para información adicional.

Sin embargo, incluso al usar etiquetas, colocar sugerencias o sugerencias importantes dentro de un campo de formulario puede causar los 7 problemas mencionados arriba.

Si algunos de los campos requieren una descripción adicional que es esencial para completar el formulario correctamente, es mejor colocar ese texto fuera del campo para que esté siempre visible.

Marcadores de posición y accesibilidad

Un último tema a considerar es que el texto del marcador de posición generalmente es malo para la accesibilidad.

Tres de los mayores problemas de accesibilidad son los siguientes:

El color gris claro predeterminado del texto de marcador de posición tiene un contraste de color pobre en la mayoría de los fondos. Para los usuarios con problemas visuales, el contraste deficiente del color dificulta la lectura del texto. Debido a que no todos los navegadores permiten que el texto de marcador de posición tenga un estilo mediante CSS, este es un tema difícil de mitigar.

Los usuarios con dificultades motoras son los que lo tienen más difícil. Los marcadores de posición pueden ser problemáticos: los marcadores de posición que no desaparecen requieren más interacción con el teclado o el mouse para eliminarse.

Por otra parte, si hablamos de personas con problemas visuales, no todos los lectores de pantalla leen el texto del marcador de posición en voz alta. Los usuarios ciegos pueden perder la pista por completo si el software que utilizan no menciona el contenido del marcador de posición.

 

Accesibilidad web: Cómo funciona un lector de pantalla

Cómo funciona un lector de pantalla

Para aquellos usuarios que usan software de lectura de pantalla como JAWS, NVDA o VoiceOver para acceder a la información en la Web, la experiencia del usuario puede ser bastante diferente de la de quienes pueden ver visualmente el contenido.Pero la gente prefiere pasar directamente a los detalles técnicos:

  • ¿Qué teclas presionar?
  • ¿Con qué lector de pantalla debería probar?
  • ¿Qué navegador debería usar?

 

lector_de_pantalla

Si bien todas estas consideraciones son importantes, lo mejor es dar un paso atrás y preguntarnos:

¿Cómo es la experiencia y cómo puedo simular esa experiencia si puedo ver la pantalla?
Para ello, lo vamos a explicar con un ejemplo muy claro para que se entienda bien.

Una puerta abierta

Imagina que acabas de abrir una puerta y estás mirando una gran sala de conferencias.
En el centro de la sala hay una gran mesa de conferencias con 10 sillas (5 en cada lado de la mesa).

Sentados en la mesa hay 2 hombres y 2 mujeres. Las 4 personas están sentadas en el mismo lado de la mesa (están frente a la puerta en la que estás parado). En el otro extremo de la sala (detrás de la gente sentada en la mesa) hay 3 ventanas grandes que dan a un patio con bancos, flores y árboles pequeños.

En el lado derecho de la sala hay un mostrador con una cafetera y un microondas encima.

El lado izquierdo de la sala tiene un gran televisor de pantalla plana montado en la pared.

Suponiendo que no está familiarizado con el diseño de esta sala, ¿qué es lo primero que haría al abrir la puerta? Escanear visualmente la habitación de izquierda a derecha. Algunos la pueden escanear de derecha a izquierda. Otros pueden primero mirar la mesa en el centro y luego escanear el perímetro de la habitación.

Sin embargo, no importa cómo lo hagas, la mayoría escanearía la habitación de alguna manera con la vista para tener una idea rápida del diseño y el contenido de la sala.
El escaneo sólo puede tomar unos segundos y la mayoría ni siquiera se darán cuenta de que lo hicieron.

A continuación, nos podemos centrar en ciertos elementos de interés, como las personas sentadas en la mesa o en la televisión de pantalla plana.

Una habitación oscura

Ahora, imaginemos la escena y esta vez cuando abramos la puerta, la habitación estará completamente a oscuras. No hay luz y no se puede ver absolutamente nada a primera vista. Sin embargo, nos han dado una pequeña linterna y cuando la encendemos, la luz nos permite ver un área pequeña a la vez.

¿Cómo observarías ahora el contenido de la habitación?

Algunos pueden mover la luz de izquierda a derecha comenzando por los pies y alejándose.
También se puede empezar desde la parte posterior de la habitación y mover la linterna, mientras que otros pueden apuntar la linterna al azar en varios lugares de la habitación sin un patrón en particular. A medida que mueva la luz por la habitación, tendrá que construir un mapa mental o una imagen de lo que hay en la habitación y cómo está distribuida.
La construcción de este mapa mental llevará mucho más tiempo que el escaneo visual de la sala cuando todas las luces estaban encendidas.
A medida que movemos la linterna, tendremos que recordar cada cosa que hemos visto y cómo se relacionan todas juntas.

Si olvidamos dónde se encuentra algo, llevará más tiempo localizarlo:

¿el mostrador con la cafetera estaba en el lado derecho de la habitación o estaba en la parte de atrás? ¿Cuántas personas había en la mesa, 4 o 5?

Responder estas preguntas cuando puede ver toda la habitación a la vez requerirá poco esfuerzo, pero contestarlas cuando solo puede ver un área pequeña a la vez llevará mucho más tiempo.

Un escenario análogo

Este segundo escenario es análogo a cómo un usuario de lector de pantalla revisa una página web o una aplicación de móvil.

Si bien los comandos del teclado o los gestos táctiles pueden mover el software de lectura de pantalla alrededor de la página, solo es posible leer una cosa a la vez.
No hay forma de que el usuario con discapacidad visual tenga una visión general rápida (de 1 a 3 segundos) de la página, similar a lo que podría hacer alguien que pueda ver la pantalla.

Afortunadamente, si se utilizan técnicas de navegación de página accesibles como encabezados o regiones, esto puede ayudar a los usuarios del lector de pantalla a enfocarse en ciertas áreas de la página.

Volviendo a nuestro escenario de habitación oscura desde arriba, imagina que ahora hay pequeños puntos rojos de luz en los elementos clave de la habitación: como la mesa, el mostrador, la televisión y cada persona sentada en la mesa. Hay que usar la linterna para mirar alrededor, pero los puntos rojos le dan una idea de dónde se encuentran las cosas más importantes.

Otro desafío importante que pueden enfrentar los usuarios de lectores de pantalla es cambiar dinámicamente el contenido de una página.

Volviendo a los ejemplos de habitaciones claras y oscuras, imagina que uno de los hombres se levanta y se mueve al otro lado de la mesa.

Ahora hay 2 mujeres y 1 hombre en un lado de la mesa y 1 hombre en el otro lado.
En el ejemplo de la habitación iluminada, lo más probable es que notemos el movimiento mientras sucede. Incluso si no estuviéramos mirando directamente al hombre que se movió, probablemente notaríamos el movimiento por el rabillo del ojo y nos percatamos de lo sucedido.

En cuanto al ejemplo de la habitación oscura, sería muy difícil saber que algo sucedió a menos que tengas el haz de la linterna directamente sobre el hombre que se movió en el momento preciso.
Es más probable que nunca sepa que se movió hasta algún momento después, cuando mueve la luz sobre la silla que dejó libre.

En efecto, esto es lo que sucede cuando el contenido de la página cambia pero no alerta el software de lectura de la pantalla. Es posible que el usuario nunca sepa que algo cambió en la página a menos que se muevan a través de la nueva información y se den cuenta de que ahora es diferente.

Esto que he explicado se resuelve asegurando que con el contenido dinámico se usen técnicas como alertas o regiones en vivo que hacen que el software de lectura de pantalla anuncie la información actualizada al usuario.

En nuestro escenario de la habitación oscura, el hombre puede anunciar verbalmente que se está moviendo de un lado de la mesa al otro. Incluso si la luz no estuviera en él, escucharías el anuncio y entenderías mejor lo que está cambiando.

En una ilustración final, tomemos las ventanas que dan al patio. En el escenario de la habitación iluminada, se podrá ver rápidamente que las ventanas dan a un patio con bancos, flores y árboles. Sin embargo, en el ejemplo de la habitación oscura, incluso si apuntabas la luz hacia las ventanas, no podrías ver lo que estaba afuera.
Esto ilustra elementos visuales como imágenes que no tienen una etiqueta de texto asociada.
Por ejemplo, el software de lectura de pantalla puede identificar que una imagen está presente en una página, pero la única forma en que puede comunicar información sobre la imagen es a través del texto alternativo que se le asigna.
Sin la etiqueta de texto, el usuario del lector de pantalla no tendría idea de qué se muestra en la imagen. En el ejemplo de la habitación oscura, se podría colocar un letrero junto a las ventanas con una descripción de lo que aparece afuera. Cuando usemos la linterna, entonces podremos leer el letrero.

 

Usabilidad web: Mensajes de error en formularios

Mensajes de error en formularios

En esta entrada os voy a hablar de cual es la mejor manera de colocar los mensajes de error en los formularios.

¿Dónde colocamos los mensajes de error en los formularios?

Es importante conocer donde podemos colocar los errores, ya que si no se colocan donde los usuarios esperan verlos, les será imposible completar el formulario.

Cuando los usuarios cometen errores, deben comprender cuáles son esos errores para poder corregirlos y volver a enviar el formulario. Quieren completar el formulario, pero si hacerlo requiere mucho esfuerzo, se irán del sitio web.

¿En la parte superior o alineados con los campos erróneos?

Las dos ubicaciones más comunes para los mensajes de error se encuentran en la parte superior del formulario y en línea con los campos erróneos.

¿Qué ubicación es más intuitiva para los usuarios?

Mostrar todos los mensajes de error en la parte de arriba del formulario produce mucha carga cognitiva en la memoria del usuario. Esto obliga a los usuarios a recordar cada mensaje de error para cada campo erróneo.

Para reducir la carga cognitiva de los usuarios, hay que mostrar los mensajes de error alineados con los campos erróneos. Así pueden corregir los errores de forma más rápida y sencilla.

Ubicación de los mensajes de error de preferencia del usuario

Colocar los mensajes de error en línea con los campos erróneos es mucho más cómodo para los usuarios. Prefieren que los mensajes de error se ubiquen a la derecha del campo.

Los mensajes de error colocados a la izquierda del campo no son buenos para los usuarios. Los mensajes de error colocados sobre el campo causan mayor carga cognitiva seguida de mensajes de error debajo del campo, por lo tanto dificulta la usabilidad de los campos de formulario.

Por qué a la derecha del campo es mejor

Es importante entender por qué es preferible y esperado colocar los mensajes de error a la derecha del campo. De esta forma, los diseñadores pueden educar mejor a los demás sobre cómo se comportan los usuarios cuando toman decisiones de diseño.

El sistema de lectura occidental va de izquierda a derecha. Cuando los usuarios mueven los ojos de la entrada al mensaje de error, se produce una progresión natural que requiere poco esfuerzo mental y visual. Al mover los ojos desde el mensaje de error a la entrada para la corrección también sigue el flujo natural para releer el texto.

mensaje de error a la derecha del campo

Por qué a la izquierda del campo es peor

Colocar mensajes de error a la izquierda del campo va en contra del sistema de lectura occidental. Los usuarios mueven los ojos en la dirección opuesta al flujo de lectura natural cuando aparece el mensaje de error. En lugar de producirse una progresión natural, es antinatural y no es óptima, cuando los usuarios lo que desean es completar el formulario.

Tampoco es intuitivo porque los usuarios esperan elementos de mayor prioridad en el lado izquierdo. Colocar el mensaje de error a la izquierda lo hace más importante que el campo. Pero el campo es más importante porque los usuarios necesitan enfocarse en él para rellenarlo.

Mensaje de error a la izquierda del campo

Por qué sobre el campo aumenta la carga cognitiva

Los usuarios experimentan una mayor carga cognitiva con mensajes de error sobre el campo (es decir, formularios con etiquetas alineadas en la parte superior). Esto es causado por una combinación del mensaje de error y el texto de la etiqueta del campo que confunde a los usuarios.

La proximidad de los dos textos crea un ruido visual que distrae a los usuarios cuando intentan leer el mensaje de error o la etiqueta. Ver ambos textos en su campo de visión hace que sea difícil concentrarse solo en uno de ellos y puede confundirlos.

Mensaje de error encima del campo

Ubicación de los mensajes de error para formularios móviles

Las pantallas móviles carecen del espacio horizontal para mostrar un mensaje de error y un campo, uno al lado del otro. Esto significa que los mensajes de error a la derecha del campo no son la mejor ubicación en los formularios móviles. En su lugar, hay que colocar los mensajes de error debajo del campo.

Mensaje de error abajo del campo

Aunque no se corresponde con el flujo de lectura natural de izquierda a derecha del usuario, sí se corresponde con el flujo de lectura natural de arriba hacia abajo.

Cuando los usuarios leen texto, mueven los ojos de izquierda a derecha bajando una página. Los mensajes de error debajo del campo son menos incómodos que en el campo, porque siguen la progresión de lectura vertical.
Colocar el mensaje de error demasiado cerca de la etiqueta del campo después puede aumentar la carga cognitiva cuando los usuarios leen el texto.

A la derecha o debajo de campo: ¿Cuál es el mejor?

Ambos, a la derecha del campo y debajo del campo son ubicaciones óptimas para los mensajes de error.

¿Pero qué ubicación se debería usar? 

Si deseamos que la implementación tarde menos tiempo en hacerse para ordenadores y dispositivos móviles, la mejor opción es poner los mensajes de error debajo del campo. Implementarlos para ordenadores también los hará utilizables para dispositivos móviles. Si queremos implementar mensajes de error para ambos dispositivos, la mejor opción es colocarlos a la derecha del campo en el escritorio y debajo del campo para dispositivos móviles.

Colocación de mensajes de error intuitivos

Los mensajes de error deben corresponderse con el flujo de lectura del usuario, por lo que los errores requieren menos esfuerzo cognitivo para corregirlos. Cuando los usuarios trabajan y piensan menos, pueden completar el formulario más rápido. Cuanto más rápido ayudemos a los usuarios a superarlo, antes podrán pasar a lo que quieran hacer.

Si quieres saber más sobre los formularios puedes leer la entrada sobre los marcadores de posición.

 

Usabilidad web: Problemas con el editor Gutenberg

Introducción

Una de las partes más importantes de WordPress, aparte de todas las personas que trabajamos en ello, es el editor, ya que es donde escribes tus contenidos y puedes aportar y ayudar ofreciendo todo el conocimiento que tienes, con la idea de hacer un WordPress mejor para todos.

Pero desde que está la posibilidad de utilizar este editor, veo que aún le queda mucho por mejorar y, que usarlo así de primeras, el cambio impresiona bastante. Pero bueno, aún así intentaré mostrar los principales problemas que nos podemos encontrar.

Principalmente, si pensamos en personas con dificultades físicas y/o con dificultades visuales que usen el editor, el esquema mental que tenido en su mente durante tanto tiempo, en un segundo se desbarata. Con lo cual tiene que volver a empezar y adaptarse a un cambio tan brusco cuesta, como a todos, pero a ellos más aún, y claro, teniendo tantas cosas para mejorar, la frustración es aún mayor.

Problemas de usabilidad con Gutenberg

La primera impresión al usar Gutenberg hace ya unos cuantos meses, y reconozco lo que he usado poco, era que al existir la posibilidad de mover bloques, cualquier persona que use el teclado y le dé por error se puede llegar a confundir, sobre todo si es una persona con visión nula. Y para una persona con problemas físicos, lo que ocurre es que se aumenta la carga motora innecesariamente, al tener que volver a colocar el bloque en el lugar que le corresponde. Bueno, en este caso, no tanto.

Pero cuando tienes que modificar estilos, sí. Porque tienes que pasar los estilos en cada uno de los bloques para seguir, a menos que uses las flechas de dirección o usar los comandos de teclado asignados para ello. Que a fin de cuentas es lo que se hace con el editor actual, y no nos encontramos con el problema de que al usar el TAB hay que pasar por los bloques y cada una de las opciones que tiene, lo cual es bastante cansado.

Me falla la barra de herramientas fija en la parte superior

Sí, así, tal y como lo lees. ¿Por qué? Porque si nos fijamos bien en las diferentes opciones del bloque, en la primera de ellas que es «Cambiar tipo de bloque». Según lo que quieras poner ya sea una lista, un encabezado o una cita, la mejor solución es usar el comando correspondiente, porque es un pérdida de tiempo usar la tecla TAB si el usuario se equivoca al elegir qué quiere.

Yo pregunto: ¿Es necesario pasar con el teclado todas las opciones que se ven al desplegar esa opción? NO. Esto puede ser muy cansado para el usuario. Es cierto que beneficia a las personas que usan el ratón y es bastante rápido, pero nos olvidamos de los usuarios que no pueden usar un ratón y el problema principal es que se aumenta la carga motora sin necesidad. No sólo con eso, sino con todo. Porque se tiene que usar constantemente para estar editando y modificando las cosas. Y, también, todo esto puede marear a un usuario ciego.

Pero investigando por estos lares, me he dado cuenta de que existe la opción de «Fijar la barra de herramientas». En el menú de puntos de la esquina superior derecha, en Ajustes. 
Opción Fijar barra de herramientas

Inserción de imágenes

He creado esta imagen para hacer ver uno de los problemas principales de usabilidad, al menos para mí y para muchos usuarios.

Problema de usabilidad de Gutenberg

Y aquí me encuentro con otro problema: que una vez que insertas una imagen, le das a Intro, y te obliga a poner otra y no hay forma de salir de ahí, hasta que no pasas varias veces con el TAB. Te vuelves loca. ¿Y si yo quiero poner un párrafo o un encabezado inmediatamente después? Con lo cual esto es un problema grave de usabilidad. Te interrumpe cada vez que quieres hacer algo.

En las imágenes es importante añadir el texto alternativo para que las personas ciegas puedan hacerse una idea de cual es la información de la imagen. Una leyenda es añadir algo más de información cuando se trata de una información adicional de la propia imagen, como explicar un gráfico o una imagen compleja, por ejemplo.

Atajos de teclado

Cuando se va a buscar el menú de los atajos de teclado y quieres desplazarte hacia abajo para seguir viendo el resto de comandos, no se puede, es dependiente de ratón.

Y tampoco se sabe cuáles son los atajos para poner los encabezados, algo muy importante para llevar a cabo el orden necesario en cuanto a accesibilidad web, y por lo tanto para ayudar a las personas ciegas a navegar y a entender el contenido.

Inserción de Enlaces

A la hora de insertar un enlace también da problemas. Cuando insertamos un enlace, se inserta bien, pero no te deja abrirlo en una ventana nueva. Una vez lo pones, no puedes comprobar que funciona porque no te deja. Para comprobar que funciona nos tenemos que ir a la opción «Ver entrada» y ya sale, cuando debería dejar hacerlo desde el propio enlace.

Inserción de  vídeos y Opción Incrustados

Hay un problema de usabilidad bastante grande con la inserción de vídeos. Directamente, es que no se puede. Esto, desde un primer momento crea bastante confusión a los usuarios, porque por ejemplo, al insertar un vídeo usando la opción de Vídeo se espera eso, poder insertar un vídeo sin problemas.

En la pestaña Incrustados, que aparece en el menú de bloques de la esquina superior izquierda, en cuanto a los vídeos, me parece un error poner todo lo que corresponde a las redes sociales, vídeos, así como las diferentes plataformas de música y fotos. Hay que intentar ser coherentes con lo que estamos haciendo. Si ya tenemos la opción de Vídeo, que en un primer momento sirve para eso, no podemos confundir al usuario con la palabra Incrustados.

Es más, como sugerencia, diría que hasta podría clasificar las opciones en función de su finalidad: Fotos, audio, vídeos y Redes Sociales. Sería mucho más cómodo a la hora de hacer las búsquedas de lo que se necesite en el momento.

Además de esto, es muy posible que algunas de las opciones no sean accesibles y seguramente tendrán que mejorar muchísimo en cuestión de accesibilidad. Con lo cual, ese menú puede suponer una pérdida de tiempo para los usuarios.

Menú de bloques

En cuanto al menú de bloques, que está dividido en diferentes pestañas que su vez despliegan un menú con diferentes opciones, me quedaba con: Más utilizados, Bloques comunes, Formatos y Elementos de diseño. Incluso, me plantearía redistribuir los Elementos y eliminaría alguno que otro porque lo único que hace es entorpecer y complicar las cosas. De los Formatos en las tablas no se puede tabular y es dependiente de ratón, con lo cual es un problema grave de usabilidad.

Los Widgets están siempre y cuando se pueda añadir una barra lateral y al no poderse hacer, o al menos yo no lo he descubierto, no tiene mucho sentido.

Y la opción de Reutilizable no entiendo para qué sirve. No le encuentro ningún sentido.

Conclusiones

Para mi gusto y por facilidad a la hora de trabajar con Gutenberg, es mucho más cómodo trabajar como lo he explicado anteriormente, con la barra de herramientas fija en la parte de arriba.

Y yo pregunto: ¿Por qué no se añade directamente la barra de herramientas fija a la parte superior? Una funcionalidad tan importante como esta no debe pasar desapercibida para nadie y mucho menos estar escondida en un menú. Se debería incluir esta opción siempre y así no frustra tanto a los usuarios.

Por cierto, lo último que he visto ha sido dentro del menú de cada uno de los bloques, las opciones «Insertar antes» e «Insertar después», lo cual está bastante bien y mejora algo las cosas cuando estamos editando.

Y para finalizar, comento lo que toda la comunidad de WordPress lleva diciendo desde hace ya algunos meses:

Gutenber no está preparado para implementarse, necesita mejorar mucho en accesibilidad y en usabilidad para que se asiente como editor de textos en WordPress.

Accesibilidad web: ¿Cómo hacer tablas accesibles?

Introducción

Las tablas son un elemento más que forman parte de los sitios web.

Para las personas videntes pueden resultar cómodas y fáciles de interpretar, pero para las personas que usen lectores de pantallas puede ser un problema de accesibilidad.

¿Para qué sirven las tablas?

Las tablas sirven para mostrar información tabular. La información tabular permite consultar y analizar datos. Las tablas no se deben utilizar para la presentación de los contenidos en la web y, por tanto, no se debe usar para la maquetación de nuestro sitio web.

¿Cómo hacemos nuestras tablas accesibles?

En las WCAG 2.0 en el Criterio de Conformidad 1.3.1 Información y relaciones, hay una serie de técnicas que tenemos que tener en cuenta cuando tengamos que insertar en nuestros contenidos una tabla de datos:

Es importante describir la tabla

Debemos proporcionar información adicional sobre la tabla. Así describiremos el propósito de la misma y también se recomienda informar de su estructura. Disponemos de dos métodos complementarios:

  • el atributo summary dentro de la etiqueta <table>
  • la etiqueta <caption> dentro de la tabla.

 

Así se informará a los usuarios de productos de apoyo, como los lectores de pantalla. Por ejemplo, si es un listado de notas, lo debemos indicar. Si en la misma página hay múltiples listados de notas, deberemos incluir en la descripción, la asignatura para permitir al que navega saltar todas las tablas que no le interesen.

Es como poner un título y una leyenda a la tabla para que los usuarios sepan cuál es la información de la tabla, algo que me recuerda al tema de los formularios con el uso de fieldset y la etiqueta <legend>

<table summary"Notas del curso 2015-2016">
<caption>Notas finales del curso de accesibilidad</caption>
</table>
  • En las tablas de maquetación no debemos incluir el atributo summary.
  • El elemento caption y el atributo summary se pueden usar conjuntamente y no deben tener el mismo contenido.

Las tablas deben ser uniformes

Las tablas deben ser uniformes, evitando dividir, combinar o vincular celdas, y por lo tanto tienen que tener el mismo número de filas por columna y el mismo número de columnas por fila.

Para mayor facilidad de de uso y compresión de las tablas se recomienda hacer tablas simples en vez de tablas complejas.

Uso de encabezados

Las tablas deben tener definidos correctamente los encabezados con la etiqueta <th>, ya sea horizontalmente como verticalmente.

Cuando la tabla tiene una disposición de agrupación de columnas o filas, hace mucho más complicado su consulta. Disponemos del atributo scope para poder indicar que el campo actual es la cabecera de la columna o fila que hay a continuación.

En esta primera tabla la cabecera superior se corresponde con la ordenación posterior de los datos. Por tanto en cada <th> incluiremos el atributo scope=”col”.

tabla1

<thead>
<tr>
<th scope="col">Alumno</th>
<th scope="col">Nota</th>
</tr>
</thead>
<tbody>...</tbody>

Ahora vamos a trabajar con una segunda tabla, en la que tenemos una doble agrupación. En la fila superior dispondremos de <th> con el atributo scope=”col” como anteriormente, pero en la primera celda de cada fila tenemos un nuevo th en vez de td e indicaremos el atributo scope=”row”.

Hemos utilizado la técnica H63.

<thead>
<tr>
<th scope="col">Alumno</th>
<th scope="col">Sesión 1</th>
...
</tr>
</thead>
<tbody>
<tr>
<th scope="row">Marta</th>
<td>8</td>
<td>9</td>
<td>9</td> ...
</tr>
</tbody>

tabla2

 

Resumen

  • Una tabla de datos simple es aquella en la que, una celda de datos sólo se relaciona con un encabezado o de fila o de columna, es suficiente el uso de th para identificarlos. Por lo tanto es suficiente con implementar la técnica anteriormente vista H51.
  • Una tabla de datos compleja, es aquella en la que una celda de datos se relaciona con más de un encabezado de fila y/o columna, y por tanto hemos de establecer la asociación entre las celdas de datos con sus celdas de encabezado, utilizando la técnica H63 o la técnica H43.

 

Udemy: Tablas accesibles

Roger Hudson: Tablas accesibles

Office: Cómo hacer tablas accesibles en Word.

 

 

 

Accesibilidad web: Cómo hacer una navegación más accesible

En esta entrada voy a comentaros varios requisitos y técnicas de accesibilidad que nos ayudarán a tener una navegación más sencilla y más accesible.

Accesibilidad web: Cómo hacer una navegación más accesible

Cómo hacer una navegación accesible

Los requisitos a tener en cuenta son los siguientes:

  • Ofrecer varias vías de navegación para localizar el contenido
  • Facilitar la ubicación al usuario para que en ningún momento se sienta perdido
  • Mantener la consistencia lo largo del sitio

 

1. Múltiples vías  de navegación

Lo primero vamos a explicar es cómo establecer diferentes vías para mejorar la navegación de forma que los usuarios lo encuentren fácil y puedan satisfacer sus necesidades.

Para ello, tendremos en cuenta el criterio 2.4.5. «Múltiples vías: Se proporciona más de un camino para localizar una página web dentro de un conjunto de páginas web, excepto cuando la página es el resultado, o un paso intermedio, de un proceso. (Nivel AA)»

Hay quienes prefieren usar el buscador a recorrer un menú de navegación largo. Otros prefieren usar tablas de contenidos o un mapa del sitios para navegar por el sitio

Por eso, las WCAG 2.0 establece que tenemos que aplicar dos o más técnicas para mejorar la navegación.

  • Mapa del sitio
  • Función de búsqueda
  • Enlaces a páginas relacionadas
  • Tabla de contenidos

 

Mapa del sitio

Es muy importante tener en cuenta la creación de un mapa web, que ayude a facilitar la comprensión del sitio web. Para ello, tenemos la técnica G63: Proporcionar un mapa del sitio y que debe cumplir una serie de requisitos:

  • Debe estar enlazado a todas las páginas, o desde cada una de las páginas que se listan en el mapa web.
  • Desde el mapa web se tiene que poder acceder a todas las páginas del sitio, directa o indirectamente. Por lo tanto, sus elementos deben ser enlaces.
  • La presentación y la estructura deben reflejar la orgnización del sitio, con elementos HTML, como son los encabezados y las listas.
  • El orden de lectura y de tabulación debe ser el correcto.
  • Se debe actualizar cada vez que se actualiza el sitio.

Función de búsqueda

Otra técnica a tener en cuenta es proporcionar una función de búsqueda en el sittio web, patra que los usuarios puedan acceder a buscar el contenido sin necesidad de entender el sitio o navegar por él. Es muy útil en sitios de gran tamaño.

La función de búsqueda se realizará mediando un campo de búsqueda que esté presente en las páginas del sitio. La técnica que habla de esto es la G161: Proporcionar una función de búsqueda para ayudar a los usuarios a encontrar contenido.

 

Enlaces a páginas relacionadas

Otra técnica que se puede emplear es enlaces a páginas relacionadas. De esta manera los usuarios ppueden encontrar información adicional. Técnica G125: Proporcionar enlaces para navegar a páginas relacionadas.

 

Tabla de contenidos

Otra técnica es utilizar una tabla de contenidos, que consiste en un índice con las secciones y subsecciones de una página, y que proporciona un acceso directo a una sección específica. Para más información sobre ello, se puede consultar la técnica G64: Proporcionar una tabla de contenidos.

Otras técnicas para sitios pequeños

Si el sitio es pequeño se pueden aplicar otras técnicas:

  • el menú de navegación incluye el acceso a todas las páginas del sitio.
  • todas las páginas están enlazadas desde la página de inicio.

Técnicas relacionadas:

 

Ubicación del usuario

Un requisito muy importante que hará que el sitio web sea más accesible es facilitarle la ubicación a los usuarios, proporcionarle inforción sobre dónde se encuentran.

Para ello, esta el criterio 2.4.8 Ubicación: se proporciona información acerca de la ubicación del usuario dentro de un conjunto de páginas web.

Hay varias técnicas para conseguir esto:

Migas de pan.

Las migas de pan van a ayudar a:

  • Comprender cómo se estructura el contenido de un sitio web.
  • Navegar por las páginas visitadas
  • Identificar la ubicación actual de una página dentro del sitio web.

¿Qué requisitos deben cumplir las migas de pan?

  • Deben estar siempre situadas en el mismo lugar en todas las páginas.
  • Maquetarlas mediante listas, aunque visualmente se presenten en línea.
  • Usar separadores visuales entre las mismas.
  • Deben ser enlaces.
  • Deben indicar el camino usado para llegar a la página actual o bien indicar su situación en la jerarquía u organización del sitio.

 

Indicar la situación actual en la navegación

Otra técnica para facilitar la ubicación del usuario es indicar la situación actual en menús, barras de navegación, pestañas o pasos en un proceso. Todo cambio que se produzca se debe comunicar a los usuarios.

Por eso, el menú o paso en el que nos encontramos no solo se debe indicar visualmente, sino también estructural y semánticamente o mediante texto si fuera necesario como establece el criterio 1.3.1 Información y relaciones. Se puede obtener más información sobre este requisito en la técnica G128: Indica la ubicación actual dentro de las barras de navegación.

 

Elemento <link>

Otra técnica es incluir navegación semántica a través del elemento link

<head><title>Capítulo 2</title>
<link rel="index" href="index.html“ title="Índice" />

<link rel="start" href=“intro.html“ title="Introducción" />

<link rel="next" href=“cap3.html“ title="Capítulo 3" />

En este ejemplo estamos indicando, dentro de una colección de páginas: el índice, la primera página de la colección y la siguiente.

La ventaja de usar <link> para establecer las relaciones es que este elemento se puede interpretar mediante software. Se puede ampliar información en la técnica H59: Uso del elemento de enlace y las herramientas de navegación.

 

Consistencia

Otro aspecto que hace más accesible la navegación es la consistencia, tanto en la presentación y maquetación de los mecanismos de navegación, como en la identificación de los componentes que tienen la misma funcionalidad dentro de un conjunto de páginas

  • 3.2.3 – Navegación coherente
  • 3.2.4 – Identificación coherente

Navegación coherente

Si los mecanismos de navegación que se repiten en diferentes páginas de un conjunto (como el buscador, el menú de navegación, las migas de pan, etc), se presentan en el mismo orden en las diferentes páginas del conjunto, los usuarios pueden predecir dónde estarán en cada página y localizarlos con más facilidad. Para más información se puede consultar la técnica G61.

Identificación coherente

Tan importante es la navegación coherente, como la identificación coherente, porque si en un sitio web se usan diferentes etiquetas para una misma función se dificulta considerablemente la comprensión y la interacción con el sitio, y en definitiva su uso.

Identificación coherente quiere decir, en los enlaces, que aquellos que tienen un mismo destino tienen el mismo texto de enlace.

Por ejemplo, si el destino del enlace es la página de inicio del sitio, el texto del enlace no puede ser unas veces “Ir a la home”, en otras “Ir a la página de inicio” y en otras “Ir a la página principal”.

El texto del enlace además deberá ser consistente con el título de la página, el nombre con el que se identifica a la misma en las migas de pan o en el mapa del sitio.
En el caso de destinos similares, los textos de enlace deberán ser consistentes.

Por ejemplo, en un portal de noticias, el texto del enlace para ampliar información sobre cada noticia, no puede ser en un caso “Más información”, en otro “Leer más” y en otro “Más info”.

La identificación coherente también se aplica al texto alternativo de los elementos no textuales.
Por ejemplo, si se usa el mismo icono en diferentes páginas, se entiende que con la misma función, debe tener el mismo texto alternativo, si tenemos un icono para descargar un fichero, su texto alternativo no puede ser en unos casos “descargar”, en otros “guardar” y en otros “bajar”.

Y la identificación coherente se aplica también a las etiquetas de los campos de formulario: los mismos controles de formulario deben estar etiquetados igual.

Por ejemplo, no podemos etiquetar el campo contraseña en unos casos como “password”, en otros como “contraseña” y otros como “clave”.

 

Accesibilidad web: Problemas con el foco de teclado

En esta entrada voy a hablar de un problema bastante habitual en los sitios web. Hay personas que navegan por un sitio web a través de teclado, porque no ven. Al carecer de visión no pueden llevar a cabo el manejo del ratón y la visualización de la pantalla para poder dirigir el puntero.

 

Accesibilidad web: Problemas con el foco de teclado

Navegación por el sitio web a través de teclado

Para muchas personas este el único medio que tienen poder acceder a los sitios web:

  • Personas que usan un lector de pantallas o teclado braille.
  • Personas con diversidad funcional física o motriz, que pueden usar:
    • teclados alternativos.
    • Licornios, punteros de cabeza o apuntadores de boca para interactuar con el teclado.
    • Pulsadores de soplado que simulan la navegación por teclado.
  • Usuarios expertos que se manejan más rápido por teclado que con el ratón.
  • Personas que usan un portátil, que prefieren la navegación por teclado, o cuando existe un problema que impide usar el ratón.

Accesibilidad por teclado

Las WCAG 2.0 tienen varios criterios que hacen referencia a la operabilidad de los sitios web mediante el teclado.

teclado

2.1 Accesible por teclado

  • 2.1.1 Teclado Toda la funcionalidad del contenido es operable a través de una interfaz de teclado sin que se requiera una determinada velocidad para cada pulsación individual de las teclas, excepto cuando la función interna requiere de una entrada que depende del trayecto de los movimientos del usuario y no sólo de los puntos inicial y final. (Nivel A)
  • 2.1.3 Teclado (sin excepciones): Toda la funcionalidad del contenido se puede operar a través de una interfaz de teclado sin requerir una determinada velocidad en la pulsación de las teclas. (Nivel AAA)

 

Problemas con el foco de teclado

Hay varios problemas que impiden la navegación por los sitios web y que están relacionados con el foco de teclado. Estos problemas son:

  • El foco no está visible
  • El orden del foco no tiene sentido
  • Las páginas tienen trampas para el foco
  • Recibir el foco provoca automáticamente un cambio de contexto sin avisar al menos previamente al usuario.

1. El foco no está visible

Por defecto, cuando un enlace coge el foco aparece punteado alrededor.  O cuando un campo de formulario coge el foco también se aprecia visualmente, es decir, muestra un cursor parpadeando en su interior. El criterio de conformidad que recoge este problema es el 2.4.7 Foco visible.

El problema está en que hay sitios web en los que por razones estéticas, el foco no se encuentra visible, lo cual dificulta la navegación a muchos usuarios. Por lo tanto, el foco debe estar visible en todo momento.

El foco puede resaltarse con un borde más sólido y de color. Y usarse con la pseudoclase :hoveren la CSS y así resalta también con la interacción mediante ratón.

 

2. El orden del foco no tiene sentido

Otro de los problemas es que el orden del foco no tenga sentido. Por eso, es muy importante que el orden del foco sea el correcto, tal y como establece el criterio 2.4.3 de las WCAG 2.0.

Por ejemplo, si un enlace abre un menú desplegable, el siguiente elemento que debería coger el foco sería el primer elemento del menú.

No  sólo es necesario que el orden de lectura sea lineal y tenga sentido, sino también que el orden del foco por los elementos de interacción también lo tenga. De igual manera ocurre con el atributo global tabindex.

 

3. Trampas para el foco

El tercer problema que nos encontramos son las trampas para el foco. Son aquellas zonas a las que no podemos llegar mediante teclado, como son las ventanas modales o cuadros de diálogo, los controles de un reproducción de un vídeo o una animación en Flash. En estas interacciones sólo se puede volver atrás o ir a otra parte mediante el ratón.

Tal y como se puede leer en el criterio de conformidad 2.1.2 Sin trampas para el foco de teclado, vamos a seguir con el ejemplo del menú desplegable.

Si una vez que abrimos el menú, navegamos con la tecla TAB, y por cualquier razón no podemos volver a salir con el teclado, se consideraría una trampa para el foco.

 

4. Recibir el foco provoca un cambio de contexto

Otro de los problemas que se pueden dar es cuando se produce un cambio de contexto y reciben el foco sin advertir previamente al usuario.

Los cambios de contexto deberían producirse cuando el usuario realiza una acción, que normalmente se utilice para solicitar un cambio de contexto, como hacer clic en un enlace o un botón.

Los cambios inesperados en el contexto o que no puedan detectarlos pueden desorientar a los usuarios.

¿Qué es un cambio de contexto?

Es un cambio importante en el contenido de la página, que cuando se hace sin el consentimiento del usuario, puede desorientar a quienes no pueden ver la página o no pueden ver toda la página al mismo tiempo.

Esto incluye cambios en:

  • El agente de usuario. Como abrir un gestor de correo o un lector de PDF.
  • El foco: Mover automáticamente el foco a otro elemento. Una mala práctica muy habitual en los formularios es mover el foco de un control a otro automáticamente, por ejemplo al rellenar los campos de una cuenta bancaria. También es una mala práctica habitual utilizar  onfocus="blur()"para quitar el foco a un elemento cuando lo recibe.
  • El área de visualización del contenido: abrir otra ventana, otra pestaña o cambiar de marco.
  • El contenido. Cambios en el contenido que cambian el significado de la página: enviar un formulario, ir a otra página, o que lo parezca porque se cambia el orden del contenido de la misma.

Los criterios relacionados con este problema son:

3.2.1 Al recibir el foco

3.2.2 Al recibir entradas

3.2.5 Cambios a petición