Usable y accesible

PDF Techniques for WCAG 2.0

2011-07-07T12:37:00.024+02:00

Última actualización 11 de enero de 2012

Lo primero que hay que advertir es que el documento PDF Techniques for WCAG 2.0 es de momento un documento de trabajo del WCAG WG. Por tanto, las técnicas PDF de las WCAG 2.0 no están incluidas por ahora en el documento Tecniques for WCAG 2.0, como por ejemplo sí lo están las técnicas Flash (ver mi artículo Checklist para validar contenido Flash de acuerdo con las WCAG 2.0)

Desde el 3 de enero de 2012 las técnicas PDF de las WCAG 2.0 están incluidas en el documento Tecniques for WCAG 2.0, tal y como lo están, por ejemplo, las técnicas para contenido Flash (ver mi artículo Checklist para validar contenido Flash de acuerdo con las WCAG 2.0). Durante el 2011, las técnicas PDF para cumplir con las WCAG 2.0 solo eran un documento de trabajo y no estaban incluidas en el documento Tecniques for WCAG 2.0.

Si no sabes muy bien qué son las WCAG 2.0 o sus técnicas asociadas te recomiendo que comiences leyendo el artículo WCAG 2.0

Si te estás introduciendo en el tema de la accesibilidad en ficheros PDF, te recomiendo que primero te leas los artículos PDF accesibles y PDF accesibles 2: Metodología

A continuación enumero las 23 técnicas y os doy una serie de consejos prácticos para cada una. La información que incluyo en cada técnica no es un resumen de lo que se dice en el documento (al cual os remito siempre) sino una serie de recomendaciones fruto de la experiencia. El título de cada una de las técnicas os llevará a su descripción en la documentación de las WCAG 2.0

Podéis consultar el índice de la técnicas en PDF Techniques for WCAG 2.0.

Nota para mis ex-alumnos: veréis que todas las técnicas se tratan en los pasos que explico en la metodología a seguir, es importante que se siga el orden de la metodología y no el orden de las técnicas.

PDF1: Applying text alternatives to images with the Alt entry in PDF documents

Asociado al criterio de conformidad 1.1.1 de nivel A

Se debe aplicar el mismo criterio que en web, es decir, sólo deben tener texto alternativo las imágenes que NO son decorativas. Nunca podremos considerar que una imagen es decorativa si es un enlace o si tiene texto (a no ser que sea decorativo)

En web recomendamos que las imágenes decorativas estén definidas en la CSS, el equivalente en un documento PDF es que se conviertan en artifacto para que no sean leídas por el lector de pantalla.

Al igual que en web, el texto alternativo de las imágenes debe proporcionar la misma información que la imagen, pero en este caso no disponemos del atributo LONGDESC, así que toda la información alternativa deberá incluirse en el campo "Texto alternativo" de la etiqueta Figure correspondiente. Es muy importante no incluir como imagen aquel contenido que podría maquetarse sin necesidad de una imagen (por ejemplo una tabla)

El texto alternativo de las imágenes se incluye después de etiquetar el documento.

PDF2: Creating bookmarks in PDF documents

Asociado al criterio de conformidad 2.4.5 de nivel AA

Lo más cómodo es que al crear el PDF indiques que se generen los marcadores. Si el documento de origen está bien estructurado estos se crearán correctamente aunque siempre es recomendable revisarlos.

También podemos crearlos automáticamente una vez tengamos el documento etiquetado o bien crearlos manualmente.

Hay que recordar que cuando asignamos un destino a un marcador, lo mismo que cuando creamos un enlace, el enlace recuerda el scroll y el zoom que tenías en la página. Es importante que la página esté escrolada en la zona de la página correcta y que mantengas un zoom constante, no hay cosa más incómoda que el documento cambie de zoom en función del enlace que pulses.

PDF3: Ensuring correct tab and reading order in PDF documents

Asociado al criterio de conformidad 1.3.2 (A), 2.1.1 (A), 2.1.3 (AAA), 2.4.3 (A)

Es imprescindible revisar el orden de lectura del documento mediante el panel "Retocar orden de lectura" y mediante un lector de pantalla como NVDA. Es especialmente importante cuando está maquetado en varias columnas o incluye notas al pie, en cuyo caso el orden dependerá de que se haya maquetado correctamente en el fichero de origen.

Si tienes dos columnas englobadas en un único bloque de lectura se leerán linealmente. Compruébalo con el lector de pantalla y divídelas en dos bloques de lectura.

Un error habitual en la revisión de accesibilidad mediante la herramienta de Adobe es "Páginas con un orden de tabulación que puede ser incoherente con el orden de estructura". Lo podemos solucionar seleccionando en las propiedades de la página la opción "Orden de tabulación>Usar estructura del documento"

Si el PDF tiene un formulario el orden de tabulación será el de la creación de los campos, pero puedes modificar el orden moviendo los campos dentro del árbol del panel "Campos".

PDF4: Hiding decorative images with the Artifact tag in PDF documents

Asociado al criterio de conformidad 1.1.1 de nivel A

Me remito a lo que he comentado en la técnica PDF1

PDF5: Indicating required form controls in PDF forms

Asociado al criterio de conformidad 3.3.1 (A), 3.3.2 (A), 3.3.3 (AA)

Si un campo de un formulario del PDF es obligatorio debes marcarlo como tal en sus propiedades. Además deberías seguir las mismas directrices de usabilidad que las que se aplican a un formulario web, para lo cual recomiendo el artículo Formularios usables: 60 Directrices de Usabilidad y Formularios accesibles según las WCAG 2.0

PDF6: Making tables accessible in PDF documents by using table elements

Asociado al criterio de conformidad 1.3.1 (nivel A)

Para que una tabla sea accesible es necesario en primer lugar que esté etiquetada correctamente como una tabla con las etiquetas TABLE, TR, TH (para los encabezados, indicando en la propiedad "Ámbito" a qué conjunto de celdas encabeza) y TD.

Pero además es necesario que se incluya un resumen de la tabla (lo que en web sería el SUMMARY) en la opción "Editar resumen de la tabla". También se debe relacionar correctamente las celdas con sus encabezados mediante el ID de los mismos. Recordad que estos IDs deben ser únicos en el documento y no sólo únicos en la tabla.

PDF7: Performing OCR on a scanned PDF document to provide actual text

Asociado al criterio de conformidad 1.4.5 (AA) y 1.4.9 (AAA)

Una comprobación inicial que debe hacerse siempre antes de comenzar a trabajar con el PDF es si tiene imágenes fruto de texto escaneado. En este caso no podremos buscar dentro de ese texto ni los lectores de pantalla tendrán acceso a él. Por ello será necesario convertirlo en texto mediante OCR, para lo cual es muy útil y funciona bastante bien la opción de Acrobat "Documento> Reconocimiento de texto OCR"

PDF8: Providing definitions for abbreviations via an E entry for a structure element

Asociado al criterio de conformidad 3.1.4 (AAA)

La primera vez que aparece en el documento un determinado acrónimo o abreviatura debes especificar su expansión (a no ser que esté expandida en el propio texto)

Si el documento tiene un índice de abreviaturas y acrónimos podemos poner un enlace a su entrada, y en caso contrario deberá indicarse su expansión en su propiedad "Texto alternativo".

La mayoría de las veces formará parte de un párrafo y será necesario convertirla en una etiqueta independiente para poder acceder a sus propiedades. Podremos hacerlo con la opción "Crear etiqueta a partir de la selección"

Recomiendo leer: "¿Cómo he de marcar correctamente las abreviaturas y acrónimos?", que aunque se refiere a web, hay muchos puntos en común con un PDF.

PDF9: Providing headings by marking content with heading tags in PDF documents

Asociado al criterio de conformidad 1.3.1 (A) y 2.4.1 (A)

Al igual que ocurre en web, el documento debe tener un sistema de encabezados lógico y coherente con la estructura del documento. Es importante validar el documento siempre con un lector de pantalla como NVDA para comprender los problemas que puede ocasionar un sistema de títulos mal definido.

No utilices nunca el lector de Adobe Acrobat, no se asemeja demasiado a lo que es un lector de pantalla de verdad.

PDF10: Providing labels for interactive form controls in PDF documents

Asociado al criterio de conformidad 1.3.1 (A), 3.3.2(A) y 4.1.2 (A)

El label de cada campo debe estar posicionado correctamente en relación con el campo.

Además, cada campo debe tener un nombre significativo en su propiedad "Nombre", que debería ser el de su label. Si no se incluye el campo “Nombre” el lector de pantalla leerá el tipo de campo, lo cual no resulta muy significativo.

En el tooltip incluirías el texto de ayuda contextual que tuviera asociado el campo, cuya información puedes ampliar si lo consideras necesario.

PDF11: Providing links and link text using the /Link structure element in PDF documents

Asociado al criterio de conformidad 1.3.1 (A), 2.1.1 (A), 2.1.3 (AAA), 2.4.4 (A), 2.4.9(AAA)

Los enlaces deben definirse antes de etiquetar el documento. Por tanto, si creamos desde el fichero de origen un PDF ya etiquetado, todos los enlaces necesarios del documento deberán estar definidos en el documento de origen (incluidos los de los acrónimos y abreviaturas al índice, los enlaces de la llamada de una nota a dicha nota, etc.)

Si etiquetamos el documento desde Adobe, primero deberemos comprobar si existen todos los enlaces y sino crearlos mediante la herramienta “Vínculo”.

Deberemos además comprobar en las etiquetas que es efectivamente de tipo LINK y que es interpretado correctamente por NVDA.

Es importante que el texto del enlace y el contexto en el que se incluye sea significativo, y en caso contrario añadir un texto alternativo en sus propiedades ("Texto alternativo"). Los lectores de pantalla sustituirán el texto del enlace por el del texto alternativo, por tanto hay que asegurarse de que el texto alternativo tiene sentido en el contexto del texto que tiene antes y después. El ejemplo más claro de un enlace en el cual ha de incluirse texto alternativo es todo aquel cuyo texto sea una URL.

PDF12: Providing name, role, value information for form fields in PDF documents

Asociado al criterio de conformidad 1.3.1 (A) y 4.1.2 (A)

Como he indicado en la técnica PDF10, todo campo de formulario de un PDF debe tener un nombre que coincida con su label y un tooltip con la información de ayuda contextual del campo (si la necesita) Además debemos rellenar la pestaña "Opciones" de sus propiedades para indicar su valor y estado por defecto.

Siempre será necesario comprobar con un lector de pantalla si podemos interactuar correctamente con los campos: activarlos, cambiar de valor, etc.

PDF13: Providing replacement text using the /Alt entry for links in PDF documents

Asociado al criterio de conformidad 2.4.4 (A) y 2.4.9 (AAA)

Me remito a la técnica PDF11 donde ya he tratado las alternativas textuales de los enlaces.

PDF14: Providing running headers and footers in PDF documents

Asociado al criterio de conformidad 2.4.8 (AAA) y 3.2.3 (AA)

Los encabezados y pies de página deben ser consistentes a lo largo de todo el documento e incluir información relevante, como el capítulo del documento dónde nos encontramos o el número de página. Ello ayuda, especialmente a los usuarios con una discapacidad intelectual, a ubicarnos dentro del documento.

Además, han de ser definidos como encabezados o pies de página en el documento de origen, lo cual beneficia a los lectores de pantalla. Los encabezados y pies de páginas definidos como tales desde el documento de origen son generados en el PDF como artifactos de página, que al contrario que los artifacto normales tienen asociados una lista de propiedades.

