AJAX accesible

El objetivo de este artículo es reflexionar sobre los retos de accesibilidad que supone un desarrollo con AJAX. Me voy a centrar en la accesibilidad, sin entrar en los problemas de usabilidad que plantea (seguro que a todos os suenan los diez famosos problemas), tema que abordaré otro día.

Entiendo que si sigues leyendo es porque sabes lo que es AJAX como técnica de enriquecimiento de aplicaciones web, si no es así te recomiendo que antes de continuar le eches un vistazo a “AJAX: un nuevo acercamiento a Aplicaciones Web“ con la traducción del famoso artículo “Ajax: A New Approach to Web Applications” de Jesse James Garret.

AJAX no es un fin, es un medio

Mucha gente dará por sentado que si alguien preocupado por temas de usabilidad y accesibilidad hace un artículo sobre AJAX es para concluir: “no uséis AJAX, es el demonio, AJAX no es accesible”.

Nada más lejos de mis intenciones. Me gusta AJAX, he trabajado con AJAX y recomiendo a menudo AJAX. Y aquí entran las matizaciones.

• Recomiendo AJAX para problema concretos y siempre con sentido común.
• No recomiendo AJAX a toda costa, para todo, sólo porque los demás lo están usando o con el único afán de hacer alarde del dominio de la tecnología de moda. Usar AJAX con cualquier otro objetivo que no sea el de hacer más fácil, satisfactoria y productiva la experiencia del usuario, es simplemente una estupidez, y lo que es peor, un error que se descubre demasiado tarde.

En definitiva: AJAX no es un fin, es un medio para mejorar la experiencia del usuario. Parece evidente, pero un inquietante número de arquitectos y diseñadores software pierden la perspectiva.

AJAX con sentido común

Creo que Alex Bosworth, en su famoso artículo “10 Places You Must Use Ajax” recomienda muy acertadamente para qué usar o no usar AJAX:

Recomienda usar AJAX para:

• Form driven interaction.
• Deep hierarchical tree navigation.
• Rapid user-to-user communication.
• Voting, Yes/No boxes, Ratings submissions.
• Filtering and involved data manipulation.
• Commonly entered text hints/autocompletion.

NO recomienda usar AJAX para:

• Simple forms.
• Search.
• Basic navigation.
• Replacing a large amount of text.
• Display manipulation.
• Useless widgets.

Dicho esto, es cierto que un desarrollo con técnicas AJAX plantea interesantes retos de accesibilidad, y para afrontarlos deberemos partir de dos premisas básicas:

• La inmensa mayoría de los problemas tienen solución, unas veces será más fácil que otras, unas veces será más costosa que otras, pero siempre hay una solución. Al fin y al cabo en eso consiste nuestro trabajo ¿no? en encontrar soluciones a los problemas.
• Nada es de por si accesible o no accesible, ni una página, ni un script; los que los hacen inaccesibles son siempre los desarrolladores, por falta de conocimientos o por falta de interés.

AJAX y navegadores

AJAX se basa en el uso del objeto XMLHTTPRequest mediante Javascript ejecutado en el navegador para realizar peticiones asíncronas al servidor, y en la manipulación, también por Javascript, del Document Object Model (DOM) para visualizar e interactuar dinámicamente con la información presentada.

Por tanto, aunque AJAX no necesita ningún tipo de plugin para el navegador, requiere que el navegador soporte y tenga activo el Javascript, y que además soporte el objeto XMLHTTPRequest. En Internet Explorer 5 y 6, además, es necesario tener la secuencia de comandos ActiveX activada, ya que, en estas versiones, la implementación de Microsoft (denominada XMLHTTP) es un componente ActiveX (mientras que en versiones más recientes de los navegadores está implementado como un objeto nativo).

En resumen, los navegadores que soportan AJAX, siempre y cuando tengan Javascript activado, y en su caso la secuencia de comandos ActiveX, son:

• Microsoft Internet Explorer para Windows versión 5.0 y superiores, y los navegadores basados en él (por ejemplo Maxthon)
• Navegadores basados en Gecko como Mozilla, Mozilla Firefox, SeaMonkey, Camino, Flock, Epiphany, Galeon y Netscape versión 7.1 y superiores
• Navegadores con el API KHTML versión 3.2 y superiores implementado, incluyendo Konqueror versión 3.2 y superiores, Apple Safari versión 1.2 y superiores.
• Opera versión 8.0 y superiores
• Dispositivos móviles: Opera Mobile Browser 8.0 basado en Safari y API KHTML, que soporta aplicaciones desarrolladas en AJAX gracias a su motor de Javascript y su seguimiento del DOM. El mes pasado Mozilla lanzaba Minimo Mobile Browser 0.2 compatible con Windows Mobile 5.0, y que soporta Javascript y AJAX.
  
  [Si os interesa el uso de AJAX en entornos móviles, es interesante echar un vistazo a MOJAX (Mobile AJAX Application Frameworks)]
  

Los navegadores que NO soportan AJAX son:

• Opera 7 y anteriores
• Microsoft Internet Explorer para Windows versión 4.0 y anteriores
• IE para Macintosh, todas las versiones
• Dillo
• Navegadores basados en texto como Lynx y Links
• Navegadores para incapacitados visuales (braille)
• Dispositivos móviles: Deepfish de Microsoft, presentado también hace un par de meses no soporta controles ActiveX, AJAX, cookies, ni JavaScript.

AJAX accesible

El punto de verificación 6.3 de las Pautas de Accesibilidad de la WAI dice así:

Asegúrese de que las páginas sigan siendo utilizables cuando se desconecten o no se soporten los scripts, applets u otros objetos programados. Si esto no es posible, proporcione información equivalente en una página alternativa accesible.

Dicho punto es de Prioridad 1, es decir, es necesario para alcanzar un nivel de adecuación Simple A. Por tanto, para asegurar la accesibilidad de nuestra aplicación, se debe ofrecer una alternativa para el contenido mostrado dinámicamente por Javascript.

Si se utiliza un framework para implementar técnicas AJAX, bien sea open source, comercial o propio de nuestra organización, habrá que asegurarse de que éste ofrece una alternativa accesible adecuada para cada componente AJAX y de que tienen en cuenta las incompatibilidades entre navegadores. [1]

Y por supuesto, todos aquellos contenidos que se inserten dinámicamente en la página deben cumplir las normas de accesibilidad de ese elemento, tal y como las cumplen los demás elementos de la página. Y por tanto, si se utiliza un framework, asegurarse de que cumpla este requisito. [2]

Y después de todo lo dicho, llegamos a lo realmente importante, al "meollo" del asunto.

