Usable y accesible

Falsos errores de validadores automáticos de accesibilidad basados en las WCAG 2.0

2012-05-06T01:12:00.000+02:00

Falso Error 1: campo de texto sin LABEL asociado... pero que tiene un TITLE adecuado

Los criterios de conformidad 1.1.1, 1.3.1, 3.3.2 y 4.1.2 hacen referencia a que un campo de formulario debe estar correctamente identificado, lo que en las WCAG 1.0 era el punto de verificación 12.4 Asocie explícitamente las etiquetas con sus controles. [Prioridad 2]

En estos cuatro criterios de conformidad de las WCAG 2.0 se admite una de estas dos técnicas suficientes para cumplirlos:

H44: Using label elements to associate text labels with form controls
H65: Using the title attribute to identify form controls when the label element cannot be used

Aunque lo más recomendable siempre es utilizar la técnica H44 y asociar cada campo de formulario (salvo los de tipo button o los input de tipo image, submit, reset y hidden) con su correspondiente label, hay casos en los que no podemos usar label o este podría resultar confuso. En esos casos podemos usar la técnica H65, es decir, no etiquetar el campo con label sino usar el atributo title para etiquetar el campo e identificar su propósito.

Ejemplos en los que podríamos usar el atributo title de un campo de formulario para etiquetarlo en vez de etiquetarlo con label:

Cuando para introducir una fecha o un código de cuenta en un formulario tenemos varios campos (por ejemplo campos diferentes para día, mes, año). En estos casos podemos identificar cada uno de esos campos con el atributo title (sin necesidad de que cada uno tenga un label)
Cuando tenemos un campo de búsqueda y un botón Buscar sin una etiqueta previa "Buscar" o "Buscador". Si debemos respetar el diseño podemos etiquetar el campo de búsqueda mediante su atributo title. En este caso además contamos con la técnica suficiente G167 Using an adjacent button to label the purpose of a field, en la que se indica concretamente que un botón "Buscar" justo a continuación de un campo de búsqueda es suficiente para cumplir con el criterio de conformidad 3.3.2
Una tabla en la que el contenido de alguna de sus celdas sea un campo de formulario. Por ejemplo la tabla resumen de tu pedido en un ecommerce, en la que el contenido de una de sus columnas sea un campo editable con el número de unidades de cada producto.

Sin embargo, hay validadores automáticos de accesibilidad basados en las WCAG 2.0 que anuncian un error cuando encuentran un campo sin un label asociado, aunque este tenga un atributo title adecuado.

Validadores que SÍ dan este falso error: Examinator

Validadores que NO dan este falso error: TAW, AChecker, Deque Worldspace Free Analysis, AccessMonitor

Falso Error 2: imagen que es un enlace y tiene ALT vacío... pero que va acompañada por un texto dentro del enlace

Es el siguiente caso, correcto como se puede consultar por ejemplo en la técnica H2, y que por tanto no está incumpliendo el criterio de conformidad 1.1.1:

<a href="ayuda.html"><img src="image/ayuda.gif" alt="" /> Ayuda</a>

Sin embargo hay validadores automáticos de accesibilidad basados en las WCAG 2.0 que anuncian un error cuando encuentran una imagen dentro de un enlace si dicha imagen tiene ALT vacío, sin tener en cuenta que puede ser un caso como el descrito.

Validadores que SÍ dan este falso error: AChecker

Validadores que NO dan este falso error (o solo advierten que las imágenes decorativas es mejor incluirlas en las CSS): TAW, Examinator, Deque Worldspace Free Analysis, AccessMonitor

Falso Error 3: H2 presente en el código antes que un H1... sin tener en cuenta que estén bien marcados

La técnica H42 Using h1-h6 to identify headings, incluye un ejemplo 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".

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.

Sin embargo hay validadores automáticos de accesibilidad basados en las WCAG 2.0 que anuncian un error cuando encuentran un encabezado superior colocado en el código después de uno inferior, cuando solo deberían reportar una advertencia para que se revise que están bien marcados.

Validadores que SÍ dan este falso error: Deque Worldspace Free Analysis

Validadores que NO dan este falso error: TAW (en una versión anterior sí daba error pero ya está corregido), Examinator, AChecker, AccessMonitor

Falso Error 4: indicar en cualquier caso que es obligatorio incluir enlaces para saltar bloques de contenido y un primer enlace en la página que lleve al contenido principal de la misma

El criterio de conformidad 2.4.1 Evitar bloques: Existe un mecanismo para evitar los bloques de contenido que se repiten en múltiples páginas web (Nivel A), se puede cumplir de dos formas diferentes (tal y como se puede consultar en Understanding SC 2.4.1):

Agrupando los bloques de contenido de manera que los productos de apoyo puedan reconocerlos y saltarlos: estructurar las páginas con encabezados, agrupando los enlaces en listas, etc.
Proporcionando enlaces para saltar los bloques de contenido, en cuyo caso se ofrece un listado de técnicas de las que es necesario elegir al menos una, entre ellas las dos que comento.

Por tanto, no se puede reportar siempre y en todos los casos como error que no haya un enlace al comienzo de la página para ir al contenido principal. Puede que la página esté bien estructurada y por tanto se esté cumpliendo con el criterio de conformidad 2.4.1. Puede además que no haya claramente un área de contenido principal y por tanto este enlace no resulte útil.

De la misma manera, no se puede reportar siempre y en todos lo casos que no haya enlaces para saltar bloques de contenido.

Y en cualquier caso, no se debería incluir como error ambas, sino indicar que al menos es necesario una de ellas.

Validadores que SÍ dan este falso error: Examinator, AccessMonitor

Validadores que NO dan este falso error: TAW, Deque Worldspace Free Analysis, AChecker

Hasta aquí los que he detectado por ahora. ¿Conocéis más falsos errores?

Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM)

2012-04-08T21:39:00.002+02:00

El 27 de marzo (de 2012) el W3C/WAI publicó el primer borrador de la "Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM)" (según la traducción que hace la nota de prensa del W3C España), en inglés "Website Accessibility Conformance Evaluation Methodology 1.0".

Este borrador de trabajo es un primer esbozo y, como se indica, puede ser actualizado, reemplazado o quedar obsoleto en cualquier momento. Por otra parte algunas de sus secciones están todavía sin desarrollar. Sin embargo, es un documento de gran interés para los consultores de accesibilidad que solo está disponible en inglés. El objetivo de este artículo es difundirlo y resumirlo en castellano, actualizándolo a medida que se publiquen nuevas versiones.

Hasta el 27 de abril se pueden enviar comentarios sobre este primer borrador, que son públicos y se pueden consultar en "public-wcag-em-comments@w3.org Mail Archives".

WCAG-EM pretende proporcionar una metodología armonizada internacionalmente para la evaluación de sitos web (incluyendo aplicaciones web y sitios web para dispositivos móviles) en conformidad con las WCAG 2.0

Es independiente del tamaño del sitio web o de la tecnología con la que se construye el mismo. Es además independiente de herramientas de evaluación de accesibilidad, navegadores web o productos de apoyo concretos.

Debido a que generalmente no es factible ni conveniente evaluar cada una de las páginas de un sitio web, resulta fundamental emplear un método fiable para determinar la conformidad global de un sitio web. En el documento se especifican los pasos concretos para definir el alcance de la evaluación, seleccionar una muestra representativa, auditar la muestra seleccionada y reportar los resultados de la evaluación mediante informes estructurados y uniformes.

Esta metodología se utiliza para una exhaustiva evaluación de la conformidad de sitios web de acuerdo sobre las WCAG 2.0 Para la revisión preliminar de un sitio que permita identificar los errores más evidentes recomiendan "Preliminary Review of Websites for Accessibility", publicado en la web de la WAI

La metodología se aplica siempre a un sitio web completo sin exclusiones u omisiones de páginas que sirvan a la finalidad y funcionalidad del sitio, y que por tanto forman parte de la navegación, el diseño y los procesos completos del sitio. Sin embargo sí que se permite aplicar a ámbitos claramente separables de un único sitio web, como podría ser la parte pública y la parte privada del mismo.

Se especifica el conocimiento que debería tener el evaluador y que se puede resumir en un profundo conocimiento de las WCAG 2.0, sobre cómo evaluar la accesibilidad y sobre el diseño de web accesibles, y por tanto conocedores de los siguientes recursos:

"Evaluating Websites for Accessibility", una suite de documentos de la WAI que constituye la metodología a seguir para evaluar la accesibilidad de un sitio Web y asegurar la calidad de los procedimientos. Lo traté con detenimiento en el artículo "Metodología para la evaluación de la accesibilidad Web: 'Evaluating Web Sites for Accessibility' de la WAI "
Web Content Accessibility Guidelines (WCAG) 2.0, y todos los documentos asociados ("How to Meet WCAG 2.0 (Quick Reference)", "Understanding WCAG 2.0" y "Techniques for WCAG 2.0")
Accessible Web Design (Designing for Inclusion), y que incluye documentos como: "Essential Components of Web Accessibility", "How People with Disabilities Use the Web", "Developing Websites for Older People", "Web Content Accessibility and Mobile Web" o "Involving Users in Web Projects for Better, Easier Accessibility".

La metodología puede ser llevada a cabo por un evaluador de forma individual o por un equipo de revisión. Se indica que la participación de personas con discapacidad y de personas mayores, aunque no es obligatoria, ayuda a identificar barreras de accesibilidad adicionales.