Por ejemplo, crea un Word con un encabezado, conviértelo en PDF, selecciona un texto que aparezca en dicho encabezado y busca su tag en el panel "Etiquetas". No lo encontrarás, es un artifacto y no será leído por los lectores de pantalla. Sin embargo búscalo en el panel "Contenido", verás que sí aparece. Editando el diccionario de su contenedor se observa que tiene propiedades como "Subtype" ("Header", si es un encabezado)

Más información en: About PDF Artifacts (PDF, 112 KB)

PDF15: Providing submit buttons with the submit-form action in PDF forms

Asociado al criterio de conformidad 3.2.2 (A)

Al igual que debemos hacer en un formulario web, en un formulario PDF el botón que envía el formulario debe ser un botón de tipo "Submit" (en Propiedades>Acciones)

PDF16: Setting the default language using the /Lang entry in the document catalog of a PDF document

Asociado al criterio de conformidad 3.1.1 (A)

Se debe indicar el idioma del PDF en las propiedades del mismo (pestaña "Avanzadas").

Tenemos que recordar que también es necesario marcar los cambios de idioma en el texto accediendo para ello a las propiedades de su etiqueta (consulta cuándo es necesario hacerlo en "¿Debo indicar el cambio de idioma de cualquier palabra?")

PDF17: Specifying consistent page numbering for PDF documents

Asociado al criterio de conformidad 1.3.1 (A) y 2.4.8(AAA), 3.2.3 (AA)

Si el documento incluye la paginación del mismo, por ejemplo en el pie, esta debe ser coherente con la paginación del propio documento en Acrobe. Lo puedes modificar en el panel "Páginas".

PDF18: Specifying the document title using the Title entry in the document information dictionary of a PDF document

Asociado al criterio de conformidad 2.4.2 (A)

Uno de los primeros pasos que ha de realizarse al modificar un PDF es acceder a sus propiedades para personalizar su metainformación. Uno de los datos más importantes, no sólo de cara a la accesibilidad del PDF sino también de cara al SEO, es personalizar su título.

Una de las recomendaciones que siempre doy y que hasta ahora no había visto documentada como técnica de accesibilidad es precisamente la que se indica en este pauta, no sólo añadir un título significativo sino indicar además que este sea el campo que se visualice en el título de la ventana del PDF (por defecto se muestra el nombre del PDF) Sería el mismo comportamiento que en una página web y se modifica en la pestaña "Vista inicial" de las propiedades del documento (en el campo "Mostrar> Título del documento")

PDF19: Specifying the language for a passage or phrase with the Lang entry in PDF documents

Asociado al criterio de conformidad 3.1.1 (A) y 3.1.2 (AA)

Me remito a la técnica 16 donde ya lo he explicado. Si el texto en otro idioma está insertado dentro de un párrafo, será necesario convertirlo en una etiqueta independiente (SPAN) para poder acceder a sus propiedades. Podremos hacerlo con la opción "Crear etiqueta a partir de la selección"

PDF20: Using Adobe Acrobat Pro's Table Editor to repair mistagged tables

Asociado al criterio de conformidad 1.3.1 (A)

Me remito a la técnica 6 dónde ya he explicado lo referente a las tablas.

PDF21: Using List tags for lists in PDF documents

Asociado al criterio de conformidad 1.3.1 (A)

Al igual que en un página web, los elementos que forman parte de una lista deben estar etiquetados correctamente (L, LI, Lbl, LBody), esto permite al lector de pantalla informar de la lista (por ejemplo cuando empieza y termina) adecuadamente.

PDF22: Indicating when user input falls outside the required format or values in PDF forms

Asociado al criterio de conformidad 3.3.1(A) y 3.3.3(AA)

Al igual que en un formulario web, en un formulario PDF se debe indicar los campos que son obligatorios y los formatos requeridos (por ejemplo en un campo fecha); y en caso de que el usuario cometa un error se le debe informar apropiadamente.

Me remito a la técnica 5 donde ya lo hemos comentado. Se pueden ver ejemplos concretos en la explicación de esta técnica.

PDF23: Providing interactive form controls in PDF documents

Asociado al criterio de conformidad 2.1.1(A) y 2.1.3(AAA)

Una vez más, la forma de actuar es la misma que en un formulario web. El formulario PDF debe ser accesible no sólo mediante ratón, sino también por teclado.

Tabla resumen de los criterios de éxito a los que están asociados cada una de las técnicas PDF

Ampliación de la tabla del artículo WCAG 2.0 Techniques for PDF del blog de Adobe (en dicha tabla no aparecerían algunos criterios de nivel AAA que tienen asociados técnicas PDF)

Criterio de éxito	Nivel	Técnica PDF
1.1.1 Contenido no textual	A	PDF1 PDF4
1.2.1 Solo audio y solo vídeo(grabado)	A	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-av-only-alt
1.2.2 Subtítulos (grabados)	A	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-captions
1.2.3 Audiodescripción o Medio Alternativo (grabado)	A	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-audio-desc
1.2.4 Subtítulos (en directo)	AA	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-real-time-captions
1.2.5 Audiodescripción (grabado)	AA	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-media-equiv-audio-desc-only
1.3.1 Información y relaciones	A	PDF6 PDF9 PDF10 PDF11 PDF12 PDF17 PDF20 PDF21
1.3.2 Secuencia significativa	A	PDF3
1.3.3 Características sensoriales	A	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-content-structure-separation-understanding
1.4.1 Uso del color	A	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-without-color
1.4.2 Control del audio	A	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-dis-audio
1.4.3 Contraste (mínimo)	AA	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-contrast
1.4.4 Cambio de tamaño del texto	AA	G142
1.4.5 Imágenes de texto	AA	PDF7 Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-text-presentation
1.4.9 Imágenes de texto (sin excepciones)	AAA	PDF7
2.1.1 Teclado	A	PDF3 PDF11 PDF23
2.1.2 Sin trampas para el foco del teclado	A	G21
2.1.3 Teclado (sin excepciones)	AAA	PDF3 PDF11 PDF23
2.2.1 Tiempo ajustable	A	PDF3 G133
2.2.2 Poner en pausa, detener, ocultar	A	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-time-limits-pause
2.3.1 Umbral de tres destellos o menos	A	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-seizure-does-not-violate
2.4.1 Evitar bloques	A	PDF9 Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-skip
2.4.2 Titulado de páginas	A	PDF18
2.4.3 Orden del foco	A	PDF3
2.4.4 Propósito de los enlaces (en contexto)	A	PDF11 PDF13
2.4.5 Múltiples vías	AA	PDF2 Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-mult-loc
2.4.6 Encabezados y etiquetas	AA	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-navigation-mechanisms-descriptive
2.4.7 Foco visible	AA	G149 G165 G195
2.4.8 Ubicación	AAA	PDF14 PDF17
2.4.9 Propósito de los enlaces (sólo enlaces)	AAA	PDF11 PDF13
3.1.1 Idioma de la página	A	PDF16 PDF19
3.1.2 Idioma de las partes	AA	PDF19
3.1.4 Abreviaturas	AAA	PDF8
3.2.1 Al recibir el foco	A	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-consistent-behavior-receive-focus
3.2.2 Al recibir entradas	A	PDF15
3.2.3 Navegación coherente	AA	PDF14 PDF17 G61
3.2.4 Identificación coherente	AA	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-consistent-behavior-consistent-functionality
3.3.1 Identificación de errores	A	PDF5 PDF22
3.3.2 Etiquetas o instrucciones	A	PDF5 PDF10
3.3.3 Sugerencias ante errores	AA	PDF5 PDF22
3.3.4 Prevención de errores (legales, financieros, datos)	AA	Técnicas generales: http://www.w3.org/WAI/WCAG20/quickref/#qr-minimize-error-reversible
4.1.1 Procesamiento	A	Not Applicable: PDF is not implemented using markup languages
4.1.2 Nombre, función, valor	A	PDF10 PDF12

Servicios relacionados

Formación y cursos sobre creación de PDF accesibles. Conversión de PDF en PDF accesibles

Respuesta a 25 dudas habituales sobre accesibilidad web

2011-01-30T21:06:00.057+01:00

Artículos relacionados: Consejos avanzados de accesibilidad web

Última actualización: 16/04/2012

A continuación se dan respuesta a 25 dudas habituales de accesibilidad respondidas de acuerdo a las WCAG 2.0 y su documento asociado Techniques for WCAG 2.0

¿Puedo utilizar ventanas emergentes?
¿Puedo utilizar frames?
¿Puedo utilizar tablas para maquetar?
¿Mi sitio Web es inaccesible si utiliza Flash?
¿Mi sitio Web es inaccesible si utiliza javascript?
¿Cómo debo asociar los labels y los campos del formulario: de forma explícita o implícita?
¿Cómo debo presentar el texto: justificado o alineado a la izquierda?
¿Cómo he de marcar correctamente las abreviaciones y acrónimos?
¿Es correcto utilizar botones en la página que permitan aumentar el tamaño del texto?
¿Cómo se especifica correctamente el color de fondo y de primer plano?
¿Cómo marcar adecuadamente un emoticon?
¿Es correcto que aparezca en el código HTML un H2 antes que un H1?
¿Es recomendable incluir una opción de "Leer está página"?
¿Cuánto se ha de poder ampliar el tamaño de un texto?
¿Cómo marcar la pronunciación de una palabra?
¿Cómo se implementan de forma accesible los enlaces con el mismo texto que enlazan con diferentes páginas?
¿Debo indicar el cambio de idioma en cualquier tipo de palabra?
¿Cualquier sonido automático de la página tiene que tener la opción de pausar o detener el audio?
¿Está permitido que las imágenes que son enlaces no queden punteadas alrededor al coger el foco?
¿Hay alguna limitación en cuanto al ancho de un bloque de texto? ¿Alguna pauta de accesibilidad indica el número de caracteres que debe tener?
¿Una versión de alto contraste suple los requerimientos obligatorios de contraste entre el color de primer plano y el del fondo?
¿Cuándo puedo ponerle a una imagen alt=""?
¿Es correcto que el contenido de un input se borre al coger el foco?
¿Qué se considera texto grande y texto pequeño?
¿Es obligatorio antes de enviar un formulario que el usuario confirme el envío?

1. ¿Puedo utilizar ventanas emergentes?

Cuando hablamos de ventanas emergentes (pop-ups) nos referimos tanto a nuevas ventanas del navegador abiertas mediante el atributo TARGET como a ventanas que se abren mediante javascript con WINDOW.OPEN

El criterio de conformidad "3.2.5 Change on Request: Changes of context are initiated only by user request or a mechanism is available to turn off such changes. (Level AAA)" de las WCAG 2.0 dice:

The intent of this Success Criterion is to encourage design of Web content that gives users full control of changes of context. This Success Criterion aims to eliminate potential confusion that may be caused by unexpected changes of context such as automatic launching of new windows, automatic submission of forms after selecting an item from a list, etcetera. Such unexpected changes of context may cause difficulties for people with motor impairments, people with low vision, people who are blind, and people with certain cognitive limitations.

Asociado a este criterio hay dos técnicas que contestarán a nuestra pregunta:

H83: Using the target attribute to open a new window on user request and indicating this in link text

La técnica H83 dice así:

The objective of this technique is to avoid confusion that may be caused by the appearance of new windows that were not requested by the user. Suddenly opening new windows can disorientate or be missed completely by some users. In HTML 4.01 Transitional and XHTML 1.0 Transitional, the target attribute can be used to open a new window, instead of automatic pop-ups. (The target attribute is deleted from HTML 4.01 Strict and XHTML 1.0 Strict.)

Note that not using the target allows the user to decide whether a new window should be opened or not. Use of the target attribute provides an unambiguously machine-readable indication that a new window will open. User agents can inform the user, and can also be configured not to open the new window. For those not using assistive technology, the indication would also be available from the link text.