Cuando indico que es necesario ofrecer una alternativa accesible NO me refiero a crear dos aplicaciones diferentes, una con AJAX y otra sin AJAX. La WAI desaconseja explícitamente los sitios alternativos por no ser una solución integradora, eso sin contar con el elevado coste de realizar dos versiones, las dificultades y el coste de su mantenimiento (“casa de dos puertas es difícil de guardar” ).

El objetivo, por lo tanto, es conseguir hacer accesible una única aplicación.

¿Cómo podemos pues ofrecer alternativas accesibles para los desarrollos AJAX sin crear dos aplicaciones diferentes?

Antes de entrar en el tema me gustaría hacer un inciso sobre la etiqueta "noscript", de la que a menudo se echa mano. Por ejemplo, imaginemos un menú dinámico implementado por AJAX, de tal manera que al pulsar en una de las opciones principales del menú, se consulta al servidor su árbol de submenús para pintarse en la página.

Puede pensarse que una buena alternativa accesible sería en la etiqueta "noscript" incluir todo el árbol del menú (o si este es muy extenso, un enlace a un página con todas las opciones de menú). Pero hay que advertir que la etiqueta "noscript" no estará en el estándar XHTML2.0

De todas formas, como voy a explicar ahora, hay una manera más robusta de hacer las cosas.

Para empezar, tu aplicación debe utilizar un patrón MVC (Modelo-Vista-Controlador) que separe los datos de la aplicación, la interfaz de usuario y la lógica de negocio en tres componentes distintos… y si no… vamos “apañaos”.

Por otra parte, es graciosa tanta preocupación por separar el contenido, la presentación y el comportamiento, para luego encontramos las páginas llenas de Javascript. No me refiero a que el código no esté en ficheros JS (faltaría más), sino a tener el código Javascript mezclado con el código HTML, empozoñándolo al estilo de <input onClick=”mifuncion()”>.

Todo el código javascript debe ser no intrusivo, invisible, de tal manera que no afecte su desactivación al funcionamiento de la página, y por supuesto tener cuidado con el tipo de eventos que se manejan (el evento onClick será inservible, por ejemplo, a un usuario que no disponga de ratón).

[Si lo de javascript “no intrusivo” te suena a chino, ya te estás yendo a Unobtrusive Javascript y a Behaviour].

Bien, tenemos pues una aplicación como dios manda en la que además, desde la primera petición al servidor de nuestras páginas, éste identifica el User-Agent en una cabecera del protocolo http, pudiendo guardar esta información en una variable. Dicha variable será recuperable en toda la aplicación y servirá a los componentes AJAX de nuestro framework para que decidan cómo deben presentarse (en combinación con la identificación en su código generado de si está activado el Javascript en el navegador).

Cuando hablo de componentes AJAX, en realidad pienso siempre en un framework personal o corporativo de mi organización o de mi cliente. Desconfío de los grandes frameworks de AJAX por varias razones: tienen bugs al estar todavía poco maduros y no siempre hacen todo lo que el cliente/usuario/guía de estilo te exige que hagan. Prefiero un framework personal, al que le puedes echar mano con facilidad, sólo con los componentes que necesitas, a la medida de tus necesidades, y por supuesto basado en prototype. [3]

En este contexto, un componente AJAX sería, por ejemplo, una tabla con ordenamiento de columnas y paginación mediante AJAX, o un menú dinámico que consulte por AJAX las subopciones que ha de desplegar antes de repintarse.

Nuestro componente “tabla” define internamente dos comportamientos en función del User-Agent: cómo pintarse para el caso de que sí admita javascript y en el de que no lo admita.

Por otro lado, hay que decir que la variante accesible dependerá mucho del tipo de componente; por ejemplo:

• Si se trata de un autocompletar en una caja de texto, puede decidirse que no es necesario disponer de una alternativa accesible, puesto que no tenerla no merma en nada la interacción con el formulario.
• En el caso de una validación campo a campo de un formulario asíncronamente mediante AJAX, siempre que el formulario tenga un botón submit que valide los campos en servidor, no necesitará mayor alternativa.
• En el caso de las capas de detalle (o balones) que aparecen sobre una celda de una tabla a modo de resumen (para no tener que navegar al detalle completo si no se desea), mi punto de vista es que si existe el enlace de detalle en cada fila, tampoco es necesaria otra alternativa accesible.

Por lo tanto, si cada componente de nuestro framework tiene correctamente implementado internamente su comportamiento en función de las capacidades del navegador y del contexto de ejecución, este framework conseguirá el objetivo de cualquier diseño técnico orientado a componentes: independizar a la aplicación que los utiliza acerca de sus particularidades de implementación, lo que en este caso significa, en un caso ideal, que el desarrollador de la aplicación no deberá preocuparse acerca de las alternativas accesibles para los elementos enriquecimiento utilizados.

De esta manera, la alternativa accesible es sólo a nivel de capa de presentación y sólo a nivel de componentes, no de aplicación. [4]

Es necesario conocer...

Si os interesa este tema, son imprescindibles los 40 tutoriales y artículos de AJAX y accesibilidad.

También es imprescindible conocer WAI-ARIA, para ello podéis leer mi artículo WAI-ARIA. Introducción, referencias, ejemplos, herramientas

Por último comentar el artículo "Making Ajax Work with Screen Readers" de Gez Lemon and Steve Faulkner, que proponen manejar el búfer virtual del lector de pantalla JAWS como vía para hacer accesible una aplicación web.

Como complemento de nuestra aplicación puede ser buena idea, pero no es un estándar, ni JAWS es el único software para usuarios con deficiencias visuales, ni por supuesto la accesibilidad está pensanda sólo para este colectivo, como a veces parece que mucha gente piensa.

En resumen, buenas prácticas

• Respetar las pautas de accesibilidad en todos los elementos de las páginas aunque estén insertados dinámicamente.
• Utilizar un patrón MVC que facilite la separación entre las lógicas de control y flujo de navegación (Controlador), de negocio y acceso a datos (Modelo), y de presentación en los distintos clientes, dispositivos y contextos (Vista).
• Utilizar Javascript no intrusivo.
• Conocer los navegadores para discapacitados visuales y comprobar que pueden interactuar con la aplicación: eventos adecuados, foco accesible, etc.
• Detectar el User-Agent del usuario desde la primera petición guardando esta información para que sea recuperable por todas las páginas de la aplicación.
• Crear una serie de módulos, de componentes AJAX, que en función del User-Agent y de si está habilitada la ejecución de Javascript sepan como “pintarse”, dando por tanto una opción alternativa accesible dependiendo del componente en cuestión.
• Acatar la hoja de ruta de la WAI que permitirá por ejemplo informar mediante roles al usuario del funcionamiento exacto de la aplicación cuando los navegadores las implementen.

Notas

