Accesibilidad, Parte 2: Perceptible

Spanish (Español) translation by Javier Salesi (you can also view the original English article)

Éste principio señala que todo el contenido debe estar en un formato (o disponible a pedido en un formato) que pueda ser claramente perceptible por el usuario. Dicho de otra forma, tus sitios web deberían ser diseñados de tal manera que cualquiera pueda "leer" el contenido, sin importar si tiene alguna discapacidad. Muchos usuarios con discapacidades utilizarán tecnologías asistenciales; por ejemplo esos con trastornos visuales pueden usar un lector de pantalla, que lee lo que aparece en la pantalla, o un convertidor de texto a lenguaje braille. El objetivo entonces es facilitar éstas tecnologías asistenciales.

Por favor recuerda que las pautas aquí no son exhaustivas, así que siempre deberías consultar las Pautas de Accesibilidad para el Contenido Web.

Proporcionar Textos Alternativos a Imágenes (1.1)

Utilizar las Etiquetas Alt para imágenes

Éste es quizá el consejo más común para mejorar la accesibilidad. Si tu sitio web contiene cualquier imagen, entonces éstas son ignoradas por lectores de pantalla a menos que uses la etiqueta alt.

Nota que la descripción de alt podría no necesariamente ser una descripción de lo que es la imagen, sino más bien lo que la imagen está tratando de transmitir. La etiqueta alt dice en palabras lo que estás tratando de decir con la imagen.

Mientras éste consejo es principalmente adecuado para editores, lo destaco aquí porque desarrolladores de temas con frecuencia proporcionarán un logo en lugar de texto para transmitir el nombre del sitio web o compañía. En ésta instancia, es probablemente mejor usar el nombre del sitio (get_bloginfo('name')) como la descripción alternativa:

1	echo '<p class="site-title"><a href="' . esc_url( home_url( '/' ) ) . '"><img id="logo" alt="'.esc_attr(get_bloginfo('name')).'" src="' . $logo . '">' . get_bloginfo('name') . '</a></p>';

Las etiquetas Alt no deberían ser usadas para imágenes meramente decorativas, pues si lo haces estás esencialmente forzando al usuario a buscar información excesiva e innecesaria.

Proporcionar Alternativas a CAPTCHAs

Si tu plugin crea un formulario, puedes requerir alguna clase de confirmación que está siendo accesada por una persona más bien que por una computadora. Si decides proporcionar al usuario con una imagen o clip de audio, que luego deben interpretar, deberías explicar ésto, en texto, y proporcionar una forma alternativa de CAPTCHA para tener en cuenta a diferentes discapacidades.

Asegurar que el Contenido Puede Ser Discernido (1.4)

No dependas exclusivamente de Posición, Color o Forma para Transmitir Significado

Ésta pauta se aplicará principalmente a desarrolladores de plugins, pero también puede aplicarse a temas. Si el color, forma o posición son usados para transmitir un significado que no es discernible del texto, ese significado se pierde en usuarios que son daltónicos o ciegos.

Por ejemplo, un ejemplo típico podría ser botones de formularios de contacto que dependen exclusivamente de un ícono de la popular fuente de íconos web Font Awesome:

1	<button><span class="fa fa-envelope fa-lg"></span></button>
2	<button><span class="fa fa-times fa-lg"></span></button>

El propósito de éstos botones es evidente a un usuario que puede ver, pero para esos que dependen de lectores de pantalla no hay indicativo de lo que hacen los botones. Si, para fines de diseño, quieres evitar usar texto, deberías especificar la etiqueta usando el atributo aria-label.

1	<button aria-label="Email">
2	<span class="fa fa-envelope fa-lg"></span>
3	</button>

Éste es solo un ejemplo del protocolo ARIA (Accesibilidad en Aplicaciones Web Enriquecidas), que cubriremos más detalladamente en el próximo artículo.

Asegurar que hay Suficiente Contaste entre Texto y Fondo

Éste es un requisito casi obvio. Aún para una persona con buena vista, un sitio web con un bajo contraste entre texto y fondo es difícil de leer y puede causar fatiga visual. Para aquellos con trastornos de la visión, un mayor grado de contraste es requerido, porque las Pautas de Accesibilidad para el Contenido Web señalan que el color de texto y el del fondo deben tener una relación de contraste de 4.5:1.

