Accesibilidad web: Diversidad funcional auditiva.

 

diversidad funcional auditiva

Para hablar de accesibilidad auditiva en la web, lo primero que vamos a hacer es remitirnos a la Ley 27/2007, de 23 de octubre, por la que se reconocen las lenguas de signos españolas y se regulan los medios de apoyo a la comunicación oral de las personas sordas, con discapacidad auditiva y sordociegas, que en su disposición adicional duodécima establece:

Disposición adicional duodécima. Lenguas Oficiales.

Las Administraciones Públicas deberán fomentar el pluralismo lingüístico en la utilización de las nuevas tecnologías de la Sociedad de la Información, en particular en los ámbitos territoriales en que existan lenguas propias.

También hay que decir que, desde que entró en vigor la Lengua de Signos Española (LSE), el 24 de ocubre de 2007, también está equiparada a cualquier lengua del Estado.

En su artículo 14 establece lo siguiente:

Artículo 14

1. Los poderes públicos promoverán las medidas necesarias para que los medios de comunicación social, de conformidad con lo previsto en su regulación específica, sean accesibles a las personas sordas, con discapacidad auditiva o sordociegas mediante la incorporación de las lenguas de signos españolas.

2. Asimismo, los poderes públicos adoptarán las medidas necesarias para que las campañas de publicidad institucionales y los distintos soportes audiovisuales en los que éstas se pongan a disposición del público sean accesibles a estas personas.

3. Se establecerán las medidas necesarias para incentivar el acceso a las telecomunicaciones en lengua de signos española.

4. Las páginas y portales de Internet de titularidad pública o financiados con fondos públicos se adaptarán a los estándares establecidos en cada momento por las autoridades competentes para lograr su accesibilidad a las personas sordas, con discapacidad auditiva y sordociegas mediante la puesta a disposición dentro de las mismas de los correspondientes sistemas de acceso a la información en la lengua correspondiente a su ámbito lingüístico.

Una vez visto esto, vamos a explicar la importancia de comprender lo que necesitan las personas con problemas auditivos.

A este tipo de usuarios, al tener déficit auditivo les cuesta comprender el habla en la comunicación y por lo tanto, el proceso de la información.

Por ello, a la hora de diseñar webs se han de tener en cuenta varios aspectos.

¿Cómo diseñar sitios web para personas con dificultades auditivas?

Las tareas cognitivas a tener en cuenta son las siguientes.

Tarea de búsqueda visual

Consiste en buscar información o elementos en la pantalla. En las búsquedas visuales que implican palabras, por ejemplo en un menú, los sordos tienen dificultades.

En este caso, es importante apoyar las palabras con iconos cuando se pueda. Y si no se puede, tenemos que tener en cuenta su vocabulario para facilitarles las cosas. Hay que exponer o formular palabras para unas determinadas acciones, y usar esas palabras.

Tareas de atención dividida

Las páginas web tienen mucha información que se nos presenta de golpe, y hay que procesarla de manera concurrente, es decir, dividiendo nuestra atención.

Para conseguir este objetivo, primero hay que saber cómo se procesa la información las personas sordas. Para ello, tenemos que conocer el principio de compatibilidad estímulo/código de procesamiento.

En primer lugar, para entender mejor de qué hablamos, vamos a explicarlo.

En la web hay diferentes formatos en los que se puede presentar la información:

  • Por palabras escritas, para la construcción de textos o artículos de investigación.
  • Mediante habla, insertando vídeos grabados, un sistema de lectura de voz, o un audio.
  • Sonidos e imágenes.

 

Las personas oyentes tenemos dos códigos para procesar la información: El verbal y el visoespacial. El verbal con las palabras escritas y el habla, y el visoespacial con los sonidos y las imágenes.

Sin embargo, las personas sordas procesan la información con las palabras escritas y las imágenes, es decir, su procesamiento quedaría reducido por sus limitaciones. Sólo accederían a la información mediante texto e imágenes.

Tareas de navegación

Las personas, cuando tienen algún tipo de limitación, siempre desarrollan capacidades para sacar provecho de lo que tienen. En el caso de las personas sordas tienen muy desarrolladas las habilidades visoespaciales, por lo que son mejores a la hora de navegar.

