UT5 — Diseño de webs accesibles¶

Índice¶

1. El Consorcio World Wide Web (W3C)
2. Principios y Pautas de Accesibilidad al Contenido en la Web (WCAG)
3. Criterios de conformidad. Niveles de conformidad
4. Técnicas para satisfacer los requisitos definidos en las WCAG
5. Prioridades. Puntos de verificación
6. Métodos para realizar revisiones preliminares y evaluaciones de adecuación o conformidad de documentos web
7. Herramientas de análisis de accesibilidad web
8. Chequeo de la accesibilidad web desde diferentes navegadores y dispositivos
9. Posicionamiento en buscadores. Mejora de la visibilidad de un sitio web en diferentes buscadores
10. Glosario rápido
11. Repaso: preguntas para autoevaluarte
12. De dónde sale esto (fuentes de la carpeta)
13. Avisos

De qué va esta unidad¶

Imagina que entras en la web de tu banco y no puedes leer los textos porque el contraste de color es horrible. O que quieres reservar mesa en un restaurante desde el móvil, pero el formulario no funciona con el lector de pantalla que usas porque eres ciego. O, simplemente, que se te ha roto el brazo derecho y durante seis semanas tienes que navegar la Web solo con el teclado y la mano izquierda. En los tres casos el problema no es tuyo: es de quien diseñó la interfaz sin pensar que la Web la usa gente muy diversa.

Esta unidad trata de eso: de diseñar interfaces web que funcionen para el mayor número posible de personas, tengan o no una discapacidad, usen el navegador que usen y accedan desde el dispositivo que accedan. Vamos a conocer al organismo que pone las reglas del juego (el W3C), las pautas técnicas que ha escrito para que el contenido web sea accesible (las WCAG), cómo se mide si una página las cumple (criterios y niveles de conformidad), qué herramientas existen para comprobarlo y, para cerrar el círculo, cómo hacer que un sitio accesible y bien construido también se posicione bien en los buscadores. Al fin y al cabo, una web a la que nadie llega tampoco sirve de mucho.

Como en el resto del módulo, usaremos como hilo conductor la web ficticia del Café Central, el cliente que venís auditando y mejorando en las prácticas: en esta unidad le toca pasar una auditoría de accesibilidad y de visibilidad en buscadores.

En DAW, la accesibilidad no es un "extra" de última hora: es una competencia profesional que se te va a pedir en cualquier empresa seria, y cada vez más una obligación legal (lo veremos con ejemplos actuales a lo largo del tema). Saber aplicar WCAG con soltura te distingue de quien solo sabe maquetar bonito.

Qué deberías saber hacer al terminar (resultados de aprendizaje)¶

El resultado de aprendizaje de esta unidad (RA5) dice que al terminar desarrollas interfaces web accesibles, analizando las pautas establecidas y aplicando técnicas de verificación. Traducido a cosas concretas, al final de la UT5 deberías ser capaz de:

• Explicar por qué diseñar de forma accesible es necesario, no opcional.
• Analizar si un documento web es accesible o no, y detectar barreras concretas.
• Reconocer los principios y las pautas de accesibilidad (WCAG) y sus niveles de conformidad (A, AA, AAA).
• Identificar errores de accesibilidad relacionándolos con su prioridad o criterio.
• Llevar una página hasta el nivel de conformidad que se te pida.
• Verificar ese nivel con herramientas externas (automáticas y manuales).
• Comprobar que la interfaz se ve y funciona bien en distintos navegadores y tecnologías de asistencia.
• Usar herramientas y estrategias de SEO que mejoren la visibilidad del sitio en los buscadores.

1. El Consorcio World Wide Web (W3C)¶

El W3C (World Wide Web Consortium) es la comunidad internacional que desarrolla los estándares que permiten que la Web siga creciendo de forma ordenada. Se fundó en 1994 y su misión es desarrollar tecnologías interoperables —especificaciones, pautas, software y herramientas— para que la Web alcance su máximo potencial. Lo forman empresas y organismos de todo el mundo (entre ellos, ayuntamientos y universidades españolas), con personal a tiempo completo y una enorme cantidad de gente colaborando de forma voluntaria.

Uno de sus directores es Tim Berners-Lee, el inventor de la propia World Wide Web en 1989 y fundador, en 2009, de la World Wide Web Foundation, encargada de financiar y coordinar esfuerzos para que la Web beneficie a la humanidad. Suya es la frase que abre buena parte de la documentación de accesibilidad del W3C:

"El poder de la Web está en su universalidad. El acceso de todos, independientemente de la discapacidad, es un aspecto esencial." — Tim Berners-Lee

Dentro del W3C existe la WAI (Web Accessibility Initiative, Iniciativa para la Accesibilidad Web), que es quien desarrolla las estrategias, pautas y recursos que vamos a ver en esta unidad. Las pautas de la WAI se consideran estándares internacionales de accesibilidad web; de hecho, las WCAG 2.0 son también norma ISO/IEC 40500, lo que les da un peso legal y técnico añadido en muchos países.

El W3C no solo se ocupa de accesibilidad: también publica (o publicó en su momento) estándares como HTML o CSS. El material de referencia de esta unidad, por ejemplo, cita como ejemplo de esa labor normativa HTML 4.01 (1999), XHTML 1.0 (2002) o CSS2 (2008), y menciona que en su momento CSS 2.1 y los primeros módulos de CSS3 (color, fondos y bordes) estaban todavía en fase de borrador. Son ejemplos ya superados —hoy trabajamos con HTML5 y con los módulos de CSS3 ya consolidados—, pero sirven para entender algo importante: el W3C no impone sus estándares de golpe, los va publicando, revisando y sustituyendo mediante un proceso de consenso internacional, y eso es exactamente lo que ha pasado también con las WCAG, como veremos a continuación.

