Pedro Luis Diez Orzas

La EN 301 549 es la norma armonizada europea que fija los requisitos de accesibilidad de los productos y servicios TIC. Es el documento técnico que traduce la obligación legal en requisitos concretos y verificables. Su versión vigente es la V3.2.1, publicada por ETSI en marzo de 2021 y adoptada en España como UNE-EN 301549:2022. Es la referencia que usan tanto la contratación pública como la normativa de accesibilidad del sector privado. Si solo conoces las WCAG, te falta la mitad del mapa. La norma va bastante más allá de las páginas web. Datos clave Quién la publica. ETSI, junto con CEN y CENELEC, por mandato de la Comisión Europea. Versión vigente. V3.2.1 de marzo de 2021. En España, UNE-EN 301549:2022. Qué incorpora. Los criterios de nivel A y AA de las WCAG 2.1 en sus capítulos 9, 10 y 11. Qué cubre además. Hardware, software, documentos, vídeo, voz, documentación y soporte. Para qué sirve. Da presunción de conformidad con la normativa europea de accesibilidad. Qué es la norma EN 301 549 y de dónde viene La EN 301 549 nació para resolver un problema de compras públicas. Las administraciones europeas necesitaban un criterio común para exigir accesibilidad en sus licitaciones de tecnología. La norma especifica los requisitos funcionales de accesibilidad de los productos y servicios TIC, junto con los procedimientos de prueba y la metodología de evaluación de cada requisito. Está pensada para tecnologías web, no web e híbridas, y abarca software, hardware y servicios. La usan tanto quien compra como quien provee. Qué relación tiene con las WCAG y con la ley Conviene tener clara la cadena. La ley obliga, la norma armonizada dice cómo se demuestra el cumplimiento y las WCAG aportan los criterios concretos para el contenido digital. La Decisión de Ejecución (UE) 2021/1339, de 11 de agosto de 2021, estableció la V3.2.1 como la norma armonizada aplicable a sitios web y aplicaciones móviles. Cumplirla otorga presunción de conformidad. Eso significa que si cumples la norma, se presume que cumples la ley. No es obligatorio usarla, pero es el camino más corto y el que reconocen las autoridades de vigilancia. Cómo se numeran los requisitos La norma no reescribe las WCAG, las incorpora con su propia numeración. El criterio 1.1.1 de las WCAG 2.1 se corresponde con el requisito 9.1.1.1 de la EN 301 549. Saber esto ahorra tiempo. Cuando un informe de auditoría te habla del 9.1.4.3, está señalando el criterio de contraste mínimo de las WCAG. Qué cubre cada capítulo de la norma Aquí está la diferencia real con las WCAG. La norma organiza los requisitos por tipo de tecnología, y solo uno de esos bloques habla de páginas web. Capítulo Qué regula 4 Requisitos funcionales de rendimiento, como poder usar el producto sin visión o sin audición 5 Requisitos genéricos aplicables a cualquier producto TIC 6 Productos con comunicación de voz bidireccional 7 Productos con capacidad de vídeo, subtitulado y audiodescripción 8 Hardware 9 Contenido web 10 Documentos que no son web 11 Software, incluidas las aplicaciones móviles nativas 12 Documentación y servicios de atención al cliente 13 Servicios de intermediación y de emergencia A esos capítulos se suman varios anexos. El A relaciona la norma con la directiva, el B conecta requisitos con declaraciones de desempeño funcional y el C explica cómo se determina la conformidad. ¿Tienes claro qué capítulos de la norma te aplican y en cuántos idiomas? Cuéntanos tu caso Qué exige el capítulo 9 para las páginas web El capítulo 9 recoge todos los criterios de nivel A y AA de las WCAG 2.1, más los cinco requisitos de conformidad del apartado 9.6. En cifras, son los 30 criterios de nivel A y los 20 de nivel AA de las WCAG 2.1. Los criterios de nivel AAA aparecen en el apartado 9.5, pero como recomendación, no como obligación. Si quieres el detalle de qué pide cada nivel, lo desarrollamos en la guía sobre las WCAG 2.2 y los niveles de accesibilidad. Qué exige el capítulo 10 para los documentos El capítulo 10 se ocupa de los documentos electrónicos que no son páginas web. PDF, documentos de texto, hojas de cálculo, presentaciones o libros digitales. También aquí se aplican las WCAG 2.1, aunque se excluyen los criterios que no tienen sentido fuera de un navegador. La lógica es la misma, el soporte cambia. Este capítulo es el que sorprende a más empresas. Un catálogo comercial en PDF colgado de la web entra dentro del alcance, y la maquetación accesible no es opcional. Qué exige el capítulo 12 para la documentación y el soporte El capítulo 12 no tiene equivalente en las WCAG y por eso se pasa por alto. Exige que la documentación del producto y los servicios de atención al cliente también sean accesibles. Eso incluye manuales de usuario, guías de ayuda, formación y los canales de soporte. Un manual accesible no sirve de nada si el chat de atención al cliente no lo es. Para una empresa que vende en varios países, este capítulo tiene una consecuencia directa que veremos más abajo. Qué versión de la norma está vigente La V3.2.1 sigue siendo la referencia armonizada. Frente a la versión anterior, revisó los requisitos de texto en tiempo real, movió los criterios AAA al apartado 9.5 y añadió un anexo sobre accesibilidad cognitiva. ETSI trabaja en la versión V4, que alineará los capítulos con las WCAG 2.2 y actualizará el lenguaje sobre servicios de accesibilidad de plataforma. La buena noticia para quien ya cumple es que V4 no cambia la arquitectura de capítulos ni la relación con la EAA. Habrá que verificar los criterios nuevos, no rehacer el enfoque. Cómo se demuestra la conformidad con la norma El resultado operativo de aplicar la EN 301 549 es una declaración de conformidad. Un documento que recorre los requisitos aplicables e indica el grado de cumplimiento de cada uno. El anexo C de la norma explica cómo se determina esa conformidad. Y el capítulo 4 aporta vías alternativas cuando