La tarea de navegación es una tarea espacial, tanto de percepción como de memoria, ya que se pueden recordar los pasos hasta donde se ha llegado: Volver atrás, seleccionar enlaces, etc. Sin estas habilidades visoespaciales las personas sordas se desorientan.

Por todo esto, se recomienda poner mapas web, que les son de de gran ayuda.

Tareas de lectura y comprensión de textos

Las personas sordas tieen problemas con la lectura, ya que ellos se comunican con la lengua de signos. Por ello, al diseñar para estas personas hay que tener en cuenta varias cosas:

  • Escribir directamente lo que se quiere decir, sin exceso de palabras.
  • Usar un vocabulario familiar.
  • Enumerar y separar las instrucciones y los procesos.
  • Resaltar puntos y palabras claves en negrita.
  • Evitar oraciones subordinadas, artículos y pronombres.
  • Evitar las frases negativas.

Tareas de manejo de ratón y escritura

La tarea del manejo del ratón es una tarea sencilla porque lo manejan igual que las personas oyentes. Por otro lado, la escritura les es un poco más difícil. Si a eso le añadimos que no tienen la posibilidad de aprender la gramática y el vocabulario es mucho más complicado.

A la hora de diseñar para una persona es más fácil activar una casilla de verificación que escribir un comentario.

Tecnicas SMIL

En las WCAG 2.0, existen unas técnicas que se utilizan para describir presentaciones multimedia, es decir, combinar texto con imágenes, audio y vídeo. Son las técnicas SMIL.

Las personas con sordera total necesitan de la lengua de signos para comunicarse. Las técnicas SMIL establecen los criterios relacionados con los audios y vídeos.

Los criterios de accesibilidad a tener en cuenta para llevar a cabo estas técnicas son:

1.2.2 Subtítulos (grabados)

1.2.4 Subtítulos (en directo)

1.2.3 Audiodescripción o Medio Alternativo (grabado)

1.2.5 Audiodescripción (grabada)

1.2.7 Audiodescripción ampliada (grabada)

 

1.2.6 Lengua de señas (grabada)

SM13: Proporcionar interpretación en lengua de señas a través de una pista de vídeo sincronizada mediante SMIL 1.0

SM14: Proporcionar interpretación en lengua de señas a través de una pista de vídeo sincronizada mediante SMIL 2.0

Lengua de Signos

La Lengua de Signos no es universal, por lo que debe adaptarse al público en cuestión.

En los vídeos, se tienen que ver los brazos, las manos y los gestos del cuerpo para que la conversación se interprete y resulte legible. Es preferible que sea una persona/intérprete a un avatar.

Pero también existe una herramienta muy buena para hacer un poco más accesibles los vídeos para las personas sordas. Se trata de la herramienta TextoSign, qiue es un traductor automático de texto a Lengua de Signos, Se pueden exportar a vídeo y se pueden integrar en los sitios webs.

Para finalizar, tengo que mencionar que en España existen alrededor de un millón de personas sordas, de las cuales cuatrocientas mil usan lengua de signos. En España sólo hay un intérprete de signos por cada 221 personas sordas. En otros países europeos, la proporción es un intérprete por cada diez personas sordas.

Aquí se ve de manera clara el gran problema que tienen las personas sordas a la hora de acceder a la web, y a la información.

Subtítulos

Para las personas sordas o con problemas de audición, los subtítulos son muy importantes.

El subtitulado para personas sordas no solo debe transcribir el diálogo o la narración, sino también la información importante como los efectos de sonidos: ruido, risas, etc.

Cuando en el vídeo hablan dos o más personas se debe distinguir a los hablantes, utilizando un color para cada personaje, y mantenerlo.

Para evitar confusiones entre los personajes y que la conversación no se pueda diferenciar por etiquetas o por colores, es recomendable poner guiones. También se pueden distinguir poniendo entre paréntesis el nombre de la persona.

Los subtítulos pueden ser abiertos, es decir, que estén siempre disponibles. o pueden ser cerrados, que pueden ser activados o desactivados por los usuarios.

Transcripciones