[1] Por ejemplo, Rails incluye alternativas accesibles para formularios que se envían por Javascript, incluyendo un argumento que indica a qué URL enviarlo si no está habilitado el Javascript.

[2] Por ejemplo, Dojo 0.4 empieza a ofrecer funcionalidad completa desde teclado e integración con modos de alto contraste así como con lectores de pantalla para las personas discapacitadas. dojo.a11y: la fundación para la accesibilidad (a11y), ha implementado algunos de los widgets de esta versión e implementará algunos más para la siguiente (0.5).

[3] Esta afirmación la considero válida en la actualidad, pero la evolución tecnológica que puede haber en un plazo de 2-3 años en los frameworks y productos disponibles, su integración con los IDEs, etc, seguramente desaconsejará a corto plazo el uso de frameworks propios, cuya principal debilidad es el coste y dificultad del futuro mantenimiento evolutivo/correctivo/adaptativo/perfectivo).

[4] A nivel de lógica de negocio, no sería óptimo trabajar sólo con macropeticiones (peticiones globales de la página como en una aplicación sin AJAX) ni siquiera componer las macropeticiones a través de las micropeticiones (pequeñas peticiones sólo de aquellos contenidos de la página que vamos actualizar con AJAX), por ello, sí que será necesario que junto a las micropeticiones haya macropeticiones para las variantes accesibles.

Artículos relacionados
[07-09-07] AJAX accesible: WAI-ARIA. Introducción, referencias, ejemplos, herramientas
[14-11-13] Live Regions y WAI-ARIA. Cómo mejorar la accesibilidad de contenidos que se actualizan automáticamente
[13-03-14] Nuevas técnicas ARIA en las WCAG 2.0. Novedades de la actualización del documento "Techniques for WCAG 2.0" del 11 de marzo de 2014

Metodologías, certificaciones y entidades certificadoras de la accesibilidad web en España

Última actualización: 10 de junio de 2018

Índice

1. Qué es una certificación y quién puede certificar la accesibilidad web en España
2. Entidades de certificación de la accesibilidad web en España
   
   • 2.1. Certificación "Accesibilidad TIC" de AENOR
   • 2.2. Certificación "Euracert" (Technosite), actualmente Ilunion
   • 2.3. Comparativa certificación Ilunion - AENOR
3. Metodologías de evaluación de la accesibilidad web
   • 3.1 Metodología de Revisión de la Accesibilidad de la WAI
   • 3.2 Metodología de Evaluación de Conformidad con la Accesibilidad en Sitios Web (WCAG-EM) del W3C
   • 3.3 Metodología para la inclusión de la accesibilidad en todas las fases de desarrollo de un sitio web
   • 3.4 Futura metodología europea de monitorización de la accesibilidad de los sitios web y apps del sector público
4. Otros sellos:
   
   • 4.1 Símbolo internacional de la accesibilidad Web
   • 4.2 Logotipos de validación del W3C
   • 4.3 Logotipos de validadores automáticos de accesibilidad
   • 4.4 Logotipos del nivel de Conformidad con las Directrices de Accesibilidad para el Contenido Web 1.0 (WCAG 1.0)
   • 4.5 Logotipos del nivel de Conformidad con las Directrices de Accesibilidad para el Contenido Web 2.0 (WCAG 2.0)
   • 4.6 Sello GESAccesibilidad
   • 4.7 Universal Accesskey
   • 4.8 Sello MobileOk del W3C
   • 4.9 Protocolo NI4 Navegación Fácil
   • 4.10 RNIB Surf Right
   • 4.11 Sello Bequal
   • 4.12 Sello DIGA
   • 4.13 Sello de Calidad de Internet IQ

1. Qué es una certificación y quién puede certificar la accesibilidad web en España

La Organización Internacional de Normalización (ISO) define certificación como

atestación por tercera parte relativa a productos, procesos, sistemas o personas, entendiéndose por atestación la actividad que se basa en la decisión tomada luego de la revisión y consiste en autorizar y emitir una declaración de que se ha demostrado que se cumplen los requisitos specificados. Esta declaración puede ser un certificado o una marca de conformidad.

En todos los casos la declaración garantiza a los usuarios de la evaluación de la conformidad que se cumplen los requisitos especificado. Para que la certificación se realice en forma imparcial debe ser realizada por una tercera parte, es decir un organismo independiente de los respectivos intereses del proveedor del objeto de la certificación (primera parte) y del usuario de la certificación (segunda parte).

Los requisitos especificados, a los que hace mención la definición de certificación, pueden estar contenidos en normas, especificaciones técnicas, reglamentos u otros documentos normativos.

La legislación española indica que:

Artículo 7. Sistema de certificación de páginas de internet.

1. A los efectos de este real decreto, las páginas de internet se podrán certificar por una entidad de certificación cuya competencia técnica haya sido reconocida formalmente por una entidad de acreditación de acuerdo con lo dispuesto en el capítulo II del título III, sobre calidad industrial, de la Ley 21/1992, de 16 de julio, de Industria y en sus correspondientes disposiciones de desarrollo contenidas en el Real Decreto 2200/1995, de 28 de diciembre, por el que se aprueba el Reglamento de la infraestructura para la calidad y la seguridad industrial.

2. En los procedimientos de certificación a los que se refiere el apartado anterior se emplearán preferentemente normas técnicas españolas, normas aprobadas por organismos de normalización europeos y, en su defecto, otras normas internacionales aprobadas por organismos oficiales de normalización.

En Real Decreto 1494/2007, de 12 de noviembre (cap.III, art. 7)

Por tanto, la Administración Pública no tiene la obligación de certificar los sitios web, pero si lo hace, debe hacerlo con una entidad acreditada.

Una entidad de certificación acreditada permite que sea percibida como una organización técnicamente competente, independiente y fiable por los que han de confiar en la veracidad y valor de sus certificados.

A nivel internacional se demuestra cumpliendo con las Normas ISO de la serie 17000.

Solo cuando una empresa ha demostrado que cumple lo establecido en esas normas será identificada a nivel internacional como una entidad de certificación.

En España, solo la ENAC, Entidad Nacional de Acreditación, está autorizada para evaluar y declarar ese cumplimiento, y declarar una entidad de certificación acreditada.

Enlaces de interés:

• ENAC, Entidad Nacional de Acreditación
• Consulta de entidades acreditadas de la ENAC
• Conoce la diferencia entre certificación acreditada y no acreditada (ENAC) (PDF)

En resumen:

• No es obligatorio que la Administración Pública certifique sus portales.
• Si lo hace, debe ser con una entidad de certificación acreditada.
• Para ser una entidad de certificación acreditada se debe cumplir con Norma ISO de la serie 17000.
• La ENAC es la entidad que acredita en España, y la que puede declarar a una entidad de certificación acreditada.

2. Entidades de certificación de la accesibilidad web en España

