Los cambios que presenta WCAG 2.1

Recomiendo la lectura de WCAG 2.1, medida provisional hasta las WCAG 3.0, que explica con mucho detalle las novedades que incorpora el último borrador de WCAG 2.1:

• 1.4.10 Zoom content (AA)
• 1.4.11 Graphics Contrast (AA)
• 1.4.12 User Interface Component Contrast (Minimum) (AA)
• 1.4.13 Adapting Text (AA)
• 2.2.6 Interruptions (minimum) (AA)
• 2.2.7 Accessible Authentication (A)
• 2.4.11 Character Key Shortcuts (A)
• Guideline 2.5 Pointer Accessible
• Guideline 2.6 Additional sensor inputs
• 2.6.1 Orientation (AA)
• Guideline 2.7 Speech
• 2.7.1 Accessible Name (A)
• 3.2.6 Accidental Activation (A)
• 3.2.7 Change of Content (AA)
• Requisito 5.1.2 Full Pages, nota adicional
• Nuevos términos en el glosario
• Corrección de errata en los criterios actuales 1.3.3 y 1.4.1

Lista de verificación de WCAG 2.0

En WCAG 2.0 checklists se puede encontrar una lista más de verificación de las pautas de accesibilidad web.

Extensiones a WCAG 2.0

En octubre de 2015, W3C anunció que comenzaba el trabajo en el desarrollo de una recomendación para la extensión de WCAG 2.0: Work Begins on Extensions to WCAG 2.0.

En enero 2016 se publicó el primer borrador de Requirements for WCAG 2.0 Extensions.

¿Se complica el uso de WCAG 2.0? Sí, un poco, así que recomiendo la lectura de Extensions to WCAG 2.0 para entenderlo un poco.

Comienza la extensión de WCAG 2.0

Web Content Accessibility Guidelines (WCAG) 2.0, las pautas que ayudan a crear contenido web accesible son de diciembre de 2008 y se están quedando un poco viejas. Han aparecido nuevas tecnologías y ahora los usuarios acceden a la Web e interactuan con la Web de formas muy distintas a como lo hacían hace casi 10 años. El W3C lo sabe y ya está trabajando en actualizarlas. Sin embargo, la solución no va a ser crear una nueva recomendación, sino proponer un marco para poder extender la versión actual: Work Begins on Extension to WCAG 2.0.

En este anuncio podemos leer:

New technologies on the horizon and the rapid evolution of the underlying technologies for user interaction on the Web are likely to continue to drive the need for new guidance. 

To address these needs, the WCAG Working Group has begun to develop a framework for WCAG 2.0 extensions. These would be separate guideline documents, to increase the amount of coverage on particular accessibility needs. Authors and policy-makers would be able to choose to meet the guidelines with one or more extensions, which inherently meet the base WCAG 2.0 guidelines, while organizations that have policies built around WCAG 2.0 alone would not be impacted by the extensions.

No diseñar contenido de un modo que se sepa podría provocar ataques, espasmos o convulsiones

Las Pautas de accesibilidad para el Contenido Web 2.0 (WCAG 2.0) tienen una pauta un poco "extraña":

Pauta 2.3 Convulsiones: No diseñar contenido de un modo que se sepa podría provocar ataques, espasmos o convulsiones.

Esta pauta tiene como objetivo evitar ataques epilépticos (epilepsia fotosensible) y otras complicaciones derivadas de la fotosensibilidad que presentan ciertas personas cuando una imagen parpadea con cierta frecuencia.

El caso más conocido fue el de la serie de dibujos animados Pokémon. En diciembre de 1997 se emitió el capítulo Dennō Senshi Porygon que causó supuestos ataques epilépticos en 12.000 niños (Pokémon contagion: photosensitive epilepsy or mass psychogenic illness?). Hay dudas de que todos fueran ataques reales, se cree que fue más producto de una "histeria colectiva", pero sí que hay varios cientos de casos que fueron reales.

Parece que la peor combinación es el rojo con el cyan, justo la que apareció en ese capítulo de Pokémon: A study of the effect of color photostimulation from a cathode-ray tube (CRT) display on photosensitive patients: the effect of alternating red-cyan flicker stimulation.

Por cierto, este fue el fragmento culpable:

Si no funciona el anterior, quizás funcione este:

¿Otra vez quieren quitar el atributo alt?

