Técnicas WCAG 2.0 para otras 5 dudas sobre accesibilidad

Artículos relacionados

• Respuesta a 25 dudas habituales sobre accesibilidad web (enero 2011)


• Formularios accesibles según las WCAG 2.0 (junio 2009)


• WCAG 2.0 (febrero 2008)

1. ¿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.

El ejemplo de marcado correcto que propone la técnica es:

=8-0 (fright) <abbr title="fright">=8-0</abbr> <img src="fright.gif" alt="fright"/>

2. ¿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.

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

En algunos sitios nos encontramos una opción que permite leer el contenido de la página (por ejemplo con Vozme), ¿se recomienda esta práctica?

En respuesta a esta duda podemos consultar la técnica G79: Providing a spoken version of the text (asociada al criterio de éxito 3.1.5, de nivel AAA) en donde sí se recomienda.

A mí siempre me ha parecido que es útil cuando lee el contenido y no toda la página, puesto que para leer toda la página los usuarios que lo necesitan ya utilizan un lector de pantalla, que evidentemente tiene muchas más funcionalidades.

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

El criterio de éxito 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 una tecnología asistiva, hasta un 200% (es decir, hasta dos veces el ancho y la altura) sin pérdida de contenido o funcionalidad:

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.

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

En el criterio de éxito 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:


<p>When we talk about these guidelines, we often just call them
<ruby>
<rb>WCAG</rb>
<rp>(</rp>
<rt>Wuh-KAG</rt>
<rp>)</rp>
</ruby>.
</p>

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).

Canal YouTube

Este fin de semana me he estado divirtiendo personalizando el canal YouTube "Usable y accesible".

 

El objetivo del canal es recopilar vídeos relacionados con la accesibilidad y la usabilidad web. Cualquier sugerencia sobre vídeos que podría incluir será bien recibida.

Personalizar el canal es bastante sencillo, pero incluir un banner o enlaces, como se ve por ejemplo en el canal de Antena 3 o de U2, está sólo disponible para los parners de Youtube.

Cualquiera puede solicitar entrar dentro del programa de parterns, pero las solicitudes se revisan teniendo en cuenta diversos criterios, entre los que se incluyen el volumen de la audiencia, el país de residencia, la calidad del contenido y el cumplimiento de las "Normas de la comunidad" y de los "Términos de uso".

Así que si tu canal no es famoso ni tiene muchas visitas es difícil que te acepten la solicitud, en cuyo caso no puedes volver a presentarla durante dos meses.

YouTube te permite vincular la cuenta de YouTube, Twitter y Facebook, de esta manera es más fácil seguir las novedades del canal.

Fácil de leer

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.

Sexismo lingüístico

Hoy me ha llamado la atención la advertencia que he visto a pie de página en la Web del SACU (Servicio de Asistencia a la Comunidad Universitaria).

El texto dice textualmente:

Esta página web utiliza lenguaje no sexista. Las referencias a personas, colectivos o cargos citados en los textos en género masculino, por economía del lenguaje, debe entenderse como un género gramatical no marcado. Cuando proceda, será igualmente válida la mención en género femenino.

Por si alguien desconoce el término, el "sexismo lingüístico" hace referencia a cuando el lenguaje resulta discriminatorio debido a su forma, es decir, debido a las palabras o estructuras elegidas.

Lo primero que nos viene a la cabeza son los desdoblamientos que últimamente tanto se oyen en los medios de comunicación, el "miembro y la miembra" del que se ríe Pérez Reverte. Y la verdad es que a veces es para troncharse.

Sin embargo resulta un tema bastante interesante cuando te acercas a él sin extremismos ni prejuicios. O al menos a mí como lingüista me lo parece.

Hay un libro muy interesante, fácil de leer y con muchos ejemplos: "Manual de Lenguaje Administrativo no sexista", en el que encontré el siguiente ejemplo:

A la inauguración podrán acudir los concejales acompañados de sus mujeres.

Opines lo que opines del sexismo lingüístico, tendrás que reconocer que no es una frase muy afortunada.

Sería más apropiado:

"A la inauguración podrán acudir los concejales acompañados de sus parejas"

"A la inauguración podrán acudir los miembros de la Corporación Municipal acompañados de sus parejas".

(En realidad en el libro ponía "cónyuges" y no "parejas", pero supongo que no pedían el libro de familia para entrar en la inauguración.)

Me gusto especialmente el capítulo "Problemas estilísticos", en el que se desaconseja el uso de la "/", la "@" y los dobletes, que precisamente parecen los recursos más utilizados para demostrar tu simpatía por esta causa.

No obstante, y a pesar de que esté admitido, siempre que sea posible ha de evitarse separar con la barra la palabra y el morfema, pues afea el texto y dificulta su lectura, ya que si se opta por este recurso se habrá de utilizar no solo en los sustantivos, sino en todos los elementos con los que concuerden.

[...]

En determinados ámbitos, como el publicitario, se ha puesto de moda la utilización de la arroba al final de palabra (niñ@ para hacer referencia a niños y niñas). Este signo, supuestamente englobador de los dos sexos, no es recomendable, entre otras muchas razones, porque no es un signo lingüístico...

[...]

Las repeticiones o desdoblamientos de los términos pueden, como hemos visto evitar la ambigüedad del uso del masculino genérico; con todo, no se debe abusar de tal procedimiento, siendo recomendable emplear otras alternativas como, por ejemplo, los colectivos, las perífrasis o cualquier otro giro que, al mismo tiempo que no oculte a la mujer, no provoque recargamiento y lentitud en la expresión.

[...]

Resumen. Es inadmisible el empleo del símbolo @; cuando sea necesario economizar espacio puede recurrirse a los dobletes con barra (/), aunque proponemos limitar su uso a los impresos y formularios, puesto que dificulta la lectura y, como los desdoblamientos, lentifica el discurso.

Así que menos barras, menos arrobas, menos miembros y miembras y más sentido común.

A mí me parece un poco triste que lleguemos al extremo de tener que advertir al pie de nuestros escritos que "las referencias a personas, colectivos o cargos citados en los textos en género masculino, por economía del lenguaje, debe entenderse como un género gramatical no marcado. Cuando proceda, será igualmente válida la mención en género femenino".

Documentos que recomiendo conocer(7)

Serie "Documentos que recomiendo conocer"

Usabilidad

Libros

• "The Principles of Readability", William H. DuBay, 2004 (PDF)


• "Introduction to Good Usability", Peter Conradie, 2008 (PDF)


• "Search User Interfaces", Marti A. Hearst, 2009


• "Research-Based Web Design & Usability Guidelines", Michael O. Leavitt y Ben Shneiderman , 2006 (PDF, 157 MB)

Recursos

• "247 web usability guidelines", UserFocus, 2009.
  Incluye una checklist en formato Excel que InterGraphicDESIGNS ha traducido al español: Checklist en español(Formato Excel)


• "Generic Work Process"
  Herramientas, métodos y técnicas que pueden ser utilizados en el proceso de Diseño Centrado en el Usuario.


• "Cambio hacia los Estándares Web o cómo mejorar fácilmente tu sitio Web", W3C Quality Assurance
  [Visto en Círculo de Maquetadores]


• "Web 2.0 how-to design guide" de Scratchmedia


• Presentaciones del Congreso de Webmasters 2009.


• "Material del taller de la Semana de la Ciencia", Itákora, 2007

Móvil

• "Web Browsing on mobile phones. Characteristics of User Experience Doctoral Dissertation", Virpi Roto, 2006 (PDF)


• "Mobile Usability", Jakob Nielsen, 2009.
  Comentado por Álvaro Brito en "Estudio de Usabilidad Móvil de Jacob Nielsen", 2009

Estudios

• "Análisis de la eficacia de los sitios web universitarios argentinos", Paula Maciel, 2008

Accesibilidad

Libros

• "Guía de estilo sobre discapacidad para profesionales de los medios de comunicación", José Luis Fernández Iglesias, 2006. Permite la descarga gratuita en PDF.