Es decir, aunque no se recomienda el uso de ventanas emergentes y se hace hincapié en los problemas que provocan, las WCAG 2.0 no prohíben el uso de TARGET con HTML 4.01 Transitional y XHTML 1.0 Transitional, eso sí, debe indicarse siempre mediante texto y dentro del enlace que se abrirá en ventana nueva.

Por ejemplo:

Show Help (opens new window)

¿Se puede ocultar la aclaración "se abre en ventana nueva" mediante la CSS? ¿Se puede indicar en el title del enlace?

El criterio de conformidad 2.4.4 (A) permite como técnicas suficientes para que los enlaces transmitan su próposito elegir (aparte de que el propio enlace sea suficientemente descriptivo):

que la aclaración se incluya con el atributo title. Es la técnica H33, pero en la misma, aunque permitida, se desaconseja su uso por las limitaciones del soporte del atributo title y se aconseja que el propio enlace describa su propósito aunque parte del mismo se oculte mediante la CSS.
incluir la aclaración dentro del enlace pero ocultarla por CSS

Sin embargo, para cumplir con el nivel AAA, sería obligatorio que la advertencia de que se abre en ventana nueva se incluya dentro del enlace puesto que:

así lo recomienda el texto y el ejemplo de la técnica H83 del criterio 3.2.5, tal y como hemos visto. Se especificaba que las ventanas emergentes no sólo causan problemas a personas con una discapacidad visual, sino también a personas con problemas motores o cognitivos que no están usando un lector de pantalla y para las cuales por tanto sería opaco el contenido oculto por CSS.
el criterio 2.4.9 (AAA) obliga a que el propósito de los enlaces esté especificado en el texto del enlace, aunque admite como técnica la ocultación de parte del texto del enlace mediante CSS. Pero no admite la aclaración en el atributo title del enlace.

SCR24: Using progressive enhancement to open new windows on user request
Tras advertir de nuevo de los problemas de las ventanas emergentes, se explica cómo hacer un WINDOW.OPEN de forma accesible mediante javascript no intrusivo.
Consultar la técnica para ver un ejemplo.
Conclusión
Hay muchas razones para no usar ventanas emergentes, sin embargo no están prohibidas por las WCAG 2.0, siempre y cuando se cumplan estas dos normas:
- Si te utiliza TARGET se debe indicar dentro del enlace y mediante texto que se abre una ventana nueva.
- Si se utiliza javascript el enlace debe tener un HREF con la ruta de la página y mediante javascript no intrusivo implementar el WINDOW.OPEN
Complementariamente se citan tres errores comunes a la hora de crear nuevas ventanas que sí reportan problemas de accesibilidad:
Es decir, no se debe abrir una ventana nueva al cargar la página sin que el usuario lo haya requerido, ni se deben abrir ventanas emergentes sin previo aviso cuando se introducen datos o se seleccionan campos en un formulario (cuando se cambia el estado de un check o un radio o se selecciona el elemento de una lista).
2. ¿Puedo utilizar frames?
La técnica H70: Using frame elements to group blocks of repeated material dice así:

The objective of this technique is to demonstrate how framesets can be used to group blocks of repeated material. Since most user agents and assistive technology provide a way to navigate from frame to frame, using frames to organize elements can provide a mechanism for easily bypassing blocks of repeated content. If the site uses framesets, organize the blocks of content into separate frames. Make certain that the repeated blocks of content appear in the same frame within the frameset of each Web page. In addition, each frame element must have a title attribute to describe the content of the frame. When frames are properly titled, users can use frame navigation to easily navigate between blocks of content.
This technique is appropriate when framesets are already used to organize the content of the page; other techniques are preferred for pages that are not already using framesets, because many people using assistive technology have trouble with frames. An advisory technique about using noframes is available in Success Criterion 4.2.1.
Esta técnica, como se indica en la misma, NO está recomendando el uso de frames. Únicamente reconoce su utilidad para agrupar contenido repetido y da instrucciones sobre cómo identificarlos correctamente en caso de que ya se estén usando en el sitio web.
Si se utilizan frames habrá que ofrecer un NOFRAMES y cada frame deberá tener un TITLE como se explica en la técnica H64: Using the title attribute of the frame and iframe elements
Ambas técnicas están asociadas al criterio de conformidad 2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A)
Aunque no me gusten los frames, con las WCAG 2.0 en la mano podremos aconsejar que no se usen, pero no podremos mantener que es obligatorio eliminarlos si ya se están utilizando.
Conviene recordar que el uso de frames puede provocar diferentes problemas de usabilidad y accesibilidad en las páginas (si bien es cierto que hay soluciones para todos raramente se encuentran implementadas):
- Suelen impedir que funcione correctamente el botón "Atrás" del navegador.
- Aunque cambie el contenido de los frames, el URI del conjunto de frames no varía y por tanto no se puede hacer referencia a su estado actual con una dirección web.
- Algunos navegadores pueden tener problemas para añadir una página a los marcadores o favoritos.
- Los usuarios pueden tener dificultades para imprimir el conjunto de frames.
- Suele suponer problemas para indexar correctamente las páginas por los buscadores, que pueden indexar cada frame y no estos en su conjunto.
- El usuario podría acceder a un marco fuera de su contexto (por ejemplo a una página sin su cabecera o sin su menú de navegación).
3. ¿Puedo utilizar tablas para maquetar?
La técnica H73: Using the summary attribute of the table element to give an overview of data tables dice:

Although WCAG 2 does not prohibit the use of layout tables, CSS-based layouts are recommended in order to retain the defined semantic meaning of the HTML table elements and to conform to the coding practice of separating presentation from content. However, if a layout table is used, then the summary attribute is not used or is null. The purpose of a layout table is simply to control the placement of content; the table itself is “transparent" to the user. A summary would “break" this transparency by calling attention to the table. A null summary (summary="") on layout tables is acceptable.
Es decir, aunque hay razones de sobra para no utilizar tablas para maquetar y por ello se desaconseja su uso (también por ejemplo en las técnicas G140: Separating information and structure from presentation to enable different presentations y G146: Using liquid layout), las WCAG 2.0 no las prohíbe.
Eso sí, se han de cumplir ciertas reglas:
- El SUMMARY de estas tablas debe estar vacío.
- Estas tablas no deben utilizar CAPTION, como se indica en la técnica H39: Using caption elements to associate data table captions with data tables:
 If a table is used for layout, the caption element is not used. The purpose of a layout table is simply to control the placement of content; the table itself is “transparent" to the user. A caption would "break" this transparency by calling attention to the table.
- Tampoco se deben asociar las celdas como se indica en la técnica H43: Using id and headers attributes to associate data cells with header cells in data tables:
 
 This technique is not recommended for layout tables since its use implies a relationship between cells that is not meaningful when tables are used for layout.
Así que si a pesar de todo alguien insiste "¿pero si se usan tablas para maquetar la página es innaccesible? ¿cumple con las WCAG 2.0?", pues la realidad es que sólo podemos contestar que si se cumplen las normas citadas sí se pueden usar.
Que nadie interprete que yo las recomiendo, por favor, me limito a informar de lo que dicen las WCAG 2.0
4. ¿Mi sitio es inaccesible si utiliza Flash?
En la presentación "WCAG 2 Compliance With Flash" (PDF, 151 KB), de The Paciello Group Blog se explica como con la versión 6 y posteriores el contenido Flash puede ser accesible y cumplir con las WCAG 2.0 puesto que:
- All content exposed to AT
- Keyboard accessibility
- Accessible interactive components
En octubre de 2010 el W3C (World Wide Web Consortium) actualizó los documentos "Understanding WCAG 2.0" y "Techniques for WCAG 2.0" incluyendo 36 técnicas específicas para el contenido Flash, donde se explica como implementar Flash accesible de forma nativa.
Es reseñable que el documento de técnicas Flash del W3C ("Flash Techniques for WCAG 2.0") antes de comenzar a explicar estas técnicas que permiten hacer un Flash accesible de forma nativa, incluye tres consideraciones especiales para el cumplimiento de las WCAG 2.0:
- 2.4.2 Page Titled - In order to meet 2.4.2, Flash content must be embedded within an HTML page that has a page title in the HTML title element. See H25: Providing a title using the title element (HTML).
- 3.1.1 Language of Page - The language of Flash content is established by the lang attribute of the containing object element in HTML, not within the Flash SWF file itself. Authors may include more than one Flash SWF in a single web page, each with a different language indicated in the object element's lang attribute. See FLASH13: Using HTML language attributes to specify language in Flash content (Flash).
- 3.1.2 Language of Parts - Since the language of Flash content is not established within the Flash SWF file, it is not currently possible to indicate changes of language within a single SWF file.
Como ocurre a menudo el problema no está en la tecnología en sí sino en los desarrolladores.
En resumen, si se utiliza la tecnología Flash de forma accesible (compatible con los productos de apoyo) NO deberemos ofrecer una alternativa accesible en HTML y en la declaración de conformidad se indicará que depende de la tecnología Flash.
Si se utiliza Flash de forma no accesible se deberá proporcionar una alternativa accesible en HTML y entonces en la declaración de conformidad no incluiríamos javascript como tecnología de la que se depende.
Si Flash se usa de forma no accesible y sin alternativa accesible en HTML deberemos excluir las páginas que lo utilizan de la declaración de conformidad.
Por último deberá cumplir también con el requisito de conformidad 5 de no interferencia: si en una página se usa una tecnología que no es compatible con la accesibilidad o bien una que sí lo es pero usada de forma no compatible, no debe impedir a los usuarios acceder al contenido del resto de la página. Además, es necesario que la página web como un todo siga cumpliendo con los requisitos de conformidad cuando cualquier tecnología de la que no se depende está activada en los agentes de usuario así como cuando esté desactivada o no se soporte. Por ejemplo, no puede atrapar el foco con el teclado sin dejarlo salir, no puede tener destellos que puedan provocar ataques epilépticos, etc.
Lo mismo se aplicaría a los documentos PDF.
Otras referencias de interés sobre accesibilidad y Flash son:
- "Checklist para validar contenido Flash de acuerdo con las WCAG 2.0" de Olga Carreras.
- "Guía de accesibilidad en Flash" de Inteco
- "Flash navegable mediante teclado en Firefox" de Uninstallme.
- El blog Adobe Accessibility, donde se puede descargar: "Accessibility-only version of the Flash and Flex accessibility documentation" (ZIP, 2.84 MB).
- "Best Practices for Accessible Flash Design" de Adobe
- "Adobe Flash CS4 Professional accessibility" de Adobe
- "Can You Create Accessible Websites Using Flash?" de MSF&W
- "Video en Flash Accesible" de El Rallador.
- "Making Video Accessible" de Longtail Video
- "Flash Video Accessibility" de Illinois Department of Human Services.
5. ¿Mi sitio es inaccesible si utiliza javascript?
Javascript no era bienvenido en las pautas WCAG 1.0, no olvidemos que datan de 1999, pero el W3C sí que contempla javascript y AJAX en las WCAG 2.0. Es más, se recomiendan soluciones implementadas con javascript en numerosas técnicas: para abrir ventanas emergentes de forma no intrusiva, para cambiar de CSS de forma dinámica, etc.
Estas son todas las técnicas relacionadas con javascript y ARIA:
- Client-side Scripting Techniques for WCAG
- ARIA Techniques for WCAG 2.0
El problema no es utilizar o no javascript, sino cómo se utiliza.
En el artículo "Creating Accessible JavaScript" de WebAIM, cuya lectura se recomienda en las técnicas, se resumen muy bien las normas para crear javascript accesible:

Such uses of JavaScript do not need additional accessibility features incorporated because important content is not displayed or functionality introduced by such scripting.
Making JavaScript accessible involves looking at the following issues.
- When using event handlers, use only those that are device independent (e.g., do not require the use of the mouse only).
- Content and functionality that is provided through scripting must be made accessible to assistive technologies.
- Web pages that utilize scripting must be fully navigable using a keyboard.
- JavaScript should not modify or override normal browser functionality in a way that may cause confusion.
- When JavaScript cannot be made natively accessible, an accessible alternative must be provided.
¿Es necesario ofrecer una alternativa al JavaScript? ¿Se debe realizar una versión que funcione sin JavaScript?
La duda surge porque estamos acostumbrados a trabajar con las WCAG 1.0, en las cuales se especifica con claridad que es necesario una alternativa:
"Punto de Verificación 6.3: Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page".
Las WCAG 2.0 lo que promueven es que el código JavaScript debe ser accesible nativamente. Es decir, si se implementa de forma no intrusiva, si es independiente del dispositivo (no requiere por ejemplo sólo el uso del ratón), si es accesible para los productos de apoyo, etc. no tiene porque suponer un problema de accesibilidad.
Pero si a pesar de todo no lo logramos, las WCAG 2.0 dicen en el Requisito de conformidad número 4:
4. Only Accessibility-Supported Ways of Using Technologies: Only accessibility-supported ways of using technologies are relied upon to satisfy the success criteria. Any information or functionality that is provided in a way that is not accessibility supported is also available in a way that is accessibility supported.
En el documento "Comparison of WCAG 1.0 Checkpoints to WCAG 2.0, in Numerical Order" del W3C, el punto 6.3 se corresponde además con los requisitos de conformidad 1 (nivel de conformidad) y 5 (no interferencia). Como nota adicional se dice: There is no longer a requirement that pages work without script or other programmatic objects, only that those objects meet the conformance requirements listed above.
En resumen, si se utiliza la tecnología javascript de forma accesible (compatible con los productos de apoyo, según las técnicas de las WCAG 2.0 y la implementación de WAI-ARIA) no deberemos ofrecer una alternativa accesible y en la declaración de conformidad se indicará que depende de la tecnología javascript.
Si se utiliza javascript de forma no accesible se deberá proporcionar una alternativa accesible y entonces en la declaración de conformidad no incluiríamos javascript como tecnología de la que se depende.
Si javascript se usa de forma no accesible y sin alternativa accesible entonces deberemos excluir las páginas que lo utilizan de la declaración de conformidad.
Por último deberá cumplir también con el requisito de conformidad 5 de no interferencia: si en una página se usa una tecnología que no es compatible con la accesibilidad o bien una que sí lo es pero usada de forma no compatible, no debe impedir a los usuarios acceder al contenido del resto de la página. Además, es necesario que la página web como un todo siga cumpliendo con los requisitos de conformidad cuando cualquier tecnología de la que no se depende está activada en los agentes de usuario así como cuando esté desactivada o no se soporte.
He hablado de javascript accesible en algunos artículos anteriores:
6. ¿Cómo debo asociar los labels y los campos del formulario: de forma explícita o implícita?
La técnica H44: Using label elements to associate text labels with form controls asociada al criterio 1.3.1 (A) dice así:
The HTML and XHTML specifications allow both implicit and explicit labels. However, some assistive technologies do not correctly handle implicit labels (for example, <label>First name <input type="text" name="firstname"></label>).
- JAWS 7.10 was tested on Windows XP with Internet Explorer 6.0 and Firefox 1.5. It reads the label for explicit and implicit labels for text fields in both virtual PC cursor and forms reading mode. In forms mode it does not read the label for implicit labels on checkboxes and radio fields.
- Window-Eyes 5.5 was tested on Windows XP with Internet Explorer 6.0 and Firefox 1.5. It will always speak the label for an explicitly labelled form field. It does not speak the label for the implicitly labelled form control in browse on mode but will speak the implicit label when navigating from control to control in browse off mode.
Por dichas razones aconseja asociarlos de forma explícita como en estos ejemplo, es decir, mediante el atributo for del label y el id (que debe ser único en la página) del campo:
<label for="firstname">First name:</label> <input type="text" name="firstname" id="firstname" />
<input type="checkbox" id="markuplang" name="computerskills" checked="checked"> <label for="markuplang">HTML</label>
Además se especifica que:
- el label debe estar colocado antes del elemento del formulario al que etiqueta salvo que este sea un checkbox o un radiobutton (en cuyo caso se coloca detrás del mismo)
- el label sólo se usa con los textarea, select e input (de tipo text, checkbox, radio, file y password) pero NO se usa con button (cuyo contenido es su etiqueta) ni con los input de tipo image (su atributo alt será su etiqueta), submit y reset (su atributo value es su etiqueta) o hidden (no tienen etiqueta)
Por otro lado, hay que destacar que la técnica H65, también asociada al criterio 1.3.1 (A), admite el uso del atributo title para etiquetar los campos de formulario cuando NO se usa para ello label, bien porque en el diseño de la página no hay un texto que pueda etiquetarse como label o tenerlo podría generar confusión.
En esta técnica se explica que si no hay un label los lectores de pantalla y los agentes de usuario en general pueden leer o mostrar el valor del title asociado a un campo de formulario (mejor soportado que en el caso de los enlaces)
Se ponen varios ejemplos muy habituales. Por ejemplo, si tenemos varios campos de fecha (dia, mes, año) o de cuenta bancaria, sin un label para cada uno, podemos etiquetarlos con su atributo title.
En el caso de tener un campo de búsqueda y un botón "Buscar", bastaría con que el campo tuviera un atributo title del estilo "Escribe el término de búsqueda aquí". Pero incluso ni esto sería necesario, puesto que sería suficiente con la técnica G167 que indica que un botón adyacente a un campo puede hacer de label del mismo (si su texto es claro y ejecuta una acción sobre el campo) Es decir, en este caso no sería necesario etiquetarlo ni con label ni con title y pone precisamente como ejemplo el caso del campo y el botón buscar.
7. ¿Cómo debo presentar el texto: justificado o alineado a la izquierda?
La técnica G169: Aligning text on only one side dice así:
Many people with cognitive disabilities have a great deal of trouble with blocks of text that are justified (aligned to both the left and the right margins). The spaces between words create "rivers of white" running down the page, which can make the text difficult for some people to read. This failure describes situations where this confusing text layout occurs. The best way to avoid this problem is to create text layout that is fully justified.
Es decir, el texto no debe justificarse, puesto que algunas personas con discapacidades cognitivas o visuales pueden tener problemas para leer el texto que está justificado a ambos lados. Esta dificultad proviene de que las variaciones entre el espaciado entre las palabras puede provocar que las palabras estén demasiado juntas o por el contrario "ríos blancos", es decir, zonas del texto donde la separación de las palabras dejan grandes zonas continuas de espacio en blanco.
Sin embargo se ofrece como alternativa que el sitio ofrezca un mecanismo para eliminar la justificación del texto como se especifica en la técnica G172: Providing a mechanism to remove full justification of text:
The objective of this technique is to provide a version of the page that does not have full justification (justified both left and right). There may be circumstances when for layout purposes an author may want to have the text fully justified. In these cases, it is sufficient to provide a feature that removes the justification of text. The control should be easy to find and access and near the beginning of the page.

El problema de la justificación del texto se presenta también como un error común de accesibilidad en F88: Failure of SC 1.4.8 due to using text that is justified (aligned to both the left and the right margins)
Todas ellas están asociadas al criterio de conformidad 1.4.8 Visual Presentation: For the visual presentation of blocks of text, a mechanism is available to achieve the following: (Level AAA)
8. ¿Cómo he de marcar correctamente las abreviaciones y acrónimos?
Hay varias técnicas relacionadas con el criterio de conformidad 3.1.4 Abbreviations: A mechanism for identifying the expanded form or meaning of abbreviations is available. (Level AAA).
El marcado dependerá de si la abreviación tiene un único significado en la página o si tiene diferentes significados dentro de la misma página.
Si la abreviación tiene un único significado en la página
En este caso habrá que explicar o ampliar la abreviatura la primera vez que aparece de una de las siguientes maneras:
- G97: Providing the abbreviation immediately following the expanded form. Por ejemplo:
 "The United Nations High Commissioner for Human Rights (UNHCR) was established in 1950 to provide protection and assistance to refugees."
- G55: Linking to definitions
- H28: Providing definitions for abbreviations by using the abbr and acronym elements. Por ejemplo:
 The use of <acronym title="Keep It Simple Stupid">KISS</acronym> became popular in ...
Y habrá que explicar o ampliar la abreviatura en todas sus apariciones en la página de una de estas maneras:
Si la abreviación tiene diferentes significados dentro de la misma página
En este caso se deberá explicar o ampliar todas las veces que aparece siguiendo la técnica G55: Linking to definitions o la H28: Providing definitions for abbreviations by using the abbr and acronym elements.
Traté el tema de las abreviaturas y acrónimos en Más accesible a pesar de blogger (I). DÍA 8: Revisión de abreviaturas y acrónimos
9. ¿Es correcto utilizar botones en la página que permitan aumentar el tamaño del texto?
Asociado al criterio de conformidad 1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA) está la técnica G178: Providing controls on the Web page that allow users to incrementally change the size of all text on the page up to 200 percent en la que se puede leer:
The purpose of this technique is to provide a mechanism on the Web page to incrementally increase the size of text. Many people with low vision do not use magnifying software, and they may not be familiar with browsers text size adjustments. This may be particularly true of older people who are learning about computers later in life and who may be experiencing age related vision loss. It may also be true of some people with cognitive disabilities who also require increased font size.
This technique provides a mechanism that some users will find easier to use. The mechanism may include links or buttons that will switch the visual presentation to a different style sheet or use scripts to change the text size dynamically.
To implement this technique, an author provides controls that allow the user to incrementally increase or decrease the text size of all of the text on the page to a size that is at least 200% of the default text size.
This can be achieved by providing links, buttons or linked images and the controls themselves should be as easy to find (ex. prominently positioned within the page, presented in a larger text size, hight contrast, etc.) as possible.
Está muy extendida la creencia de que los botones que permiten ampliar el tamaño de letra son un ejemplo de falsa accesibilidad, una moda, y que no deberían utilizarse (por ejemplo en Too much accessibility. GOOD INTENTIONS, BADLY IMPLEMENTED de Patrick H. Lauke).
Sin embargo vemos que es una técnica suficiente para cumplir con el criterio de conformidad 1.4.4 (AA) que puede ser útil para usuarios con baja visión que no usan magnificadores de pantalla y que no están acostumbrados a las opciones del navegador, como ejemplo personas mayores no habituadas al uso de ordenadores o personas con discapacidades cognitivas.
Para implementar correctamente estos botones (enlaces o imágenes) deben:
- permitir aumentar progresivamente el tamaño del texto de la página hasta al menos un 200% de su tamaño por defecto
- ser fáciles de localizar, con un tamaño grande y suficiente contraste
- estar correctamente etiquetados de forma que se reconozca claramente cuál es su función
10. ¿Cómo se especifica correctamente el color de fondo y primer plano?
En el criterio de conformidad 1.4.8 Visual Presentation: For the visual presentation of blocks of text, a mechanism is available to achieve the following: (Level AAA) se especifican las técnicas que aseguran que el usuario podrá seleccionar los colores de primer plano y fondo:
1. C23: Specifying text and background colors of secondary content such as banners, features and navigation in CSS while not specifying text and background colors of the main content (CSS)
 Example 1. An HTML Web page uses CSS to specify the text and background colors of all secondary content such as navigation bars, menu bars, and the table of contents. Neither the text color nor background of the main content is specified. The user sets their own color preferences in the browser so that they view the main content in colors and contrasts that work well for them. The distinction between the separate sections of the page are still visually obvious.
 Se puede consultar cómo modificar los colores en los principales navegadores en "Changing colours in your browser" de la BBC.
 OR