Figura: fotograma del vídeo "Introducción a la Accesibilidad Web y Estándares W3C" de la Web Accessibility Initiative (WAI). Origen: WEB - W3C WAI - Introducción a la accesibilidad web.pdf.

Ejemplo actual — la accesibilidad ya es ley en buena parte de Europa. Desde el 28 de junio de 2025 es aplicable en la Unión Europea la Directiva sobre requisitos de accesibilidad de productos y servicios (conocida como European Accessibility Act), que obliga a comercio electrónico, banca, transporte de viajeros y otros muchos servicios digitales a cumplir requisitos de accesibilidad. Según se ha informado en medios especializados en desarrollo web, muchas empresas europeas han tenido que revisar a fondo sus interfaces durante 2024-2025 para adaptarse a tiempo.

En las noticias — apps de la Administración. En los últimos años se ha hablado repetidamente de que webs y apps de ayuntamientos y organismos públicos suspenden auditorías de accesibilidad (menús sin foco de teclado visible, contrastes insuficientes, formularios sin etiquetas). Es un recordatorio de que ni siquiera las administraciones —obligadas por ley a cumplir WCAG— lo consiguen siempre a la primera.

Ideas clave de esta sección¶

• El W3C es el organismo internacional que estandariza las tecnologías de la Web.
• La WAI es la parte del W3C dedicada específicamente a la accesibilidad.
• Las pautas de la WAI (WCAG) son estándares internacionales; WCAG 2.0 es además norma ISO/IEC 40500.

2. Principios y Pautas de Accesibilidad al Contenido en la Web (WCAG)¶

Las WCAG (Web Content Accessibility Guidelines, Pautas de Accesibilidad para el Contenido Web) son el documento técnico del W3C que explica cómo hacer que el contenido web sea más accesible para personas con discapacidad. Por "contenido" se entiende tanto la información en sí (textos, imágenes, sonidos) como el código o marcado que define su estructura y presentación.

Ojo con las versiones, porque aquí es fácil liarse: las WCAG han tenido varias versiones y todas siguen vigentes a la vez.

• WCAG 1.0 se publicó como Recomendación del W3C en mayo de 1999. Organizaba sus reglas en "puntos de verificación" con distinta prioridad (lo vemos en el punto 5).
• WCAG 2.0 se publicó el 11 de diciembre de 2008 y sustituyó a la 1.0 como referencia principal. Tiene 12 pautas.
• WCAG 2.1 se publicó el 5 de junio de 2018 (con actualizaciones posteriores en 2023, 2024 y 2025). Añade una pauta nueva y 17 criterios de conformidad nuevos, y pasa a tener 13 pautas.
• WCAG 2.2, la versión vigente y recomendada hoy, se publicó el 5 de octubre de 2023 y se actualizó el 12 de diciembre de 2024. Mantiene las 13 pautas y añade 9 criterios de conformidad nuevos.

Las tres versiones (2.0, 2.1 y 2.2) están diseñadas para ser compatibles hacia atrás: si tu web cumple WCAG 2.2, automáticamente cumple también WCAG 2.1 y WCAG 2.0 (con una única excepción: el criterio 4.1.1 "Interpretación" —también citado como "validación del código"—, sobre el buen formato del marcado, ha quedado obsoleto en la 2.2). Por eso el W3C recomienda trabajar directamente con la versión más reciente, WCAG 2.2, en vez de mirar hacia atrás a la 2.0.

Los cuatro principios (POUR)¶

Toda la estructura de las WCAG se apoya en cuatro principios, conocidos por sus siglas en inglés como POUR: los contenidos web deben ser Perceptibles, Operables, U — comprensibles (Understandable) y Robustos.

1. Perceptible. Los componentes de la interfaz deben poder percibirse: la información no puede ser invisible para ninguno de los sentidos del usuario (por ejemplo, una imagen necesita un texto alternativo para quien no puede verla).
2. Operable. La interfaz no puede exigir una interacción que a alguien le sea imposible de realizar (por ejemplo, todo debe poder manejarse también con el teclado, no solo con el ratón).
3. Comprensible. Tanto la información como el funcionamiento de la interfaz deben entenderse (lenguaje claro, comportamiento predecible, ayuda ante errores).
4. Robusto. El contenido debe poder ser interpretado de forma fiable por una amplia variedad de "agentes de usuario" —navegadores, lectores de pantalla, futuras tecnologías— incluidas las ayudas técnicas.

Si falla alguno de los cuatro, alguien se queda fuera. Por eso las pautas y los criterios de éxito de las WCAG se agrupan siempre bajo uno de estos cuatro principios.

Figura: los cuatro principios POUR tal como los presenta el material de la unidad. Origen: DIW02.pdf.

Las pautas, agrupadas por principio¶

Bajo cada principio hay varias pautas (guías generales, no verificables por sí mismas) y, dentro de cada pauta, criterios de éxito concretos que sí se pueden comprobar. La siguiente tabla recoge las 12 pautas originales de WCAG 2.0 (siguen vigentes en la 2.2); WCAG 2.1 añadió una pauta más, 2.5 Modalidades de entrada, dedicada a que la funcionalidad se pueda usar con formas de entrada más allá del teclado (pantallas táctiles, voz, puntero), con lo que WCAG 2.1 y 2.2 llegan a las 13 pautas mencionadas antes.