• "Diseño de Páginas Web Accesibles", Sección de Documentación Consejería de Trabajo, Consumo y Política Social de la Región de Murcia. Permite la descarga gratuita en PDF.


• "Delivering inclusive websites", COI, 2009 (PDF)

Recursos

• "IMS Guidelines for Developing Accessible Learning Applications", 2002


• "IBM Web accessibility checklist", IBM


• "Evaluación de la accesibilidad de sitios web con la barra de herramientas de Firefox Web Developer Toolbar" de Sergio Luján


• "Google accessibility"

Accesibilidad en documentos de Office

• "Pautas de accesibilidad en presentaciones PowerPoint", CEAPAT. [Visto en accesibilidadweb.com]


• "Accessible Web Publishing Wizard", Virtual508.com. Accesibilidad de documentos Word y PPT.

Navegadores

• "When can I use... Compatibility tables for features in HTML5, CSS3, SVG and other upcoming web technologies", Alexis Deveria.

SEO y marca

• "Audiciencia de Internet", AICM (Asociación para la Investigación de Medios de Comunicación)


• "Personal Branding", Colin Wright [Visto en sortega]


• "How to convert clicks into profit", Google [Visto en Daniel Ulczyk]

Enlaces en los que perderse (5)

User Experience

• "So you wanna be a user experience designer", Whitney Hess, 2009. La autora nos propone todo tipo de recursos: libros, blogs, publicaciones, eventos, listas de correo, etc.

Information Architecture

• Information Architecture Institute. Learning IA. En el portal del Information Architecture Institute podemos encontrar todo tipo de recursos relacionados con Arquitectura de Información.


• "Gestión de proyectos web – Arquitectura de la Información", Anna García Sans, 2009.

Maquetación

• Code.google.com

Artículos relacionados:

• Enlaces por los que perderse anteriores
  
• Enlaces de interés

Imprescindibles (17)

Estos son los artículos que llamaron últimamente mi atención (no tienen porque ser recientes):

Usabilidad

• "Lo que la usabilidad no es", Jordi Sánchez, 2009.


• "Argumentaciones sobre Usabilidad", Daniel P. Uriol, 2005.


• "Diseño de Arquitecturas de Información: Descripción y Clasificación", Yusef Hassan Montero, 2005.


• "La regla de 3 clics", Usolab, 2009.


• "Reduciendo el esfuerzo del usuario", Usolab, 2009


• "10 Useful Usability Findings and Guidelines", Smashing Magazine, 2009. Relacionado con "You look where they look", James Breeze, 2009.


• "Lenguaje claro, sencillo y directo en el contenido", Maestros del Web, 2009


• "Flash vs HTML, la eterna guerra: un estudio", Xavier Lluch, 2009.


• "Eye-Tracking en Interacción Persona-Ordenador", Yusef Hassan Montero, 2007.

Accesibilidad

• "Técnicas propias para crear páginas accesibles" de Documento Web, 2009.


• "Como usar el longdesc", Álvaro Bito, 2009.

Diseño y maquetación

• "CSS Differences in Internet Explorer 6, 7 and 8", Smashing Magazine, 2009.


• "Diseño web para iPhone", Edgar Parada, 2009.


• "Guía para maquetar emails promocionales", Ateneu Popular, 2009.

Navegadores

• "Más comparaciones de navegadores ", anieto2K, 2009. Gana Chrome seguido de Firefox.

Curiosidades

• "Cuánta tinta de impresora gasta cada tipo de letra: una explicación visual", Microsiervos, 2009.

Serie "Imprescindibles" (recopilación de artículos de interés)

Noticias... (21)

Estas son las noticias que en los últimos meses llamaron mi atención:

Octubre

• "La Universidad de Jaén presenta su proyecto de Diseño, Implantación y Certificación del Sistema de Gestión de la Accesibilidad Universal" en Universia.


• "Un programa de software libre permite la lectura por voz de la pantalla del ordenador" en Europa Press.


• "A new home for accessibility at Google" en el blog de Google.