El atributo alt es el buque insignia de la accesibilidad web: es la característica típica que se emplea para explicar cómo se puede mejorar la accesibilidad de una página web.

Desgraciadamente, existe el atributo title que mucha gente emplea para hacer lo que se debe hacer con el atributo alt (consulta también El uso del atributo title).

El W3C lleva tiempo con la idea de eliminar la obligación de que todas las imágenes tengan el atributo alt, lo cual no alegra a mucha gente que cree que de golpe y porrazo se van a cargar 15 años de enseñar a la gente la necesidad de utilizar (correctamente) el atributo alt.

En Image alt Exception Change Re-Re-Re-Requested nos explican lo que está pasando dentro del W3C. Personalmente, creo que sería un completo error que se eliminase la obligación de que todas las imágenes tengan un atributo alt (que puede ser nulo) o que se pudiera sustituir por otras cosas, como el atributo title o las propiedades aria-label o aria-labelledby: el lío sería monumental.

Por cierto, parece que hay algunos que se han enfadado porque las discusiones que están teniendo lugar han salido del grupo que desarrolla WCAG y se han hecho públicas.

¿Las páginas tienen que ser válidas para ser accesibles?

Validar o no validar, e ahí la cuestión...

En WCAG 1.0, la pauta 3 "Utilice marcadores y hojas de estilo y hágalo apropiadamente" decía:

3.2 Cree documentos que estén validados por las gramáticas formales publicadas. [Prioridad 2]

Está claro que para cumplir WCAG 1.0, las páginas web tenían que ser válidas.

Sin embargo, en WCAG 2.0 hay un poco de confusión. La pauta 4 "Robusto" dice en su único punto 4.1 Maximizar la compatibilidad con las aplicaciones de usuario actuales y futuras, incluyendo las ayudas técnicas:

4.1.1 Procesamiento: En los contenidos implementados mediante el uso de lenguajes de marcas, los elementos tienen las etiquetas de apertura y cierre completas; los elementos están anidados de acuerdo a sus especificaciones; los elementos no contienen atributos duplicados y los ID son únicos, excepto cuando las especificaciones permitan estas características. (Nivel A) 

Nota: Las etiquetas de apertura y cierre a las que les falte un carácter crítico para su formación, como un signo de "mayor qué", o en las que falten las comillas de apertura o cierre en el valor de un atributo, no se consideran completas.

Y si se consulta Cómo cumplir 4.1.1, la técnica G134 Validating Web pages hace referencia explícita a la validación de HTML y CSS.

Por tanto, sí que las páginas tienen que seguir siendo válidas para poder cumplir con WCAG 2.0. Y hay varios expertos que confirman la importancia de validar el código:

• Parsing - clean code means a website your customers can use
• WCAG 2.0 parsing error bookmarklet

Sin embargo, hay algunos autores que no piensan los mismo. Por ejemplo, en el artículo WCAG Next pone:

Remove Parsing Requirement
While the intentions are noble, SC 4.1.1 (Level A), which requires that significant coding validation errors be avoided, has little impact on end-user accessibility and is next to impossible to evaluate. The areas in which coding errors impact accessibility are already sufficiently covered by other success criteria (such as proper form labeling, frame titles, table headers, etc.). I can’t think of a single instance where a significant coding issue would impact assistive technology specifically. The parsing requirement should be removed or perhaps changed to require strict validation at Level AAA.

Para terminar, unos vídeos en los que explico la importancia de validar las páginas web:

¿WCAG es la "biblia" de la accesibilidad?

Siguiendo con lo que se comentó en mi entrada anterior Más allá del cumplimiento de WCAG, ¿qué es lo que dice el W3C al respecto?

Lo podemos leer en la introducción de WCAG 2.0:

Web Content Accessibility Guidelines (WCAG) 2.0 defines how to make Web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability. These guidelines also make Web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general.

[...]

Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, as well as to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community. Metadata may assist users in finding content most suitable for their needs.

Es lo que hay... pero por lo menos tenemos esto. Mucho mejor es tener WCAG, aunque no sean perfectas, que no tener nada.

¿Qué hacer si algo no se puede hacer accesible?