En WCAG 2.2 no se añaden pautas nuevas respecto a 2.1, pero sí 9 criterios de éxito nuevos, casi todos pensados para colectivos muy concretos: personas que usan solo teclado, personas con temblores en las manos o personas con discapacidad cognitiva. Los vemos con detalle en el punto 3, porque están directamente ligados a los niveles de conformidad.

<!-- Ejemplo propio: alternativa textual (pauta 1.1) -->
<img src="cafe-central-terraza.jpg"
     alt="Terraza del Café Central con mesas de madera junto al ventanal">

<!-- Imagen puramente decorativa: alt vacío, no "decorativo" ni descripciones inútiles -->
<img src="separador-linea.png" alt="">

Ejemplo actual — Netflix y los subtítulos. La pauta 1.2 (alternativas para contenido multimedia) es la razón técnica por la que servicios como Netflix, YouTube o los canales de RTVE ofrecen subtítulos y, en catálogos crecientes, audiodescripción: no es un capricho, responde a un criterio WCAG muy concreto sobre "medios sincronizados".

En las noticias — rediseños que rompen el contraste. Es habitual que, tras un rediseño de marca, alguna empresa reciba críticas en redes sociales porque el nuevo tono corporativo (grises muy claros, pasteles) deja el texto casi ilegible sobre el fondo. Suele solucionarse ajustando el contraste sin tocar apenas el resto del diseño, prueba de que cumplir Perceptible no está reñido con tener una imagen de marca cuidada.

Ideas clave de esta sección¶

• WCAG 2.0, 2.1 y 2.2 conviven; 2.2 (octubre de 2023, actualizada en 2024) es la versión de referencia actual y es compatible con las anteriores salvo el criterio 4.1.1.
• Todo se organiza en 4 principios (POUR) → pautas → criterios de éxito verificables.
• WCAG 2.2 tiene 13 pautas; WCAG 2.1 añadió la pauta "Modalidades de entrada" respecto a las 12 de WCAG 2.0.

3. Criterios de conformidad. Niveles de conformidad¶

Cada pauta se concreta en uno o varios criterios de éxito: una afirmación comprobable, que puede ser verdadera o falsa al aplicarla a un contenido web concreto ("todas las imágenes informativas tienen texto alternativo": sí o no). Estos criterios son los que de verdad se auditan; las pautas son solo el paraguas que les da sentido.

Para ordenar las exigencias según su importancia, las WCAG definen tres niveles de conformidad:

• Nivel A (el más bajo). La página satisface todos los criterios de éxito de nivel A, o proporciona una versión alternativa que sí los cumple. Son los requisitos mínimos: sin ellos, ciertos grupos de usuarios directamente no pueden usar la página.
• Nivel AA. Satisface todos los criterios de nivel A y AA. Es el nivel que exige la mayoría de normativas y contrataciones públicas, porque ofrece un equilibrio razonable entre accesibilidad y esfuerzo de desarrollo.
• Nivel AAA (el más alto). Satisface todos los criterios de nivel A, AA y AAA. El propio W3C reconoce que no siempre es posible ni razonable alcanzar el AAA para un sitio entero; a veces conviene aplicarlo solo a partes muy concretas del contenido.

Lograr un nivel superior implica siempre haber alcanzado los niveles anteriores: no se puede ser "AAA" sin cumplir antes A y AA.

Figura: logotipos que el W3C pone a disposición de quienes diseñan webs para indicar el nivel de conformidad alcanzado. Origen: DIW02.pdf.

Los 9 criterios nuevos de WCAG 2.2, con su nivel¶

Como decíamos en el punto anterior, WCAG 2.2 suma 9 criterios de éxito repartidos entre tres pautas ya existentes. Son un buen ejemplo de cómo las WCAG evolucionan siguiendo problemas reales detectados por personas usuarias:

Fíjate en el criterio 2.5.8: exigir que un botón mida al menos 24×24 píxeles CSS no es un capricho estético, es directamente aplicable al típico botón "❤" o "×" diminuto que tanto cuesta pulsar en el móvil con el pulgar o con manos con temblor.

Ejemplo actual — gestores de contraseñas y 3.3.8. El criterio "Autenticación accesible" es, en la práctica, el motivo técnico por el que cada vez más servicios permiten iniciar sesión con enlace mágico por correo, con la app del banco o dejando que el gestor de contraseñas del navegador rellene el campo automáticamente, en lugar de forzar a memorizar y teclear una contraseña compleja.

En las noticias — captchas de "elige todas las imágenes con semáforos". Los captchas visuales llevan tiempo en el punto de mira de la accesibilidad porque dependen de reconocer objetos, algo que WCAG 2.2 (criterio 3.3.9) señala explícitamente como barrera para personas con ciertas discapacidades cognitivas o visuales. Es habitual ver debates en la comunidad de desarrollo web sobre alternativas como reCAPTCHA v3 (invisible) o los retos basados en proof-of-work.

Ideas clave de esta sección¶

• Un criterio de éxito es una afirmación comprobable (verdadero/falso).
• Hay tres niveles acumulativos: A ⊂ AA ⊂ AAA.
• WCAG 2.2 aporta 9 criterios nuevos, sobre todo en AA, pensados para foco de teclado, arrastre, tamaño de objetivos, ayuda constante, no repetir datos y autenticación accesible.

4. Técnicas para satisfacer los requisitos definidos en las WCAG¶

Los criterios de éxito dicen qué hay que conseguir, pero no cómo. Para eso existen las técnicas: el grupo de trabajo de las WCAG documenta y mantiene actualizada una lista de más de 375 técnicas concretas (y sigue creciendo), asociadas cada una a la tecnología con la que se implementan (HTML, CSS, ARIA, JavaScript, PDF...) y al criterio de éxito al que dan respuesta.