Tras esta introducción, que se corresponde con un resumen de los apartados 1 y 2 de la WCAG-EM, en el apartado 3 se definen los pasos del procedimiento de evaluación.

Se indica que los detalles de estos pasos pueden variar ligeramente dependiendo del tipo de sitio, el propósito de la evaluación, y el proceso utilizado por el evaluador. Algunos de los pasos también pueden solaparse o llevarse a cabo en paralelo, pero es importante que se tengan en cuenta todos los pasos para garantizar una evaluación fiable. También es importante documentar claramente cada paso para garantizar unos resultados verificables y justificar la declaración de conformidad.

Los pasos son:

Paso 1. Definir el alcance de la evaluación

El alcance se debería definir de acuerdo con quienes han encargado la evaluación para asegurar unas expectativas comunes. Se divide en los siguientes subpasos:

Paso 1a: definir el alcance exacto sin contradecir las limitaciones que se han indicado en el ámbito de aplicación de la metodología. Esto puede requerir conocer la propiedad o el proceso de desarrollo de algunas partes del sitio, y tener que llevarse a cabo a la vez que el paso 2 (navegar por el sitio web)
Paso 1b: definir el objetivo de la evaluación, que puede ser:
- Basic conformance: sólo se identifica si un sitio es o no conforme sin proporcionar información adicional (adecuado por ejemplo si solo se quiere verificar la declaración de conformidad)
- Detailed review: identifica si un sitio web es o no conforme y se proporciona más información sobre los errores identificados, como puede ser el número de errores y su ubicación.
- In-Depth analysis: identifica si un sitio web es o no conforme y se analizan con detalle los errores identificados, incluyendo la descripción de los errores y las sugerencias de soluciones.
- Other: se puede establecer otro objetivo pero debe definirse claramente y con exactitud.
Paso 1c: definir cuál el nivel de adecuación (A, AA, AAA) que se va a evaluar, que puede ser AAA aunque el objetivo a alcanzar sea el nivel A o AA (para tener una visión más completa de la accesibilidad del sitio o para mejorar tipos de contenidos concretos: las tablas, formularios, etc.)
Paso 1d: definir el contexto de uso del sitio web, quién lo usa y cómo lo usa. Es importante identificar si es un sitio público o no (por ejemplo una intranet) Se debe definir el conjunto mínimo de navegadores web y productos de apoyo con los que se va a realizar la evaluación (y que puede variar significativamente en función de si es un sitio público o una intranet, según el idioma, la ubicación geográfica o el público objetivo del sitio)
Paso 1e (opcional): definir las técnicas a utilizar que pueden ser las definidas en "Techniques for WCAG 2.0" pero no obligatoriamente estas. Este paso se puede superponer con el paso 2 (explorar el sitio web), y en todo caso las técnicas exactas que se han usado para evaluar la conformidad con las WCAG 2.0 deben estar documentadas en el paso 5 (informar de los resultados de la evaluación)

Paso 2. Explorar el sitio web

El evaluador debe poder acceder a todas las páginas. Este paso permite comprender mejor el uso y funcionalidad del sitio; y además ayuda a identificar las páginas relevantes o con problemas que son candidatas a incluirse en la muestra a analizar.

Se divide en los siguiente subpasos:

2a: identificar las páginas clave del sitio. Se indican como tales: la home, la página de login y otras páginas de entrada; el mapa web, la/s página/s de contacto, ayuda, información legal; las páginas similares que son enlazadas desde todas las páginas (cabecera, pie o menú de navegación); así como las diferentes plantillas
2b: identificar las funcionalidades clave del sitio, incluyendo las tareas que los usuarios deben llevar a cabo para realizar una funcionalidad (por ejemplo, "selección y compra de un producto", "registrar una cuenta en el sitio", etc.)
2c: identificar diferentes tipos de páginas (no plantillas como en el paso 2a), con diferentes estilos, layout, estructuras y funciones, que a menudo son generadas por diferentes plantillas y escritas por diferentes personas:
- Páginas web con diferentes estilos, layout, estructura, navegación, interacción y diseño visual;
- Páginas con contenido diverso, como los formularios, tablas, listas, encabezados, multimedia y scripts;
- Páginas con diferentes componentes funcionales, tales como selector de fechas, lightbox, slider, y otros;
- Páginas que utilizan diversas tecnologías, tales como HTML, CSS, Flash, JavaScript, PDF, Silverlight y WAI-ARIA;
2d: identificar las tecnologías de las que se depende (según el concepto de las WCAG 2.0: el contenido no puede ser conforme si dicha tecnología se desconecta o no es soportada), que pueden ser HTML, CSS, Flash, JavaScript, PDF, Silverlight, WAI-ARIA, SMIL, SVG, etc.

Paso 3. Seleccionar una muestra representativa

Se debe seleccionar una muestra de páginas que represente a todo el sitio. El tamaño de la muestra dependerá del tamaño y complejidad del sitio.

Los subpasos de los que se compone son:

3a: incluir las páginas principales del sitio. Tienen que formar parte de la muestra todas las plantillas y todas las páginas relevantes (la home, la página de login y otras páginas de entrada; el mapa web, la/s página/s de contacto, ayuda, información legal; las páginas similares que son enlazadas desde todas las páginas como la cabecera, pie o menú de navegación) identificadas en el paso 2a.
3b: incluir al menos dos páginas diferentes (si procede) de las identificadas en:
- el paso 2b: páginas con funcionalidades clave
- el paso 2c: diferentes tipos de páginas
- el paso 2d: páginas con diferentes tecnologías
En sitios complejos puede hacer falta seleccionar más de dos páginas de cada tipo; otras veces una misma página puede ser representativa de varias de estas características.
Debería seguirse siempre este proceso de selección, aunque en re-evaluaciones puede ser útil seleccionar parte de la muestra de una evaluación anterior para comparar el resultado.
3c: incluir otras páginas relevantes para la accesibilidad o las personas con discapacidad:
- Páginas con información y ayuda sobre el uso de la página web o pertinentes para la accesibilidad;
- Páginas especialmente populares y las que se utilizan comúnmente como páginas de entrada al sitio;
- Mensajes de error del servidor web (por ejemplo, la página de error 404) o de una aplicación web;
3d: incluir en la muestra procesos completos. Es decir, todas las páginas de un proceso, no se puede seleccionar solo una página del proceso.

Paso 4. Auditar la muestra seleccionada

Esta sección no está todavía redactada. Los subpasos propuestos (aun sin desarrollar) son:

4a: comprobar para la más amplia variedad de casos de uso
4b: utilizar cuando sea posible las "WCAG 2.0 Techniques"
4c: evaluar la accesibilidad según las técnicas utilizadas y las características de accesibilidad identificadas
4d (opcional): archivar las páginas auditadas (en un pantallazo, guardando una copia, etc.) para futuras referencias o controversias.
4e (opcional): registrar las herramientas y métodos de evaluación

Paso 5. Informar de los resultados de la evaluación

Esta sección no está todavía redactada. Los subpasos propuestos (aun sin desarrollar) son:

5a: proporcionar documentación para cada paso
5b (opcional): proporcionar una declaración de accesibilidad
5c (opcional): proporcionar una puntuación
5d (opcional): proporcionar información sobre los errores identificados
5e (opcional): proporcionar sugerencias para solucionar los errores
5f (opcional): proporcionar un informe legible por máquinas (como EARL)

Plantilla para el informe

El objetivo del apéndice C es ofrecer un ejemplo de plantilla, con la idea de tener tres diferentes niveles de presentación de informes. Se ofrece un ejemplo por cada uno de los objetivos posibles de la evaluación especificados en el paso 1b.

En el caso más completo, los contenidos que debería ofrecer el informe serían:

Resumen
Terminología
Fecha de la declaración de conformidad y validez en el tiempo
Fecha de la evaluación
Persona que hizo la evaluación
Directrices, versión y URI: "Web Content Accessibility Guidelines 2.0 en http://www.w3.org/TR/2008/REC-WCAG20-20081211/"
Nivel de conformidad testeado (A,AA,AAA) y si dicho nivel de conformidad es satisfecho
Descripción concisa de las páginas, con una lista de URI para las cuales se hace la declaración, indicando si los subdominios están incluidos en la declaración
Lista de los criterios de conformidad cumplidos más allá del nivel de conformidad alcanzado
Descripción del sitio que ha sido evaluado, incluyendo una descripción general de lo que está y no está incluido
Listado de las tecnologías de las que se depende y una lista de aquellas que están excluidas de la evaluación (pero disponibles en el sitio evaluado)
Declaración parcial de conformidad (si se trata de una evaluación de conformidad)
Resultados, por cada directriz y criterio de conformidad, indicando:
- si lo pasa o no
- la frecuencia y alcance del problema, si se da en toda la muestra o el listado de páginas en el que se encuentra
- descripción de los problemas existentes y las barreras para los usuarios o enlaces a estas descripciones en la web del W3C/WAI
- descripción de las técnicas
- listado de agentes de usuario, incluidos productos de apoyo, que se utilizaron durante la evaluación, indicando su versión
- listado de las páginas de la muestra
Disclaimer

Artículos relacionados:

Herramienta de ayuda para validar de acuerdo a las WCAG 2.0

2012-02-14T16:34:00.002+01:00

En el artículo anterior "Herramienta de ayuda para realizar una consultoría de accesibilidad web" compartía y explicaba una herramienta de ayuda para realizar una consultoría de accesibilidad web respecto a las WCAG 1.0 y la Norma UNE 139803.