Hace unos días, durante una conversación que tuve con una persona que quería resolver unas dudas sobre accesibilidad web, surgió la cuestión de qué hacer si algo no se podía hacer accesible. Yo le dije que entonces se tendría que proporcionar una alternativa accesible y esta persona me dijo que en la ONCE le habían dicho que eso no se podía hacer, que eso de ofrecer una versión alternativa era discriminación.

¿De verdad?

¿Es discriminación ofrecer un baño adaptado a las personas con discapacidad?

¿Es discriminación incluir un vídeo en una página web, junto con una videodescripción?

Las Pautas de Accesibilidad al Contenido en la Web lo permiten. En WCAG 1.0 podemos leer en la pauta 11 Utilice las tecnologías y pautas W3C:

11.4 Si, después de los mayores esfuerzos, no puede crear una página accesible, proporcione un vínculo a una página alternativa que use tecnologías W3C, sea accesible, tenga información (o funcionalidad) equivalente y sea actualizada tan a menudo como la página (original) inaccesible. [Prioridad 1]

En WCAG 2.0 podemos leer en los niveles de adecuación:

Nivel de conformidad: Uno de los siguientes niveles de conformidad se satisface por completo.
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.
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 proporciona una versión alternativa conforme al Nivel AA.
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.

Y una versión alternativa conforme es:

Una versión que:

1. es conforme según un nivel designado, y
2. proporciona la misma información y funcionalidad en el mismo idioma, y
3. se mantiene actualizada con la misma frecuencia que el contenido no conforme, y
4. para la cual al menos una de las siguientes condiciones es verdadera:
   1. se puede acceder a la versión conforme desde la página no conforme a través de un mecanismo compatible con la accesibilidad, o
   2. sólo se puede acceder a la versión no conforme desde la versión conforme, o
   3. sólo se puede acceder a la versión no conforme desde una página conforme que además proporciona un mecanismo para llegar a la versión conforme.

Por tanto si tenemos una página web con algo que no es accesible y no se puede accesible, podemos ofrecer una alternativa, pero siempre que se cumpla lo anterior. Y si lo hacemos así, la página web cumplirá con WCAG 2.0.

Mientras que algunas personas pueden entender esta forma de actuar como una discriminación, como "ofrecer una puerta trasera para las personas con discapacidad", hay que entender que no es así y que hay situaciones en las que es la única solución o que es incluso mejor que sea así. Por ejemplo, en el documento Understanding Conforming Alternate Versions muestran varias situaciones que refuerzan esta solución:

Why does WCAG permit conforming alternate versions of Web pages to be included in conformance claims? That is, why include pages that do not satisfy the Success Criteria for a conformance level in the scope of conformance or a claim?

• Sometimes, pages use technologies that are not yet accessibility supported. When a new technology emerges, assistive technology support may lag behind, or may only be available to some target audiences. So authors may not be able to rely on the new technology for all users. However, there may be other benefits to using the new technology, e.g., better performance, a wider range of modalities available, etc. The alternate version requirement allows authors to include such Web pages in their Web site by providing an accessible alternative page in technologies that are accessibility supported. Users for whom the new technology is adequately supported get the benefits of the new version. Authors who look ahead to future accessibility support can satisfy the Success Criteria now with the alternate version page, and also work with the other page to build in future access when assistive technology (AT) support is available.

• For a variety of reasons, it may not be possible to modify some content on a Web page. For instance,

• It may be critical to include an exact visual copy of a document for legal or historical reasons

• The Web page may be included in a site but the site owner may not have the legal rights to modify the content on the original page

• The company may not legally be able to remove, or alter in any way, something that was previously posted.

• An author may not have permission to alter a document from another department, agency, or company

• Sometimes, the best experience for users with certain types of disabilities is provided by tailoring a Web page specifically to accommodate that disability. In such a situation, it may not be possible or practical to make the Web page accommodate all disabilities by satisfying all of the Success Criteria. The alternate versions requirement permits such specialized pages to be included within a conformance claim as long as there is a fully conformant 'alternate version' page.

• Many sites which are committed to accessibility have large quantities of legacy documents. While the information has been made available in accessible formats, there would be significant institutional resistance and procedural obstacles to removing these files en mass. Some organizations, especially governmental bodies, give precedence to traditional print-oriented processes. Even as these organizations have adapted to Internet publishing and embraced the need for accessible formats, they still retain a paper mindset and often insist on formats designed for hard copy as the "primary" version (even for documents that are only ever "published" electronically). Although the Working Group feels these approaches should be deprecated it does not feel they can be forbidden so long as accessible versions are readily available.