Es importante entender que las técnicas son informativas, no normativas. Es decir: no son obligatorias en sí mismas, lo obligatorio es el criterio de éxito. Se agrupan en dos categorías:

• Técnicas suficientes. Formas documentadas de cumplir un criterio de éxito concreto. La mayoría de criterios tienen asociada una lista de técnicas suficientes: si aplicas una de ellas correctamente, se considera que el criterio queda satisfecho.
• Técnicas de asesoramiento (recomendables). Van más allá del mínimo exigido por cada criterio individual, y ayudan a mejorar la accesibilidad en general, pero no cuentan como "suficientes" porque no son siempre comprobables, o funcionan bien en unos contextos y en otros no.

Los documentos del W3C permiten filtrar las técnicas por tecnología, nivel de conformidad y categoría, lo cual es muy práctico cuando estás desarrollando: puedes consultar, por ejemplo, solo las técnicas suficientes en HTML para nivel A.

<!-- Ejemplo propio de "técnica suficiente" para el criterio 3.1.1 (idioma de la página) -->
<html lang="es">
  ...
</html>

<!-- Ejemplo propio de técnica suficiente para 4.1.2 (nombre, función, valor)
     en un botón personalizado con ARIA -->
<div role="button" tabindex="0" aria-pressed="false">
  Reservar mesa
</div>

Ejemplo actual — el "Café Central" y sus botones personalizados. Si en la web del Café Central el equipo decide construir un botón de "reservar mesa" con un <div> en lugar de un <button> nativo (algo muy habitual cuando se quiere un diseño muy concreto), la técnica suficiente para seguir cumpliendo 4.1.2 pasa por añadir los atributos ARIA (role, tabindex, aria-pressed...) que le devuelvan al elemento el comportamiento accesible que un <button> normal ya trae de fábrica.

Ideas clave de esta sección¶

• Los criterios de éxito son el "qué"; las técnicas son el "cómo", y son informativas, no normativas.
• Hay más de 375 técnicas, organizadas por tecnología, nivel y categoría.
• Se dividen en técnicas suficientes (para cumplir el criterio) y de asesoramiento (para ir más allá).

5. Prioridades. Puntos de verificación¶

Este contenido tiene truco: los PDF de la unidad apenas lo tratan. El material de referencia (DIW02.pdf) menciona que existieron las WCAG 1.0 (Recomendación del W3C de mayo de 1999) y que las WCAG 2.0 las sustituyen, pero no llega a detallar cómo funcionaba su sistema de prioridades y puntos de verificación. Como es un concepto histórico necesario para entender de dónde vienen los niveles A/AA/AAA actuales, lo resumimos aquí con el conocimiento general sobre WCAG 1.0 —queda marcado como información de contexto, no como dato verificado en los PDF de esta UT— y te remitimos al aviso final de este documento.

Las WCAG 1.0 no hablaban de "criterios de éxito" ni de niveles A/AA/AAA como hoy: sus reglas se llamaban puntos de verificación (checkpoints), y cada uno tenía asignada una prioridad del 1 al 3, según cuánto afectaba a que la página fuera usable por personas con discapacidad:

• Prioridad 1: puntos de verificación que un desarrollador debe cumplir sí o sí, porque si no algunos grupos de usuarios se quedan directamente sin poder acceder al contenido.
• Prioridad 2: puntos que debería cumplir, porque su ausencia dificulta mucho el acceso (aunque no lo impide del todo).
• Prioridad 3: puntos que podría cumplir, para mejorar aún más el acceso.

De ahí salió, precisamente, el esquema de niveles que usamos hoy: cumplir todos los puntos de Prioridad 1 daba conformidad de nivel A (Simple-A); cumplir Prioridad 1 y 2 daba nivel AA (Doble-A); y cumplir las tres prioridades daba nivel AAA (Triple-A). Cuando el W3C publicó WCAG 2.0 en 2008 mantuvo esta misma nomenclatura de niveles A/AA/AAA por continuidad, pero cambió el fondo: en vez de una lista fija de puntos de verificación por prioridad, pasó al modelo actual de criterios de éxito verificables organizados en 4 principios que hemos visto en los puntos 2 y 3. Es decir: el "envoltorio" (A/AA/AAA) se ha mantenido durante 25 años, pero el contenido técnico de detrás se ha renovado por completo.

Ejemplo actual — por qué ya no se habla de "prioridades". Si buscas hoy documentación de accesibilidad y encuentras una página que todavía habla de "checkpoints de prioridad 1, 2 y 3", es una señal casi segura de que es material desactualizado, escrito pensando en WCAG 1.0 (de 1999) y no en las WCAG 2.x vigentes. Es un error frecuente en apuntes y cursos antiguos de accesibilidad que conviene saber detectar.

Ideas clave de esta sección¶

• WCAG 1.0 (1999) organizaba sus reglas en puntos de verificación con prioridad 1, 2 o 3.
• De esas prioridades nació la idea de niveles A / AA / AAA que hoy seguimos usando, aunque desde WCAG 2.0 (2008) el contenido técnico es otro: criterios de éxito bajo los 4 principios POUR.
• Los PDF de esta UT no detallan este modelo histórico con profundidad: lo que tienes aquí es contexto general, no un dato extraído literalmente de ellos.

6. Métodos para realizar revisiones preliminares y evaluaciones de adecuación o conformidad de documentos web¶

