Accesibilidad Web, la guía definitiva

por

Cada vez más a menudo es fácil encontrarse con un requisito en nuestro proyecto que se llame Accesibilidad Web. Cada vez que vemos este requisito ocurren dos cosas: nos echamos a temblar y sabemos que vamos a sufrir.

¿A quien no le ha pasado esto? Otros sencillamente no sepáis de que estoy hablando y nunca os habréis encontrado este problema pero el día que os crucéis con él os acordaréis de mis palabras muahahah.

Ahora en serio, la Accesibilidad Web es algo complicado y tedioso ya que no existe una herramienta que nos valide un portal y nos diga si es o no accesible. Hay muchos puntos "Automáticos" como que el código esté bien formado que pueden se comprobados con algunas herramientas pero hay otros puntos que deben ser comprobados de forma manual.

Pues bien, lo que hoy os traigo es un recopilatorio de todas las experiencias que he conseguido acumular a lo largo de los años realizando Accesibilidad Web en numerosos portales de diferente índole.

Hoy en día, los requisitos de accesibilidad suelen verse cuando trabajamos para grandes clientes relacionados con la adminsitración pública aunque te los podrías encontrar en otros casos.

Actualmente se trabaja con las WCAG 2.0 y existen 3 grados de cumplimiento: A, AA y AAA. Para que os hagáis una idea, cummplir el nivel A es relativamente sencillo, el AA es el más habitual que nos pedirán y la cosa ya empieza a complicarse pero si llegamos al nivel AAA olvidaros de hacer nada porque es totalmente imposible en un proyecto normal y moderno llegar a cumplirla. Como ya os digo, lo habitual es que se pida AA, yo nunca me he encontrado con un nivel AAA.

¿Qué beneficios consigo si hago mi portal Accesible?

Podemos pensar que la accesibilidad es algo sólo beneficia a los usuarios discapacitados y que a nosotros no nos va a aportar nada ya que la cuota de mercado es muy pequeña en comparación con el resto de usuarios pero no es así. Cumplir la Accesibilidad Web nos va a permitir generar un código mucho más robusto y por consiguiente una mejor aplicación. Si cada miembro se acostumbra a realizar código accesible, respetando las normas de la W3C los portales resultantes, aunque no tengan que ser accesibles, serán mucho mas robusto y usables.

Si te acosumbras a generar código HTML accesible te saldrá sólo sin necesidad de hacer una segunda vuelta para hacer accesible un portal.

Y después de este rollo que os acabo de contar ¡vamos al turrón!

Todos los puntos que a continuación os cito y explico son,, desde mi punto de vista lo que deberíamos cumplir principalmente para pasar una certificación de Accesibilidad.

1.El portal debe ser navegable mediante teclado

Debe ser posible navegar a través del portal utilizando única y exclusivamente el teclado de un ordenador. La navegación debe ser ordenada y esperada, es decir, no puede haber saltos inesperados. A través de la tecla TAB debemos ser capaces de navegar a través de los diferentes elementos activos del portal. A lo sumo, se podría utilizar también las flechas de dirección aunque se reservarían para casos más específicos. Además, el usuario debe saber en todo momento en que elemento está el foco, ya sea remarcándolo con un borde punteado o cualquier otro tipo de marca visible.

Aquellos elementos que al ser pulsados o al pasar por encima del ratón(o cualquier otro tipo de evento) realizan algún tipo de acción también deben ser tabulables. Para ello es necesario añadirle el atributo tabindex=0 en su definición. Por ejemplo:

	
Aceptar

CONSEJO: desconectad el ratón e intentadnavegar por todo el portal solo con teclado, activa elementos, interactua con todo lo que puedas y si encuentras algo que deberías poder activar y no eres capaz entonces es que tienes un problema. También piensa en la rapidez de navegación, si por ejemplo tienes en tu menu principal un montón de opciones y para llegar del primer elemento al último hace falta tabular por todos y cada uno de los padres e hijos entonces tienes un problema de usabilidad, SI de usabilidad.

2.Todo elemento clicacle debe poder activarse también con ENTER

Todo elemento sobre el que podamos hacer click y active una acción(redirección, apertura de popup, tooltip, etc) debe poder activarse situándose sobre él con TAB y presionando la tecla ENTER. El resultado final debe ser el mismo que si hubiésemos hecho click. Esto se puede lograr a través de jQuery(si disponemos de la librería) con el evento keyup. Por ejemplo:

	$(document).ready(funtion(){

		$('.boton').keyup(function(e){

		   if(e.which == 13) {
			   abrirpopup();
		   }

		});
	});