A concern when permitting Web pages that do not satisfy the Success Criteria is that people with disabilities will encounter these non-conforming pages, not be able to access their content, and not be able to find the “conforming alternate version." A key part of the Alternate Versions provision, therefore, is the ability to find the conforming page (the alternate version) from the non-conforming page when it is encountered. The conformance requirement that permits alternate pages, therefore, also requires a way for users to find the accessible version among the alternate versions.
Note that providing an alternate version is a fallback option for conformance to WCAG and the preferred method of conformance is to make all content directly accessible.

WCAG también ayuda a las personas mayores

These guidelines also make Web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general.

Traducción:

Estas pautas también hacen que el contenido web sea más fácil de usar por las personas mayores con capacidades que cambian debido al envejecimiento y muchas veces mejoran la usabilidad para todos los usuarios en general.

WCAG 2.0

Aplicación de WCAG 2.0 a cosas que no son páginas web

WCAG 2.0 es agnóstico respecto a la tecnología, lo que significa que se puede emplear con tecnologías distintas a la Web.

¿Cómo? El documento Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies explica cómo se puede hacer.

De WCAG 1.0 a WCAG 2.0

Migrating from WCAG 1.0 to WCAG 2.0 (Incorporating W3C WCAG 2.0 Recommendation) es un documento que preparó Roger Hudson para ayudar a realizar la transición de WCAG 1.0 a 2.0. En este documento se establece la correspondencia entre los puntos de verificación de WCAG 1.0 y los criterios de éxito de WCAG 2.0.

INTECO publicó un documento parecido llamado Hacia las Pautas WCAG 2.0 hace tiempo.

¿UNE 139803:2004 o UNE 139803:2012?

El 2 de octubre de 2012 se publicó en el Boletín Oficial del Estado la nueva Norma UNE 139803:2012. Esta Norma sustituye a la anterior Norma UNE 139803:2004 que establecía los requisitos de accesibilidad web que se debían aplicar en España. Básicamente, la antigua norma era igual a WCAG 1.0, mientras que la nueva norma es una adaptación de WCAG 2.0.

Desgraciadamente, la resolución que se publicó el 2 de octubre era simplemente un anuncio de las nuevas normas publicadas por AENOR, y se indicaban las normas antiguas que las nuevas sustituían, pero no aclaraba algunas dudas importantes:

• Las leyes y reales decretos en materia de accesibilidad web hacen referencia a la antigua norma, ¿se actualizan automáticamente por la entrada en vigor de la nueva norma?
• ¿Qué ocurre con los sitios web que cumplían la antigua norma? ¿Se tienen que adaptar a la nueva?
• ¿Qué ocurre con los sitios web que se están desarrollando conforme a la antigua norma? ¿Se tienen que adaptar a la nueva antes de publicarse?

En definitiva, una situación bastante extraña, por no decir injusta y peligrosa. Un cambio tan importante debería de ir acompañado de un período de transición para adaptarse a la nueva norma. Y eso no se indicaba ni en esa resolución ni en posteriores.

Sin embargo, gracias a Álvaro D.Z., un lector de este blog, me ha llegado un documento con fecha 14 de mayo de 2013 de la Oficina Permanente Especializada, dependiente del Ministerio de Sanidad, Servicios Sociales e Igualdad, en el que se responde:

La Abogacía del Estado del Ministerio de Sanidad, Servicios Sociales e Igualdad, en contestación a una consulta elevada a instancia de la Subdirección General de Coordinación y Ordenación de la Dirección General de Políticas de Apoyo a la Discapacidad indicó como conclusión a una solicitud de informe que La Norma UNE de la AENOR 139803:2012 "Requisitos de accesibilidad para contenidos en la Web" sustituye a todos los efectos a la mencionada en el Real Decreto 1494/2007 con la referencia de niveles de accesibilidad y prioridades de la Norma UNE 139803:2004 sin necesidad de su incorporación o adaptación en una Orden Ministerial.

Por tanto, según dicho informe, es de aplicación, a todos los efectos, la Norma UNE 139803:2012.

¿Y si te ha pillado a medias de un desarrollo? Te fastidias...

¿Y qué hago con mis sitios web que cumplían la norma anterior? Misterio, misterioso...