Auditar la accesibilidad de una web se puede abordar en dos niveles: una revisión preliminar rápida, que cualquiera puede hacer en pocos minutos para detectarnos barreras evidentes, y una evaluación completa de conformidad, mucho más exigente, necesaria si vas a declarar formalmente que tu sitio cumple un nivel WCAG determinado.

Revisión preliminar: comprobaciones sencillas¶

El propio W3C WAI publica una guía de comprobaciones sencillas ("Easy Checks") para hacer una primera revisión de accesibilidad sin necesidad de ser expertos. No son concluyentes —una página puede "aprobar" estas comprobaciones y aun así tener barreras importantes—, pero permiten detectar problemas típicos en poco tiempo. Entre las comprobaciones que propone están:

• Título de página: que exista, describa el contenido y sea distinto en cada página del sitio (se usa en la pestaña del navegador, en marcadores y es lo primero que lee un lector de pantalla al entrar en la página).
• Texto alternativo de imágenes: que toda imagen informativa tenga alt, y que las puramente decorativas lleven alt="".
• Encabezados: que existan, que sigan una jerarquía lógica (h1 → h2 → h3...) y que se pueda navegar por ellos.
• Contraste de color: mínimo de 4,5:1 entre texto y fondo para texto de tamaño normal (coincide con el criterio 1.4.3 de las WCAG).
• Redimensionado del texto: que la página siga siendo usable al aumentar el tamaño del texto, sin que se corte contenido ni se superpongan bloques.
• Acceso por teclado y foco visible: que se pueda llegar con la tecla Tab a todos los elementos interactivos, que el foco se vea claramente y que nunca quede "atrapado" en un componente (la famosa "trampa de teclado").
• Formularios, etiquetas y errores: que cada campo tenga una etiqueta asociada (<label for="...">), que los campos obligatorios se marquen sin depender solo del color, y que los errores se expliquen con claridad.
• Contenido en movimiento, parpadeante o intermitente: que pueda pausarse, detenerse u ocultarse si dura más de cinco segundos, y que nada parpadee más de tres veces por segundo (riesgo de crisis epilépticas).
• Alternativas a contenido multimedia: subtítulos y transcripciones en audio y vídeo.
• Comprobación básica de estructura: ver la página sin imágenes ni CSS y comprobar que la información sigue teniendo sentido en el orden en que se lee (así es, aproximadamente, como "ve" la página un lector de pantalla).

Figura: ilustración de la guía de comprobaciones sencillas del W3C WAI para hacer una primera revisión de accesibilidad. Origen: WEB - W3C WAI - Comprobaciones sencillas.pdf.

Evaluación de conformidad y declaración de conformidad¶

Cuando lo que se necesita es poder declarar formalmente que una web cumple las WCAG (por ejemplo, para optar a una subvención o cumplir un contrato), no basta con una revisión rápida: hay que comprobar de forma sistemática cada criterio de éxito aplicable. Según el material de la unidad, hacer una declaración de conformidad con las WCAG 2.0 exige cumplir cinco condiciones:

1. Nivel de conformidad: satisfacer por completo uno de los tres niveles (A, AA o AAA), o dar una versión alternativa que sí lo cumpla.
2. Páginas completas: el nivel de conformidad se aplica a páginas web completas, no a fragmentos sueltos.
3. Procesos completos: si una tarea implica varias páginas seguidas (por ejemplo, todo el proceso de compra de una tienda online, desde elegir el producto hasta pagarlo), todas las páginas del proceso deben cumplir el nivel exigido; basta con que una falle para que el proceso entero no sea conforme.
4. Solo tecnologías con soporte de accesibilidad: cualquier información o funcionalidad implementada con una tecnología que las ayudas técnicas no soporten bien debe estar disponible también por otra vía que sí lo soporte.
5. No interferencia: el uso de tecnologías no compatibles con la accesibilidad no debe bloquear el acceso al resto de la página.

La declaración en sí es opcional: se puede tener una web conforme sin declararlo públicamente. Pero si se hace, debe incluir fecha, título y versión exacta de las pautas seguidas, nivel alcanzado, descripción y URLs de las páginas cubiertas, y las tecnologías web en las que se confía.

Para evaluaciones completas y homogéneas entre distintos evaluadores, el W3C WAI ofrece además una metodología de evaluación de conformidad de sitios web (WCAG-EM), con su propia herramienta de generación de informes, pensada precisamente para estructurar todo este proceso de análisis en profundidad.

Ejemplo actual — la auditoría del Café Central. En la práctica UT05TE01 (Auditoría de accesibilidad y visibilidad del Café Central) vas a hacer justo esto a pequeña escala: primero una revisión rápida tipo "Easy Checks" (título, alt, contraste, teclado, formulario de reserva...) y después, si el cliente quisiera declarar conformidad AA, tocaría revisar criterio a criterio y documentar el resultado.

Ideas clave de esta sección¶

• Hay dos niveles de análisis: revisión preliminar rápida (comprobaciones sencillas) y evaluación completa de conformidad.
• Declarar conformidad exige cumplir un nivel completo, en páginas y procesos enteros, con tecnologías accesibles y sin interferencias.
• La declaración de conformidad es opcional, pero si se hace debe seguir un formato con información mínima obligatoria.

7. Herramientas de análisis de accesibilidad web¶

Ninguna herramienta automática, por sí sola, puede garantizar que una web es accesible al 100 %: hacen falta ambas cosas, análisis automático y revisión manual. El material de la unidad recoge un proceso de evaluación en dos fases (propuesto originalmente por INTECO):