Las transcripciones son también importantes para todas aquellas personas que no puedan seguir los subtítulos y necesiten leer el texto sobre lo que dice más detenidamente y a su ritmo.

Puede presentarse simultáneamente con el contenido audiovisual o de manera independiente.

 

Entradas relacionadas:

Se puede leer más información sobre la diversidad funcional auditiva en la entrada: “Accesibilidad web: Confederación Estatal de Personas Sordas”

 

Acccesibilidad web: ¿Cómo hacer formularios accesibles?

Hace unos días hablé sobre consejos para llevar a cabo la accesibilidad web en WordPress, y comenté que había que hacer los formularios accesibles.

El tema de los formularios es muy amplio, por eso he decidido hacer una entrada dedicada a ello.

formularios accesibles

Para hacer formularios accesibles hay que saber etiquetar correctamente los controles del formulario. Para ello, hay que respetar la semántica, que es lo que va a permitir que los campos sean accesibles.

Campos de formulario

Cada campo de formulario está asociado a un control, que determinará qué tipo de campo es.

Para establecer la relación entre la etiqueta y el control del formulario, tal y como indica la técnica H44, hay que asociarla con el atributo forcuyo valor debe ser igual al id del control del formulario. Sólo una etiqueta puede estar asociado a cada elemento de forma única, el id debe ser único en la página.

Campos de tipo Texto:

<label for="name" > Nombre (obligatorio) </label>
<input type="text" name="nombre" id="name"

El elemento label debe usarse con los elementos <textarea> <select> y los inputs de tipo "text", "checkbox", "file" y "password."

El elemento label no debe usarse con los input de tipo imagen, porque estos se etiquetan con el atributo alt, como indica la técnica H36.

Tampoco debe usarse en los input de tipo "submit" o "reset", los cuales se etiquetan con el atributo value.

<input type="submit" name="Enviar" value="Enviar" / >

Tampoco se usa con el elemento "button", donde ya se usa el contenido como etiqueta.

<button type="submit" name="Enviar">Enviar</button>

Tipo textarea: Es la caja que aparece cuando vamos a envíar un formulario y escribimos nuestra consulta o dudas al respecto.

<label for="address">Pon tu dirección:</label><br />
<textarea id="address" name="addresstext"></textarea>

Campos con opciones: Para establecer campos donde se den opciones a elegir, a la hora de hacerlos accesibles es necesario contar con dos etiquetas, para que los campos sean reconocidos por los dispositivos de apoyo, como el lector de pantallas. Estas etiquetas son: <fieldset></fieldset>, que nos servirá para agrupar los elementos dentro del campo. Y usar la etiqueta <legend></legend> para poner un título al campo.

Para trabajar los campos con opciones existen dos tipos: de tipo checkbox, y de tipo radio.

Tipo checkbox: Estos campos permiten seleccionar más de una opción a la hora de elegir.

<fieldset>
<legend> Selecciona el tipo de envío </legend>
<p><label> <input type="checkbox" name="deliverytype" value="urgente" checked > Urgente </label></p>
<p><label> <input type="checkbox" name="deliverytype" value="acuse" > Acuse </label></p>
<p><label> <input type="checkbox" name="deliverytype" value="contrareembolso" > Contrareembolso </label></p>
</fieldset>

Y el otro tipo de campo de opciones es el de tipo radio. Se usa igual que el del tipo checkbox, pero hay que que especificar que es de tipo radio. Este tipo de campos sólo permite marcar una sola opción a la hora de elegir.

<fieldset>
<legend> Selecciona una prioridad </legend>
<p><label> <input type="radio" name="priority" value="baja" checked > Baja </label></p>
<p><label> <input type="radio" name="priority" value="media" > Media </label></p>
<p><label> <input type="radio" name="priority" value="alta" > Alta </label></p>
</fieldset>

El uso de estas etiquetas viene especificada en la técnica H71 de las WCAG 2.0.

Campos de selección: Asociar la etiqueta <label></label> para el título del grupo y el campo (select) para agrupar las opciones, y (option) para poner cada uno de los valores a seleccionar.