No es inmediatamente obvio como se aprecia o significa la relación pero hay una variedad de herramientas que te ayudan a comprobar la relación.

Texto más grande tiene un requerimiento menor de 3:1, y logos, y texto que es pura decoración o no visible, y texto/botones 'deshabilitados' no tienen un requerimiento de contraste.

Aunque la mayoría de temas ofrecen a sus usuarios la capacidad para ajustar los colores usados en el sitio web, es una buena idea asegurar que al menos los colores predeterminados (o 'paletas' disponibles) satisfagan el requerimiento mínimo de contraste. Más tarde en ésta serie abordaremos la creación de una característica en tu tema que advierte al usuario si está seleccionando colores con contraste insuficiente.

Evitar Fondos Blancos

La Asociación Británica de Dislexia recomienda evitar fondos con solo el color blanco para el texto y mejor utilizar un color claro, crema o pastel. La razón detrás de ésta es que la brillantez de una página blanca puede "deslumbrar" al lector.

Para esos que sufren del Síndrome de Sensibilidad Escotópica (o Síndrome de Irlen), un muy alto contraste entre fondo y texto puede exacerbar síntomas tales como:

texto que parece moverse en la página (subir, caer, girar como remolino, temblar, etc.)
"perder" el contenido del texto y sólo ver ríos de blanco a través del texto
texto que parece borroso

Éstos síntomas hacen díficil e incómoda la lectura, y puede causar fatiga ocular, fatiga visual, somnolencia y dolores de cabeza.

Después de ver la sección anterior, el mejor consejo es asegurar un buen contraste, pero no demasiado contraste. Como las preferencias varían entre individuos, lo que constituye "demasiado" para unos será poco para otros según el juicio personal.

Organizar la Estructura de tu Página (1.3)

Un maquetado estructurado, con el uso apropiado de encabezados, facilita a los usuarios entender la información que se les presenta. Usuarios de lectores de pantalla dependen un poco de una estructura 'sensible' para ayudarlos a encontrar su camino en la página.

Estructurar el Maquetado de tu Página

Una forma rápida de probar ésto es ver tu tema con CSS y Javascript deshabilitados. Una mejor forma es usar Lynx que es un navegador basado en texto. Si la estructura de tu sitio causa que el contenido aparezca en una forma desordenada entonces será complicado para los usuarios usar Lynx u otras tecnologías asistenciales para leer tu sitio web. Debido a que usuarios dependen de tales tecnologías no tienen las ventajas que CSS y Javascript en cuanto a apoyo en la orientación de la página y en el flujo del contenido, es importante que la correcta secuencia de lectura sea obvia sin ellas.

Ésto es muy simple de lograr, asegura que la estructura HTML refleje el orden visual esperado. Ésto es muy natural, y si encuentras que tu sitio web no se lee bien sin CSS, entonces probablemente la has desviado intencionalmente. Como regla general tu sitio web debería seguir el patrón:

Título
Navegación
Contenido Principal
Contenido Lateral
Pie de Página

Utilzar Headers (encabezados) Apropiadamente

Éste es muy fácil de cumplir. Las reglas son simples:

Usar etiquetas <h*> únicamente para headers (encabezados)-no sólo para aplicar un estilo particular a algún texto.
Motores de búsqueda y los lectores de pantalla utilizan etiquetas header para estructurar tu página, piensa en como las usas. Ellas deberían reflejar la estructura de la página.
Úsalas en orden: <h3> debería ser anidado en una <h2> y <h2> dentro de una <h1>. (Ésto sigue de (2)).

Una pregunta que se formula con frecuencia es: ¿Debería el título de mi sitio estar dentro de una etiqueta <h1>? Las recomendaciones de W3C indican que mientras hay algunos casos donde ésto sería algo válido, en el contexto de temas de WordPress, es probablemente mejor no usar etiquetas <h1> para el título del sitio. Hay un par de razones:

El título del sitio debería ser incluído en la etiqueta <title>. Mientras que ésto es con frecuencia pasado por alto y un poco feo para usuarios, es lo primero que leen los lectores de pantalla. Por lo tanto encerrar el título del sitio en <h1> le da una prominencia redundante a usuarios de lectores de pantalla, mientras que hacer el título más obvio para los usuarios que pueden ver puede lograrse sin el uso de la etiqueta header.
Las etiquetas header son usadas para organizar información. El título de tu sitio no es particularmente útil para tal propósito.

Sin importar de lo que decidas, los subsecuentes headers en tu página deberían colocarse debajo. Así, artículos en "The Loop" o los títulos de tu página deberían tener etiquetas <h2> si has usado la etiqueta <h1> para el título de tu sitio, y etiquetas <h1> si no es el caso.

Después del contenido del artículo, la mayoría de los temas mostrarán los comentarios del artículo. Es natural tener "Comentarios" como un encabezado, pues es una lógica separación del contenido, pero como está ligado al contenido del artículo, el nivel de encabezado debería reflejar ésto. Lo más lógico de hacer es tener el encabezado "Comentarios" un nivel menor al título del artículo.

Aqui hay un snippet de un single.php:

<div id="content" role="main"> 
    
    <div id="post-<?php the_ID(); ?>" <?php post_class(); ?>> 
    
        <h1 class="entry-title"> <?php the_title(); ?> </h1> 
    
        <div class="entry-content"> 
            <?php the_content(); ?> 
        </div><!--.entry-content--> 
    
        <?php comments_template(); ?> 
    
    </div> 
    
</div>

En mi ejemplo he usado una etiqueta <h1> para el título del artículo, también la plantilla de comentarios (comments.php) podría entonces verse así:

<div id="comments"> 

    <h2 class="comments-title"> 
        <?php printf( _n( 'One Comment on %2$s', '%1$s Comments on %2$s', get_comments_number(), 'mytheme' ), number_format_i18n( get_comments_number() ), get_the_title() ); ?> 
    </h2> 
    
    //... 
    
</div>

Asegurar que tu sitio Responda Bien al Tamaño de Texto Incrementado (1.4)

Algunos usuarios con una ligera discapacidad visual pueden depender de aumentar el tamaño de la letra en lugar de tecnologías asistenciales como magnificadores de pantalla. En vista de ésto, las Pautas de Accesibilidad para el Contenido Web especifican que tu sitio no debería "romperse" cuando el texto es aumentado a 200%. "Romperse" aquí significa que el texto desaparece, colisiona, se desborda de sus contenedores, o más generalmente el maquetado del sitio se desacomoda, siendo difícil o confuso de leer.

Usa Tamaño de Fuente Relativo

Debido a que navegadores modernos han mejorado en el redimensionado del texto, usar tamaños de fuente relativos no es tan importante como solía ser (aunque IE9 no redimensiona tamaños de fuente definidos en pixeles). No obstante, es aún recomendado usar tamaños de fuente relativos (porcentajes, ems o rems). La unidad rem soluciona algunos de los problemas con la unidad em-y aunque únicamente fue introducida con CSS3, puedes usarla de una forma compatible con versiones antiguas de navegadores. Detalles de cómo implementar fuentes relativas están ligeramente fuera del alcance de éste artículo, pero puedes encontrar más aquí:

Usar Maquetados Fluidos

Sin embargo, redimensionar el texto puede llevar a problemas de maquetado. El texto podría ser empujado fuera de la pantalla, forzando al usuario a utilizar la barra de desplazamiento, o el texto podría salir de su contenedor, potencialmente a otro texto, haciendo ilegibles partes de la página web. Aquí es donde un maquetado responsivo (o fluído) puede ayudar. Sitios "responsivos" están diseñados para adaptarse al dispositivo en que están siendo observados; pues raramente usan pixeles fijos para anchura/altura o tamaño de fuente. Consecuentemente, tales sitios generalmente se comportan bien cuando los tamaños de fuente son cambiados: su maquetado no se rompe.