Adicionalmente a que sea clicable, si un elemento al pasar por encima de él con el ratón o realizar cualquier otro tipo de evento activa una acción será necesario que dicha acción también sea posible realizarla a través de la navegación por teclado utilizando los eventos de keyup, keydown, focus, etc...

3.Enlaces

Todo enlace(a) debe tener su atributos title y href(detectable por las herramientas automáticas) y además, el texto de este atributo title debe describir de forma explícita la acción que conlleva el pulsar ese enlace. Se debe tener en cuenta también si dos enlaces tienen el mismo texto en un diseño no basta con que se diferencien por el texto del title sino que debe mostrarse un texto oculto dentro del enlace que explique exactamente lo que ha a hacer el enlace al ser pulsado.

Ejemplo 1

	Ver másinformación del artículo 1
	Ver másinformación del artículo 2

En el ejemplo 1 se muestran 2 enlaces que pertenecen a un listado de noticias en las que siempre se ve junto a cada noticia un Ver más. Visualmente se debe mostrar ese texto pero se ha añadido un texto adicional englobado por un para que SOLO sea leído por los lectores de pantalla que permite contextualizar que acción va a llevar a cabo si se pulsa sobre él. Sino un usuario ciego sólo vería varios enlaces con el mismo texto y no sabría a qué artículo hace referencia cada enlace, sobretodo si utiliza la herramienta de listados de enlaces.

El CSS asociado a la class ocultaAccesibilidad es el siguiente:

	.ocultaAccesibilidad{
		left:-9999px;
		position:absolute;
		opacity:0;
	}

Recordemos que no se puede utilizar display:none ya que los lectores de pantalla ignoran todo elemento que esta en display:none.

Ejemplo 2

	Desplegar subcategorías de la categoría de productos deAlimentación

En este caso el enlace no redirecciona, sino que muestra un nuevo nivel de hijos de la categoría. Visualmente sólo muestra el nombre de la Categoría pero para los usuarios con lectores de pantalla detectará el texto oculto que les indicatá exactamente lo que ocurrirá si se activa ese accionador.

Ejempo 3

	Ir a la categoría de productos deElectronica

Por último, este ejemplo redireccionaría al detalle de una categoría de productos de Electrónica. Tanto el title como el texto completo del enlace es lo suficientemente explicativo para que una persona ciega, al situar su lector sobre este enlace sepa lo que va a ocurrir si lo pulsa y se garantiza el diseño original del portal.

3.1 Cambios de texto

Ya sean enlaces o labels asociados a inputs, cuando realizamos alguna acción como plegar/desplegar o activar/desactivar algo es necesario que el texto "oculto" de accesbilidad varie su texto para que ponga exactamente lo que va a ocurrir si se pulsa.

Si por ejemplo tenemos el código del Ejemplo 2 del punto anterior en el que tenemos un elemento desplegable, en el momento que un usuario pulsa sobre el enlace, el texto "Desplegar subcategorías de la categoría de productos de Alimentación" debe modificarse por "Plegar subcategorías de la categoría de productos de Alimentación" ya que ahora la acción que ocurriría si se pulsa es la de plegarse.

De esta forma indicamos exactamente el estado actual e indicamos lo que ocurrirá exactamente al ser pulsado.

4.Inputs

Todo elemento input debe tener asociado un verde o ,en su defecto, ha de disponer de un atributo title que funcione a modo de label. Quedan exentos de esta regla los elementos de tipo submit, image o hidden.

	

La asociación entre input y label se debe llevar a cabo mediante el ID único del input y el atributo for del label.

Aunque la norma establece que si un elemento no dispone de label basta con que tenga un title, en la práctica locertificadores de Accesibilidad no lo aceptan y es necesario aplicar la misma técnica que se aplicaba para los textos ocultos de los enlaces.

	

4.1 Legend

En ocasiones hay ciertos casos en los que es necesario agrupar los inputs para que tengan sentido en su conjunto. Supongamos que tenemos un formulario en el que aparece una pregunta del estilo ¿Desea recibir el folleto de nuestra tienda? con dos radio buttons asociados SI NO. Los radio button por separado no tienen sentido ya que son simplemente dos textos sin contexto por lo que es necesario relacionar estos campos con la pregunta original.