Ahora comparto la versión de esa herramienta para realizar una consultoría de accesibilidad en base a las WCAG 2.0

El funcionamiento es el mismo, por tanto se puede consultar la descripción detallada en el artículo anterior.

La única novedad es que en cada criterio de éxito incluyo una descripción amigable de lo que hay que revisar en cada uno de ellos. Esta descripción está basada en la traducción de WebAIM`s WCAG 2.0 Checklist por parte de Jose Ramón Quevedo.

Otra herramienta complementaria que os recomiendo es la WCAG 2.0 Checklist de Roger Hudson, en la cual incluye por cada criterio de éxito las técnicas a aplicar (está en formato Word y no genera datos automáticos como la que yo comparto)

La descarga es gratuita.

Descarga de la herramienta de ayuda para realizar una consultoría de accesibilidad web de acuerdo a las WCAG 1.0/Norma UNE 139803. Archivo excel .XLSX de 85.6 KB

Descarga de la herramienta de ayuda para realizar una consultoría de accesibilidad web de acuerdo a las WCAG 2.0. Archivo excel .XLSX de 84 KB

Esta prohibido su uso comercial y su distribución sin permiso del autor.

Servicio relacionado: Consultoría de accesibilidad web

Artículos relacionados:

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:

Reseña "WCAG 2.0 made easy" de Olga Revilla

2011-01-29T10:32:00.017+01:00

Autor: Olga Revilla

Nº páginas: 157

Formato: papel y ebook

Idioma: inglés

Web: WCAG 2.0 made easy

Referencia online: One Guideline a Day

Por fin tuve tiempo de leer con calma "WCAG 2.0 made easy" de Olga Revilla, que aunque está escrito en inglés es una lectura ágil, más aun si estás familiarizado con la temática.

"WCAG 2.0 made easy" es un libro muy práctico que recomiendo sin duda no sólo a todos aquellos que quieran comenzar con las WCAG 2.0, sino también a los que ya están trabajando con ellas, puesto que resulta una referencia rápida de gran utilidad (tanto como lo fue su iniciativa One Guideline a Day)

En la primera parte del libro se introducen de forma general las WCAG 2.0 y se explican de forma muy clara aspectos que siempre generan dudas, como son la declaración de conformidad o el tema de las tecnologías compatibles con la accesibilidad.

En los capítulos posteriores aborda cada uno de los criterios de conformidad (agrupados en sus correspondientes principios y pautas) de manera muy didáctica, pues resume las técnicas aplicables a cada uno en:

You must... (Sufficient Techniques)
You should... (Advisory Techniques)
Don`t do! (Commun Failures)

Lo cual resulta, como digo, muy útil y práctico.

No se incluyen las técnicas Flash, que se listan al final del libro en un apéndice. A los que os interese el tema os recomiendo complementariamente Checklist para validar contenido Flash de acuerdo con las WCAG 2.0

Al final del libro incluye otros recursos como una checklist de validación, una tabla de correspondencias entre los puntos de verificación de las WCAG 1.0 y los criterios de conformidad de las WCAG 2.0 así como herramientas de validación. Este apartado es el que quizás podría ampliarse más.

Incluyo otras recomendaciones para el apartado de recursos:

La checklist de validación de Roger Hudson tiene a su favor que incluye las técnicas que se pueden aplicar a cada criterio de conformidad (aunque hay que recordar que el documento de las técnicas está en constante evolución): WCAG 2.0 Checklist
Como alternativa a la tabla de correspondecias entre las WCAG 1.0 y las WCAG 2.0, podéis consultar una en la que además se incluye la correspondencia con los requisitos de la norma UNE 139803 en: Correspondencia entre los requisitos de la Norma UNE 139803, los puntos de control de las WCAG 1.0 y los criterios de éxito de las WCAG 2.0
Sobre los validadores podéis consultar una lista más completa en: WCAG 2.0 Validar de acuerdo a las WCAG 2.0

Felicito desde aquí a Olga por su trabajo y le agradezco las palabras que en él me brinda, así como el ejemplar dedicado.

Artículos relacionados:

Checklist para validar contenido Flash de acuerdo con las WCAG 2.0

2011-01-03T22:12:00.000+01:00

En octubre, 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.

Al igual que en su día preparé una checklist para validar formularios de acuerdo con las técnicas de las WCAG 2.0 (en "Formularios accesibles según las WCAG 2.0"), esta vez he preparado una checklist para validar contenido Flash de acuerdo con estas nuevas técnicas de las WCAG 2.0

Descargar "Checklist para validar contenido Flash de acuerdo con las técnicas de las WCAG 2.0" (Excel, 112 KB )

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.

Otros artículos de Usable y accesible relacionados con las técnicas de las WCAG 2.0:

Formularios accesibles según las WCAG 2.0

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

Técnicas WCAG 2.0 para 10 dudas habituales sobre accesibilidad

Técnicas WCAG 2.0 para otras 5 dudas sobre accesibilidad

WCAG 2.0

10 razones para pasarse a las WCAG 2.0

WCAG 2.0 Checklist

Borrador de la traducción oficial al español de las WCAG 2.0

2010-01-11T14:46:00.004+01:00

El último mes he estado abducida por el trabajo. Repasando hoy mis alertas de Google me he llevado la grata sorpresa de que SIDAR ha publicado el borrador de la traducción oficial al español de las WCAG 2.0.

"Abierto el plazo de revision pública de las WCAG 2.0 en español", INTECO, 22/12/2009.

Artículos de este blog relacionado con las WCAG 2.0:

WCAG 2.0

WCAG 2.0

10 razones para pasarse a las WCAG 2.0

Técnicas WCAG 2.0 para 10 dudas habituales sobre accesibilidad

Técnicas WCAG 2.0 para otras 5 dudas sobre accesibilidad

Formularios accesibles según las WCAG 2.0

WCAG 2.0 Checklist

Mapa conceptual de las WCAG 2.0

Comparativas

Diferencias de prioridad entre los requisitos UNE 139803:2004 y los puntos de control de las WCAG 1.0

Correspondencia entre los requisitos de la Norma UNE 139803, los puntos de control de las WCAG 1.0 y los criterios de éxito de las WCAG 2.0

Validadores

Validación de accesibilidad de acuerdo a las WCAG 2.0 con PISTA

TAW WCAG 2.0

TAW Monitor

Técnicas WCAG 2.0 para otras 5 dudas sobre accesibilidad

2009-10-30T21:49:00.025+01:00

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

Fácil de leer

2009-10-27T13:40:00.000+01:00

Artículos relacionados
[06-02-09] Reseña: "Cómo escribir para la Web" de Guillermo Franco

La técnica G153: Making the text easier to read (nivel AAA) nos da unas pautas para reducir la complejidad de un texto:

Develop a single topic or subtopic per paragraph.

Use the simplest sentence forms consistent with the purpose of the content. For example, the simplest sentence-form for English consists of Subject-Verb-Object, as in John hit the ball or The Web site conforms to WCAG 2.0.

Use sentences that are no longer than the typical accepted length for secondary education. (Note: In English that is 25 words.)

Consider dividing longer sentences into two.

Use sentences that contain no more than two conjunction.

Indicate logical relationships between phrases, sentences, paragraphs, or sections of the text.

Avoid professional jargon, slang, and other terms with a specialized meaning that may not be clear to people.

Replace long or unfamiliar words with shorter, more common terms.

Remove redundant words, that is, words that do not change the meaning of the sentence.

Use single nouns or short noun-phrases.

Remove complex words or phrases that could be replaced with more commonly used words without changing the meaning of the sentence.

Use bulleted or numbered lists instead of paragraphs that contain long series of words or phrases separated by commas.

Make clear pronoun references and references to other points in the document.

Use the active voice for documents written in English and some other Western languages, unless there is a specific reason for using passive constructions. Sentences in the active voice are often shorter and easier to understand than those in the passive voice.

Use verb tenses consistently.

Use names and labels consistently.

También se propone en la técnica G86: Providing a text summary that requires reading ability less advanced than the upper secondary education level (nivel AAA) la creación de un resumen del texto que requiera una habilidad de lectura menos avanzada que la de un nivel de educación de secundaria.

10 razones para pasarse a las WCAG2.0

2009-10-09T10:05:00.011+02:00

1 …porque el propio W3C así lo recomienda

WCAG 2.0 succeeds Web Content Accessibility Guidelines 1.0 [WCAG10], which was published as a W3C Recommendation May 1999. Although it is possible to conform either to WCAG 1.0 or to WCAG 2.0 (or both), the W3C recommends that new and updated content use WCAG 2.0. The W3C also recommends that Web accessibility policies reference WCAG 2.0.

En Web Content Accessibility Guidelines (WCAG) 2.0

2 … porque es igual de legal

Las leyes que establecen el marco legal de la accesibilidad Web en España se aprobaron a finales de 2007, antes de que la nueva versión de las WCAG fuera recomendación oficial.

El Real Decreto 1494/2007 de 12 de noviembre reconoce que las WCAG son el documento de referencia de la accesibilidad Web y permite validar de acuerdo a normas distintas siempre y cuando permitan alcanzar un nivel de accesibilidad similar al que garantiza la Norme UNE 139803. Y este es un requisito que evidentemente cumplen las WCAG 2.0.

Es perfectamente válido basarse en las WCAG 2.0 para cumplir con la legislación española en el ámbito de la accesibilidad Web.