2.1 Certificación "Accesibilidad TIC" de AENOR

Historia

A comienzos de 2007, AENOR (Asociación Española de Normalización y Certificación) lanzaba la certificación "Accesibilidad TIC" web en colaboración con:

• la Fundación CTIC (Centro Tecnológico de la Información y la Comunicación), constituida por un patronato de empresas del sector tecnológico y por el Gobierno del Principado de Asturias, que alberga la Oficina Española del W3C y es creadora del TAW (Test Accesibilidad Web).
  
• ESI (European Software Institute) que forma parte de la Corporación Tecnológica Tecnalia y fue creada por la Comisión Europea con el apoyo del Gobierno Vasco.
  
  
  AENOR calificó en febrero de 2007 a tres técnicos de European Software Institute (ESI-Tecnalia) como evaluadores expertos en la norma UNE de Accesibilidad Web.

5 de febrero de 2007 [...] Estos especialistas trabajarán como inspectores cualificados de acuerdo a los procedimientos vigentes en la certificación de productos y según los requisitos deontológicos establecidos por AENOR, especialmente, en lo relativo a la independencia para asumir labores de asesoramiento y consultoría. [En Fundación CTIC]

La Fundación CTIC tenía anteriormente su propia metodología para la evaluación web y ofrecía servicios de consultoría, auditoría y certificación de accesibilidad con el sello:

 

[..] hemos desarrollado una metodología de evaluación y soporte basada en los estándares y especificaciones del W3C para detectar y corregir problemas de accesibilidad y estandarización, mediante la combinación de herramientas de revisión automática y manual. [En Fundación CTIC]

Junto con ESI también otorgaba el sello de "Certificación Internacional de Accesibilidad Web" que definían como "una certificación internacional independiente basada en las pautas WCAG 1.0 (Web Content Accesibility Guidelines) del W3C (World Wide Web Consortium), elaborada en base a una metodología de evaluación e inspección que permite detectar problemas de accesibilidad combinando herramientas de revisión automática y manual". El sello de esta certificación era:

 

Actualmente, estos dos sellos (CTIC y Certificación Internacional de Accesibilidad Web) han desaparecido.

La certificación "Accesibilidad TIC" de AENOR certificaba inicialmente en base a la Norma UNE 139803:2004 Aplicaciones informáticas para personas con discapacidad. Requisitos de accesibilidad para contenidos Web) aprobada mediante Resolución 2855 de fecha 2005-01-25 de la Dirección General de Desarrollo Industrial. (B.O.E. nº 43-2005 de fecha 2005-02-19).

La Norma UNE 139803:2004 (basada en las WCAG 1.0) fue sustituida por la nueva versión, la Norma UNE 139803:2012 (basada en las WCAG 2.0) el 4 de julio de 2012, publicándose en el BOE el 3 de septiembre de 2012.

El 9 de mayo de 2007 se anunciaba que ocho webs estrenaban este certificado de accesibilidad:

Las primeras páginas web en España que han obtenido el certificado de accesibilidad son los portales de la Agencia Valencia de Turismo, del Ayuntamiento de Ermua, del Ayuntamiento de Gijón, del Ayuntamiento de Zaragoza, de CajAstur, del Centro Europeo de Empresas e Innovación de Vizcaya, de la Diputación Foral de Vizcaya y del Gobierno del Principado de Asturias. [En Fundación CTIC]

Certificación AENOR actualmente

AENOR cuenta con cerca de 190 acreditaciones, reconocimientos, acuerdos y nombramientos para las actividades de certificación, validación, verificación, inspección y ensayos, otorgados entre otros, por ENAC (Entidad Nacional de Acreditación). Además mantiene implantado y documentado un Sistema de Gestión de la Calidad basado en la gestión por procesos y que cumple con las normas internacionales aplicables como UNE-EN ISO/IEC 17021, UNE-EN ISO/IEC 17025, etc.

AENOR solo audita, nunca participa en actividades de desarrollo ni ayuda a corregir los problemas. Certifica el nivel AA y AAA (si solo se satisfacen los criterios de nivel A no se obtiene el certificado)respecto a la norma UNE 139803:2012 (equivalente a las WCAG 2.0)

La certificación de AENOR sigue un proceso que consiste en evaluar un sitio web, combinando sistemas de revisión automática con metodologías de inspección manual.

Dispone de dos tipos de certificación:

• “Certificado AENOR - Marca N de Accesibilidad TIC”: para obtener este certificado es necesario, además del cumplimiento de las Pautas de Accesibilidad, que la organización haya implantado y mantenga un Sistema de Gestión de la Accesibilidad. Se hace un seguimiento semestral de la certificación y auditorías anuales del Sistema de Gestión de la Accesibilidad.

  El periodo de validez es de 3 años y se realizan actividades de seguimiento semestralmente.

• “Certificado de conformidad con la Norma 139803”: se otorga a aquellas organizaciones que únicamente desean demostrar la conformidad de su sitio Web con los requisitos de la Norma de referencia (UNE 139803) de manera puntual. No tiene seguimiento de la certificación ni por tanto garantía de continuidad, por ello no se concede licencia de uso de la marca.

  Por ejemplo, un organismo se lo puede pedir a la empresa con la que externaliza el desarrollo, como muestra de que el sitio es accesible en el momento de entrega.

Como hemos visto, para alcanzar el Certificado AENOR - Marca N de Accesibilidad TIC, es necesario implantar en la empresa un Sistema de Gestión de la Accesibilidad que asegure que la esta se mantendrá en el tiempo. Para ello, la organización debe:

• Identificar los procesos necesarios para que el diseño y desarrollo del sitio web sea accesible.
• Identificar el flujo de publicación de contenidos para que el sitio web permanezca accesible.
• Identificar los procesos de mantenimiento y mejora de sitios web para que este permanezca accesible.
• Identificar los puntos de control y la frecuencia de los mismos para mantener la accesibilidad del sitio web.
• Asegurarse de la disponibilidad de recursos e información necesaria para el diseño, desarrollo, gestión de contenidos y mantenimiento de las páginas Web.

Los siguientes procedimientos deben estar documentados, implantados y mantenidos:

• Gestión de recursos, incluye el personal (competente y bien formado), y las herramientas necesarias.
• Elaboración del sitio web: procesos y métodos de control. La documentación debe incluir, para cada etapa, tanto las revisiones a realizar como las responsabilidades y autoridades.
• Gestión de proveedores: para cada servicio o proceso prestado por un proveedor se deben definir las características críticas y una metodología de evaluación, selección y seguimiento del nivel de prestación de dichas características.
• Seguimiento de la satisfacción de los usuario: se han de definir los métodos para obtener y utilizar esa información incluyendo las quejas y sugerencias de mejora.
• Medir y hacer un seguimiento del cumplimento de la página: se deben mantener registros que evidencien su conformidad, mediante controles y responsabilidades. Se deben detectar productos que no cumplan y prevenir su entrega. Se deben registrar las no conformidades y las acciones correctivas para prevenir que vuelva a ocurrir.
• Tratamiento de las reclamaciones del cliente: se deben mantener registros de las reclamaciones, su análisis y las acciones correctoras a las que dieron lugar, y conservarlos durante 3 años para que estén a disposición del auditor.