• "Bruselas mejorará la distribución de obras digitales para discapacitados". Sólo el 5% de las publicaciones europeas está disponible en formatos accesibles. En Solidaridad Digital.


• "El consejo de ministros aprueba la Ley General Audiovisual". En busca de mayor accesibilidad a los disminuidos sensoriales, se imponen exigencias de subtitulado del 75% de los programas para la televisión en abierto estatal y autonómica. En Cine & Tele.

Septiembre

• "Las webs de las grandes empresas españolas se olvidan de la accesibilidad". Según un estudio elaborado por el CERMI y Technosite, sólo seis de las 30 mayores compañías españolas cumple con los niveles que exige la ley en accesibilidad de sus páginas web. En Baquia.


• "Cermi y Fundación ONCE elaboran un nuevo modelo de ley autonómica ". El Comité Español de Representantes de Personas con Discapacidad (CERMI) ha instado a las Comunidades Autónomas a renovar y actualizar su legislación en materia de accesibilidad, para situarla en el paradigma de los derechos, la no discriminación y el cumplimiento efectivo. En Solidaridad Digital


• "Desarrollan el primer sistema de traducción de voz a la lengua de signos española". El sistema traduce en tres fases. En una primera fase se reconoce la voz del funcionario y se obtiene la secuencia de palabras pronunciada. Seguidamente, se traduce la secuencia de palabras a glosas (representación escrita de los signos) y, finalmente, se representan los signos mediante un agente animado. En Inteco.


• "El 9% de los clientes de las nuevas tecnologías son discapacitados" en el Mundo.


• "Adobe emprende acciones en pro de la accesibilidad para otras plataformas y herramientas de asistencia" en Programar a ciegas.

Julio

• "El Gobierno de Aragón y la Universidad de Zaragoza crearán el Centro Aragonés de Investigación en Tecnología Asistiva" en Discapnet


• "Empleo presenta una web, pionera en España, de contenidos de empleo accesibles para personas sordas" en Europa Press


• "El SACU implanta la lengua de los signos en su página web" en Diario de Sevilla.


• "Barclays renueva su web para hacerla accesible a usuarios con discapacidad" en Eco Diario.

Facebook profesional: ¿Grupo o Página?

Hoy no voy a hablar de usabilidad ni accesibilidad, sino de redes sociales.

Pensando en un nuevo proyecto me ha surgido la duda de cuál es la mejor opción para una empresa o evento que quiere tener presencia en Facebook, -cuyas estadísticas son asombrosas, más de 300 millones de usuarios, la segunda página más visitada de Internet o 14 millones de fotos subidas a diario,- ¿crear un Grupo al que puedas unirte o crear una Página profesional de la que te hagas fan?

Así que he decidido crear un Grupo y una Página profesional de "Usable y accesible" para decidirlo. Mi conclusión es que es mejor opción una Página profesional.

¿Por qué es mejor opción la Página que el Grupo?

Integración con Twitter

Cuando creas una Página la primera opción es sincronizarla con Twitter. De esta manera todo lo que escribes en el muro se publica automáticamente en Twitter.

Al crear un Grupo no tienes esta posibilidad.

Integración con tu Blog

Una Página tiene una pestaña "Notas" en la cual puedes indicar el feed de tu blog. Desde ese momento, en el "Muro" se publica una entrada cada vez que escribes un artículo en tu blog. En la pestaña "Notas" puedes ver un listado de los post, suscribirte, etc.

En un Grupo, sin embargo, tienes que incluir a mano las noticias recientes o los enlaces.

Integración con otras redes sociales mediante aplicaciones de Facebook

Existen aplicaciones para integrar tu canal de YouTube, de Flickr o de SlideShare, entre otros muchos.

Según la aplicación puedes indicar que aparezca como una pestaña nueva de la página, o que en la pestaña principal "Muro" se muestre un panel con las últimas actualizaciones.

En mi Página he usado la aplicación "SlideShare" para integrar mis presentaciones PPT; "YouTube Box" para mostrar los vídeos favoritos de mi cuenta de YouTube (desde YouTube también puedes publicar en Facebook); y "My Flickr" para integrar mis imágenes de Flickr.