La adopción de las WCAG 2.0 en las legislaciones de los distintos países es un hecho que se irá haciendo poco a poco realidad. En "Adopting WCAG 2" de Roger Hudson podemos consultar datos concretos sobre la adopción de las WCAG 2.0 por diferentes países.

A nivel europeo, el 1 de octubre de 2009, Viviane Reding, miembro de la European Commission responsible for Information Society and Media propuso a los estados miembros elaborar una Ley Europea de la Discapacidad que adoptara las nuevas Web Content Accessibility Guidelines.

También es muy interesante el evento que tuvo lugar el 23 de marzo de 2009, "Expert meeting on web accessibility in Europe and the implementation of Web Content Accessibility Guidelines (WCAG) 2.0"

En su informe podemos leer:

There is a clear consensus that WCAG 2.0 provides an opportunity for a common approach to web accessibility across Europe, which should not be missed. Organizations proposed that the Commission should propose binding legislation on web accessibility.

3… porque ya tenemos validadores automáticos

Aunque toda revisión de accesibilidad debe incluir una validación manual por expertos, los validadores automáticos de accesibilidad son sin duda una herramienta de gran utilidad.

Desde junio de 2009 el TAW (Test de Accesibilidad Web) ya permite la validación de acuerdo a las WCAG 2.0

4… porque no hay lugar para interpretaciones personales

Las WCAG 1.0 daban cabida a diferentes interpretaciones, sin embargo las WCAG 2.0 establecen de forma clara y precisa unos requisitos que pueden verificarse de forma inequívoca, lo cual permite un resultado objetivo: diferentes personas pueden llegar a la misma conclusión partiendo del mismo análisis.

En las WCAG 2.0 cada punto de control incluye una serie de técnicas que se han de cumplir. Cada técnica además tiene asociado un test con el procedimiento para validar si se cumple o no dicha técnica.

5 … porque se aplica a todas las tecnologías Web

Las WCAG 1.0 partían de la base de que el HTML es la única tecnología con soporte para la accesibilidad, sin embargo las WCAG 2.0 admiten cualquier tecnología con soporte para la accesibilidad, y por tanto se aplican a una gama más amplia de tecnologías Web: contenido multimedia, AJAX, JavaScript, PDF, Flash.

Ya no es necesario proporcionar versiones alternativas para estos desarrollos si se hacen accesibles de forma nativa. Abordar la accesibilidad de estos contenidos es más asequible y por tanto más fácil de que se lleve a cabo.

Por otro lado, el portal estará mejor preparado para afrontar los cambios futuros en materia de accesibilidad.

6 … porque se eliminan los puntos de control obsoletos

Muchos de los puntos de verificación de las WCAG 1.0 son válidos "hasta que las aplicaciones de usuario" cumplan alguna condición, pero desde 1999 nunca se han actualizado.

En las WCAG 2.0 desaparecen requisitos pesadilla como por ejemplo:

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

Más información en "Correspondencia entre los requisitos de la Norma UNE 139803, los puntos de control de las WCAG 1.0 y los criterios de éxito de las WCAG 2.0"

7 … porque se incluyen puntos de control nuevos que harán nuestras páginas más usables y accesibles

Un ejemplo muy claro es el referente a los formularios que recopilé en "Formularios accesibles según las WCAG 2.0"

Otro ejemplo destacable son todos los criterios relacionados con los contenidos multimedia y que están magníficamente recopilados en el libro "Accesibilidad a los contenidos audiovisuales en la web" que reseñé en Reseña: "Accesibilidad a los contenidos audiovisuales en la web"

8… porque son más fáciles de utilizar y entender

La documentación de las WCAG 2.0 es mucho más amplia, detallada y clara que la de las WCAG 1.0.

Las WCAG 2.0 contienen gran cantidad de técnicas, dan cuenta de los fallos típicos de cada criterio, explican cómo benefician a las personas con distintas discapacidades, proporcionan ejemplos, enlaces a recursos externos, dan información sobre el soporte en distintos agentes de usuario, etc.

Como ya he dicho, resulta muy sencillo verificar los criterios de éxito, puesto que en las WCAG 2.0 cada punto de control incluye una serie de técnicas que se han de cumplir, y cada una de estás técnicas tiene asociado un test con el procedimiento para validar si se cumple o no la técnica.

9 … porque la declaración de conformidad está ahora sujeta a unas normas muy precisas

E incluir un sello de accesibilidad supone incluir dicha declaración.

Trato este tema en el artículo WCAG 2.0

10 … refuerza positivamente la imagen institucional de la empresa

Supone estar en la vanguardia de la accesibilidad Web, puesto que a día de hoy son casi inexistentes los portales que validan de acuerdo a las WCAG 2.0 debido a la novedad de las mismas y a la resistencia al cambio.

¿Y tú que opinas?

¿Añadirías más?
¿Las rebatirías?

Enlaces de interés

"Hacia las Pautas WCAG 2.0" de Inteco.
"WCAG 2.0: The new W3C accessibility guidelines evaluated" de WebCredible
"6.2.3. Presente de las WCAG 1.0" de Cnice
"WCAG 2.0 and Accessibility Supported" de Roger Hudson

TAW WCAG 2.0

2009-06-19T20:44:00.002+02:00

!Qué gran noticia!

Se presenta la nueva versión del analizador de accesibilidad TAW que permite validar de acuerdo a las WCAG 2.0 .

De momento está en versión BETA.

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

Mapa conceptual de las WCAG 2.0

2009-04-29T12:14:00.005+02:00

Artículos relacionados
[5-05-09] Técnicas WCAG 2.0 para 10 dudas habituales sobre accesibilidad
[12-02-08] WCAG 2.0

Otro recurso de interés relacionado con las WCAG 2.0:
Mapa conceptual de las WCAG 2.0 (PDF, 380 KB) de Tripleablog

Relacionados:

WCAG 2.0 Checklist

2009-04-22T21:00:00.001+02:00

Artículos relacionados
[5-05-09] Técnicas WCAG 2.0 para 10 dudas habituales sobre accesibilidad
[12-02-08] WCAG 2.0

Recurso imprescindible en formato PDF y Word: WCAG 2.0 Checklist

This checklist has been prepared to help website developers and testers record the level of website compliance with the Success Criteria and Sufficient Techniques of the Web Content Accessibility Guidelines Version 2.0 (WCAG 2.0).

The worksheet has been prepared as series of tables in a Word document. Each table contains a WCAG 2.0 Guideline, the normative Success Criteria for the Guideline at Level AAA and the informative Sufficient Techniques for each Success Criterion.

The Success Criteria and Sufficient Techniques are presented in table rows so that the document can be easily modified by users to meet differing situations. For example, to convert the document into a Level A worksheet, delete the Level AA and AAA Success Criteria and associated Sufficient Techniques. Similarly, for each Success Criterion the rows containing Sufficient Techniques that do not apply can be deleted.

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>

Validación de accesibilidad de acuerdo a las WCAG 2.0 con PISTA

2009-03-16T22:32:00.028+01:00

Artículos relacionados
[14-03-09] Correspondencia entre los requisitos de la Norma UNE 139803, los puntos de control de las WCAG 1.0 y los criterios de éxito de las WCAG 2.0 (v1.1 del 17-03-09 con mejoras organizativas)

Descarga del documento "WAI WCAG 2.0: Normativa XML para importar en PISTA" (ZIP, 12 KB)

Uno de mis validadores favoritos de accesibilidad es PISTA. Entre otras muchas ventajas es el único que conozco que permite validar según diferentes normativas.

La normativa por defecto son las WCAG 1.0. Gracias a Olga Revilla podemos revisar nuestras páginas de acuerdo a la Norma UNE 139803.

Por mi parte me he creado mi propia normativa WAI WCAG 2.0. Se trata de un fichero XML que se importa desde el menú "Normativas".

[D-1]

He incluido todos los criterios de éxito de las WCAG 2.0, indicando para cada uno:

Número identificativo del criterio de éxito.
Descripción en español e inglés.
Nivel de prioridad.
Enlace a su descripción en el documento oficial de las WCAG 2.0.
Comprobaciones.

[D-2]
[Ver imagen "Pantalla Edición de un punto de verificación en PISTA" más grande]

Las comprobaciones son bastantes más complejas que en las WCAG 1.0, de modo que sólo he incluido las que se citan propiamente en las WCAG 2.0, pero no en las técnicas.

En cuanto a las comprobaciones automáticas sólo he incluido cuatro sencillas:

Comprobación de que la página contiene TITLE (2.4.2)
Comprobación de que se especifica el idioma del documento (3.1.1)
Comprobación de que las imágenes contienen el atributo ALT (1.1.1)
Comprobación de que se utilizan encabezados (2.4.10)

Y a pesar de todo cada una de ellas necesitará una verificación manual: que el TITLE de la página o el ALT de las imágenes es adecuado, que el idioma se corresponde con el del documento, etc.

Si alguien se anima a incluir más comprobaciones ya tiene el documento base, a partir de ahí es pelearse con el asistente de normativas y las expresiones regulares.

El resultado de una verificación nos da por ejemplo el siguiente resultado:

[D-3]
[Ver imagen "Ejemplo de verificación en PISTA de acuerdo a las WCAG 2.0 nivel A" más grande]

[D-4]
[Ver imagen "Pantalla 'Resumen de una verificación de acuerdo a las WCAG 2.0' de PISTA" más grande]

[D-5]
[Ver imagen "Informe visual de una verificación de acuerdo a las WCAG 2.0 con PISTA" más grande]