<label for="favteam">Elige tu equipo favorito:</label>
<select id="favteam" name="select">
<option value="1">Real Madrid CF</option>
<option value="2">FC Barcelona</option>
<option value="3">Atlético de Madrid</option>
<option value="4">Valencia CF</option>
<option value="5">Sevilla FC</option>
<option value="6">R. Betis Balompie</option>
<option value="7">Málaga CF</option>
<option value="8">RC Deportivo de La Coruña</option>
<option value="9">RCD Espanyol</option>
<option value="10">Villareal CF</option>
</select>

En la técnica H89, se especifica que hay que usar el atributotitle que sirva como ayuda a la hora de rellenar el formulario.

<label for="direccion">Dirección</label>
<input id="direccion" 
title="Address example: 101 Collins St, Melbourne, Australia" name="direccion" size="30" type="text" value="" />

En la técnica H90 se especifica que hay que indicar los controles de formulario que es obligatorio rellenar y para una buena presentación, en los campos que sean obligatorios, es preferible poner un texto antes del campo, en vez del asterisco.

Formulario con texto adyacente

Hablando de campos obligatorios, la técnica ARIA2, establece que los campos obligatorios hay que identificarlos con la propiedad aria-required.

   <label for="fname">First name: </label>
    <input type="text" id="fname" aria-required="true" />
    [required]

Otra técnica que se puede usar y es muy importante es la técnica H85, que establece la importancia del elemento optgroup, que permite agrupar las diferentes opciones (options) dentro de un campo (select)

<label for="food">¿Cuál es tu comida favorita?</label>
<select id="food" name="food">
<optgroup label="Frutas">
<option value="1">Manzanas</option>
<option value="3">Plátanos</option>
<option value="4">Peras</option>
<option value="5">Naranjas</option>
</optgroup>
<optgroup label="Verduras">
<option value="2">Zanahorias</option>
<option value="6">Pepinos</option>
<option value="7">Lechuga</option>
</optgroup>
<optgroup label="Productos de panadería y confitería">
<option value="8">Tarta de manzana</option>
<option value="9">Pastel de chocolate</option>
<option value="10">Merengue</option>
</optgroup>
</select>

Otra técnica a tener en cuenta es la G205, que establece que no se debe poner un formulario basado en el color, ya que puede dar problemas de accesibilidad a muchos usuarios, principalmente a personas que tengan problemas de ceguera al color.

Por otro lado, en la técnica G89, se explica que para evitar errores, hay que indicar a los usuarios qué tipo de formato deben aplicar. Por ejemplo, en un campo de tipo fecha:

<label for="date">Fecha (dd-mm-yyyy)</label>
<input type="text" name="date" id="date" />

Cuando en algunos casos no se pueda usar el elemento label, las WCAG 2.0 permiten utilizar el atributo title para etiquetar los controles del formulario e identificar su propósito. Este es el caso de los campos en los que hay que introducir datos por partes, como una fecha o un número de cuenta, tal y como indica la técnica H65.

<fieldset>
<legend>Fecha de nacimiento(dd/mm/aaaa):</legend>
<input type="text" id="dia" name="dia"
title="Día (dos dígitos)"/> /
<input type="text" id="mes" name="mes"
title="Mes (dos dígitos)"/> /
<input type="text" id="año" name="año"
title="Año (cuatro dígitos)"/>
</fieldset>

En la técnica G5, se especifica que no hay que poner límite de tiempo a los usuarios para rellenar los formularios. Y en el caso de que exista ese límite, poner un mecanismo para los usuarios puedan ampliar el tiempo, como establece las técnica G133.

También en la técnica G162, se indica cómo deben ser colocadas las etiquetas de los campos. Se indica que se deben colocar encima del campo o a la izquierda del campo, con los elementos textarea y select y con los input de tipo: "text","checkbox", "radio", "file" y "password".

En la técnica G167, se especifica la utilización de un botón al lado del campo del formulario para definir su finalidad, como es el caso del cuadro de búsqueda. En este caso, este campo identifica una región de una página, landmarks roles (o puntos de referencia), por lo que hay que usar el rol ARIA correspondiente para que sea detectado por los dispositivos de apoyo.