2. C25: Specifying borders and layout in CSS to delineate areas of a Web page while not specifying text and text-background colors (CSS)
 Example 1. A Web page is designed using HTML. CSS is used to specify border colors around discrete areas of the page and to layout the content so that the menu floats to the left of the main content area. Neither the text color nor background is specified. The user sets their own colors in the browser. They can view the page in colors and contrasts that work well for them without disrupting the layout.
 OR
3. G156: Using a technology that has commonly-available user agents that can change the foreground and background of blocks of text OR
4. G148: Not specifying background color, not specifying text color, and not using technology features that change those defaults OR
5. G175: Providing a multi color selection tool on the page for foreground and background colors
En resumen, se debe usar una tecnología que disponga de agentes de usuario de uso común que permitan cambiar el color de primer plano y del fondo de los bloques de texto (como es el caso de XHTML) o en caso contrario proporcionar una herramienta de selección de los colores de primer plano y de fondo.
Si usamos XHTML los usuarios podrán configurar las combinaciones de colores en función de sus necesidades. Sin embargo, si la página tiene contenido secundario para el que es necesario mantener una agrupación visual, debemos asegurarnos que dicha agrupación se mantiene cuando los usuarios cambian los colores de primer plano y los colores de fondo. Para ello podemos utilizar algunas de las técnicas que ya se han indicado anteriormente:
- Especificar en las hojas de estilo el color del texto y fondo del contenido secundario, como banners o mecanismos de navegación, sin especificar un color del texto ni del fondo para el contenido principal.
- Especificar en las hojas de estilo los bordes para delimitar las áreas de contenido, sin especificar un color del texto ni del fondo para el contenido principal.
11. ¿Cómo marcar adecuadamente un emoticon?
La técnica H86: Providing text alternatives for ASCII art, emoticons, and leetspeak de las WCAG 2.0 nos indica cómo hacerlo adecuadamente.
Recomienda cuando sea posible usar simplemente una palabra en vez de un icono gestual. Pero si se usa un emoticon debe tener siempre un texto alternativo.
La técnica propone tres posibles marcados correctos:
=8-0 (fright): texto alternativo a continuación entre paréntesis
<abbr title="fright">=8-0</abbr>: marcarlo como abreviatura indicando en su atributo title su significado
<img src="fright.gif" alt="fright"/>: incluirlo como imagen con su correspondiente texto alternativo con alt
Relacionado con este punto también se indica que en el caso de un ASCII art largo, además de incluir la alternativa textual inmediatamente antes o después del dibujo, se debería incluir un enlace para saltarlo.
Por ejemplo, inmediatamente antes de un dibujo ASCII art largo de una persona, pondríamos un enlace Saltar dibujo con caracteres de una persona que vaya al contenido inmediatamente posterior al dibujo mediante un ancla. De este modo, el enlace sirve a la vez de descripción del dibujo y de enlace para saltarlo.
12. ¿Es correcto que aparezca en el código HTML un H2 antes que un H1?
En el diseño actual de páginas Web es habitual la maquetación en varias columnas. En este contexto, la pauta 3.5 de las WCAG 1.0 se puede convertir en un quebradero de cabeza, puesto que indica que "elementos H2 deberían seguir a los elementos H1, los H3 deberían seguir a los elementos H2, etc" ["Técnicas HTML para las Pautas de Accesibilidad al Contenido de la Web 1.0"]. De hecho, la validación automática dará un error en aquellas páginas en las que un H2 se encuentre antes que un H1.
Este problema se corrige en las WCAG 2.0. La técnica "H42: Using h1-h6 to identify headings" incluye un ejemplo significativo, en el cual el título del contenido principal coincide con el título de la página y está marcado como "H1" aunque no es el primero que aparece en la página. El contenido de la primera y tercera columna es menos importante y está marcado con "H2".
De modo que no es necesario que H1 aparezca antes que H2, lo importante es que realmente el título marcado como H1 sea de primer nivel y los marcados como H2 de segundo nivel.
Desgraciadamente el validador automático TAW para las WCAG 2.0 sigue mostrando un error en aquellas páginas que muestran un H2 antes que un H1 en el código.
La buena noticia es que me han dicho que lo van a corregir en la próxima versión.
13. ¿Es recomendable incluir una opción de "Leer está página"?
En algunos sitios nos encontramos una opción que proporciona un audio del contenido de la página mediante alguna herramienta automática de conversión de texto a voz como Vozme.
¿Se recomienda esta práctica?
En respuesta a esta duda, la técnica G79: Providing a spoken version of the text (proporcionar una versión hablada del texto) es una técnica suficiente para cumplir con el criterio de conformidad 3.1.5 Cuando un texto requiere un nivel de lectura más avanzado que el nivel mínimo de educación secundaria una vez que se han eliminado nombres propios y títulos, se proporciona un contenido suplementario o una versión que no requiere un nivel de lectura mayor a ese nivel educativo (Nivel AAA)
En dicha técnica se indica que para determinado tipo de usuarios puede resultar muy útil escuchar el texto leído en voz alta. Indican también que esto es efectivo para pequeñas cantidades de texto y para documentos que no cambian a menudo. Por tanto, es útil cuando lee el contenido textual y no toda la página (cabecera, menús, pie, etc.) como se encuentra en muchos portales.
También hay que tener en cuenta que está asociado a un criterio que habla de texto que requiere un nivel de lectura más avanzado que el de secundaria.
14. ¿Cuánto se ha de poder ampliar el tamaño de un texto?
El criterio de conformidad 1.4.4 (nivel AA) indica que a excepción de los títulos y las imágenes de texto, el texto debe poder cambiar su tamaño, sin un producto de apoyo, hasta un 200% (es decir, hasta dos veces el ancho y la altura) sin pérdida de contenido o funcionalidad. Por tanto, cuando el texto aumente no se deben producir desbordamientos o solapamientos de contenido que dificulten su percepción. Por ejemplo, porque algunos contenidos se salgan de su contenedor y se posicionen sobre otro contenido.

The working group feels that 200% is a reasonable accommodation that can support a wide range of designs and layouts, and complements older screen magnifiers that provide a minimum magnification of 200%.
Above 200%, zoom (which resizes text, images, and layout regions and creates a larger canvas that may require both horizontal and vertical scrolling) may be more effective than text resizing.
Assistive technology dedicated to zoom support would usually be used in such a situation and may provide better accessibility than attempts by the author to support the user directly.