Hreflang es un atributo que indica a los buscadores qué versiones de una misma página existen en otros idiomas o regiones. Sirve para que cada usuario aterrice en la versión correcta, no en la de otro mercado. No es una etiqueta difícil de escribir, pero sí una de las peor implementadas del SEO técnico. Basta un enlace recíproco que falta para que Google ignore todo el conjunto. Esta guía recoge los tres métodos que admite Google, los códigos que puedes usar y los errores que anulan la anotación, todo según su documentación oficial. Datos clave Métodos válidos. Etiquetas link en el head, cabeceras HTTP o sitemap XML. Los tres son equivalentes. Elige solo uno. Usar los tres a la vez no aporta ninguna ventaja en la Búsqueda. Reciprocidad obligatoria. Si A enlaza a B, B debe enlazar a A o se ignoran las etiquetas. Autorreferencia. Cada versión debe incluirse a sí misma en el conjunto. Códigos. Idioma en ISO 639-1 y región opcional en ISO 3166-1 Alpha 2. Qué es hreflang y para qué sirve Hreflang le comunica a Google que varias URLs son variantes localizadas del mismo contenido. Con esa información, la Búsqueda puede mostrar a cada usuario la versión más adecuada según su idioma y su ubicación. Google recomienda declararlo en tres situaciones concretas. Cuando solo se traduce la plantilla y no el contenido principal, cuando hay variaciones regionales del mismo idioma y cuando la página está traducida por completo. Lo que hreflang no hace Aquí hay un malentendido muy extendido. Google no usa hreflang ni el atributo lang del HTML para detectar el idioma de una página. Lo determina con sus propios algoritmos, analizando el contenido. Tampoco es una directiva. Hreflang es una señal que Google puede seguir o ignorar, y no fuerza el posicionamiento de una versión concreta en un país determinado. Cómo implementar hreflang con los tres métodos válidos Google admite tres formas de declararlo y las considera equivalentes. Puedes elegir la que mejor encaje con tu web, pero conviene usar solo una. Mantener tres implementaciones a la vez complica el trabajo sin aportar nada. Etiquetas link en el head Es el método más habitual. Se añade un elemento link por cada variante dentro de la sección head, incluida la versión de la propia página. Ese mismo bloque tiene que aparecer idéntico en las cuatro páginas. Y debe estar dentro del head, no inyectado en el body por un script. Cabeceras HTTP Es la opción para archivos que no son HTML, como los PDF. Se devuelve una cabecera Link en la respuesta con todas las variantes separadas por comas. Este método resuelve un problema real en proyectos multilingües. Los catálogos y las fichas técnicas en PDF también necesitan declarar sus equivalentes en otros idiomas. Sitemap XML Es el método más cómodo cuando hay muchas URLs, porque centraliza todo en un archivo. Cada elemento url incluye un hijo xhtml:link por cada variante, incluida la suya. Con tres versiones de una página, el sitemap tendrá tres entradas y cada una con tres hijos idénticos. Hay que declarar el espacio de nombres xhtml en la cabecera del archivo. ¿Tu web multiidioma no acaba de posicionar en los mercados donde vendes? Pide una revisión Cómo se escriben los códigos de idioma y región El valor de hreflang se compone de un código de idioma y, de forma opcional, uno de región separado por guion. El idioma va en formato ISO 639-1 y la región en ISO 3166-1 Alpha 2. La regla que más se incumple es que el primer código siempre es el idioma. No se puede indicar solo el país, y Google no lo deduce. Valor Significado Correcto de Alemán, sin importar la región Sí en-GB Inglés para usuarios del Reino Unido Sí fr-be Francés para usuarios de Bélgica Sí be Bielorruso, no Bélgica Error frecuente en-UK UK es código reservado, el válido es GB Se ignora es-419 No figura en ISO 3166-1 Alpha 2 No admitido En idiomas con varios alfabetos, el sistema de escritura se infiere del país. También puedes declararlo con el código ISO 15924, como zh-Hans para chino simplificado. Para qué sirve el valor x-default El valor x-default es reservado y se usa cuando la configuración del navegador del usuario no coincide con ninguna de las versiones que ofreces. Es tu página de respaldo. Google indica que funciona mejor en páginas selectoras de idioma y país, aunque puede declararse en cualquier página. No necesita código de idioma porque su función es precisamente cubrir a quien no encaja en ninguno. Sin x-default, es Google quien decide qué versión enseña a esos usuarios. Y su criterio no tiene por qué coincidir con el tuyo. Los errores de hreflang más habituales La documentación de Google señala tres fallos recurrentes, a los que conviene sumar otros que aparecen en cualquier auditoría de una web multiidioma. Hay una razón de fondo para la exigencia de reciprocidad. Evita que el responsable de otro sitio marque de forma arbitraria una página suya como versión alternativa de la tuya. Para validar la implementación existen herramientas de terceros que el propio Google menciona, como el generador de etiquetas de Aleyda Solís o el validador de Merkle. Genera contenido duplicado tener la web en varios idiomas Es la duda que frena muchos proyectos de internacionalización, y la respuesta de Google es clara. Las versiones localizadas de una página solo se consideran duplicadas si el contenido principal no está traducido. Traducir bien tu web no genera penalización por duplicidad. El riesgo aparece cuando se publica la misma página con la plantilla traducida y el cuerpo intacto en el idioma original. Ahí es donde una traducción automática sin revisión pasa factura. Si el contenido no llega a ser realmente distinto y útil en cada idioma, hreflang no te salva. Qué estructura de URL conviene para cada idioma Hreflang funciona con cualquier estructura, incluso entre dominios distintos, así que la decisión se toma por otros motivos. Estos son los tres modelos habituales. Modelo Ejemplo Cuándo encaja