1. Análisis automático, para detectar de forma rápida los problemas de accesibilidad que se pueden comprobar por software.
2. Evaluación manual, para revisar todo lo que un programa no puede juzgar por sí mismo (por ejemplo, si un texto alternativo describe bien la imagen, o si el orden de lectura tiene sentido).

Entre las herramientas recogidas en el material de la unidad están:

Aunque este listado viene del material de la unidad, conviene saber que el ecosistema de herramientas cambia con el tiempo: algunas de estas siguen activas hoy prácticamente igual (WAVE, TAW), y el hueco de las barras de navegador clásicas lo ocupan hoy, en buena parte, extensiones y auditores integrados en los propios navegadores.

Ejemplo actual — Lighthouse y axe DevTools. Hoy en día, además de herramientas como WAVE, es muy habitual usar el panel Lighthouse, integrado directamente en las herramientas de desarrollo de Chrome y Edge, que entre otras cosas puntúa la accesibilidad de la página, o la extensión axe DevTools (de Deque Systems), muy usada en equipos profesionales de desarrollo front-end para integrar comprobaciones de accesibilidad en el propio flujo de trabajo, incluso en pruebas automatizadas.

En las noticias — sanciones por accesibilidad. En los últimos años se han conocido casos, sobre todo en Estados Unidos, de demandas y sanciones a empresas (cadenas de comercio, bancos, aerolíneas...) por tener webs o apps que no cumplían criterios básicos de accesibilidad. Es una de las razones por las que cada vez más equipos de desarrollo integran herramientas de análisis de accesibilidad desde el principio del proyecto, y no solo al final.

Ideas clave de esta sección¶

• Ninguna herramienta automática certifica el 100 % de la accesibilidad: hace falta combinar análisis automático y revisión manual.
• El material de la unidad recoge validadores de código (W3C), evaluadores de accesibilidad (TAW, eXaminator, WAVE) y barras de herramientas de navegador.
• Hoy se añaden a ese ecosistema herramientas integradas en el navegador, como Lighthouse, o extensiones profesionales como axe DevTools.

8. Chequeo de la accesibilidad web desde diferentes navegadores y dispositivos¶

Una página puede parecer perfecta en tu navegador habitual y fallar estrepitosamente en otro, o para alguien que usa una tecnología de asistencia distinta a la tuya. Por eso el chequeo de accesibilidad hay que repetirlo variando navegador, sistema operativo y dispositivo o tecnología de acceso.

La propia guía de comprobaciones sencillas del W3C recuerda que hay comportamientos que cambian de un navegador a otro. Por ejemplo, la navegación con la tecla Tab funciona en Firefox, Chrome, Safari o Internet Explorer, pero en su momento no en Opera; en macOS hay que activar explícitamente "acceso total por teclado" para poder tabular por todos los controles, mientras que en Windows viene activado por defecto; y para probar el "zoom de solo texto" (que agranda el texto sin ampliar el resto de la página) algunos navegadores lo traen de serie y otros necesitan una extensión. Son detalles muy concretos, pero ilustran algo importante: "probarlo en mi navegador" no es probarlo, hay que variar el entorno.

Junto al navegador hay que tener en cuenta las tecnologías asistenciales que usan las personas con discapacidad para acceder al contenido, porque cada una "lee" la página de una forma distinta:

• Dispositivos de entrada: teclado virtual en pantalla (con predicción de palabras), teclados alternativos (teclas más grandes, más separadas o con colores/imágenes), teclado Braille (con 6 u 8 teclas principales) y software de reconocimiento de voz.
• Dispositivos de salida: lectores de pantalla (que convierten el contenido en voz mediante un sintetizador), ampliadores de pantalla (para baja visión), líneas Braille (celdas táctiles de 6 u 8 puntos) y navegadores específicos para personas ciegas, que leen las páginas en voz alta.

Comprobar la web con estas tecnologías —o al menos simular su comportamiento, por ejemplo navegando solo con teclado o con las imágenes y estilos desactivados, como propone la "comprobación básica de estructura" que vimos en el punto 6— es la única forma real de saber si el diseño aguanta fuera de tu propio ordenador.

Figura: así "ve" la estructura de una página una tecnología de asistencia que navega por encabezados, independientemente del navegador o dispositivo que se use. Origen: WEB - W3C WAI - Comprobaciones sencillas.pdf.

Ejemplo actual — VoiceOver, TalkBack y NVDA. Hoy los lectores de pantalla más usados para comprobar accesibilidad son VoiceOver (integrado en macOS e iOS), TalkBack (integrado en Android) y NVDA (gratuito, para Windows). Un equipo de desarrollo serio prueba con al menos uno de escritorio y uno móvil, porque el comportamiento no es idéntico.

En las noticias — "modo oscuro" y accesibilidad. La generalización del modo oscuro en sistemas operativos y navegadores ha traído de vuelta el debate sobre el contraste: algunos diseños que cumplían WCAG en modo claro dejan de cumplirlo en modo oscuro (o al revés), lo que obliga a comprobar la accesibilidad en ambos modos, no solo en uno.

Ideas clave de esta sección¶

• Hay que repetir las comprobaciones en varios navegadores y sistemas operativos: el comportamiento del teclado o del zoom de texto no es siempre igual.
• Las tecnologías asistenciales (lectores de pantalla, líneas Braille, teclados adaptados, reconocimiento de voz...) "leen" la página de forma distinta a como tú la ves.
• Navegar solo con teclado, o ver la página sin estilos ni imágenes, es una forma barata y rápida de detectar muchos problemas de accesibilidad sin tener el hardware especializado.