Para ello, se debe utilizar los elementos fieldset y legend para agruparlo todo de la siguiente forma:

	
¿Desea recibir el folleto de nuestra tienda?

4.2 Aviso de acciones ocurridas

Cada vez que se activa un elemento accionable se debe informar al usuario de lo que acaba de ocurrir mediante cambios de foco que solo será reconocidos por los lectores. Vamos a ver un ejemplo para entenderlo.

Supongamos que estamos en un listado de productos y tenemos un selecbox para ordenar los productos. Cuando nosotros seleccionamos una de las opciones(ordenar por precio más bajo por ejemplo) automáticamente se debe trasladar el foco de la acción a un elemento oculto que explique lo que acaba de ocurrir e inmediatamente devuelva el foco al punto anterior de tal forma que para un usuario normal es imperceptible pero los lectores de pantalla lo leen y avisan al usuario discapacitado que se acaba de ordenar el listado de productos por el precio más bajo.

	$("select.ordenar").change(function(){
		$('.aviso-cambio-select span').$(this).val();
		$('.aviso-cambio-select').focus();
		$(this).focus();
	});

HTML

	
Ahora los productos están ordenados por

Esto mismo debería ocurrir si activamos un checkbox o al añadir productos a un carrito(se debe informar de que se acaba de añadir el producto al carrito o que se ha aumentado en 1 o n unidades) por ejemplo.

5.Elementos hover

Existen diferentes elementos que al pasar por encima con el ratón realizan una acción(en general muestran una capa oculta con información). Debemos asegurar que además de pasar por encima con el ratón, al hacer focus sobre ese elemento mediante teclado realice la misma acción. Adicionalmente, se considera aceptable situarse sobre el elemento y que haya que pulsar ENTER sobre él para que muestre la capa siempre y cuando esto no implique un cambio de contexto, es decir que no te redireccione, por ejemplo, a otra página.

6.ID únicos

No esta permitido la repetición de IDs. Todo ID debe ser único.

7.Imágenes

Toda imagen debe disponer de un atributo ALT, además, el texto de este atributo ALT debe describir correctamente a la imagen salvo que la imagen sea totalmente de carácter visual, en este caso el ALT debería ir vacío. En caso de que una imagen represente datos importantes(por ejemplo, un organigrama) debe disponer de un atributo LONGDESC que describa el contenido de lo que se muestra en la misma.

Debemos tener en cuenta también el color aplicado a la letra del ALT de la imagen. Si bien es cierto que para un usuario normal no le afectará, se debe tener en cuenta que cuando se muestra el Alt, el color de fondo del bloque que ocupa la imagen debe contrastar con el color del texto para que sea legible.

Otra cosa que se debe tener en cuenta es que cuando una imagen está dentro de un enlace y su ALT(el de la imagen) ha sido rellenado con una descripción detallada de la imagen(por ejemplo de un producto), si dentro del enlace existe otro texto similiar que describe la imagen o hace referencia a lo mismo que dice el texto de la imagen el ALT de la imagen deberá ir vacío ya que sino la herramienta de listador de enlaces, al leer ese enlace, leerá dos veces el mismo texto.

8.Estilos en línea y HTML

No esta permitido que existan estilos en línea salvo para aquelllos elementos que se generan de forma dinámica o que la propia herramienta de gestión de contenidos incluye. En cuanto al HTML sólo se pueden utilizar aquellos componentes HTML que no están descatalogados o desaconsejados por las W3C.

9.Foco

Cuando utilizamos un portal o una aplicación suele suceder diferentes eventos que trasladan el foco visual(que no el programado) de las acciones a otro elemento(por ejemplo un popup). Cuando esto ocurre, un usuario normal no tiene problema en pulsar con el ratón sobre el nuevo elemento para acceder a él, independientemente de donde se haya situado pero para las persona discapacitadas esto no ocurre así.

Es necesario que cuando se producen eventos que conlleven un cambio en la navegación(apertura de un popup por ejemplo), el foco de la acción se situe sobre el primer elemento accesible de la nueva navegación y además la navegación no pueda salirse de ese elemento(en caso de ser un popup por ejemplo).