<div role="search">
<label for="busqueda">
<input id="busqueda" type="text"></label>
<button type="submit">Buscar</button>
</div>

Es muy importante tener en cuenta los Roles ARIA.

En la técnica H84 especifica que cuando tenemos que elegir entre varias opciones para navegar a una página diferente, hay que poner un botón para que el usuario lo elija libremente.

<label for="idioma">Selecciona un idioma</label>
<select name="idioma" id="idioma">
<option value="1">Español</option>
<option value="2"> Italiano</option>
<option value="12">Inglés</option>
</select>
<input type="button" name="submit" value="Cambiar de idioma">

Por todas estas razones, es importante tener en cuenta la accesibilidad de los formularios, para facilitar la vida a muchas personas.

Pero también existen otras opciones para aquellas personas que no se atrevan a usar código, lo pueden hacer mediante un plugin. Normalmente en WordPress, para establecer un formulario de contacto usamos el plugin Contact Form 7, pero lamentablemente los campos no son accesibles por defecto.

Para solucionar este problema, tenemos que instalar el plugin Contact Form 7 Accessible Defaults. Este plugin sí tiene los campos accesibles por defecto.

 

Entradas relacionadas:

Si quieres tener más información acerca de los formularios puedes leer la entrada “Usabilidad web: Cómo hacer formularios usables?”

Y si quieres aprender más sobre ellos, lee la entrada Mensajes de error en los formularios”. Otra entrada interesante para leer es “Cómo hacer un buen uso del marcador de posición en los formularios.”

Accesibilidad web: Para quién se hace y qué beneficios aporta

Después de ver qué es la accesibilidad web, por qué es importante y cómo cumplirla vamos a ver la última parte de las cuatro grandes preguntas: ¿Para quién se hace? y veremos los beneficios que aporta.

¿Para quién se hace?

La accesibilidad en las webs se hace para todas las personas porque todos usamos la web. Hay que tener en cuenta que en España según el INE (Instituto Nacional de Estadística), somos cerca de 4 millones de personas, así que si quieres ampliar las visitas de tu web tendrás que pensar en las personas con diversidad funcional. Para ello, vamos a enumerar los cuatro grandes grupos diferenciados:

Diversidad Funcional Motriz: Personas con dificultad en los movimientos y para usar las manos, personas con espasmos musculares, así como problemas de habla.

Algunas diversidades funcionales motrices son: la  atrofia muscular, la Parálisis Cerebral Infantil, Parkinson, Esclerosis Lateral Atrófica, Espina Bífida, Esclerosis Múltiple, etc.

A muchas de estas personas, entre las que me incluyo, les cuesta manejar el ratón y el teclado.

Diversidad Funcional Auditiva: Hay personas que tienen pérdida auditiva, por lo que para comunicarse y vivir en sociedad necesitan unos audífonos. Y también hay personas con sordera total que se comunican mediante la lengua de signos.

Diversidad Funcional Visual: Hay personas que tienen problemas de visión, que puede ser de múltiples formas:

  • Baja visión. Hay miles de problemas de visión, como la presbiscia, el daltonismo, visión nocturna, retinosis pigmentaria, degeneración macular…
  • Ceguera total. Personas con visión nula. Estas personas en su día a día para acceder a la web utilizan lectores de pantalla y/o magnificadores de pantalla para navegar por la web. Hay personas que usan estos dispositivos de apoyo y prefieren leer la web impresa, por tanto, tiene que haber una opción para poder imprimirla.

Diversidad Funcional Intelectual: Personas que presentan dificultades a nivel cognitivo, como las personas afectadas por dislexia, Sindrome de Down, afasia, autismo, etc.

Es por esto, que a la hora de diseñar siempre hay que pensar en las preguntas claves.

Preguntas claves para llevar a cabo la accesibilidad web

  • ¿Para quién vamos escribir?

Tienes que pensar que hay un porcentaje de usuarios que acceden a tu web, que tienen diversidad funcional y que son (somos) clientes potenciales para tu web, blog o negocio. Con lo cual es importante que escribas para tu público en función de los objetivos de tu empresa.

  • ¿Entenderá lo que escribo?