Un ejemplo de sitio certificado es el Ayuntamiento de Bilbao. Otros son el Ayto. de Zaragoza, el Ayto. de Madrid, la Diputación de Vizcaya, etc. Se puede consultar el Buscador de empresas certificadas de AENOR.

Web de la Certificación de Accesibilidad TIC de AENOR.

Nota 2018 Fundación CTIC

Ha comenzado a verse el sello:

Por ejemplo en la web del IMSERSO, con un año de duración y auditorías periódicas.

2.2 Certificación Euracert (Technosite), actualmente Ilunion

Historia

Durante el año 2006 se publicó el esquema europeo de certificación CWA N°15554 y la metodología europea de evaluación de la accesibilidad web (UWEM, Metodología de Evaluación Web Unificada).

En demanda de la Comisión Europea, el proyecto Support-EAM (Supporting the creation of an eAccesibility Mark), entre cuyos partners está Tecnosite o BrailleNet, lanzó y condujo unas jornadas de trabajo en el CEN (European Commitee for Standardization), en la que participaron 39 organizaciones de 16 países de Europa que produjo un acuerdo (CWA nº 15.554:2006) el 15 de abril de 2006.

Publicaron un documento que presenta el esquema de certificación de la accesibilidad de la Web en Europa "Especificaciones para el esquema de la evaluación de la conformidad y marca de calidad sobre accesibilidad Web": [CEN Workshop Agreement (CWA) N°15554 “Specifications for a Web Accessibility Conformity Assessment Scheme and a Web Accessibility Quality Mark"].

Presentado por el CEN como un acuerdo europeo de primer nivel sobre cómo esquemas estándar de evaluación comúnmente utilizados en Europa pueden ser aplicados en la evaluación de la conformidad de la accesibilidad Web.

Este acuerdo refleja tres tipos de peticiones que fueron identificadas:

• Declaración de conformidad por proveedores (de acuerdo con la ISO/IEC 17050)
• Inspección (de acuerdo con la ISO/IEC 17020)
• Certificación de productos (de acuerdo con la ISO/IEC 45015)

En el mismo año se presenta UWEM 1.0 (Unified Web Evaluation Methodology), la metodología europea de evaluación de la accesibilidad web. El objetivo fue ser totalmente compatible con las pautas de WCAG 1.0. En la actualidad, la UWEM se limita a las pautas de prioridad 1 y 2 y presenta un método único tanto para la evaluación por un experto humano como de manera automática por interfaces de máquinas.

La última versión es la UWEM 1.2 y hay un plan para adaptarla a las WCAG 2.0 todavía sin ejecutar que dará lugar a la UWEM 2.0.

La UWEM fue el resultado del esfuerzo conjunto de tres proyectos europeos aunados en un grupo llamado WAB Cluster. 23 organizaciones europeas participan en estos tres proyectos europeos cuyos nombres son EIAO (para la creación de un observatorio de la Web), Support EAM (Supporting the creation of an a eAccesibility Mark, un proyecto de certificación ) y BenToWeb (para el desarrollo de herramientas de evaluación)

La metodología ha sido concebida para cumplir los siguientes requisitos:

• Conformidad técnica con los documentos de técnicas y las recomendaciones existentes de la Iniciativa de Accesibilidad a la Web (WAI)
• Independencia con respecto a instrumentos y navegadores
• Interpretación única
• Replicabilidad
• Traducción
• Conformidad con la reglamentación europea

En la metodología se incluyen datos sobre:

• La definición y el muestreo de un sitio Web.
• El informe, la interpretación y la integración/agregación de los resultados de las pruebas.

La UWEM se encuentra disponible es español en Metodología Unificada de Evaluación Web (UWEM 1.0.) y se puede ampliar información sobre la misma en Esquema de Certificación y Sello de Calidad, Support EAM

Esta metodología UWEM es la utilizada por la certificación Euracert.

A nivel europeo había ya varias metodologías de evaluación previas a la UWEM: AccessiWeb ([ACCESSIWEB]), Drempelvrij.nl ([DREMPELVRIJ]) o en España MEWA ([MEWA, Metodología Web Accesible MEWA]). MEWA era la metodología de Technosite (o Fundosa Teleservicios, empresa perteneciente a la Fundación ONCE, de la que depende el portal Discapnet), que ofrecía servicios de consultoría, auditoría y certificación de accesibilidad con el sello:

 

Gracias al trabajo sobre armonización hecho a nivel europeo por organizaciones especializadas en accesibilidad Web y con el respaldo de la Comisión Europea, actualmente existen recursos sobre accesibilidad Web considerados como referencias:

• recomendaciones internacionales: WCAG 1.0 de WAI,
• una metodología de evaluación (UWEM): la versión 1.0 de la UWEM ofrece una interpretación de las WCAG 1.0 de WAI (prioridades 1 y 2),
• un esquema de evaluación de la conformidad: el Acuerdo Adoptado en el workshop CEN es un documento que describe las "Especificaciones para un esquema sobre evaluación de la conformidad y una marca de calidad sobre accesibilidad Web". 3 esquemas sobre evaluación de conformidad son presentados:
  
  
  • Inspección por terceras partes,
  • Certificación por terceras partes,
  • Autodeclaración.

[En Euracert]

A comienzos del año 2007, ONA (Bélgica), Technosite (España) y la Asociación BrailleNet (Francia), que como dijimos tenían metodologías propias de evaluación, lanzan la etiqueta Euracert, la primera etiqueta de certificación de accesibilidad de sitios web a nivel europeo, diseñada sobre las bases de estas referencias con objeto de permitir el reconocimiento de sitios web etiquetados en otros países. Define un marco general que permite un reconocimiento mutuo entre organizaciones que trabajan sobre las pautas y recomendaciones internacionales. Para ser una organización Euracert autorizada es necesario:

1. publicación en línea de la metodología UWEM y la tabla de correspondencia entre su metodología y las UWE en su idioma nacional.
2. firma de una Carta de entendimiento con un Socio de Euracert (consultar la página Listado de Socios) en las bases de la UWEM y el Acuerdo Adoptado en el workshop CEN.
3. dar la posibilidad a cada nuevo sitio web etiquetado de obtener la etiqueta Euracert como añadido a su etiqueta nacional.
   
   

[En Eurocert]

En este contexto Tecnosite establece una correspondencia entre su metodología MEWA y la UWEM 1.0 con la correspondiente “Tabla de correspondencia MEWA/UWEM”. Bankinter fue la primera primera entidad financiera en lograr la certificación europea de accesibilidad web 'Euracert' el 11 de abril de 2007:

Bankinter se ha convertido en la primera entidad financiera en lograr la certificación europea de accesibilidad web 'Euracert', que acredita que las páginas de Internet del Banco cuentan con los estándares más elevados de accesibilidad y cumplen en ese sentido con las pautas establecidas por las diferentes ganizaciones especializadas y con el respaldo de la Comisión Europea, lo que significa que son accesibles para el mayor número de personas, independientemente de sus limitaciones. La etiqueta Euracert cubre los dos niveles contemplados por la Comisión Europea para la metodología unificada de Evaluación de Accesibilidad Web (UWEM 1.0), niveles A y AA según pautas WCAG 1.0 W3C/WAI. [En Technosite]

Technosite certificaba finalmente de acuerdo a las WCAG 2.0:

Actualmente: certificación Ilunion - Tecnología y accesibilidad

En 2014 se unifica toda la actividad del grupo baja la misma marca: Ilunion.

Actualmente, la certificación es realizada por Ilunion - Tecnología y accesibilidad, anteriormente Tecnosite, del grupo Fundosa, dependiente de Fundación ONCE.

Se puede consultar las certificaciones ISO que tiene la división de Tecnología y Accesibilidad en "Excelencia y sistemas de gestión" (Ilunion).

Ofrece servicios de desarrollo y de certificación. Los consultores de accesibilidad son personas con discapacidad y las revisiones de accesibilidad se realizan en equipo, participando en las evaluaciones personas con diferentes discapacidades.

El sello que se incluye actualmente es:

Un ejemplo de su certificación es la de Iberdrola. Otras empresas certificadas son Alcampo, Mercadona, AXA, Bankinter, etc. Se puede ver todo el listado en "Entidades certificadas" (Ilunion)

La duración de la certificación es de 2 años, con auditorias semestrales.

2.3 Comparativa certificación Ilunion - AENOR

Ilunion	AENOR
Duración 2 años	Duración 3 años
AA WCAG 2.0 / UNE 139803:2012	AA WCAG 2.0 / UNE 139803:2012
Auditorías semestrales	Auditorías semestrales
En el equipo de consultores participan personas con diferentes discapacidades.	Se audita el sistema de gestión de la accesibilidad (se puede hacer integrada con la auditoría ISO 9001)
En el texto sobre la certificación incluido en la web certificada se observan excepciones: determinados apartados, determinados contenidos (PDF, vídeos), etc.
Ayto. Valencia, Junta de Castilla y León, Endesa, Iberdrola, Metro Madrid, Bankinter ... (ver todas)	Ayto. Madrid, Ayto. Zaragoza, Ayto. Bilbao, Diputación de Vizcaya, Cabildo de Tenerife… (ver todas)

3. Metodologías de revisión de la accesibilidad web

3.1 Metodología de Revisión de la Accesibilidad de la WAI

"Evaluating Web Sites for Accessibility" es una suite de documentos de la WAI.

Hasta la WCAG-EM, constituía la metodología a seguir para evaluar la accesibilidad de un sitio Web y asegurar la calidad de los procedimientos.

A grandes rasgos, consistía en:

• validación automática de la accesibilidad
• validar la sintaxis del lenguaje de marcas
• validar la CSS
• utilizar diferentes navegadores gráficos y versiones, con distintas configuraciones (sin ratón, sin script, sin CSS, sin marcos, sin gráficos, etc.)
• utilizar otros tipos de navegadores solo-texto (Lynx), lector de pantalla (Jaws), un navegador con conversión texto-voz, una pantalla pequeña, etc.
• revisar la gramáticas y la ortografía
• revisar la claridad, simplicidad y legibilidad del contenido
• revisión por usuarios discapacitados noveles o expertos

Más información en "Metodología para la evaluación de la accesibilidad Web: "Evaluating Web Sites for Accessibility" de la WAI"

 

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

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

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.

Lo trato con detalle en el artículo Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM)