9. Posicionamiento en buscadores. Mejora de la visibilidad de un sitio web en diferentes buscadores¶

De nada sirve una web accesible y perfectamente construida si nadie la encuentra. El SEO (Search Engine Optimization, optimización en buscadores) consiste en ayudar a los buscadores a entender tu contenido y a las personas usuarias a decidir si quieren visitarlo. La guía de SEO de Google para principiantes —que es la referencia de esta sección— deja claro desde el principio algo importante: no hay ningún truco mágico para aparecer el primero; lo que hay son buenas prácticas que facilitan el rastreo, la indexación y la comprensión de tu contenido, y que además suelen tardar semanas o meses en notarse en los resultados.

Cómo te encuentra Google¶

Google explora la Web constantemente con programas llamados rastreadores (crawlers) que van de enlace en enlace. La forma principal en la que Google descubre páginas nuevas es, precisamente, a través de enlaces desde otras páginas ya rastreadas; por eso promocionar el sitio y conseguir que otros enlacen a él ayuda tanto como (o más que) cualquier ajuste técnico. También se puede enviar un sitemap (un archivo con todas las URL importantes del sitio) para ayudar al rastreo, aunque no es obligatorio.

Es fundamental que Google pueda ver la página igual que la ve una persona usuaria: si se ocultan recursos clave como el CSS o el JavaScript, el buscador puede no entender bien el contenido y perjudicar el posicionamiento. Para comprobarlo existe la herramienta de inspección de URLs de Search Console.

Organizar el sitio y evitar contenido duplicado¶

Usar URL descriptivas (/pets/cats.html en vez de una cadena de caracteres aleatorios) ayuda tanto a usuarios como a buscadores, porque puede mostrarse como ruta de exploración en los resultados. Agrupar páginas del mismo tema en directorios también ayuda a que Google entienda con qué frecuencia cambia cada sección del sitio.

Cuando el mismo contenido es accesible desde varias URL distintas (contenido duplicado), el buscador elige una única URL "canónica" para mostrar; si no la eliges tú (con una redirección o con <link rel="canonical">), Google intentará adivinarla, pero es mejor controlarlo.

Contenido útil, enlaces y palabras clave¶

El factor con más peso, según la propia guía de Google, es tener contenido interesante y útil: bien escrito, organizado en párrafos y títulos, original (no copiado), actualizado y fiable. Conviene también anticipar las palabras que usaría la gente para buscar tu contenido (por ejemplo, alguien puede buscar "charcutería" y otra persona "tabla de queso" para lo mismo), aunque no hace falta cubrir todas las variantes posibles porque los sistemas de Google entienden el lenguaje de forma bastante flexible.

Los enlaces, tanto internos como hacia otros sitios de confianza, ayudan a que Google descubra páginas nuevas y entienda de qué tratan. El texto del enlace (el texto en azul o subrayado que se puede pulsar) debería describir con claridad el destino.

<!-- Ejemplo propio, inspirado en la guía de SEO de Google -->
<a href="/blog/menu-vegano-cafe-central">carta vegana del Café Central</a>
<!-- mejor que: -->
<a href="/blog/post-14">haz clic aquí</a>

Figura: un buen texto de enlace ayuda tanto a las personas como a los buscadores a entender el destino antes de hacer clic. Origen: WEB - Google - Guía de SEO para principiantes.pdf.

Cómo se ve tu página en los resultados de búsqueda¶

Dos elementos concentran casi toda la atención visual en un resultado de búsqueda: el enlace de título (construido a partir de la etiqueta <title> y otros encabezados de la página) y el fragmento (la descripción bajo el título, que suele salir de la metadescripción o del propio contenido de la página). Un buen título es único, claro, conciso y describe con precisión el contenido; una buena metadescripción es breve y recoge los puntos más relevantes de la página.

Figura: el enlace de título de un resultado de búsqueda se construye, entre otras fuentes, a partir de la etiqueta <title> del <head> del documento. Origen: WEB - Google - Guía de SEO para principiantes.pdf.

<head>
  <title>Carta y horarios del Café Central | Café Central</title>
  <meta name="description"
        content="Consulta la carta, los horarios y cómo llegar al Café Central,
        nuestra cafetería en el centro de la ciudad.">
</head>

Figura: el "fragmento" del resultado de búsqueda suele extraerse del contenido de la página o de la metadescripción. Origen: WEB - Google - Guía de SEO para principiantes.pdf.

Añadir imágenes de calidad cerca de texto relevante, con un texto alternativo descriptivo, también ayuda a que aparezcan en búsquedas de imágenes, y de paso —fíjate en la conexión con la unidad entera— es exactamente lo mismo que exige la accesibilidad en la pauta 1.1 de las WCAG que vimos en el punto 2. Accesibilidad y SEO, en este punto concreto, tiran del mismo hilo.

Lo que NO debería preocuparte tanto¶

La guía de Google es explícita sobre varios mitos habituales del SEO: la metaetiqueta de "palabras clave" no se usa para posicionar; repetir palabras clave en exceso va en contra de las políticas de spam; las palabras clave en el dominio o la ruta apenas tienen efecto (salvo en las rutas de exploración); PageRank es solo uno más de muchos factores; tener contenido duplicado no conlleva una penalización automática; el orden o número de encabezados no afecta directamente al posicionamiento (aunque sí importa para accesibilidad, que es otra historia); y ni la E-E-A-T (experiencia, conocimiento, autoridad, fiabilidad) ni la longitud del contenido son, por sí solas, un factor de posicionamiento.

