¿Seguro? Normalmente detrás de esta petición habitual de algunos clientes se encuentra un “y yo más” para tratar de destacar sobre páginas de la competencia o por darse notoriedad.

Recordemos que las Pautas de Accesibilidad al Contenido Web 1.0 (WCAG 1.0) tienen unos 10 años y han estado vigentes todo este tiempo sin cambiarse ni flexibilizarse. La versión 2.0 de dichas pautas se aprobaron en diciembre de 2008 pero actualmente la legislación española hace referencia a la UNE 139803:2004 que a su vez sigue las WCAG 1.0 así que debemos seguir ciñéndonos de momento a esta primera versión.

Echemos un vistazo al siguiente punto de verificación para cumplir el nivel máximo (AAA):

Hasta que las aplicaciones de usuario manejen correctamente los controles vacíos, incluya caracteres por defecto en los cuadros de edición y áreas de texto.

Pautas de Accesibilidad al Contenido en la Web 1.0. Punto 5.2

Es decir, si tenemos un formulario de registro que se piden una serie de campos en todos los controles deberemos indicar un texto por defecto. Podría resultar visualmente un poco raro y tal vez se pida que se cambie pero… es uno de los puntos a tratar para lograr el nivel AAA.

Otro punto:

Especifique la expansión de cada abreviatura o acrónimo cuando aparezcan por primera vez en el documento.

Pautas de Accesibilidad al Contenido en la Web 1.0. Punto 4.2

Desde el punto de vista de gestión de contenidos es un reto. La herramienta que usemos tendrá que estar preparada para ello y las personas encargadas de su gestión deberán conocer cómo y por qué deben hacerlo.

Probablemente este requerimiento caiga en saco roto cuando se manejen volúmenes de información grandes.

Veamos este otro punto:

Proporcione atajos de teclado para los vínculos más importantes (incluidos los de los mapas de imagen de cliente), los controles de formulario y los grupos de controles de formulario.

Pautas de Accesibilidad al Contenido en la Web 1.0. Punto 9.5

Es decir, proporciona atajos de teclado para aquellas funcionalidades más importantes. Es algo que realmente no cuesta hacer aunque nos pidan un nivel mínimo de Accesibilidad (A).

Veamos ahora por ejemplo un punto necesario para cumplir la triple A (AAA) según las WCAG 2.0:

Se proporciona una interpretación a lengua de signos para todo contenido de audio pregrabado del contenido multimedia sincronizado.

Pauta 1.2. Pautas de Accesibilidad de Contenido Web 2.0 [Traducción]

Si proporcionamos algún tipo de audio previamente grabado en nuestra página web, deberemos dotarle de un video en lengua de signos con el contenido del mismo. Tiene sentido el hacerlo pero no siempre se querrá hacer por algún tema de disponibilidad de recursos o de presupuesto.

Tras la asistencia a Sobrevivir a WCAG 2.0: Guía de utilización y aplicación, un vistazo a estas pautas en su versión máxima nos muestra la exigencia a la hora de abordar algunos problemas algunos de los cuales tecnológicamente no estén aún disponibles.

¿A qué viene todo esto? Antes de abordar un nivel máximo de accesibilidad por el hecho de destacar entre el resto, tratemos primero de concienciar a todo el equipo implicado, tanto en el desarrollo como en el cliente mismo, seamos conscientes de lo que queremos hacer y siempre procuremos que una tercera parte revise nuestro trabajo para comprobar que lo hemos hecho correctamente o si por el contrario deberemos subsanar algo.

En resumen, un nivel doble A (AA) bien trabajado por todas las partes implicadas y revisada (certificada) por un tercero es un motivo para estar orgulloso del trabajo hecho y poder hablar de él así como promocionarlo.

Ahora bien, si se insiste con el nivel máximo (AAA), no hay problema, lo hacemos.