15. ¿Cómo marcar la pronunciación de una palabra?
En el criterio de conformidad 3.1.6 (nivel AAA) se indican distintas técnicas. La más sencilla es colocar la pronunciación entre paréntesis tras la palabra, pero hay otras como incluir un glosario con la pronunciación de las palabras o asociar la palabra con un fichero de audio donde se escuche su pronunciación.
Sin embargo, la solución que más ha llamado mi atención es la que se describe en la técnica H62: Using the ruby element, en la cual se propone utilizar el elemento RUBY.
Ejemplo:
When we talk about these guidelines, we often just call them WCAG ( Wuh-KAG )
Si estás usando Explorer, que soporta este elemento desde la versión 5.0, verás escrita la pronunciación sobre el acrónimo "WCAG"; si accedes desde Firefox, Opera o Chrome la pronunciación la encontrarás tras el acrónimo entre paréntesis; si accedes con un lector de pantalla como JAWS oirás "uve doble ce a ge abre paréntesis gu kag cierra paréntesis".
El código del ejemplo es:
When we talk about these guidelines, we often just call them <ruby> <rb>WCAG</rb> <rp>(</rp> <rt>Wuh-KAG</rt> <rp>)</rp> </ruby>. 
Hay que tener muy presente que esta solución sólo sirve para páginas XHTML 1.1, pues es un elemento que no está definido en versiones anteriores. Por tanto, si lo utilizas con HTML 4 o XHTML 1.0 la página no será válida.
Para más información sobre RUBY:
Ruby Annotation. W3C Recommendation 31 May 2001 (Markup errors corrected 25 June 2008).
16. ¿Cómo se implementan de forma accesible los enlaces con el mismo texto que enlazan con diferentes páginas?
Es el típico ejemplo de "Leer más" o "Más información" en un listado de noticias.
En las WCAG 1.0 se especifica en relación al punto de verificación 13.1 Identifique claramente el objetivo de cada vínculo que si en la página hay dos o más vínculos con el mismo texto deben remitir al mismo recurso y de lo contrario se han de diferenciar por el atributo "title":
Si hay más de un vínculo en una página con el mismo texto, todos estos vínculos deben remitir al mismo recurso. Esta coherencia ayudará al diseño de la página tanto como a la accesibilidad.
Si dos o más vínculos van referidos a objetivos diferentes pero comparten el mismo texto, distinga los vínculos especificando un valor diferente para el atributo "title" de cada elemento A.
En "Técnicas HTML para las Pautas de Accesibilidad de los Contenidos Web 1.0" del W3C.
Las WCAG 2.0 también tienen dos criterios de conformidad (2.4.4 de nivel A y 2.4.9 de nivel AAA) que obligan a que se clarifique el propósito de un vínculo. Una de las técnicas suficientes para cumplir con el criterio de conformidad 2.4.4 es la "H33: Supplementing link text with the title attribute". Esta técnica consiste también en incluir el atributo "title" para clarificar el destino del vínculo cuando la información complementaria proporcionada por el atributo "title" es algo que el usuario debe saber antes de seguir el enlace.
Sin embargo, la propia técnica H33 de las WCAG 2.0 desaconseja el uso del atributo "title" para clarificar el destino de un vínculo por la falta de soporte del atributo "title" en muchos user-agent. De hecho, esta técnica no es válida para cumplir con el criterio de conformidad 2.4.9, que también se refiere a clarificar el destino de un vínculo pero es más estricto por ser de nivel AAA.
En esta técnica se recomiendan otras dos técnicas suficientes alternativas al uso de "title":
- o bien que el enlace tenga el texto completo (sería la técnica H30) por ejemplo: "Leer más sobre el artículo 'WCAG 2.0'" en vez de "Leer más"
- o bien ocultar mediante CSS el texto del enlace que sigue a "Leer más" (sería la técnica C7), lo cual resulta muy útil cuando el texto del enlace puede llegar a ser demasiado extenso. También se permite incluir un enlace o botón para ver u ocultar las versiones largas de los enlaces (serían las técnicas G189 y SCR30)
Estas alternativas permitirían cumplir con los criterios de conformidad 2.4.4 (nivel A) y 2.4.9 (nivel AAA).
En cuanto a la opción de ocultar por CSS parte del texto del enlace, es necesario que la ocultación del texto se haga de forma accesible para los lectores de pantalla, es decir, no se debe utilizar display:none sino localizarlo fuera de pantalla.
El ejemplo correcto sería el siguiente:
En la CSS:
a span { height: 1px; width: 1px; position: absolute; overflow: hidden; top: -10px; }
En la página:
```
<dl>

<dt>Winnie the Pooh </dt>

<dd><a href="winnie_the_pooh.html">

Winnie the Pooh HTML </a> </dd>

<dd><a href="winnie_the_pooh.pdf">

Winnie the Pooh PDF </a> </dd>

<dt>War and Peace</dt>

<dd><a href="war_and_peace.html">

War and Peace HTML</a></dd>

<dd><a href="war_and_peace.pdf">

War and Peace PDF </a> </dd>

</dl>
```
Hay otra manera de cumplir con la pauta 2.4.4 (nivel A), pero que sin embargo no será válida para cumplir con la pauta 2.4.9 (nivel AAA), y por tanto es menos aconsejable, pues las WCAG 2.0 alientan a cumplir más criterios de los estrictamente necesarios para alcanzar un determinado nivel de adecuación.
Esta última alternativa es que será válido el enlace "Leer más" cuando esté correctamente contextualizado. Por ejemplo, en el caso de un párrafo (sería la técnica H78) el W3C propone el siguiente ejemplo:
Sería incorrecto:
```
Coming soon to a town near you...the final 15 in the

National Folk Festival lineup.

<a href="final15.html">[Read more...]</a>
```
Pero sería correcto:
```
Coming soon to a town near you...the final 15 in the

National Folk Festival lineup.

<a href="final15.html">[Read more...]</a>


```
De igual manera, hay otras técnicas para indicar cómo se puede asociar correctamente un enlace con su contexto (en listas, tablas, etc.)
De forma general, además de usar el texto de la frase que contiene al enlace, también podemos incluir la descripción adicional en aquellos elementos que los producto de apoyo como un lector de pantalla puede relacionar con el enlace. En estos casos es preferible que la información de contexto que aclara el propósito de los enlaces esté situada antes de los enlaces.
Entre los contextos que se pueden determinar por software tenemos:
- Elemento de lista (LI) que contiene al enlace.
- En listas anidadas, elemento de la lista padre (LI) que contiene la lista en la que se encuentra el enlace.
- Párrafo (P) que contiene al enlace.
- Celda (TD) de la tabla que contiene al enlace y sus encabezados asociados (TH)
- Elemento de encabezado anterior H1-H6
17. ¿Debo indicar el cambio de idioma en cualquier tipo de palabra?
La pauta 4.1 (prioridad 1) de las WCAG 1.0 indica Identifique claramente los cambios en el idioma del texto del documento y en cualquier texto equivalente. De la misma manera, el criterio de conformidad 3.1.2 de las WCAG 2.0 también obliga a identificar los cambios de idioma pero establece una serie de excepciones. No es necesario identificar el cambio de idioma de:
- los nombres propios
- los términos técnicos, por ejemplo: Homo sapien, Alpha Centauri, hertz, habeas corpus (ejemplos textuales de la explicación del criterio)
- las palabras en un idioma indeterminado
- las palabras o frases que se hayan convertido en parte natural del texto que las rodea.
Para resolver las dudas que esto puede ocasionar recomiendan que se considere si la palabra se pronuncia igual que en el idioma del texto que la rodea (salvo por el acento o la entonación): If there is doubt whether a change in language is intended, consider whether the word would be pronounced the same (except for accent or intonation) in the language of the immediately surrounding text.
18. ¿Cualquier sonido automático de la página tiene que tener la opción de pausar o detener el audio?
La pauta 1.4.2 (nivel A) de las WCAG 2.0 indica que sólo es necesario si el sonido dura más de 3 segundos: If any audio on a Web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level. (Level A)
19. ¿Está permitido que las imágenes que son enlaces no queden punteadas alrededor al coger el foco?
Es una práctica habitual utilizar :focus{outline:0;} o peor aun onfocus="blur()" para evitar que las imágenes queden punteadas alrededor cuando cogen el foco.
Las WCAG 1.0 indican mediante el punto de verificación 9.4 (de prioridad 3 y de prioridad 2 en la Norma UNE 139803) que es necesario poder acceder mediante el tabulador a vínculos, controles de formulario y objetos. Sin embargo no se especifica si es necesario que el foco sea visible.
Esto se corrige en las WCAG 2.0 Su criterio de conformidad 2.4.7 (nivel AA) especifica claramente que el foco debe ser visible, de hecho incluye como fallos habituales las dos prácticas comentadas:
- F55: Failure of Success Criteria 2.1.1, 2.4.7, and 3.2.1 due to using script to remove focus when focus is received
- F78: Failure of Success Criterion 2.4.7 due to styling element outlines and borders in a way that removes or renders non-visible the visual focus indicator.
Por tanto, no sólo se debe poder acceder mediante el tabulador a toda imagen que sea enlace, sino que además cuando coja el foco este debe ser visible como se aprecia en este ejemplo:
Si el foco es visible facilita el uso de las páginas web mediante el teclado al permitir reconocer visualmente y en todo momento cuál es el componente con el cual se está interactuando. Asimismo, resaltar los elementos cuando reciben el foco también sirve para que los usuarios sepan que se trata de elementos de interacción.
Por otra parte, las personas con problemas de atención, memoria a corto plazo o limitaciones para realizar procesos también se benefician al poder reconocer en todo momento dónde se encuentra el foco.
En caso de que queramos modificar la presentación del indicador del foco por defecto, debemos hacerlo de forma que mejoremos claramente su visibilidad (por ejemplo cuando un campo del formulario coja el foco que presente bordes anchos y otro color de fondo) y que se muestre tanto al coger el foco con el ratón como mediante el teclado.
También es importante otro aspecto relacionado con el foco, y es que los enlaces ocultos (por ejemplo para "saltar al contenido") deben ser visibles al menos cuando cojan el foco porque si siempre están ocultos generan desorientación y confusión a los usuarios de teclado al tabular por elementos no visibles.
20. ¿Hay alguna limitación en cuanto al ancho de un bloque de texto? ¿Alguna pauta de accesibilidad indica el número de caracteres que debe tener?
Una duda habitual es la anchura que debe tener (en número de carácteres) un bloque de texto para su óptima legibilidad. Hay muchos estudios al respecto, unos recomiendan entre 80-100 caracteres y otros entre 60-80 por ser el ancho preferido de los usuarios. Se pueden consultar esos estudios en el artículo "Columnas, anchos de línea y legibilidad" de Juan Carlos García.
¿Dicen algo al respecto las WCAG? El criterio de conformidad 1.4.8 (nivel AAA) indica que el ancho de un bloque de texto no debe ser mayor de 80 caracteres o símbolos (40 si se trata de chino, japonés o coreano)..
For people with some reading or vision disabilities, long lines of text can become a significant barrier. They have trouble keeping their place and following the flow of text. Having a narrow block of text makes it easier for them to continue on to the next line in a block. Lines should not exceed 80 characters or glyphs (40 if CJK), where glyphs are the element of writing in the writing system for the text.
En relación con este requisito, las técnicas que aseguran que sea así aunque se redimensione el navegador son :
- C20: Using relative measurements to set column widths so that lines can average 80 characters or less when the browser is resized, o
- H87: Not interfering with the user agent's reflow of text as the viewing window is narrowed
Para cumplir este requisito es suficiente con no interferir en la reubicación del texto cuando se disminuye el tamaño de la ventana (hasta una cuarta parte del ancho de la pantalla). El objetivo es permitir que los usuarios puedan redimensionar la ventana hasta conseguir un ancho de línea ideal sin que se produzca scroll horizontal para leer una línea de texto.
Para ello el ancho de los contenedores principales de texto se deberá definir con unidades de medida relativas.
En este criterio de conformidad también se especifica que el espacio entre líneas (interlineado) debe ser, al menos, un espacio y medio dentro de los párrafos y el espacio entre párrafos, al menos, de 1.5 veces mayor que el espacio entre líneas.
People with some cognitive disabilities find it difficult to track text where the lines are close together. Providing extra space between lines and paragraphs allows them to better track the next line and to recognize when they have reached the end of a paragraph. It is best if there are several different options, for instance, space-and-a-half and double spacing for line spacing. By space and a half within paragraphs we mean that top of one line is 150% further from the top of the line below it than would be true when the text is 'single spaced' (the default spacing for the font). By Paragraph spacing that is 1.5 times larger than the line spacing we mean that the spacing from the top of the last line of 1 paragraph is 250% farther from the Top of the first line of the next paragraph (i.e., that there is a blank line between the two paragraphs that is 150% of the single space blank line).
21. ¿Una versión de alto contraste suple los requerimientos obligatorios de contraste entre el color de primer plano y el del fondo?
La técnica G174 de las WCAG 2.0 ofrece como alternativa para cumplir con los criterios de conformidad 1.4.3 y 1.4.6 referentes al contraste de color, el utilizar la cláusula de "Version alternativa" de los requisitos de conformidad e incluir un botón o enlace para visualizar la página en alto contraste. Un ejemplo de una web que ofrece una versión en alto contraste es: Media, del Ministerio de Educación.
Pero para que se utilice con éxito esta técnica es necesario:
- El botón o enlace a la versión alto contraste debe cumplir con los requerimientos de contraste.
- La versión alto contraste debe tener el mismo contenido y funcionalidad.
- La versión alto contraste debe cumplir con todos los demás requisitos de accesibilidad.
Los dos últimos requisitos no deben suponer un problema si simplemente se carga una CSS diferente.
22. ¿Cuándo puedo ponerle a una imagen alt=""?
¿Qué entendemos por imagen decorativa? Cualquier imagen que no forma parte del contenido significativo de la página y que por tanto debería ser ignorada por los lectores de pantalla. Según la definición incluida en el criterio de conformidad 1.1.1: serving only an aesthetic purpose, providing no information, and having no functionality
Las imágenes decorativas deberían estar definidas en las CSS, pero si se incluyen en las páginas deben tener alt=""
El error cómun F39. Failure of Success Criterion 1.1.1 due to providing a text alternative that is not null (e.g., alt="spacer" or alt="image") for images that should be ignored by assistive technology indica además que aunque es válido alt=" " (ojo, se admite un espacio en blanco pero no que contenga  ) es más recomendable usar alt="".
Además las imágenes decorativas no podrán tener el atributo "title" o este deberá estar vacío (ver técnica H67)
NO se puede considerar que una imagen es decorativa (y por tanto no puede estar definida en la CSS ni tener alt=""):
- si es un enlace, a no ser que sea un icono que acompaña a un texto y el enlace los englobe a los dos, en cuyo caso el alt del icono sí deberá ser vacío (ver técnica H2)
- si incluye texto, a no ser que dicho texto sea también decorativo, entendiendo como tal (ver criterio de conformidad 1.4.9): Text is only purely decorative if the words can be rearranged or substituted without changing their purpose. Example: The cover page of a dictionary has random words in very light text in the background.
23. ¿Es correcto que el contenido de un input se borre al coger el foco?
En el criterio de conformidad 3.2.2 se especifica que un cambio de contenido no siempre es un cambio de contexto. En este caso es válido que se borre el texto de un input al coger el foco pues supone un cambio de contenido pero no un cambio de contexto.
Por el contrario, no sería válido el comportamiento que se implementa a veces en los campos de fecha o de número de cuenta, en los que al terminar de incluir el contenido del campo el foco salta automáticamente al siguiente campo, pues en este caso sí que es un cambio de contexto. Según se especifica, si se implementa este comportamiento se debe incluir una explicación antes de los campos: consultar la ténica G13: Describing what will happen before a change to a form control that causes a change of context to occur is made
24. ¿Qué se considera texto grande y texto pequeño?
En algunos criterios de conformidad de las WCAG 2.0 (1.4.3, 1.4.6) se establecen diferentes obligaciones en función de si el tamaño de texto es grande o no.
En el criterio de conformidad 1.4.3 se indica:
large scale (text)
with at least 18 point or 14 point bold or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts
Note 1: Fonts with extraordinarily thin strokes or unusual features and characteristics that reduce the familiarity of their letter forms are harder to read, especially at lower contrast levels.
Note 2: Font size is the size when the content is delivered. It does not include resizing that may be done by a user.
Note 3: The actual size of the character that a user sees is dependent both on the author-defined size and the user's display or user-agent settings. For many mainstream body text fonts, 14 and 18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text (assuming that the body font is 100%), but authors would need to check this for the particular fonts in use. When fonts are defined in relative units, the actual point size is calculated by the user agent for display. The point size should be obtained from the user agent, or calculated based on font metrics as the user agent does, when evaluating this success criterion. Users who have low vision would be responsible for choosing appropriate settings.
Note 4: When using text without specifying the font size, the smallest font size used on major browsers for unspecified text would be a reasonable size to assume for the font. If a level 1 heading is rendered in 14pt bold or higher on major browsers, then it would be reasonable to assume it is large text. Relative scaling can be calculated from the default sizes in a similar fashion.
Note 5: The 18 and 14 point sizes for roman texts are taken from the minimum size for large print (14pt) and the larger standard font size (18pt). For other fonts such as CJK languages, the "equivalent" sizes would be the minimum large print size used for those languages and the next larger standard large print size.
En resumen, se considera texto grande al que tiene al menos 18 pt o 14 pt en negrita, medidas que, salvo para las fuentes muy delgadas o inusuales, se consideran suficientes para la mayor parte de las tipografías.
En cuanto al texto incluido en las imágenes se especifica:
Note: Because different image editing applications default to different pixel densities (ex. 72 PPI or 96 PPI), specifying point sizes for fonts from within an image editing application can be unreliable when it comes to presenting text at a specific size. When creating images of large-scale text, authors should ensure that the text in the resulting image is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text. For example, for a 72 PPI image, an author would need to use approximately 19 pt and 24 pt font sizes in order to successfully present large-scale images of text to a user.
25. ¿Es obligatorio antes de enviar un formulario que el usuario confirme el envío?
El criterio de conformidad 3.3.4 (nivel AA) indica que es necesario que:
- los envíos sean reversibles,
- o bien que se puedan comprobar los datos y dar la oportunidad al usuario de corregirlos,
- o bien que se ofrezca un mecanismo para revisar, confirmar y corregir la información antes de enviarla.
El criterio 3.3.4 sólo obliga a las páginas que:
- causen compromisos legales
- supongan una transación económica
- modifiquen o borren datos controlables por el usuario
- envíen respuestas del usuario a algún tipo de prueba
Sin embargo, el criterio de conformidad 3.3.6, que es de nivel AAA y por tanto es más estricto, obliga a cualquier tipo de envío de información.
Se pueden consultar las distintas formulas para implementar estas opciones en las técnicas asociadas a este criterio 3.3.4