El documento estará disponible de forma permanente en el apartado de descargas. Por supuesto la descarga es libre y gratuita, pero como política general de este blog, por problemas pasados, conlleva la previa aceptación del contrato coloriuris asociado.

Descarga del documento "WAI WCAG 2.0: Normativa XML para importar en PISTA" (ZIP, 12 KB)

Correspondencia entre los requisitos de la Norma UNE 139803, los puntos de control de las WCAG 1.0 y los criterios de éxito de las WCAG 2.0

2009-03-14T21:53:00.007+01:00

Descarga del documento "Correspondencia entre los requisitos de la Norma UNE 139803, los puntos de control de las WCAG 1.0 y los criterios de éxito de las WCAG 2.0" (Excel, 108 KB)

Comparto con vosotros un recurso de gran utilidad a la hora de afrontar una revisión de accesibilidad conforme a las WCAG 2.0

Se trata de una excel con cuatro pestañas:

Pestaña 1: Correspondencia organizada por prioridades tomando como referencia la NORMA UNE 139803
Pestaña 2: Correspondencia organizada por prioridades tomando como referencia las WCAG 1.0
Pestaña 3: Correspondencia organizada por prioridades tomando como referencia las WCAG 2.0
Pestaña 4: Correspondencia organizada por orden númerico de puntos de control tomando como referencia las WCAG 1.0

He resaltado en las tablas:

Los cambios de prioridad de la Norma UNE respecto a las WCAG 1.0
Los cambios de prioridad de las WCAG 2.0 respecto a las WCAG 1.0
Los nuevos criterios de las WCAG 2.0

El documento estará disponible de forma permanente en el apartado de descargas. Por supuesto la descarga es libre y gratuita.

Versiones:
17-03-09: actualizado a v1.1 con mejoras organizativas.

Descarga del documento "Correspondencia entre los requisitos de la Norma UNE 139803, los puntos de control de las WCAG 1.0 y los criterios de éxito de las WCAG 2.0" (Excel, 108 KB)

Noticias... (16)

2009-03-04T16:23:00.016+01:00

Estas son las noticias que han llamado mi atención últimamente:

WCAG 2.0

Esta semana me sorprendía conocer la web Codexexempla, que dispone de uno de los recursos más codiciados en la actualidad, la traducción (no oficial) de las WCAG 2.0.

Otras traducciones interesantes que ofrece son:
- "Comparativa entre los puntos de comprobación de las Pautas de Accesibilidad de Contenido Web 1.0 y las Pautas 2.0, agrupados por prioridades" de la versión en inglés del 15 de diciembre de 2008.
- "Fe de erratas de las Pautas de Accesibilidad de Contenido Web del WCAG Samurai", [traducción] V1.0 de 26 de febrero de 2008

"¿Qué pasa con las WCAG 2?", se pregunta Olga Revilla, y en consecuencia ha puesto en marcha la web One Guideline a Day en la que pretende ir analizando una por una las pautas, criterios de éxito, técnicas y errores comunes que vienen publicados en la WCAG 2, comparándolo con las anteriores y aportando un poquito de mi experiencia en este campo.

Relacionado: WCAG 2.0 en este blog.

Novedades W3C

Se han actualizado los siguientes borradores:

Authoring Tool Accessibility Guidelines 2.0 W3C Working Draft 17 February 2009.

HTML 5. W3C Working Draft 12 February 2009 y HTML 5 differences from HTML 4 W3C Working Draft 12 February 2009

Accessible Rich Internet Applications (WAI-ARIA) 1.0 W3C Working Draft 24 February 2009

Relacionados:

HTML 5 en este blog.

Ajax accesible II: WAI-ARIA en este blog.

Dominios .tel

"Llegan los dominios .tel" eWeek Europe

"Llega el dominio .tel" TIC Pymes

Móvil

"Banco Popular integra Iphone 3G en su banca móvil" (leído en Computing.es) como ya lo hizo antes Caixa Penedès (Iphone y accesibilidad en este blog)

"Instant Mobilizer de dot.mobi" el Libro de Apuntes: un servicio que moviliza tu página web, es decir, la transforma automáticamente para que se vea correctamente desde los teléfonos móviles.

Sectores

"Pensando la banca del futuro", Usolab: se ha creado el Center for Future Banking, un centro donde se "investigará cómo las nuevas tecnologías y los conocimientos sobre el comportamiento humano pueden transformar la experiencia de los clientes y elevar el papel del banco en su vida financiera", es decir, simplificar la vida de la gente y hacer la experiencia con la banca más satisfactoria.

"Las empresas aseguradoras impulsarán la accesibilidad de sus páginas web" en Acceso.com

WCAG 2.0 ya son recomendación

2008-12-12T09:12:00.002+01:00

Estándar Web del W3C define la accesibilidad para la Web de nueva generación (11/12/2008)

Web Content Accessibility Guidelines (WCAG) 2.0. W3C Recommendation 11 December 2008

Sí quieres introducirte en las WCAG 2.0 puedes leer el artículo WCAG 2.0

Novedades en las WCAG 2.0 (2)

2008-11-12T09:58:00.001+01:00

Artículos relacionados
[12-02-08] WCAG 2.0
[04-10-08] Novedades en las WCAG 2.0 (1)

El 3 de noviembre se publicó nueva versión de las WCAG 2.0 (Web Content Accessibility Guidelines (WCAG) 2.0. W3C Proposed Recommendation 03 November 2008). Están todavía en estado "Candidatas a recomendación", seguimos por tanto a la espera de que pasen a ser "Recomendación". Se admiten comentarios a las mismas hasta el 2 de diciembre.

Web Content Accessibility Guidelines (WCAG) 2.0 was published as a W3C Proposed Recommendation on 3 November 2008. This means that the technical material of WCAG 2.0 is complete and it has been implemented in real sites. The next stage is the final publication, which is expected in December 2008. Please see additional information in:

WCAG 2.0 moves to last stage for expected final publication in December 2008 e-mail

With real world implementations WCAG 2.0 steps closer to expected December 2008 publication blog post

How WAI Develops
Accessibility Guidelines through the W3C Process

Overview of WCAG 2.0 Documents

Leído en la web de la WAI (Web Accessibility Initiative).

Artículos relacionados
[12-02-08] WCAG 2.0
[04-10-08] Novedades en las WCAG 2.0 (1)

Novedades en las WCAG 2.0 (1)

2008-10-04T21:50:00.001+02:00

Artículos relacionados
[12-02-08] WCAG 2.0
[12-11-08] Novedades en las WCAG 2.0 (2)

WCAG 2.0 Implementations: Most done, a few to go. Since publishing Web Content Accessibility Guidelines (WCAG) 2.0 as a Candidate Recommendation, the WCAG Working Group has been collecting and evaluating implementations (that is, examples of how real Web sites meet WCAG 2.0). We have implementions for almost all success critieria, and need a few more. For an updated list of implementations needed, see the Update in the WCAG 2 FAQ.

The WCAG Working Group is meeting 1-3 October 2008 to address remaining issues. We are still hoping to complete WCAG 2.0 in 2008, and will provide another status update by November. See How WAI Develops Accessibility Guidelines through the W3C Process for the steps needed to complete WCAG 2.0.

Noticia en la página de la WAI (Web Accessibility Initiative): WCAG 2.0 Implementations: Most done, a few to go

Por lo visto sigue habiendo esperanzas de que el 2008 sea su año.

Artículos relacionados
[12-02-08] WCAG 2.0
[12-11-08] Novedades en las WCAG 2.0 (2)

Noticias... (11)

2008-07-08T11:46:00.001+02:00

Las noticias que más han llamado mi atención durante estos meses de ausencia han sido estas cuatro:

1

La AGPD (Agencia Española de Protección de Datos) sanciona a una web que tiene la opción "Recomendar a un amigo"

Según la Agencia Española de Protección de Datos esta práctica vulnera la Ley de Servicios de la Sociedad de la Información y Comercio Electrónico (LSSI), que no prevé que se pueda enviar ningún mail con contenido publicitario o promocional

La única excepción a este hecho sancionable es que exista un consentimiento previo e informado o que, con antelación, haya habido una relación contractual entre el remitente del correo y el destinatario.

¡Ojo al enviar datos "a un amigo! Protección de Datos considera que es sancionable

Al hilo de esta noticia hay que recordar que la AGPD también sancionó en enero a un usuario que mandó un correo felicitando la Navidad a sus conocidos sin CCO.

La AGPD multa con 601,01 euros por felicitar las fiestas por e-mail sin CCO

2

El W3C invita a los desarrolladores a implementar las Pautas de Accesibilidad al Contenido en la Web (WCAG) 2.0 (Candidata a Recomendación)

En febrero explicaba todo acerca de las WCAG 2.0, que entonces eran sólo un borrador. El 30 de abril se publicaba la recomendación candidata que el w3C animaba a los desarrolladores a implentar.

Habrá que estar atentos a la fecha fijada: 31 de agosto.

Working closely with Web developers, we expect to receive initial implementations by 30 June 2008 and to show evidence of meeting the exit criteria by 31 August 2008.

El W3C invita a los desarrolladores a implementar las Pautas de Accesibilidad al Contenido en la Web (WCAG) 2.0 (Candidata a Recomendación)

WCAG 2.0 Se Mueve: Lista para Prueba de Conducción

Presentación sobre WCAG 2.0 Working Draft (2007)

3

Google incorpora mejoras en su algoritmo para indexar los contenidos textuales dentro de archivos Flash