3.3 Metodología para la inclusión de la accesibilidad en todas las fases de desarrollo de un sito web

El Diseño Inclusivo es un marco metodológico mejorado a partir del Diseño Centrado en el Usuario (DCU) que intenta satisfacer las necesidades de un mayor rango de usuarios involucrando a usuarios con necesidades especiales (ver "Diseño Inclusivo: Marco Metodológico para el Desarrollo de Sitios Web Accesibles", Yusef Hassan Montero y Francisco J. Martín Fernández, 2003)

El Diseño Inclusivo tiene por tanto como objetivo garantizar la accesibilidad siguiendo las pautas y técnicas reconocidas para asegurar la accesibilidad (como la WCAG) para una amplia gama de audiencias sin necesidad de una adaptación especial (que no sea un producto de apoyo).

El proceso de Diseño Inclusivo sigue las mismas fases reiterativas que el DCU, esto es, un continuo Diseño-Prototipado-Evaluación (ver Reseña "Just Ask: Integrating Accessibility Throughout Design", reseña en español del libro recomendado como guía de referencia por la WAI)

Un estándar básico en este sentido en la norma BS 8878:2010 Web Accessibility. Code of Practice" del Reino Unido, que estandariza un proceso:

• para la creación e inclusión de una política de accesibilidad web dentro de la estrategia de cualquier organización;
• para la consideración de la accesibilidad web a lo largo de todo el ciclo de vida de cualquier producto web.

La trato en detalle en el artículo: BS 8878:2010. Proceso para integrar la accesibilidad en todo el ciclo de vida de un producto web

Una metodología de Diseño Inclusivo sólida es AWA (Accessibility for Web Applications) que explico en detalle en el artículo Accesibilidad integrada en todas las fases de desarrollo de una aplicación Web: marco metodológico AWA

3.4 Futura metodología europea de monitorización de la accesibilidad web

La Directiva (UE) 2016/2102 del Parlamento Europeo y del Consejo, de 26 de octubre de 2016, sobre la accesibilidad de los sitios web y aplicaciones para dispositivos móviles de los organismos del sector público, especifica en el artículo 8 que los estados comprobarán periódicamente la conformidad de los sitios web y las aplicaciones para dispositivos móviles de los organismos del sector público.

Esto se realizará mediante una metodología transparente, transferible, comparable, reproducible y fácil de usar. La directiva estipula que la Comisión establecerá esta metodología para el seguimiento de la conformidad antes del 23 de diciembre de 2018.

Esta metodología podrá tener en cuenta un análisis pericial e incluirá:

• la periodicidad del seguimiento y el muestreo de los sitios web y aplicaciones para dispositivos móviles que vayan a ser objeto de seguimiento;
• a nivel de cada sitio web, el muestreo de páginas web y del contenido de dichas páginas;
• a nivel de cada aplicación para dispositivos móviles, el contenido que se ha de examinar, teniendo en cuenta el momento de la distribución inicial de la aplicación y de las actualizaciones posteriores de sus funcionalidades;
• una descripción de la manera en que debe demostrarse suficientemente la conformidad o no conformidad con los requisitos de accesibilidad establecidos [...];
• en caso de detectarse deficiencias, un mecanismo para proporcionar datos e información sobre la conformidad con los requisitos de accesibilidad establecidos en el artículo 4, en un formato que pueda ser usado por los organismos del sector público para corregir esas deficiencias, y
• unas disposiciones adecuadas, incluyendo en caso necesario ejemplos y directrices, para las pruebas automáticas, manuales y de capacidad de utilización, en combinación con los parámetros relativos a los muestreos, de una manera que sea compatible con la periodicidad del seguimiento y de la presentación de informes.

A partir del 23 de diciembre de 2021 los estados presentarán sus informes cada tres años (se enumera también el contenido de dicho informe).

Poco después de aprobarse la normativa se publicó en la web de la Comisión Europea el estudio "Monitoring methodologies for web accessibility in the European Union", 21/10/2016 (PDF), que es el primer paso para establecer la metodología de monitorización de la accesibilidad de los sitios web y apps del sector público.

El estudio analiza la situación de la monitorización de la accesibilidad de sitios web en Europa (incluye la de España, con el Observatorio de Accesibilidad Web) y ofrece recomendaciones sobre cómo hacer el seguimiento de la accesibilidad web de manera significativa y razonable en toda Europa.

Presenta por tanto las recomendaciones que presumiblemente se utilizarán para definir la metodología de seguimiento de la accesibilidad de los sitios web y apps del sector público y controlar así el cumplimiento de la Directiva.

Entre lo más destacable, el estudio propone que una metodología europea de monitorización de la accesibilidad web:

• debería combinar los métodos automáticos y manuales de revisión de la accesibilidad web;
• debería combinar la autodeclaración con la evaluación de expertos y la participación de los usuarios finales;
• debería basar la selección de muestra de páginas web a evaluar en las WCAG-EM (ver artículo Metodología de Evaluación de Conformidad con la Accesibilidad en sitios Web (WCAG-EM)).

Las metodologías de monitorización de la accesibilidad de aplicaciones móviles están fuera del alcance del estudio, ya que este se propuso antes de que la accesibilidad de la aplicaciones móviles se introdujera en la Directiva.

4. Otras etiquetas habituales

Hemos visto que la legislación española dice que las páginas de internet se podrán certificar por una entidad de certificación cuya competencia técnica haya sido reconocida formalmente por una entidad de acreditación, y que en España, solo la ENAC, Entidad Nacional de Acreditación, está autorizada para evaluar y declarar ese cumplimiento, y declarar una entidad de certificación acreditada.

En este apartado recojo otros sellos relacionados con la accesibilidad que se pueden ver en los sitios web y que no son de entidades de certificación acreditadas:

4.1 Símbolo internacional de la accesibilidad Web

Expresa el compromiso de esa web por intentar ser accesible para todos. Actualmente no se suele utilizar.

El tradicional Símbolo Internacional de Accesibilidad (SIA) surgió de un concurso en 1968 que ganó Susanne Koefoed y que posteriormente modificó Karl Montan. El símbolo tuvo una aceptación inmediata y, con respaldo de la Organización Internacional de Normalización (ISO) y de la ONU, se convirtió rápidamente en la forma de designar una instalación accesible.

Imagen de ciudadaccesible.cl

En 2010 Sara Hendren y Brian Glenney propusieron una modificación de la imagen tradicional, que es de uso gratuito. Fue bien acogida y su difusión fue rápida. El nuevo símbolo, incorporado oficialmente en varios estados de USA (por ejemplo en Nueva York) y adoptado también en diferentes países, es para muchos una mejor representación del símbolo de accesibilidad.

Imagen de ciudadaccesible.cl

Su debilidad es que la figura sigue representando una ayuda técnica y confundiéndose con un símbolo de “discapacidad”, cuando su finalidad es indicar “accesibilidad”.

En julio de 2015, la Unidad de Diseño Gráfico del Departamento de Información Pública de la ONU en Nueva York diseñó un nuevo símbolo de "accesibilidad", incluyendo la accesibilidad de la información, servicios, tecnologías de la comunicación, así como el acceso físico; y que ya no se asocia a "discapacidad":

Imagen de ciudadaccesible.cl

Sin embargo no ha tenido mucha difusión.

4.2 Logotipos de validación del W3C

Los logotipos oficiales del W3C se pueden ver en "Validation icons" del W3C, que incluye entre otros los de validación de sintaxis CSS o (X)HTML, por ejemplo:

En "Logos and icons" el W3C indica que los iconos se distribuyen bajo licencia, de modo que no pueden modificarse: hay que utilizar los oficiales. También se indica que deben enlazar con la validación de la página en el correspondiente revisor automático del W3C.

4.3 Logotipos de validadores automáticos de accesibilidad

Muchos validadores de accesibilidad también tienen sellos que se pueden incluir en las páginas validadas con ellos, por ejemplo TAW (Test Accesibilidad Web) o HERA:

 

Estos logos no indican un nivel de adecuación de la página respecto a una norma (como las WCAG), pues ninguna herramienta automática puede validar todos los criterios de conformidad de forma automática.

Solo indican que la revisión automática de dicha herramienta verificó determinado nivel de adecuación en base a los criterios que puede evaluar automáticamente.

4.4 Logotipos del nivel de Conformidad con las Directrices de Accesibilidad para el Contenido Web 1.0 (WCAG 1.0)

La inclusión de estos iconos es una declaración del autor de la página en la que se insertan de que ésta se ajusta al nivel correspondiente de las Directrices de Accesibilidad para el Contenido Web 1.0 del W3C.

Nivel A de Conformidad con las Directrices de Accesibilidad para el Contenido Web 1.0 (WCAG 1.0)

Nivel AA de Conformidad con las Directrices de Accesibilidad para el Contenido Web 1.0 (WCAG 1.0)

Nivel AAA de Conformidad con las Directrices de Accesibilidad para el Contenido Web 1.0 (WCAG 1.0)

Cada uno de ellos debe enlazar con la página correspondiente del W3C. El W3C no verifica las declaraciones, sino que son los proveedores de contenido los responsables únicos del uso de estos logos. Por omisión, un icono de conformidad se refiere a una única página. Si la declaración pretende aplicarse o incluir más de una página, el icono de conformidad debe ir acompañado de información explícita del alcance, explicando qué páginas cubre la declaración.