Es muy importante escribir de una manera sencilla y clara. Hay personas que tienen dificultades en la compresión de la lectura y es importante tenerles en cuenta. Hay que cuidar a las personas que nos leen.

  • ¿Tendrá problemas con el color?

Hay personas daltónicas, las cuales les cuesta distinguir los colores. Debido a su problema de visión, tienen más difícil poder percibir el contenido si no se usan los colores de la manera adecuada para ellos.

  • ¿Y el tamaño de la letra?

Esta pregunta tiene mucha relación con la pregunta anterior. Hay personas que sufren de un problema de ceguera grave, que si no lo tenemos en cuenta, es un problema. Es importante poner una tipografía legible y un tamaño de letra adecuado, de acuerdo a las WCAG 2.0.

  • ¿Escuchará los vídeos?

Este es uno de los problemas más graves que las personas con diversidad funcional auditiva tiene. En este grupo me incluyo. Pensemos que cuando se publica un vídeo sin subtítulos perdemos la información importante del vídeo. Y los audios si no tienen una transcripción, la persona que te esté visitando se va.

Para ampliar más información, puedes leer la entrada “Accesibilidad web: Diversidad funcional auditiva.”

  • ¿Usará el ratón?

Hay muchas personas que debido a dificultades en sus manos o por problemas de visión no pueden llevan a cabo la interacción vista-mano. La solución para estos casos, es hacer las opciones accesibles mediante teclado.

Si sigues todas las pautas que te he contado, podrás llevar a cabo tu proyecto lo más accesible y usable posible, teniendo en cuenta las necesidades de las personas que visiten el sitio web.

Una vez establecidos los diferentes grupos y sus diferentes soluciones en accesibilidad web, vamos a ver qué beneficios nos aporta la accesibilidad web.

Una web accesible proporciona muchos beneficios:

  1. Mejora la usabilidad de la web para todo tipo de usuarios, porque si una web no es accesible no es usable, y por lo tanto, se originan problemas para un importante número de usuarios.
  2. Permite mejorar el acceso a los contenidos Web a las personas mayores, que se debe el deterioro de las condiciones físicas debido al envejecimiento y cuanto más fácil sea acceder para estas personas, mucho mejor. Y más, teniendo en cuenta que la población está envejeciendo.
  3. Mejora los resultados en los buscadores, es decir, mejora el posicionamiento SEO. (Search Engine Optimization).
  4. Incrementa el soporte para el mercado internacional. Se añaden subtítulos para los diferentes países, así como los contenidos, etc.).
  5. Ayuda a reducir la llamada brecha digital, permitiendo así que a un porcentaje de la población que no tengan conocimientos de las TIC (Tecnologías de la Información y de la Comunicación), puedan tener relación con ellas.
  6. Refuerza positivamente la imagen empresarial, lo que permite diferenciarse de la competencia dando acceso a tu web a un mayor número de personas (3,5 millones de personas en España demandan servicios y entornos accesibles). Y cada vez seremos más. Por ello es importante tenernos en consideración.
  7. Cumples con la legislación de accesibilidad:
    • Ley 34/2002, de 11 de julio de 2002, de servicios de la sociedad de la información y comercio electrónico (LSSICE).
    • RDL 1/2013 de 29 de noviembre de 29 de noviembre, por el que se aprueba el Texto Refundido de la Ley General de derechos de las personas con discapacidad y de su inclusión social.
    • Norma UNE 139803:2012 Requisitos de Accesibilidad para el Contenido Web
  8. Es mucho más fácil de usar y de actualizar, puesto que se disminuye el coste de desarrollo y mantenimiento, así como la carga de las páginas web: El coste de desarrollar y mantener una página web accesible es menor que frente a una no accesible, ya que una página web accesible es una página que no tiene errores, que está bien estructurada y que está bien hecha.

 

Ventaja importante de la accesibilidad web: la sonrisa de las personas

Una vez que te has parado a pensar en la felicidad de una persona al poder acceder a tu web, te pregunto:

¿Te hacen falta más razones para llevar a cabo la accesibilidad web en tu sitio?

Te animo a lo que hagas, porque es muy importante. La accesibilidad web nos beneficia a todos.