Artículos relacionados:

Formularios accesibles según las WCAG 2.0

2009-06-02T22:54:00.025+02:00

Artículos relacionados
[30-01-11] Respuesta a 25 dudas habituales sobre accesibilidad web
[27-03-09] AJAX accesible IV: Técnicas ARIA de las WCAG 2.0
[12-02-08] WCAG 2.0
[28-02-08] Formularios usables: 60 Directrices de Usabilidad

El objetivo de este artículo es la presentación de una serie de documentos que facilitan la evaluación de la accesibilidad de los formularios de acuerdo con los criterios definidos en las WCAG 2.0:

Técnicas WCAG 2.0 asociadas a la implementación de formularios accesibles
Guía rápida de normas de accesibilidad WCAG 2.0 para formularios
Checklist para validar formularios de acuerdo con las WCAG 2.0
Documentación de interés

Una de las cosas que más llamó mi atención cuando leí las WCAG 2.0 y sus técnicas asociadas (Techniques for WCAG 2.0) es el gran número de ellas que están referidas a los formularios.

Muchas de las prácticas que hasta ahora eran recomendables para hacer un formulario lo más usable posible y que recopilé en "Formularios usables: 60 Directrices de Usabilidad", están ahora recogidas en las WCAG 2.0 y se convierten por tanto en requisitos imprescindibles para que los formularios sean accesibles.

A continuación presento una serie de documentos que he elaborado para evaluar la accesibilidad de los formularios de acuerdo con los criterios definidos en las WCAG 2.0.

Técnicas WCAG 2.0 asociadas a la implementación de formularios accesibles

Las técnicas de las WCAG 2.0 están organizadas temáticamente, pero por desgracia, la documentación de las WCAG 2.0 no incluye un índice de las técnicas referentes a formularios, a enlaces, etc.

Por ello, el primer documento que necesité elaborar fue una recopilación de las técnicas relacionadas con los formularios. Dicha recopilación es extensa puesto que incluye el título de las 47 técnicas asociadas a formularios, su enlace, descripción y procedimiento de validación.

Documento: Técnicas WCAG 2.0 asociadas a la implementación de formularios accesibles (word, 320KB). Descarga directa. Documento en inglés salvo la introducción.

Guía rápida de normas de accesibilidad WCAG 2.0 para formularios

Una vez recopiladas y estudiadas las técnicas WCAG 2.0 relacionadas con los formularios, me resultó imprescindible la creación de un listado de normas de accesibilidad, fácil de consultar y memorizar.

A continuación incluyo la lista de normas de accesibilidad y las técnicas que las avalan. Asociada a cada técnica indico si es una técnica "sufficient" o "advisory" (obligatoria o recomendada), así como los criterios de éxito asociados a cada una y su nivel (A,AA,AAA)

Es importante tener en cuenta que a veces las técnicas se aplican o no en función de unas reglas, o que el desarrollador puede elegir entre varias técnicas para cumplir con un criterio de éxito, recopilo esta información en el documento Checklist para validar formularios de acuerdo con las WCAG 2.0.

Utiliza controles de formulario de forma estándar indicando correctamente su nombre, valor y estado (H91 - Sufficient [2.1.1 - A, 4.1.2 - A])
No limites el tiempo que el usuario dispone para completar un formulario, o dispón de un mecanismo para anular o ampliar el límite de tiempo (G5 - Sufficient [2.2.3 - AAA], G133 - Sufficient [2.2.1 - A], G198 - Sufficient [2.2.1 - A])
Proporciona un botón de tipo "submit" para iniciar un cambio de contexto. Si un control de formulario provoca un cambio de contexto debes informar de ello previamente (G13 - Sufficient para la 3.2.2 - A - Advisory para la 3.3.2 - A, G80 - Sufficient [3.2.2 - A], H32 - Sufficient [3.2.2 - A] - , H84 - Sufficient [3.2.2 - A], F9, F36)

La técnica SCR19 - Sufficient [3.2.5 - AAA] explica cómo asociar un evento ONCHANGE a una SELECT sin causar un cambio de contexto.
Indica si un campo es obligatorio en el LABEL asociado al campo, por ejemplo mediante un texto "(obligatorio)" o mediante un asterisco explicando su significado al comienzo del formulario (H90 ? [3.3.2 - A])
Proporciona descripciones textuales (no un mero asterisco o cambio de color) para identificar los campos obligatorios que no fueron completados (G83 - Sufficient [3.3.1 - A, 3.3.3- AA, 3.3.2 - A], F81)
Cuando se produzca un error de validación proporciona una descripción textual que:
- Describa la naturaleza del problema
- Informe de los valores admitidos
- Proporcione ejemplos de valores correctos o incluso propuesta de valores similares a los introducidos pero correctos (mediante corrección ortográfica por ejemplo)
- Permita localizar los campos que han provocado el error (si la descripción se sitúa al comienzo del formulario) mediante un enlace a dichos campos, y un enlace al listado de errores.
(G84 - Sufficient [3.3.1 - A, 3.3.3- AA], G85 - Sufficient [3.3.1 - A, 3.3.3 - AA], G139 - Advisory [3.3.1 - A, 3.3.3 - AA], G177 - Sufficient [3.3.3- AA], G194 - Sufficient [3.3.5 - AAA])