Tenga en cuenta, por favor, que el uso de este logo no depende de una revisión automática. No existe aún ninguna herramienta que pueda hacer una revisión completa de todos los puntos de verificación que hay en las directrices, y una revisión automática completa en el futuro puede seguir siendo difícil o imposible. Por ejemplo, algunos puntos de verificación se basan en una interpretación de qué información es "importante" o en si el texto equivalente para un elemento no textual es exacto. También es posible que un revisor de la accesibilidad automático presente "falsos negativos" o "falsos positivos" debido al tipo de marcado en una página. Por estas razones, los logos de esta página se usan sólo para indicar una declaración de conformidad hecha por el autor de la página, no una conformidad conseguida mediante un validador automático. [En W3C]

4.5 Logotipos del nivel de Conformidad con las Directrices de Accesibilidad para el Contenido Web 2.0 (WCAG 2.0)

Como indica el W3C en "W3C Web Content Accessibility Guidelines 2.0 Conformance Logos", para promover la accesibilidad de las páginas web se ofrece la posibilidad de incluir los iconos de adecuación a las WCAG 2.0:

Explanation of WCAG 2.0 Level A Conformance

Explanation of WCAG 2.0 Level AA Conformance

Explanation of WCAG 2.0 Level AAA Conformance

Se indica que no se deben modificar los logotipos. Por defecto, un icono de conformidad se refiere a una sola página, de lo contrario el icono de conformidad deberá ir acompañado de la información explícita de cuáles son las páginas a las que se refiere.

Más información en: WCAG 2.0 Niveles y declaraciones de conformidad WCAG 2.0

 

4.6 Sello GESAccesibilidad

GESAccesibilidad surge como resultado del proyecto Sistema de gestión de la accesibilidad web (TSI-020100-2008-355 y TSI-020100-2009-316).

Fue un proyecto de desarrollo experimental financiado por el Ministerio de Industria, Turismo y Comercio dentro del Subprograma Avanza I+D en 2008 y 2009, liderado por Taller Digital de la Universidad de Alicante en colaboración con la Fundación Biblioteca Virtual Miguel de Cervantes.

El sello lo tiene, por ejemplo, la web del Síndic de Greuges de la Comunitat Valenciana.

4.7 Sello Universal Accesskey

Lo otorga accesskey.org Lo tenía por ejemplo footyboots4kids.com

4.8 Sello MobileOk del W3C

El objetivo de las Mobile Web Best Practices 1.0 (recomendación desde julio de 2008) es servir de pautas para mejorar la experiencia de usuario en la navegación web a través de dispositivos móviles.

El W3C mobileOK Basic Test es el esquema para evaluar la conformidad de un sitio web de acuerdo con las Mobile Web Best Practices. Es utilizado por el validador automático online del W3C W3C mobileOK Checker. Como en todo validador automático, sólo se evalúan aquellos puntos que pueden verificarse de forma automática, los demás deberán ser verificados de forma manual.

La nota de agosto de 2009 W3C mobileOK Scheme 1.0 señala que los proveedores pueden identificar sus páginas como mobileOK, es decir, que pasan el validador automático y por tanto las pruebas básicas en él implementadas. En ese caso pueden añadir el icono:

Consultar "W3C mobileOK Logo and Policy"

Más información sobre las MWBP y su relación con las WCAG en: Accesibilidad y usabilidad móvil: web móvil y app nativa

4.9 Protocolo NI4 Navegación Fácil

Se podía encontrar este logotipo por ejemplo en el apartado de accesibilidad de la Seguridad Social.

El Protocolo NI4 está basado en un proceso de investigación que se llevó a cabo conjuntamente entre el Instituto de Apoyo Empresarial (I.A.E.) y AFANIAS, que lo presentaron en febrero de 2013.

Recoge las Pautas de Diseño de Navegación Fácil que pretenden aportar soluciones a los problemas específicos de las personas con discapacidad intelectual. Puedes consultarlo en la web: www.ni4.org

4.10 RNIB Surf Right

Es el sello que otorga el RNIB (Royal National Institute for the Blind, de Reino Unido) en la auditoría de accesibilidad de los sitios web de acuerdo a las WCAG 2.0. Más información en la web de RNIB

4.11 Sello Bequal

Fundado en el año 2012 por Fundación Once; CERMI; Fundación Seeliger y Conde; y FEACEM. Distingue a las compañías socialmente responsables con la discapacidad.

El modelo está estructurado en 7 categorías (Estrategia y Liderazgo, Gestión de RRHH, Accesibilidad, Compra responsable, Clientes, Acción social, Comunicación), 19 indicadores y 69 fuentes de verificación. Tiene tres niveles (Bequal, Bequal Plus y Bequal Premium) y una vigencia de tres años con revisiones anuales.

Uno de los criterios excluyentes es el incumplimiento de la Ley de Medidas de Impulso de la Sociedad de la Información. Para ello se comprueba que las empresas que estén obligadas por ley dispongan de páginas web accesibles.

Web Bequal.

4.12 Sello DIGA

La otorga la Fundación Shangri-La, que también tiene el sello DIGA para la accesibilidad física de los establecimientos.

Es un sello muy poco extendido.

Web DIGA.

4.13 Sello de Calidad de Internet IQ

iQUA (Agencia de Calidad de Internet) , es una entidad de ámbito estatal sin ánimo de lucro creada en 2002.

El sello de calidad IQ consiste en un logotipo que se inserta en las páginas web y que acredita que éstas cumplen con los estándares de calidad requeridos por IQUA.

IQUA otorga el sello de calidad basándose en el código de conducta de la Agencia, previa auditoría de la página web para comprobar si cumple con todos los estándares de calidad (criterios que se emplean en las auditorías para la obtención del sello de calidad IQ).

IQUA se reserva el derecho a realizar auditorías aleatorias de las páginas web a las que se haya otorgado el sello IQ, para comprobar si siguen cumpliendo con los niveles de calidad exigidos.

Asimismo, los usuarios de Internet podrán denunciar ante IQUA las presuntas no-conformidades que detecten en páginas que tengan el sello de calidad IQ. En ambos casos, cuando se detecte que la página web no mantiene la calidad exigida, se concederá un plazo para subsanar las no-conformidades. Si éstas persisten, IQUA invalidará el sello de calidad.

Antiguamente era muy habitual verlo, e incluía aspectos legales, de seguridad, de usabilidad y de accesibilidad.

Actualmente ya no suele verse, y ya no incluye aspectos de accesibilidad, sino que actualmente los indicadores que manejan son: legales, de calidad, de seguridad y se protección a menores.