Por cierto, la Norma UNE 139803:2012 está disponible de forma gratuita.

Enlaces significativos, ¿accesibilidad o usabilidad?

La accesibilidad y la usabilidad muchas veces se confunden. ¿O no se confunden? Quizás busquen lo mismo, pero desde distintos puntos de vista.

Las diferencias y similitudes entre la accesibilidad y la usabilidad las he tratado varias veces en este blog:

• ¿Accesibilidad vs usabilidad? (18/03/2009)
• ¿Accesibilidad, usabilidad, navegabilidad? (7/11/2007)

Ahora acabo de releer esto en el libro "Prioritizing Web Usability" de Jakob Nielsen y Hoa Loranger (New Riders, 2006):

Help people quickly differentiate links by giving them informative names. Rather than just linking to More, for example, tell users specifically what they'll get more of.

Traducción:

Ayuda a las personas a distinguir con rapidez los enlaces, dándoles nombres informativos. En lugar de simplemente enlazar con "Más", por ejemplo, dile a los usuarios concretamente "qué más" van a conseguir.

Pero, ¡esto es exactamente lo mismo que nos dice  el punto de verificación 13.1 Identifique claramente el objetivo de cada vínculo de las Pautas de Accesibilidad al Contenido en la Web 1.0?

¿Accesibilidad o usabilidad? ¿O estamos hablando de lo mismo?

Web Accessibility Wizard

Web Accessibility Wizard es un buscador específico de WCAG 2.0 que permite buscar y navegar por estas normas de una forma cómoda y rápida.

Por ejemplo, si buscamos "skip",para localizar información sobre los enlaces de "saltar a" que se suelen situar al principio de una página para saltar directamente al contenido principal de la página, obtenemos los siguientes resultados:

G1: Adding a link at the top of each page that goes directly to the main content area

G123: Adding a link at the beginning of a block of repeated 

G124: Adding links at the top of the page to each area of the content

Y si buscamos "list" obtenemos:

PDF21: Using List tags for lists in PDF documents

T2: Using standard text formatting conventions for lists

H48: Using ol, ul and dl for lists or groups of links

La Norma UNE 139803:2012 disponible de forma gratuita

Hace dos días recibí el siguiente mensaje de la D.G de Modernización Administrativa, Procedimientos e Impulso de la Administración Electrónica del Ministerio de Hacienda y Administraciones Públicas:

A través del Portal de Administración Electrónica puede obtenerse gratuitamente esta norma de inmensa utilidad para los sitios web de las Administraciones Públicas. 

La Norma UNE 139803:2012: Requisitos de Accesibilidad para contenidos en la web , es una norma española de reciente aprobación (julio de 2012) que establece los requisitos de accesibilidad para los contenidos web. En cuanto a sus requisitos, referencia completamente a las Pautas de Accesibilidad para el contenido web WCAG2.0 de la Iniciativa para la Accesibilidad Web (WAI) del Consorcio de la Web (W3C) por lo tanto hay una equivalencia directa entre ellas. 

Además, el Ministerio de Industria, Turismo y Energía aprobó el pasado 2 de septiembre una resolución en la que se especifica que la norma 139803:2012 sustituye a la norma 139803:2004 

La Secretaría de Estado de Administraciones Públicas, como parte de su iniciativa del Observatorio de Accesibilidad Web, ha suscrito un acuerdo con AENOR para la distribución gratuita de esta norma a través del Portal de Administración Electrónica. 

El conocimiento público y gratuito de esta norma pretende incidir positivamente en la implantación de estos nuevos requisitos de accesibilidad, especialmente en los portales web de las Administraciones Públicas. 

La descarga gratuita de la Norma UNE 139803:2012 puede realizarse desde: http://administracionelectronica.gob.es/PAe/accesibilidad/normativa

El daltonismo y WCAG 2.0

Hace un par de años escribí la entrada Mitos y malentendidos sobre la ceguera al color, en la que señalaba los puntos de verificación de WCAG 1.0 que hacían referencia al color y, por tanto, eran de interés para el daltonismo o ceguera al color.

¿Y qué dice WCAG 2.0 sobre este tema? Lo más importante lo encontramos en la pauta 1.4:

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.
1.4.1 Uso del color: El color no se usa como único medio visual para transmitir la información, indicar una acción, solicitar una respuesta o distinguir un elemento visual. (Nivel A)