Las Pautas de Accesibilidad para el Contenido Web recomiendan que no sólo que el texto debería poder aumentarse hasta un 200%, sino también que el sitio web pueda dar cabida al tamaño del texto incrementado. El diseño web responsivo ayuda en eso porque:

una pantalla magnificada se ajusta al tamaño de ventana gráfica 'más pequeña'
elementos se mueven para eliminar la barra de desplazamiento horizontal
tamaños no fijos evitan la superposición o cortado de texto
imagenes son redimensionadas para encajar en el espacio disponible, y no interferir con el texto.

Sin embargo, es important notar que el diseño responsivo y la accesibilidad no es lo mismo: aunque se pueden complementar, al final tienen objetivos diferentes. Un sitio responsivo no es necesariamente accesible, y viceversa.

Usar el Lenguaje de Marcado Correctamente (1.3)

Sólo utiliza tablas para representar datos

El uso de tablas como apoyo en un maquetado de página es (esperemos) una cosa del pasado. También hay ramificaciones relacionadas con accesibilidad para el mal uso de tablas. Tablas están hechas para representar datos o información, y como tal filas y columnas tienen un significado inherente, y lectores de pantalla asumen ésto cuando leen datos.

Un lector de pantalla, por ejemplo, leerá el número de la fila y la columna antes de leer el contenido de la celda. Ya que la posición de la celda en tablas utilizadas para propósitos meramente de presentación es irrelevante, ésta información puede ser confusa, o al menos irritante: al usuario final se le dice que hay estructura tubular, cuando realmente no lo hay.

Uso Correcto del Lenguaje de Marcado para tablas

La mayoría de los desarrolladores de temas no necesitarán producir tablas (y el calendario de artículos en WordPress ya está accesible). Sin embargo, plugins pueden mostrar tablas a través de código breve o widgets. Hay cosas de las que se tiene que estar conscientes cuando se produce el lenguaje de marcado para tablas:

Donde sea posible, mantener las tablas simples. Aunque filas/columnas ha sido un estándar del lenguaje de marcado por muchos años, no son soportadas universalmente por lectores de pantalla.
Donde sea apropiado, proporciona un elemento <caption> en la parte superior de una tabla, describiendo lo que muestra la tabla:
1

<table>
2

<caption> ... </caption>
3

...
4

</table>
Usa <th> para encabezados de tabla y <td> para datos de la tabla. celdas <th> nunca deberían estar vacías.
Proporciona un alcance para celdas <th>, indicando si es un encabezado de fila o columna: <th scope="col"> o <th scope="row">. Aunque el alcance es con frecuencia determinado por el lector de pantalla, no es malo ser explícito.
Puedes usar <thead>, <tbody> y <tfoot>, pero con frecuencia no ofrecen beneficios en términos de accesibilidad.

Usar el atributo title de encabezados para explicar una abreviación utilizada en la celda:

<table> 
    <caption> February 2014 </caption> 
    <thead> 
        <tr> 
            <th title="Monday" scope="col">M</th> 
            <th title="Tuesday" scope="col">T</th>
            <th title="Wednesday" scope="col">W</th> 
            <th title="Thursday" scope="col">T</th> 
            <th title="Friday" scope="col">F</th> 
            <th title="Saturday" scope="col">S</th> 
            <th title="Sunday" scope="col">S</th> 
        </tr> 
    </thead> 
    ... 
</table>

ARIA (Accesibilidad en Aplicciones Web Enriquecidas) & Formularios

Atributos de Accesibilidad en Aplicaciones Web Enriquecidas (ARIA) son útiles en identificar el propósito de una parte particular de la página, cualquier propiedad (por ejemplo etiquetar una entrada requerida de un formulario) y estado (por ejemplo etiquetar un botón como deshabilitado). Usarlas puede ayuda a tecnologías asistenciales a entender mejor tu sitio web, y así presentar tu página más claramente al usuario final. Abordaremos la Accesibilidad en Aplicaciones Web Enriquecidas en el próximo artículo de ésta serie. Más adelante en ésta serie, también veremos la forma correcta del lenguaje de marcado, y la retroalimentación accesible.

¡Sé el primero en conocer las nuevas traducciones–sigue @tutsplus_es en Twitter!