Flash se vuelve más indexable

4

Nuevas versiones de navegadores: Firefox 3, Opera 9.5, Explorer 8 beta, Opera Mini 4.1

Enlaces relacionados:

Browser History Timeline

Opera 9.5 y el movimiento hacia los nuevos estándares web

Poniendo el radar a los navegadores web más modernos

Navegadores web y el consumo de memoria

Identifican agujero crítico de seguridad en Firefox 3

Opera Mini 4.1 ya se encuentra disponible

La II Guerra de los Navegadores

Opera publica la versión 9.51

Noticias... (10)

2008-03-06T09:19:00.001+01:00

Progreso de WCAG 2.0 en Accesibilidad Web y Alan:

El Grupo de Trabajo WCAG espera publicar WCAG 2.0 como “Recomendación Candidata” en abril o mayo de 2008. [...] En función de cuanto dure la etapa de Recomendación Candidata, el último borrador de WCAG 2.0 (llamada “Propuesta de Recomendación”) podría estar disponible en el último trimestre del 2008.

[Artículo relacionado WCAG 2.0]

Explorer 8 Beta. Muy recomendables los artículos de anieto2k:

Probando Internet Explorer 8 Beta 1

Internet Explorer 8.0, será super estandar por defecto

El Consejo de Europa adopta una nueva resolución sobre Accesibilidad Universal en CEAPAT (25/02/2008)

WCAG 2.0

2008-02-12T16:21:00.080+01:00

Última actualización: 13 de abril de 2012

Índice:

Introducción a las WCAG
Niveles y declaraciones de conformidad WCAG 2.0
Enunciado de los Principios y sus Pautas
Adopción de las WCAG 2.0
Validar de acuerdo a las WCAG 2.0
Documentación y referencias:

Introducción a las WCAG

La Iniciativa de Accesibilidad a la Web del W3C (WAI), fundada en 1997, es un grupo de trabajo permanente del W3C (Consorcio World Wide Web).

La W3C es una organización internacional que trabaja en el desarrollo de estándares web, y que recibe el apoyo de los principales actores de la industria y los gobiernos del mundo.

LA WAI se dedica a promover soluciones de accesibilidad en la web para personas con discapacidades. Actúa principalmente sobre cinco áreas de trabajo:

Asegurar que las tecnologías web den soporte a la accesibilidad
Desarrollar pautas de accesibilidad
Crear herramientas de evaluación y corrección de la accesibilidad web
Desarrollar materiales para la educación y difusión
Coordinar proyectos de investigación y desarrollo

La accesibilidad web incluye los contenidos y aplicaciones, los navegadores y reproductores multimedia, las herramientas de autor y las tecnologías XML. La WAI ha propuesto para cada una de estas necesidades unas pautas a seguir.

En 1999 se publica las Pautas de Accesibilidad de Contenidos Web, WCAG 1.0 (Web Content Accessibility Guidelines, WCAG), que representan el primer y más grande esfuerzo por establecer unas pautas de diseño accesible.

El 11 de diciembre de 2008 se publica la nueva recomendación, las WCAG 2.0.

Las WCAG 1.0 y las WCAG 2.0 están organizadas y estructuradas de distinta manera.

Las WCAG 1.0 se organizan en 14 pautas que constituyen los principios generales del diseño accesible. Cada una de estas pautas tiene asociados x puntos de verificación (65 en total) que explican cómo se aplica la pauta. A su vez, cada punto de verificación tiene asignada una prioridad (1, 2, 3).

El nivel de adecuación de accesibilidad (nivel de conformidad) será:

Simple - A (A): cuando cumple todos los puntos de verificación de prioridad 1.
Doble - A (AA): cuando cumple todos los puntos de verificación de prioridad 1 y 2.
Triple - A (AAA): cuando cumple todos los puntos de verificación de prioridad 1, 2 y 3.

Las WCAG 2.0 se organizan en 4 principios fundamentales para la accesibilidad del contenido:

PERCEPTIBLE
La información y los componentes de la interfaz de usuario deben ser presentados a los usuarios de modo que ellos puedan percibirlos.

OPERABLE
Los componentes de la interfaz de usuario y la navegación deben ser operables.

COMPRENSIBLE
La información y el manejo de la interfaz de usuario deben ser comprensibles.

ROBUSTO
El contenido debe ser suficientemente robusto como para ser interpretado de forma fiable por una amplia variedad de aplicaciones de usuario, incluyendo los productos de apoyo.

A su vez, cada uno de estos grandes principios tiene asociadas unas pautas. En total son 12 pautas: los dos primeros principios tienen 4 pautas asociadas, el tercero tiene 3 y el último 1 pauta. Estas pautas no son testeables en si, sino que proporcionan las metas básicas para hacer el contenido accesible, y sirven para comprender los criterios de conformidad e implementarlos.

Cada una de estas pautas tiene asociados x criterios de conformidad (61 en total) que se han de cumplir y que sí son testeables. Los criterios de conformidad están ordenados según su nivel de cumplimiento asociado (A, AA y AAA).

Cada criterio de conformidad tiene además dos enlace:

"Comprender…": enlaza con la página de información asociada a ese criterio en el documento "Comprender las WCAG 2.0" (Understanding WCAG 2.0) donde se explica el criterio, los usuarios a los que beneficia, se listan ejemplos y se incluyen los principales errores asociados a ese criterio. Se indican también una serie de técnicas informativas para resolver el criterio de conformidad que se pueden dividir en dos categorías:
- las que son "suficientes" para resolver los criterios de conformidad.
- las que son "recomendables" van más allá de los requisitos de cada criterio de conformidad individual y permiten a los autores afrontar mejor las pautas. Algunas de las técnicas recomendables tratan sobre barreras de accesibilidad que no han sido cubiertas por los criterios de conformidad verificables.
"Cómo cumplir…": enlace al documento "Cómo cumplir con las WCAG 2.0" (How to meet WCAG 2.0)), la guía rápida donde se listan sólo las técnicas suficientes y recomendables así como los errores asociados al criterio

Las técnicas son sólo informativas, no normativas, pues el criterio de conformidad podría resolverse de otro modo no documentado en las técnicas, documento que de hecho está en constante evolución.

- Esquema de Avoka Blog -

Un documento muy interesante es el que informa de la equivalencia entre los puntos de verificación de las WCAG 1.0 y los criterios de conformidad de las WCAG 2.0: Comparison of WCAG 1.0 checkpoints to WCAG 2.0 (Non-Normative)

Como se puede comprobar, la equivalencia es compleja, un punto de verificación de las WCAG 1.0 puede corresponder con varios criterios de conformidad o con ninguno en concreto de las WCAG 2.0. Además los niveles de adecuación cambian en la mitad de los criterios de unas pautas a otras.

Para la conocer la correspondencia de los requisitos de la Norma UNE 139803: Correspondencia entre los requisitos de la Norma UNE 139803, los puntos de verificación de las WCAG 1.0 y los criterios de conformidad de las WCAG 2.0

Niveles y declaraciones de conformidad WCAG 2.0

Es necesario indicar primero que las WCAG 2.0 incorporan el concepto "compatible con la accesibilidad", cuya comprensión es vital para entenderlas y aplicarlas correctamente. Una tecnología compatible con la accesibilidad es aquella que dispone de los mecanismos necesarios para proporcionar información de accesibilidad a los agentes de usuario (navegadores) y productos de apoyo (como un lector de pantalla) que a su vez son capaces de comprender estos mecanismos y proporcionar dicha información a los usuarios que la requieran.

Las WCAG 2.0 permiten usar cualquier tecnología que sea compatible con la accesibilidad siempre que se use de forma accesible (compatible con los productos de apoyo) y siempre que los agentes de usuario y productos de apoyo soporten dicha tecnología. El W3C no especifica qué o cuántos productos de apoyo debe soportar una tecnología web para que pueda considerarse que es compatible con la accesibilidad.

Existen tres niveles de conformidad:

WCAG 2.0 Nivel A: para lograr conformidad con el Nivel A (el mínimo), la página web satisface todos los Criterios de Conformidad del Nivel A, o proporciona una versión alternativa conforme.
WCAG 2.0 Nivel AA: para lograr conformidad con el Nivel AA, la página web satisface todos los Criterios de Conformidad de los Niveles A y AA, o se proporciona una versión alternativa conforme al Nivel AA.
WCAG 2.0 Nivel AAA: para lograr conformidad con el Nivel AAA, la página web satisface todos los Criterios de Conformidad de los Niveles A, AA y AAA, o proporciona una versión alternativa conforme al Nivel AAA.

Se ha eliminado la polémica propuesta de borradores anteriores de incluir niveles mixtos A+ o A(n), aunque se ha dejado una nota animando a los desarrolladores a cumplir con más criterios de los mínimos establecidos por un nivel concreto de conformidad y a notificarlo así en sus declaraciones. De hecho, indican explícitamente que no se recomienda el nivel AAA como política general de un sitio web, ya que en algunos contenidos no es posible satisfacer todos los criterios de conformidad de Nivel AAA.

Además se especifica que:

el nivel de conformidad es para páginas completas (lo cual incluye HTML, CSS, elementos incrustados como Flash, vídeos, etc.) y no para partes de una página
cuando varias páginas forman una serie (proceso completo) que es necesario completar en orden para realizar una acción (por ejemplo un formulario con varios pasos) todas las páginas en ese proceso deben ser conformes con el nivel especificado o uno superior. No es posible lograr conformidad con un nivel en particular si una de las páginas del proceso no cumple con ese nivel o uno superior.
para cumplir los criterios de conformidad sólo se depende (se considera que se depende de una tecnología si el contenido puede no ser accesible si dicha tecnología está desactiva o no se soporta) de los usos accesibles de la tecnología. La información o las funcionalidades implementadas con tecnologías no compatibles con la accesibilidad deberán estar disponibles de una forma que sí sea compatible con la accesibilidad. Este requisito permite utilizar tecnologías usadas de forma no accesible siempre y cuando no se dependa de ellas. Es decir, la página web puede ser conforme si existen alternativas accesibles para el contenido que se incluye con tecnologías no accesibles o utilizadas de forma no accesible.
sin 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.

Es resumen, podemos usar tecnologías no compatibles con la accesibilidad o usadas de forma no compatible (por ejemplo una animación Flash, un PDF no accesible) siempre y cuando toda la información también esté disponible usando tecnologías accesibles (por ejemplo una versión alternativa en HTML) y el contenido no accesible no interfiere con el resto (por ejemplo que no atrape el foco sin dejarlo salir, por ejemplo que no produzca destellos que puedan provocar un ataque epiléptico a personas con epilepcia fotosensitiva, etc.)

Aunque el nivel de conformidad es para una página entera, la declaración de conformidad puede cubrir una o muchas páginas (un proceso, un dominio, etc.) La declaración de conformidad es opcional, si se decide añadir debe incluir la siguiente información (si se emplea un logo de conformidad, éste constituye una declaración y debe estar acompañado de todos los componentes requeridos para una declaración de conformidad):

Fecha de la declaración de conformidad
Título, versión y URI de las Pautas: "Web Content Accessibility Guidelines 2.0 en http://www.w3.org/TR/WCAG20/"
Nivel de conformidad satisfecho A, AA, AAA
Una sucinta descripción de las páginas incluidas en la declaración, como una lista de URI, especificando si los subdominios están incluidos en la declaración, o una expresión que describa todo el conjunto de páginas incluidas en la declaración de conformidad.
Una lista de las tecnologías web de las que se depende (se considera que se depende de una tecnología si el contenido puede no ser accesible si dicha tecnología está desactiva o no se soporta) para que el contenido sea accesible, siendo recomendable un link al software.

Es importante destacar que la conformidad es a nivel de página (URL única y recursos asociados). Podemos incluir una declaración de conformidad en cada página o una general donde se describa el conjunto de páginas que incluye.

En una declaración de conformidad se pueden excluir páginas pero no tecnologías. Es decir, si en un portal los PDF no son accesibles, puedes decir que todo el sitio es accesible menos la sección "www.dominio.com/biblioteca" pero no puedes decir que es accesible excepto x criterios de conformidad. Tampoco puedes decir que es accesible salvo una tecnología concreta (por ejemplo javascript o PDF que no están implementado de forma accesible ni se ofrece una versión accesible) en ese caso lo que se hace es excluir de la declaración de conformidad las páginas que usan esa tecnología.

Por otro, en la declaración de conformidad, en el listado de las tecnologías de las que dependen las páginas, solo incluimos las tecnologías compatibles con la accesibilidad utilizadas de forma accesibles, siempre y cuando no tengan una alternativa accesible en otra tecnología (por ejemplo un PDF con alternativa en HTML).

Es decir:

Si tenemos PDF no accesibles y sin alternativa accesible: excluimos de la declaración las páginas que incluyen PDF, y en el listado de tecnologías de las que dependen las páginas no incluimos la tecnología PDF
Si tenemos PDF no accesibles y con alternativa accesible (por ejemplo en HTML): incluimos en la declaración las páginas que incluyen PDF, y en el listado de tecnologías de las que dependen las páginas no incluimos la tecnología PDF
Si tenemos PDF accesibles y sin alternativa accesible (por ejemplo en HTML): incluimos en la declaración las páginas que incluyen PDF, y en el listado de tecnologías de las que dependen las páginas incluimos la tecnología PDF
Si tenemos PDF accesibles y con alternativa accesible (por ejemplo en HTML): incluimos en la declaración las páginas que incluyen PDF, y en el listado de tecnologías de las que dependen las páginas no incluimos la tecnología PDF

Opcionalmente se puede indicar:

Lista de criterios de éxito que se han cumplido más allá de lo demandado por el nivel de conformidad, preferible en forma de metadatos legibles por máquinas".
Lista de tecnologías especificas que se emplean pero de las que no se depende pues se da una alternativa accesible.
Lista de agentes de usuario y productos de apoyo que se utilizaron para probar el contenido.
Información sobre cualquier medida adicional tomada que vaya más allá de los criterios de éxito.
Versión de metadatos legible por máquinas de la listas de tecnologías específicas de las que se depende.
Versión de metadatos legible por máquinas (por ejemplo en RDF, como lo generan las principales herramientas de validación automática, ver Plantilla base XHTML) de la declaración de conformidad.

Un ejemplo de declaración de conformidad sería

On 21 June 2008, all content beginning with the URI "http://example.com/nav" and "http://example.com/docs" conform to Web Content Accessibility Guidelines 2.0 at "http://www.w3.org/TR/2006/REC-WCAG20-YYYYMMDD/". Level AAA conformance.

The documented set of accessibility-supported content technologies used for this claim is SMITH- AsCTset#2-2008 at "http://sample.com/AsCTsets/AS2-2008".
The technologies that this content "relies upon" are: XHTML 1.0 (Strict), CSS2, JavaScript 1.2, JPEG, PNG.
The user agents, including assistive technologies, that this content has been tested with can be found at "http://example.com/test/technologies.html".
This content was tested using the following user agents and assistive technologies: Firefox 1.5 on Windows Vista with Screenreader X 4.0, Firefox 1.5 on Windows XP SP 2 with Screenreader X 3.5, IE 6.0 on Windows 2000 SP4 with Screenreader Y 5.0, IE 6.0 on Windows 2000 SP4 with Screenreader Z 2.0, and Firefox 1.5 on Windows XP SP2 with Screenreader X 4.0, Safari 2.0 with OS X 10.4.

En el apartado "Understanding Conformance Claims" se pueden consultar otros ejemplos de declaraciones de conformidad.

Recordemos que la ley en España indica además que hay que añadir una dirección de contacto para dudas, quejas o sugerencias sobre la accesibilidad de la aplicación.

En las WCAG 2.0 se hace también una especificación interesante, se dice que a veces no puedes controlar determinada parte de la página, en el caso de un blog es habitual, no controlas el contenido de los comentarios o Blogguer inserta automáticamente una barra superior, fuera de tu control.

En estos casos se puede hacer una declaración parcial de conformidad, puedes decir que la página sería conforme si ciertos elementos fuera de tu control se quitaran, siempre y cuando sea de verdad contenido fuera del control del autor y, siempre y cuando, se especifique claramente cuáles son estos elementos (no vale describirlos como "todos los elementos que no controlemos").

Podrías decir que la página es conforme si esta se supervisa y se corrige de forma inmediata (2 días laborables).

También es interesante que se permite una "conformidad parcial debida al lenguaje" en caso de que la página no sea conforme pero que podría serlo de existir compatibilidad con la accesibilidad para el lenguaje (o todos los lenguajes) empleado en la página. La forma de este enunciado podría ser: "Esta página no es conforme, pero podría ser conforme con el nivel X si existiera soporte accesible para el/los siguiente/s lenguaje/s:"

Enunciado de los Principios y sus Directrices

Estas son las 12 directrices de las WCAG 2.0:

Principio 1: Perceptible - La información y los componentes de la interfaz de usuario deben ser presentados a los usuarios de modo que ellos puedan percibirlos.

Pauta 1.1 Alternativas textuales: Proporcionar alternativas textuales para todo contenido no textual de modo que se pueda convertir a otros formatos que las personas necesiten, tales como textos ampliados, braille, voz, símbolos o en un lenguaje más simple.
Pauta 1.2 Medios tempodependientes: Proporcionar alternativas para los medios tempodependientes.
Pauta 1.3 Adaptable: Crear contenido que pueda presentarse de diferentes formas (por ejemplo, con una disposición más simple) sin perder información o estructura.
Pauta 1.4 Distinguible: Facilitar a los usuarios ver y oír el contenido, incluyendo la separación entre el primer plano y el fondo.

Principio 2: Operable - Los componentes de la interfaz de usuario y la navegación deben ser operables.

Pauta 2.1 Accesible por teclado: Proporcionar acceso a toda la funcionalidad mediante el teclado.
Pauta 2.2 Tiempo suficiente: Proporcionar a los usuarios el tiempo suficiente para leer y usar el contenido.
Pauta 2.3 Convulsiones: No diseñar contenido de un modo que se sepa podría provocar ataques, espasmos o convulsiones.
Pauta 2.4 Navegable: Proporcionar medios para ayudar a los usuarios a navegar, encontrar contenido y determinar dónde se encuentran.

Principio 3: Comprensible - La información y el manejo de la interfaz de usuario deben ser comprensibles.

Pauta 3.1 Legible: Hacer que los contenidos textuales resulten legibles y comprensibles.
Pauta 3.2 Predecible: Hacer que las páginas web aparezcan y operen de manera predecible.
Pauta 3.3 Entrada de datos asistida: Ayudar a los usuarios a evitar y corregir los errores.

Principio 4: Robusto - El contenido debe ser suficientemente robusto como para ser interpretado de forma fiable por una amplia variedad de aplicaciones de usuario, incluyendo las ayudas técnicas.