Lo anterior es lo más importante de cara al daltonismo: no se tiene que emplear sólo el color para transmitir información, ya que si, por ejemplo, se emplea un código de colores como el rojo y el verde para indicar cierta información, las personas con daltonismo que no puedan diferenciar esos dos colores no podrán recibir la información transmitida.

También pueden ser de interés los puntos 1.4.3 y 1.4.6:


1.4.3 Contraste (mínimo): La presentación visual de texto e imágenes de texto tiene una relación de contraste de, al menos, 4.5:1, excepto en los siguientes casos: (Nivel AA)

• Textos grandes: Los textos de gran tamaño y las imágenes de texto de gran tamaño tienen una relación de contraste de, al menos, 3:1.
• Incidental: Los textos o imágenes de texto que forman parte de un componente inactivo de la interfaz de usuario, que son simple decoración, que no resultan visibles para nadie o forman parte de una imagen que contiene otros elementos visuales significativos, no tienen requisitos de contraste.
• Logotipos: El texto que forma parte de un logo o nombre de marca no tiene requisitos de contraste mínimo.

1.4.6 Contraste (mejorado): La presentación visual de texto e imágenes de texto tiene una relación de contraste de, al menos, 7:1, excepto en los siguientes casos. (Nivel AAA)

• Textos grandes: Los textos de gran tamaño y las imágenes de texto de gran tamaño tienen una relación de contraste de, al menos, 4.5:1.
• Incidental: Los textos o imágenes de texto que forman parte de un componente de la interfaz de usuario inactivo, que son simple decoración, que no resultan visibles para nadie o forman parte de una imagen que contiene otros elementos visuales significativos, no tienen requisitos de contraste.
• Logotipos: El texto que forma parte de un logo o nombre de marca no tiene requisitos de contraste mínimo.

¿Qué impacto tendrá que WCAG 2.0 sea un estándar ISO?

Hace un mes, WCAG 2.0 fue aprobado como estándar ISO. ¿Qué implicaciones tendrá está estandarización en el uso de WCAG? ¿Se espera un aumento de la accesibilidad?

El artículo WCAG 2.0 approved by ISO: what impact does it have? intenta explicar el impacto que va a tener esta estandarización.

Un beneficio muy importante es que se puede lograr la armonización de la legislación en materia de accesibilidad entre muchos países.

WCAG 2.0 ya es estándar ISO

Excelente noticia, porque ahora será más fácil que la legislación española haga referencia directa a WCAG 2.0, sin tener que hacer "el apaño" que se hace en España con la Norma Norma UNE 139803:2012.

A través de un mensaje de Ramón Corominas, (¡gracias!), me he enterado de la siguiente nota de prensa:
W3C Web Content Accessibility Guidelines 2.0 Approved as ISO/IEC International Standard.

El estándar lleva esta numeración, ISO/IEC 40500:2012, y efectivamente, cuando se consulta aparece con el estado 60.60 que significa "Estándar internacional publicado", que es el final del camino de la estandarización.

Lo más importante: ISO/IEC 40500:2012 = WCAG 2.0

La existencia de este estándar va a ayudar a la armonización de los niveles de accesibilidad web entre diferentes países, y evitará lo que dice Tim Berners-Lee (El lío de las guías de accesibilidad web):

No puedes diseñar un sitio e intentar que cumpla 152 grupos de guías diferentes de 152 diferentes países.

Y mañana publicaré una noticia buena sobre la nueva web del Senado, con esta ya tenemos suficiente por hoy.

Anuncio de la nueva norma UNE 139803:2012 en el BOE

Gracias a Félix Zapata, me he enterado de que hace dos días, el 2 de octubre, se publicó en el BOE-A-2012-12326 una resolución en la que ya aparece citada la nueva norma UNE 139803:2012 Requisitos de accesibilidad para contenidos en la Web (breve explicación de AENOR) que sustituye a la norma UNE 139803:2004.

¿Ahora sí? ¿Ahora ya es oficial y la accesibilidad en España se mide en base a WCAG 2.0? Parece que sí, es lo que yo entiendo, lo pone bien claro: "Sustituye a".

Recomiendo la lectura del artículo Nueva versión de la Norma UNE 139803, de Olga Carreras, para ponerse al día de las novedades de esta nueva norma.

Básicamente, UNE 139803:2012 = WCAG 2.0.