Ejemplo actual — el Café Central en Google Maps y Search Console. Para un negocio local como el Café Central, dar de alta el perfil de empresa en Google (antes "Google My Business") y configurar Search Console para vigilar cómo indexa Google sus páginas suele tener más impacto práctico e inmediato que cualquier truco de palabras clave.

En las noticias — contenido generado por IA y las políticas de Google. En los últimos años Google ha insistido repetidamente en que lo que penaliza no es usar herramientas de IA para redactar, sino publicar contenido de baja calidad, poco útil o generado en masa solo para intentar posicionar ("contenido escalado de forma abusiva"), encaje dentro de sus políticas contra el spam. Es un matiz que se repite mucho en foros y blogs de SEO desde la explosión de la IA generativa.

Ideas clave de esta sección¶

• Google encuentra páginas sobre todo a través de enlaces; el sitemap es un apoyo, no un sustituto de que el sitio esté bien enlazado y sea visible para el navegador del rastreador.
• URLs descriptivas, contenido único y útil, buen texto de enlace y buen <title> + metadescripción son las palancas con más impacto real.
• Varias prácticas "clásicas" de SEO (meta keywords, keyword stuffing, PageRank como todo) ya no funcionan o nunca funcionaron como se pensaba.
• Accesibilidad y SEO comparten técnicas: texto alternativo, encabezados con sentido, contenido bien estructurado.

Glosario rápido¶

Repaso: preguntas para autoevaluarte¶

1. ¿Qué es el W3C y qué papel juega la WAI dentro de él?
2. ¿Cuáles son los cuatro principios POUR de las WCAG y qué garantiza cada uno?
3. ¿Cuántas pautas tiene WCAG 2.2 y en qué se diferencia de WCAG 2.0 en ese número?
4. ¿Qué diferencia hay entre un criterio de éxito y una técnica? ¿Y entre una técnica suficiente y una de asesoramiento?
5. Explica con tus palabras cómo se relacionan los antiguos "puntos de verificación" de WCAG 1.0 con los niveles A/AA/AAA que usamos hoy.
6. ¿Qué cinco requisitos hay que cumplir para poder hacer una declaración de conformidad con las WCAG?
7. Cita tres herramientas de análisis de accesibilidad mencionadas en la unidad y explica si son de análisis automático, manual o mixto.
8. ¿Por qué no basta con probar la accesibilidad de una web en un único navegador?
9. Según la guía de SEO de Google, ¿cuál es el factor que más influye en el posicionamiento? Cita dos prácticas de SEO que la guía desaconseja o relativiza.
10. Pon un ejemplo de una práctica que ayude a la vez a la accesibilidad y al SEO de una página.

De dónde sale esto (fuentes de la carpeta)¶

• DIW02.pdf — Material de referencia sobre accesibilidad web (aprox. 2012, centrado en WCAG 2.0, con introducción a discapacidad y tecnología asistencial). Fuente principal para las secciones 1, 2, 3, 4, 6 y 7. Al ser un material de esa fecha, algunos datos (por ejemplo, que WCAG 2.0 "se está desarrollando") se han contrastado y actualizado con las fuentes más recientes del W3C WAI incluidas en la carpeta.
• WEB - W3C WAI - Introducción a la accesibilidad web.pdf — Página oficial actual del W3C WAI: qué es la accesibilidad web, por qué importa y cómo evaluarla. Apoya las secciones 1 y 6.
• WEB - W3C WAI - Resumen de WCAG.pdf — Página oficial actual del W3C WAI sobre las versiones WCAG 2.0/2.½.2, sus fechas de publicación y su relación con ISO. Fuente principal de la sección 2 y 3 para los datos vigentes.
• WEB - W3C WAI - Novedades de WCAG 2.2.pdf — Página oficial (en inglés) del W3C WAI con el detalle de los 9 criterios de éxito nuevos de WCAG 2.2. Fuente principal de la tabla de la sección 3.
• WEB - W3C WAI - Comprobaciones sencillas.pdf — Guía oficial del W3C WAI ("Easy Checks") para una primera revisión de accesibilidad. Fuente principal de las secciones 6 y 8.
• WEB - Google - Guía de SEO para principiantes.pdf — Guía oficial de Google para optimización en buscadores. Fuente única y completa de la sección 9.

Avisos¶

• El contenido UT5-5 (Prioridades. Puntos de verificación) no aparece desarrollado de forma explícita en ningún PDF de la carpeta: DIW02.pdf solo menciona que existieron las WCAG 1.0 (mayo de 1999) sin detallar su sistema de prioridades ni de puntos de verificación. La sección 5 de este resumen recoge ese modelo histórico como conocimiento general de contexto, claramente señalado como tal, y no como un dato extraído literalmente de los PDF de la unidad.
• Hay una discrepancia de fecha entre fuentes: DIW02.pdf (~2012) presenta WCAG 2.0 como algo que la WAI "está desarrollando actualmente", mientras que las páginas oficiales actuales del W3C WAI confirman que WCAG 2.0 se publicó como Recomendación el 11 de diciembre de 2008. Siguiendo el criterio de priorizar la fuente más reciente, este resumen usa esa fecha de 2008 como dato correcto.
• DIW02.pdf no incluía imágenes embebidas de tamaño suficiente para la tabla de "Pautas y principios de la WCAG 2.0"; las dos imágenes usadas de este PDF (principios_pour_wcag.png y niveles_conformidad_logos.png) se han obtenido renderizando y recortando las páginas correspondientes, tal como prevé el procedimiento para figuras de maquetación mixta texto+gráfico.

Siguiente paso sugerido: pasar el agente verificador-resumen sobre este resumen.md.