Sin embargo, en un Grupo no es posible utilizar estas aplicaciones, ni tener diferentes pestañas. Puedes tener fotos y vídeos pero has de subirlos manualmente.

Estadísticas

Una Página tiene estadísticas de comentarios, publicaciones, seguidores, etc. que no tiene un Grupo.

Creación automática de paneles e insignias en tu web

Facebook te proporciona el código a insertar en tu página para que los seguidores puedan hacerse fans, o una insignia en la que aparece el último estado y el número de fans.

Usable y accesible | Promocionar tu página también


No existen estas opciones para los Grupos.

Tanto en Páginas como en Grupos tienes ...

• foros
• eventos
• selección de administradores
• permisos para que los miembros/fans suban imágenes, fotos o escriban en el muro
• envío de notificaciones a todos los miembros/fans

Enlace de interés:

• Comparativas entre el Perfil, Grupo o Página de Facebook
  
• Widgets de Facebook
• "32 Ways to Use Facebook for Business", Meryl Evans, 2009.

Frases (4)

Tu usuario más importante es ciego. La mitad de las visitas de tu sitio web vienen de Google, y Google solo ve lo que un ciego puede ver. Si tu sitio no es accesible, tendrás menos visitas. Fin de la historia.

Steven Pemberton

10 razones para pasarse a las WCAG2.0

Artículos relacionados
[30-01-11] Respuesta a 25 dudas habituales sobre accesibilidad web

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 Monitor

Descubro la nueva herramienta TAW Monitor que permite hacer un seguimiento de la accesibilidad de un portal.

Se puede probar durante un mes.

Parece que el análisis se realiza de momento de acuerdo a las WCAG 1.0 (al menos sólo se puede elegir esta opción al crear el análisis) aunque en el "Cuadro de mandos" está ya preparada la casilla para la futura verificación de acuerdo a:

• las WCAG 2.0 Cuando me llegue el análisis comentaré si ha validado también de acuerdo a las WCAG 2.0 Efectivamente, sólo ha validado de acuerdo a las WCAG 1.0


• "M. OK", hemos de suponer, ante la falta de ayuda o de explicación de la abreviación, que es el TAW mobileOK, que comprueba la adecuación de un contenido móvil al nivel "mobileOK Basic" según se define en W3C mobileOK Basic Tests 1.0 que está basado en las W3C Mobile Web Best Practices 1.0.

Me parece una herramienta muy útil, aunque estoy esperando el primer informe para poder opinar más extensamente, ampliaré entonces mi comentario.

Sí que me parece que podría tener muchas más funcionalidades, así que espero que sea sólo una primera versión.

Por otro lado, para lo simple que es, me ha parecido difícil de entender y utilizar. Creo que su usabilidad deja bastante que desear.

También su accesibilidad sería mejorable, por ejemplo no hay una alternativa a la "Barra temporal", que sin JavaScript no se puede consultar.

Aunque dispone de diferentes tipos de ayuda (FAQS, ayuda contextual y ayuda por sección) las dudas que a mí me han surgido no me las ha resuelto.

Objetivo de la aplicación

El objetivo de esta monitorización es asegurar que los sitios Web no se degradan a lo largo del tiempo debido a la inserción de nuevas páginas o contenidos, manteniendo informados a los gestores y técnicos de cualquier incidencia que afecte a su calidad.

Funcionalidades de la aplicación

• Visualizar resultados analíticos mediante un cuadro de mandos que facilita la interpretación efectiva los resultados, facilitando la detección de los factores que afectan a la calidad de los portales.


• Conocer la evolución de los portales en el tiempo por medio de un histórico de análisis donde se superponen los resultados.


• Definir la temporalización de los distintos análisis, haciéndolos coincidir con la planificación en la actualización de los contenidos de los portales u otros eventos importantes.


• Enviar informes después de cada ejecución de un análisis mostrando en ellos los resultados de cada indicador.


• Envíar alertas cuando alguno de los indicadores está fuera de los parámetros definidos por el usuario o se ha detectado una incidencia grave.