Por ejemplo: supongamos que tenemos un botón que al ser pulsado(ya sea con click o con enter) abre un popup con un formulario, automáticamente en ese momento el foco de la acción debe situarse sobre el primer input del formulario. Esto permitirá a las personas que utilizan una navegación por teclado que sigan una navegación ordenada y no tengan que buscar haciendo tab por todo el portal el popup.

9.1 Limitar la navegación

Se debe limitar la navegación cuando el foco de la acción se situa sobre elementos nuevos que tiene entidad propia. Utilizando el mismo ejemplo del punto anterior, si situamos el foco sobre un popup no debemos permitir al usuario abandonar el popup haciendo tab salvo que pulse sobre el correspondiente boton de Aceptar/Cancelar o la X de cerrar el popup.

10.Errores

Es habitual que cuando un usuario rellena un formulario, por ejemplo, y lo envía se produzcan errores que lo devuelvan otra vez al formulario. En este caso es necesario situar el foco de la acción sobre el primer error que ha ocurrido para que el usuario discapacitado sepa encontrar el fallo de una forma rápida y sin problemas para agilizar su navegación.

11.Encabezados

Los encabezados(h1,h2,h3,h4,...) son un punto muy importante a tener en cuenta ya que no sólo afectan a la accesibilidad sino también al SEO. Su correcto uso será suficiente para satisfacer ambos criterios.

Nunca debe haber un encabezado que no encabece nada, parece una frase tonta pero nada más lejos de la realidad ya que es perfectamente factible que asi sea detectado por lo lectores de pantalla si utilizamos elementos ocultos.

Supongamos que tenemos un encabezado que al ser pulsado despliega justo a continuación de él un párrafo de texto. Esto, que aparentemente no tiene complicación y es algo habitual, es un fallo importante de accesibilidad debido a que los lectores de pantalla no leerán el contenido asociado(suponiendo que está oculto con display:none) a ese encabezado si el usuario navega por encabezados. ¿La solución? utilizar clases que no apliquen display:none y que oculten el texto hasta que son pulsados y su correspondiente javascript activado para que se muestren.

	.ocultaAccesibilidad{
		left:-9999px;
		position:absolute;
		opacity:0;
	}

En estos casos, los habituales efectos de jQuery slideUp y slideDown no se pueden utilizar ya que internamente utilizan el display:none para realizar los efectos.

Otra cosa muy importante a tener en cuenta es el uso correcto del orden de encabezados. NUNCA debe haber dentro de un encabezado otro encabezado que no siga el orden, es decir, dentro del contenido asociado a un h2 no puede haber un h4 sin haber antes un h3 pero lo que si está permitido es que en el código del portal aparezca un h2 por ejemplo antes que un h1. Pongamos un ejemplo:

Tenemos una columna izquierda en el contenido del portal que tiene un h2 con el nombre Navegación y en un bloque separado en una columna derecha ponemos un h1 ya que asi el diseño lo requiere. Esto SI estaría permitido ya que el h1 no está dentro del h2. Esto fue un cambio importante de las WCAG 1.0 a las 2.0.

Por último, se debe utilizar los encabezados de una forma coherente y de acuerdo a una organización de la información correcta. Los validadores te dirán si tu código está bien pero NINGúN validador te dirá si tu contenido(el texto englobado por cada encabezado) está bien. Si conseguimos esto tendremos garantizado el SEO referente a estos encabezados.

12.Colores

Todo diseño accesible debe cumplir con el contraste mínimo permitido entre color de letra y de fondo para que sea perceptible por cualquier usuario con una discapacidad visual. Existen herramientas y complementos de navegadores que permiten comprobar el contraste entre el color de cada texto y su fondo de tal forma que podamos detectar fácilmente los problemas. Esto es algo que ya debe ser previsto en la fase inicial de diseño ya que puede darse el caso que los diferentes colores corporativos de una marca no sean de inicio accesibles por sus características.

Se recomienda utilizar el complemento de Firefox WCAG Contrast Checker para comprobar este punto.

12.1 Colores con significado

En ningún caso se debe utilizar los colores para denotar algún tipo de significado que no pueda ser entendido sin ellos. Por ejemplo, mostrar una bola roja o verde en función de si un servidor está activo o caído. Una persona daltónica no podría identificar el color correctamente y al ser el mismo icono para ambos no sería correcto.

COMENTARIOS

DEJA TU COMENTARIO