La técnica SCR32 - Sufficient [3.3.1 - A,3.3.3 - AA] describe cómo realizar validaciones en cliente y añadir el texto de los errores vía DOM.
Valida los campos en cliente advirtiendo del error y devolviendo el foco al campo que produjo el error (SCR18 - Sufficient [3.3.1- A,3.3.3 - AA] salvo para 3.3.4 - AA que es Advisory)
Los campos que requieran un formato de datos concreto (fechas, nº de cuenta, etc.) deben tener asociada información sobre el formato esperado o un ejemplo (G89- Sufficient [3.3.2 - A, 3.3.5 - AAA])
Cuando el formulario es corto o tiene muchos campos del mismo tipo, incluir un texto de instrucciones al comienzo del formulario en vez de repetir la información en cada campo (G184 - Sufficient [3.3.2 - A,3.3.5 - AAA])
Se debe proporcionar una página de verificación de datos que permita modificarlos cuando el formulario supone una operación irreversible, por ejemplo de tipo financiero o jurídico (G98 - Sufficient [3.3.4 -A, 3.3.6 -AAA])
Cuando una aplicación Web ofrece la posibilidad de suprimir información, el servidor debe proporcionar un medio para recuperar la información que el usuario ha eliminado por error (G99 - Sufficient [3.3.4 - AA, 3.3.6 - AAA])
Cuando el formulario realiza una operación irreversible (eliminar datos, transacción económica) proporcionar un check no seleccionado por defecto del tipo "Confirmo que he revisado los campos y deseo enviar/eliminar" (G155 - Sufficient [3.3.4 - AA, 3.3.6 - AAA])
En las situaciones en las cuales una acción no se puede deshacer, pida confirmación antes de enviar un formulario indicando la opción seleccionada y sus consecuencias (G168 - Sufficient [3.3.4 - AA, 3.3.6 - AAA])
Establecer un periodo de tiempo durante el cual los usuarios pueden cancelar o modificar la orden enviada con el formulario. Debe indicarse el periodo de cancelación y el procedimiento para el mismo. (G164 - Sufficient [3.3.4 -AA, 3.3.6 - AAA])
Debe ser evidente el campo que tiene el foco, por ejemplo el agente de usuario debe mostrar la barra vertical parpadeante en el punto de inserción de contenido de un campo de texto o puntear el contorno de los radios y checks (G149 - Sufficient [2.4.7 - AA])
Cada control de formulario debe tener una etiqueta visible inmediatamente después en el caso de los radios y checks e inmediantemente delante (sobre el campo o a la izquierda del mismo) en el resto de controles (G162 - Sufficient [3.3.2 - A], F86)
Utiliza elementos LABEL para asociar etiquetas a los controles del formulario. Asócialos de forma explícita (H44 - Sufficient [1.1.1 - A, 1.3.1 - A, 3.3.2 - A, 4.1.2 - A], F86)
Utiliza el atributo TITLE para identificar los controles del formulario cuando el elemento LABEL no puede ser usado. Por ejemplo, en el caso de un LABEL, un INPUT de búsqueda y una SELECT para restringir la búsqueda, esta SELECT sin LABEL asociado llevaría el TITLE "Busca en" (H65 - Sufficient [1.1.1 - A, 1.3.1 - A, 3.3.2 - A, 4.1.2 - A)
Utiliza el atributo TITLE para proporcionar ayuda contextual en los controles del formulario (H89 - Advisory [3.3.5 - AAA], F86)
Cuando un botón está asociado a un control de formulario (por ejemplo un campo de texto más un botón "buscar") el botón debe situarse inmediatamente después del campo. El campo no tiene porque tener etiqueta (de este modo se evita contenido repetido en la página) pero el texto del botón debe ser muy claro puesto que sirve tambień de etiqueta para el control (G167 - Sufficient [3.3.2 - A])
Los nombres, etiquetas, etc. deben ser consistentes para el contenido con una misma funcionalidad (G197 - Sufficient [3.2.4 - AA])
Informa convenientemente de que el formulario se ha enviado con éxito (G199 - Advisory [3.3.1 - A, 3.3.2 -A, 3.3.4- AA, 3.3.6 -AAA])
Proporciona un orden de tabulación lógico mediante tabindex cuando el de por defecto no es suficiente (H4 - Sufficient [2.4.3 - A])
Agrupa semánticamente los controles relacionados, especialmente los radio y checks mediante FIELDSET y LEGEND (H71 - Sufficient [1.3.1 - A, 3.3.2 - A])
Agrupa los OPTIONS de una SELECT mediante OPTGROUP (H85 - Sufficient [1.3.1 - A])
Usa eventos independientes del dispositivo, ofreciendo de forma redundante eventos de teclado y ratón (SCR2 - Sufficient [2.1.1 - A, 2.1.3 - AAA], SCR20- Sufficient [2.1.1 -A, 2.1.3-AAA])

La técnica SCR35 - Sufficient [2.1.1-A, 2.1.3-AAA] explica como el evento ONCLICK es accesible desde teclado y ratón.
El tamaño del texto introducido en los campos de un formulario debe también aumentar cuando se incrementa el tamaño de fuente del contenido (C17 - Advisory [1.4.4 - AA], ? [1.4.8- AAA])
Identifica los campos obligatorios mediante la propiedad REQUIRED (ARIA2 - Advisory [3.3.3 - AA])

La técnica ARIA4 - Advisory [1.3.1 - A, 3.3.2 - A] explica como añadir la propiedad de forma dinámica.
Identifica el rango de valores válido mediante las propiedades VALUEMIN y VALUEMAX (ARIA3 - Advisory [3.3.3 - AA])

Checklist para validar formularios de acuerdo con las WCAG 2.0

Una vez interiorizadas las normas de accesibilidad que deben cumplir los formularios, el siguiente documento que me resultó necesario crear fue una herramienta de trabajo que facilitara las labores de revisión.

Este documento es una excel que tiene las siguientes columnas ordenadas por el nivel de cumplimiento (A,AA,AA) y el tipo de técnica (sufficient, advisory o failure):

Número y enlace de la técnica
Criterios de éxito asociados y su nivel de cumplimiento
Enlace a las normas de aplicación asociadas a la técnica
Procedimiento de validación (en versión original en inglés)
Celda para indicar si se cumple o no la técnica
Celda para apuntar observaciones

Documento: Checklist para validar formularios de acuerdo con las WCAG 2.0 (Excel, 85KB). Descarga gratuita previa aceptación del contrato coloriuris.

Documentación de interés

Documentando este artículo me encontré con uno muy bueno, que recomiendo leer de forma complementaria: "Accessible Forms using WCAG 2.0" de Roger Hudson.

También recomiendo leer:

Formularios usables: 60 Directrices de Usabilidad
Las Elmer 2: User interface guidelines for governmental forms on the Internet (PDF), guía del Gobierno de Noruega sobre la creación de formularios usables y accesibles.

Técnicas WCAG 2.0 para 10 dudas habituales sobre accesibilidad

2009-05-05T21:30:00.022+02:00

El contenido de este artículo se ha movido a la recopilación Respuesta a 25 dudas habituales sobre accesibilidad web

AJAX accesible IV: Técnicas ARIA de las WCAG 2.0

2009-03-27T21:55:00.019+01:00

Artículos relacionados
[26-05-07] AJAX accesible I
[07-09-07] AJAX accesible II: WAI-ARIA
[22-10-07] AJAX accesible III: HIJAX
[12-02-08] WCAG 2.0
[5-05-09] Técnicas WCAG 2.0 para 10 dudas habituales sobre accesibilidad

Las WCAG 2.0 (Web Content Accessibility Guidelines 2.0) incluyen cuatro técnicas (Techniques for WCAG 2.0: Techniques and Failures for Web Content Accessibility Guidelines 2.0) específicas relacionadas con WAI- ARIA.

Estas técnicas son de momento "advisory technique", pero serán "sufficient technique" en cuanto la especificación alcance el estado de recomendación, tal y como se advierte en las mismas.

ARIA1: Using Accessible Rich Internet Application describedby property to provide a descriptive, programmatically determined label

The purpose of this technique is to demonstrate how to use the Accessible Rich Internet Application (ARIA) descibedby property to provide descriptive information about a user interface control that can be programmatically determined by user agents.

ARIA techniques provide the ability to add programmatically determined information to an element which can provide additional information about the element. The user agent can provide this additional information to assistive technology for presentation to the user.

Ejemplo:


<p>The link in the next paragraph has been updated with the Accessible Rich Internet Applications describedby property to provide more information about the link</p>

<p><span id="icebergInfo">Alaskan storm cracks iceberg in Antarctica. </span>

A bad storm in Alaska last October generated an ocean swell that broke apart a giant iceberg near Antarctica six days later, U.S. researchers reported on Monday.

<a href="http://www.sciencemag.com/iceberg.html" id="iceberg" waistate:describedby="icebergInfo">More Info...</a>.
</p>

ARIA2: Identifying required fields with the "required" property

The objective of this technique is to indicate that the completion of a user input field is mandatory in a programmatically determinable way. The WAI-ARIA required state indicates that user input is required before submission. The "required" state can have values of "true" or "false". For example, if a user must fill in an address field, then "required" is set to true.

Note: The fact that the element is required is often visually presented (such as a sign or symbol after the control). Using the "required" property makes it much easier for user agents to pass on this important information to the user in a user agent-specific manner.

Ejemplo:


<label for="test">Test (required)</label>
<input name="test" id="test" aaa:required="true" />

ARIA3: Identifying valid range information with the "valuemin" and "valuemax" properties

The objective of this technique is to provide information about the allowable range of an entry field in a programmatically determinable way. The WAI-ARIA valuemin and valuemax states provide the minimum and maximum (respectively) values that may be provided by the user. User agents will not permit users to enter values outside that range, or will generate a validation error if users do so.

Ejemplo:


<form action="http://example.com/submit">
  
<p><label for="test">Enter a date in 2007:</label>
<input name="test" id="test" aaa:valuemin="2007-01-01" aaa:valuemax="2007-12-31" aaa:datatype="xsd:date" />
</p>

<p><input type="submit" value="Submit" /></p>

</form>

ARIA4: Using Accessible Rich Internet Applications to programmatically identify form fields as required

La manera de implementar la técnica ARIA2 de forma dinámica se ejemplifica así:

Ejemplo:


<head>
 <script type="text/javascript">
 //<![CDATA[
 
 // array or ids on the required fields on this page
 var requiredIds = new Array( "firstName", "lastName");
 
// function that is run after the page has loaded 
to set the required role on each of the 
 //elements in requiredIds array of id values
 function setRequired(){
  if (requiredIds){
   var field;
   for (var i = 0; i< requiredIds.length; i++){
    field = document.getElementById(requiredIds[i]);
    setAttrNS(field, "required", "true");
   }
  }
 }
 
 // method to set the attribute values based on the capability 
of the browser.  
 // Use setAttributeNS if it is available,
 // otherwise append a namespace indicator string to the 
attribute and set its value.
 function setAttrNS(elemObj, theAttr, theValue){
  if (typeof document.documentElement.setAttributeNS
      != 'undefined') {
   elemObj.setAttributeNS
   ("http://www.w3.org/2005/07/aaa", theAttr, theValue);
  }else{
   elemObj.setAttribute("aaa:" + theAttr, theValue);
  }
 }
 window.onload=setRequired;
//]]>
 </script>
 </head>
 <body>
 <p>Please enter the following data.  
 Required fields have been programmatically identified 
 as required and  marked with an asterisk (*) following 
 the field label.</p>
 <form action="submit.php">
 <p>
 <label for="firstName">First Name *: </label>
 <input type="text" name="firstName" 
    id="firstName" value="" />
 <label for="lastName">Last Name *: </label>
 <input type="text" name="lastName"
    id="lastName"  value="" />
 </p>
 </form>
 </body>

Usable y accesible

PDF Techniques for WCAG 2.0

Tabla resumen de los criterios de éxito a los que están asociados cada una de las técnicas PDF

Artículos relacionados

Servicios relacionados

Respuesta a 25 dudas habituales sobre accesibilidad web

1. ¿Puedo utilizar ventanas emergentes?

H83: Using the target attribute to open a new window on user request and indicating this in link text

¿Se puede ocultar la aclaración "se abre en ventana nueva" mediante la CSS? ¿Se puede indicar en el title del enlace?

SCR24: Using progressive enhancement to open new windows on user request

Conclusión

2. ¿Puedo utilizar frames?

3. ¿Puedo utilizar tablas para maquetar?

4. ¿Mi sitio es inaccesible si utiliza Flash?

5. ¿Mi sitio es inaccesible si utiliza javascript?

¿Es necesario ofrecer una alternativa al JavaScript? ¿Se debe realizar una versión que funcione sin JavaScript?

6. ¿Cómo debo asociar los labels y los campos del formulario: de forma explícita o implícita?

7. ¿Cómo debo presentar el texto: justificado o alineado a la izquierda?

8. ¿Cómo he de marcar correctamente las abreviaciones y acrónimos?

Si la abreviación tiene un único significado en la página

Si la abreviación tiene diferentes significados dentro de la misma página

9. ¿Es correcto utilizar botones en la página que permitan aumentar el tamaño del texto?

10. ¿Cómo se especifica correctamente el color de fondo y primer plano?

11. ¿Cómo marcar adecuadamente un emoticon?

12. ¿Es correcto que aparezca en el código HTML un H2 antes que un H1?

13. ¿Es recomendable incluir una opción de "Leer está página"?

14. ¿Cuánto se ha de poder ampliar el tamaño de un texto?

15. ¿Cómo marcar la pronunciación de una palabra?

16. ¿Cómo se implementan de forma accesible los enlaces con el mismo texto que enlazan con diferentes páginas?

17. ¿Debo indicar el cambio de idioma en cualquier tipo de palabra?

18. ¿Cualquier sonido automático de la página tiene que tener la opción de pausar o detener el audio?

19. ¿Está permitido que las imágenes que son enlaces no queden punteadas alrededor al coger el foco?

20. ¿Hay alguna limitación en cuanto al ancho de un bloque de texto? ¿Alguna pauta de accesibilidad indica el número de caracteres que debe tener?

21. ¿Una versión de alto contraste suple los requerimientos obligatorios de contraste entre el color de primer plano y el del fondo?

22. ¿Cuándo puedo ponerle a una imagen alt=""?

23. ¿Es correcto que el contenido de un input se borre al coger el foco?

24. ¿Qué se considera texto grande y texto pequeño?

25. ¿Es obligatorio antes de enviar un formulario que el usuario confirme el envío?

Formularios accesibles según las WCAG 2.0

Técnicas WCAG 2.0 asociadas a la implementación de formularios accesibles

Guía rápida de normas de accesibilidad WCAG 2.0 para formularios

Checklist para validar formularios de acuerdo con las WCAG 2.0

Documentación de interés

Técnicas WCAG 2.0 para 10 dudas habituales sobre accesibilidad

AJAX accesible IV: Técnicas ARIA de las WCAG 2.0

ARIA1: Using Accessible Rich Internet Application describedby property to provide a descriptive, programmatically determined label

ARIA2: Identifying required fields with the "required" property

ARIA3: Identifying valid range information with the "valuemin" and "valuemax" properties

ARIA4: Using Accessible Rich Internet Applications to programmatically identify form fields as required

23. ¿Es correcto que el contenido de un `input` se borre al coger el foco?