Pauta 4.1 Compatible: Maximizar la compatibilidad con las aplicaciones de usuario actuales y futuras, incluyendo las ayudas técnicas.

Adopción de las WCAG 2.0

Si la ley obliga a cumplir con la Norma UNE 139803:2004 (que se basa en las WCAG 1.0) ¿qué va a impulsar a los desarrolladores a trabajar con las WCAG 2.0 cuando con lo que tienen que cumplir es con la Norma?

El 20 de enero de 2010, Loïc Martinez Normand, presidente del grupo de normalización AEN/CTN139 en AENOR, explicó en el "Módulo 1: WCAG 2.0 Armonización" de las Jornadas SIDAR 2010 que existe una solicitud formal de la Administración para la actualización de la Norma de acuerdo a las WCAG 2.0

Se señaló además que está previsto que la Norma mantenga el mismo nombre, por lo tanto, una vez aprobada, no será necesario modificar la ley, sino que desde ese momento será obligatorio cumplir con las WCAG 2.0

Loïc explicó que el deseo de AENOR no es reinterpretar las WCAG 2.0 como se hizo con las WCAG 1.0 y la actual Norma, sino que desean que la nueva Norma sea igual al 99% con las WCAG 2.0

Por último, comentó que en ese momento se vivía un parón porque la Comisión Europea ha pedido que no se publiquen nuevas normas hasta se defina a nivel europeo el estándar de requisitos funcionales de accesibilidad para compras públicas de TIC accesible, que es posible que incorporen las WCAG 2.0

Artículos relacionado:

10 razones para pasarse a las WCAG 2.0
Correspondencia entre los requisitos de la Norma UNE 139803, los puntos de control de las WCAG 1.0 y los criterios de éxito de las WCAG 2.0
Adopting WCAG 2, de Dingo Access, sobre la adopción de las WCAG 2.0 en los distintos países del mundo.

Validar de acuerdo a las WCAG 2.0

Checklists
- WCAG 2.0 Checklist, en inglés, disponible en PDF y Word. Incluyen por cada criterio las técnicas que se aplican.
- Guías Prácticas para Profesionales Web: Puntos de verificación de las Pautas de Accesibilidad al Contenido Web (WCAG) 2.0 checklist en español de qwos.
- Herramienta de ayuda realizar una consultoría de accesibilidad de acuerdo a las WCAG 2.0
Validadores automáticos
- Online
  - Validador TAW WCAG 2.0 Beta
  - Examinator, herramienta de evaluación automática en español para las WCAG 2.0 Permite incluir una URL o subir un fichero. En la vista "Tablero" te ofrece la nota alcanzada. Es el motor de revisión utilizado por walidator.net (Web Accessibility Framework), sistema en línea para conocer el estado y la evolución de la accesibilidad de sitios y portales web, tomando como referencia las Pautas de Accesibilidad para el Contenido Web 2.0 (WCAG 2.0).
  - Web Accessibility Checker, validador en inglés que admite la validación de acuerdo a las WCAG 2.0 Permite incluir una URL o subir un fichero.
  - Deque Worldspace Free Analysis, validador en inglés que admite la validación de acuerdo a las WCAG 2.0 Permite revisión por URL, subir un fichero y la inclusión directa de código. Lo más relevante es que admite también la revisión de Flash y PDF. La extensión para Firefox "Qompliance" accede a Deque Worlspace y con un sólo clic permite validar una página de acuerdo a las WCAG 2.0
  - AccessMonitor Beta, validador en portugues que permite verificar una URL, subir un fichero o la entrada directa de código.
- Extensiones de Firefox
  - Accessibility Ainspector, extensión para Firebug que permite validar de acuerdo a las WCAG 2.0. La beta 0.9 me la desistalé porque me daba problemas, habrá que ver cómo evoluciona.
- Locales
  - SorSite, herramienta de pago con versión demo.
  - aDesigner, es una herramienta local gratuita que también incluye las WCAG 2.0 Determina el cumplimiento de las pautas (versión 1.0 y 2.0), así como la navegabilidad y la "escuchabilidad" de la página por un lector de pantalla. Admite la revisión de Flash. Existe una versión de pago que permite monotorizar la revisión de accesibilidad de un sitio.

La UWEN (Unified Web Evaluation Methodology) es la metodología europea de evaluación de la accesibilidad web. La última versión es la UWEN 1.2 y hay un plan para adaptarla a las WCAG 2.0 todavía sin ejecutar que dará lugar a la UWEN 2.0.

El objetivo de la metodología es ser totalmente compatible con las WCAG 1.0 presentando un método único tanto para la evaluación por un experto humano como de manera automática por interfaces de máquinas. El validador Walidator UWEN revisa según los procedimientos de revisión de la UWEN 1.2 Esta es además la metodología utilizada por la certificación Euracert.

El 27 de marzo (de 2012) el W3C/WAI publicó el primer borrador de la "Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM)" (según la traducción que hace la nota de prensa del W3C España), en inglés "Website Accessibility Conformance Evaluation Methodology 1.0". La WCAG-EM es una metodología armonizada internacionalmente para la evaluación de sitos web (incluyendo aplicaciones web y sitios web para dispositivos móviles) en conformidad con las WCAG 2.0.

La resumo con detalle en español en el artículo: "Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM)"

Documentos de apoyo a las WCAG 2.0

Se puede acceder a todos desde las propias WCAG 2.0. Los tres están en inglés:

WCAG 2.0 Referencia Rápida
Es una guía de referencia rápida donde, por cada criterio de éxito, se listan las técnicas suficientes, las técnicas consultivas y los errores asociados a dicho criterio.
Técnicas para WCAG 2.0
Recoge todas las ténicas y errores habituales organizados por tipo (por ejemplo, G1: Adding a link at the top of each page that goes directly to the main content area).
Comprender WCAG 2.0
Entra en más profundidad en cada criterio de éxito (se describe el criterio, se indica los usuarios a los que beneficia, se listan ejemplos, se incluyen los principales errores asociados a ese criterio, las distintas técnicas para satisfacerlo, etc.)
Comparison of WCAG 1.0 checkpoints to WCAG 2.0 (Non-Normative)

Traducción al español

WCAG 2.0: Candidata a traducción oficial, SIDAR
Comprender las WCAG 2.0: borrador, SIDAR
Comparativa entre los puntos de comprobación de las Pautas de Accesibilidad de Contenido Web 1.0 y las Pautas 2.0, agrupados por prioridades, traducción no oficial de codexexempla

Sobre las Técnicas WCAG 2.0

Sobre WCAG 2.0

10 razones para pasarse a las WCAG 2.0
"Hacia las Pautas WCAG 2.0" de Inteco. Recurso imprescindible.
Iniciativa One Guideline a Day de Olga Revilla. Muy recomendable su libro WCAG 2.0: made easy
"Sobrevivir a las WCAG 2.0", de Torres Burriel
"Web Content Accessibility Guidelines: from 1.0 to 2.0"
Web Content Accessibility Guidelines 1.0 — 2.0 Transition Cheat Sheet
Mapa conceptual de las WCAG 2.0
Cheatsheet W3C
Tetraedro de las WCAG 2.0
"Impacto de las pautas WCAG 2.0", conferencia en la Universidad Politécnica de Valencia el 9 de diciembre de 2009

Usable y accesible

Falsos errores de validadores automáticos de accesibilidad basados en las WCAG 2.0

Falso Error 1: campo de texto sin LABEL asociado... pero que tiene un TITLE adecuado

Falso Error 2: imagen que es un enlace y tiene ALT vacío... pero que va acompañada por un texto dentro del enlace

Falso Error 3: H2 presente en el código antes que un H1... sin tener en cuenta que estén bien marcados

Falso Error 4: indicar en cualquier caso que es obligatorio incluir enlaces para saltar bloques de contenido y un primer enlace en la página que lleve al contenido principal de la misma

Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM)

Paso 1. Definir el alcance de la evaluación

Paso 2. Explorar el sitio web

Paso 3. Seleccionar una muestra representativa

Paso 4. Auditar la muestra seleccionada

Paso 5. Informar de los resultados de la evaluación

Plantilla para el informe

Herramienta de ayuda para validar de acuerdo a las WCAG 2.0

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?

Reseña "WCAG 2.0 made easy" de Olga Revilla

Checklist para validar contenido Flash de acuerdo con las WCAG 2.0

Otros artículos de Usable y accesible relacionados con las técnicas de las WCAG 2.0:

Borrador de la traducción oficial al español de las WCAG 2.0

Técnicas WCAG 2.0 para otras 5 dudas sobre accesibilidad

Fácil de leer

10 razones para pasarse a las WCAG2.0

1 …porque el propio W3C así lo recomienda

2 … porque es igual de legal

3… porque ya tenemos validadores automáticos

4… porque no hay lugar para interpretaciones personales

5 … porque se aplica a todas las tecnologías Web

6 … porque se eliminan los puntos de control obsoletos

7 … porque se incluyen puntos de control nuevos que harán nuestras páginas más usables y accesibles

8… porque son más fáciles de utilizar y entender

9 … porque la declaración de conformidad está ahora sujeta a unas normas muy precisas

10 … refuerza positivamente la imagen institucional de la empresa

Enlaces de interés

TAW WCAG 2.0

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

Mapa conceptual de las WCAG 2.0

WCAG 2.0 Checklist

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

Validación de accesibilidad de acuerdo a las WCAG 2.0 con PISTA

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