WCAG 3.1.4: Abreviaturas

Qué significa esta regla

El Criterio de Éxito 3.1.4 de las WCAG — Abreviaturas (Nivel AAA) exige que siempre que aparezca una abreviatura, acrónimo o sigla en el contenido web, exista un mecanismo mediante el cual las personas usuarias puedan descubrir su forma desarrollada o su significado. Una abreviatura, en los términos de las WCAG, es una forma acortada de una palabra, frase o nombre; esto incluye abreviaturas tradicionales (por ejemplo, «aprox.» para «aproximadamente»), acrónimos (por ejemplo, «NASA» para «National Aeronautics and Space Administration») y siglas (por ejemplo, «HTML» para «HyperText Markup Language»).

El criterio no prescribe una única técnica obligatoria. En su lugar, exige que exista algún mecanismo para que las personas que se encuentren con una forma abreviada desconocida puedan determinar a qué se refiere. Los mecanismos aceptables incluyen desarrollar la abreviatura en el texto en su primer uso (por ejemplo, «HyperText Markup Language (HTML)»), usar el elemento HTML <abbr> con un atributo title que proporcione el desarrollo, ofrecer un glosario enlazado desde la página o incluir la forma completa en el contexto circundante de modo que el significado sea inequívoco.

Se produce un cumplimiento cuando cada abreviatura del contenido cuenta con al menos uno de estos mecanismos: la forma completa aparece en el texto junto a la abreviatura o inmediatamente antes de ella en su primer uso; el elemento <abbr> con un atributo title informativo envuelve la abreviatura; un glosario o una lista de definiciones accesible desde la página define el término; o el contexto circundante hace que el significado sea totalmente claro y sin ambigüedad. Se produce un incumplimiento cuando aparece una abreviatura sin ninguno de estos apoyos: la persona usuaria ve una forma abreviada como «MoNE» o «SCR» sin ninguna indicación de lo que significa, sin información emergente, sin desarrollo previo y sin glosario enlazado.

Las WCAG incluyen una excepción limitada: si la abreviatura se considera parte del propio idioma —es decir, está tan extendida que funciona como una palabra independiente (por ejemplo, «laser» o «radar», que originalmente eran acrónimos)—, entonces no es necesario desarrollarla. Del mismo modo, las abreviaturas que están definidas por los propios términos definidos del contenido y se usan de forma coherente en ese contexto con un glosario claramente accesible se consideran conformes. La prueba clave es siempre si una persona usuaria que no conoce la abreviatura puede encontrar su significado mediante los mecanismos disponibles en el contenido.

Por qué es importante

Las abreviaturas son omnipresentes en el contenido web: portales gubernamentales, sistemas sanitarios, plataformas de comercio electrónico y sitios educativos dependen en gran medida de formas abreviadas. Aunque resultan familiares para las personas expertas en el dominio, estas formas acortadas suponen barreras significativas para varios grupos de usuarios.

Las personas con discapacidades cognitivas y de aprendizaje, como dislexia, discapacidad intelectual o trastornos por déficit de atención, pueden tener dificultades para descifrar abreviaturas desconocidas, lo que las obliga a abandonar la página para buscar significados o a desistir por completo. Para las personas con deterioro de la memoria, incluso las abreviaturas que ya han encontrado antes pueden no recordarse de forma fiable de una sesión a otra, por lo que los mecanismos dentro de la página proporcionan un apoyo continuo fundamental.

Las personas usuarias de lectores de pantalla —incluidas las personas ciegas o con baja visión grave— se ven directamente afectadas porque los lectores de pantalla pueden pronunciar las abreviaturas fonéticamente de formas confusas o carentes de sentido. Por ejemplo, un lector de pantalla podría pronunciar «SCR» como una secuencia de letras sin sentido en lugar de «Sustainable Corporate Responsibility». Cuando el elemento <abbr> se usa correctamente con un atributo title, ciertas configuraciones de lectores de pantalla pueden pronunciar la forma desarrollada en lugar de la sigla, lo que mejora drásticamente la comprensión. Según la Organización Mundial de la Salud, aproximadamente 2,2 mil millones de personas en todo el mundo tienen algún tipo de discapacidad visual, una gran proporción de las cuales depende de la tecnología de apoyo para acceder al contenido digital.

Las personas que no son hablantes nativas son otro grupo afectado. Una persona usuaria turca que lee un documento técnico en inglés —o una persona angloparlante que navega por un portal gubernamental turco— puede dominar el idioma y, aun así, desconocer por completo las abreviaturas específicas del dominio o de la cultura. Proporcionar desarrollos respeta la diversidad de los antecedentes y bases de conocimiento de las personas usuarias.

Consideremos un escenario concreto: una paciente que visita el portal en línea de un hospital lee su informe diagnóstico y se encuentra con «KOAH» sin ningún desarrollo. Una persona clínica turca reconoce inmediatamente que se trata de «Kronik Obstrüktif Akciğer Hastalığı» (Chronic Obstructive Pulmonary Disease), pero una paciente o una persona cuidadora que no esté familiarizada con la terminología médica se queda sin comprender su propio diagnóstico. Proporcionar el desarrollo —ya sea integrado en el texto en el primer uso o mediante un elemento <abbr title='Kronik Obstrüktif Akciğer Hastalığı'>KOAH</abbr>— transforma un término confuso en información comprensible y respalda la toma de decisiones informada.

Más allá de la accesibilidad, existen beneficios medibles en términos de usabilidad y SEO. Los motores de búsqueda indexan las formas desarrolladas de las abreviaturas, lo que mejora la capacidad de descubrimiento del contenido para las personas que buscan utilizando los términos completos. Un lenguaje claro y sin ambigüedades también reduce las solicitudes de soporte, aumenta las tasas de finalización de tareas y genera confianza entre las personas usuarias con distintos niveles de alfabetización.

Reglas relacionadas de Axe-core

WCAG 3.1.4 requiere pruebas manuales porque ninguna herramienta automatizada puede determinar de forma fiable si una abreviatura concreta está suficientemente explicada en el contexto de una página. Los analizadores automáticos pueden detectar la presencia de elementos <abbr>, pero no pueden juzgar si a todas las abreviaturas de una página se les ha proporcionado un desarrollo accesible. A continuación se presenta un resumen del contexto relevante de axe-core:

• Se requiere prueba manual (no hay una regla específica de axe-core): Axe-core no incluye una regla automatizada específica para WCAG 3.1.4. Esto se debe a que determinar qué cadenas de texto constituyen abreviaturas, si se desarrollan adecuadamente en algún lugar de la página y si un glosario enlazado es accesible requiere juicio humano y lectura contextual. Una herramienta automatizada no puede distinguir entre «IT» (Information Technology), «it» (el pronombre) e «It» (un nombre propio) sin una comprensión profunda del lenguaje natural. Las personas evaluadoras deben leer manualmente el contenido de la página, identificar todas las abreviaturas, acrónimos y siglas y, a continuación, verificar que cada una tenga un mecanismo de desarrollo accesible.
• Comprobación relacionada — <abbr> sin title: Aunque no es una regla independiente de axe-core mapeada a 3.1.4, algunas herramientas de revisión de accesibilidad y extensiones de navegador señalan los elementos <abbr> que carecen de atributo title como una advertencia de buena práctica. Si se utiliza <abbr> como mecanismo de desarrollo, el atributo title debe estar presente y contener el desarrollo completo; un title vacío o ausente frustra el propósito del elemento y constituiría un incumplimiento de este criterio.

Cómo hacer las pruebas

1. Línea base de análisis automatizado: Ejecuta axe DevTools o Lighthouse sobre la página. Aunque ninguna de las dos herramientas tiene una regla específica para 3.1.4, axe DevTools puede mostrar avisos de buenas prácticas sobre elementos <abbr> que no tienen atributos title. Tómalos como puntos de partida, pero ten en cuenta que no detectarán abreviaturas que carezcan por completo de marcado <abbr>.
2. Auditoría manual de contenido: Lee todo el contenido de la página —incluidos encabezados, cuerpo del texto, tablas, etiquetas de formularios, etiquetas de botones, elementos de navegación y texto del pie de página—. Resalta cada palabra o secuencia de caracteres que pueda ser una abreviatura, acrónimo o sigla. Para cada una, comprueba si: (a) se desarrolló anteriormente en la misma página; (b) está envuelta en un elemento <abbr> con un title no vacío; (c) la página enlaza a un glosario que la define; o (d) el contexto circundante hace que su significado sea inequívoco.
3. Verificación con lector de pantalla usando NVDA + Firefox: Abre la página en Firefox con NVDA activo. Navega por el contenido usando las teclas de flecha. Cuando NVDA encuentre un elemento <abbr> con un title, debería anunciar el texto del título. Verifica que se estén mostrando los desarrollos. Ten en cuenta que el comportamiento de NVDA con los atributos title en elementos <abbr> puede variar según la versión y la configuración; prueba primero con la configuración predeterminada de NVDA.
4. Verificación con lector de pantalla usando VoiceOver + Safari (macOS/iOS): Activa VoiceOver y navega por la página. VoiceOver en macOS lee los atributos title en elementos <abbr>. Usa VO+A para leer la página de forma lineal y escucha si las abreviaturas reciben sus desarrollos. En iOS, desplázate por el contenido con gestos y comprueba el mismo comportamiento.
5. Verificación con lector de pantalla usando JAWS + Chrome: Con JAWS activo, navega por la página usando las teclas de flecha. JAWS gestiona <abbr title='...'> anunciando el título. Comprueba que el desarrollo se lea en voz alta correctamente para cada abreviatura marcada.
6. Comprobación con teclado y visual de los desarrollos en información emergente: Si la implementación se basa en patrones de información emergente con CSS o en información emergente mediante JavaScript vinculada a estados de hover de <abbr>, navega hasta el elemento con el teclado (o enfócalo mediante programación) y verifica que aparezca la información emergente. Las WCAG exigen que el mecanismo sea accesible, no solo accesible con el ratón: una información emergente que solo aparece al pasar el ratón por encima no es válida para las personas que usan teclado.
7. Verificación de enlaces a glosarios: Si la página se basa en un glosario enlazado, sigue el enlace y confirma que cada abreviatura utilizada en el contenido de origen tenga una entrada correspondiente con una definición clara. Verifica que el enlace al glosario esté colocado de forma destacada y sea accesible mediante teclado.

Cómo corregir

Abreviatura sin marcar en el primer uso — Incorrecto

<p>The WHO reported that NCDs account for 74% of all deaths globally each year.</p>

Abreviatura sin marcar en el primer uso — Correcto

<!-- Expand on first use inline, then use abbr for subsequent references -->
<p>The World Health Organization (WHO) reported that non-communicable diseases
(<abbr title='non-communicable diseases'>NCDs</abbr>) account for 74% of all
deaths globally each year.</p>

Elemento abbr sin atributo title — Incorrecto

<!-- abbr element present but title is missing — provides no expansion -->
<p>Submit your <abbr>VAT</abbr> registration number to proceed.</p>

Elemento abbr sin atributo title — Correcto

<!-- title attribute supplies the full expansion for assistive technologies -->
<p>Submit your <abbr title='Value Added Tax'>VAT</abbr> registration number to proceed.</p>

Información emergente solo al pasar el ratón para una abreviatura — Incorrecto

<!-- CSS tooltip only appears on mouse hover; keyboard users and touch users cannot access it -->
<span class='tooltip-trigger'>KVKK
  <span class='tooltip-text'>Kişisel Verilerin Korunması Kanunu</span>
</span>

Información emergente solo al pasar el ratón para una abreviatura — Correcto

<!-- Using abbr with title ensures the expansion is available to all users,
     including keyboard and screen reader users, without relying on hover -->
<abbr title='Kişisel Verilerin Korunması Kanunu'>KVKK</abbr>

Abreviatura en un encabezado de tabla sin desarrollo — Incorrecto

<table>
  <thead>
    <tr>
      <th>SKU</th>
      <th>MoQ</th>
      <th>ETA</th>
    </tr>
  </thead>
</table>

Abreviatura en un encabezado de tabla sin desarrollo — Correcto

<!-- abbr with title inside th provides context for all users, including screen reader users -->
<table>
  <thead>
    <tr>
      <th><abbr title='Stock Keeping Unit'>SKU</abbr></th>
      <th><abbr title='Minimum Order Quantity'>MoQ</abbr></th>
      <th><abbr title='Estimated Time of Arrival'>ETA</abbr></th>
    </tr>
  </thead>
</table>

Errores comunes

• Usar <abbr> sin atributo title: Envolver texto en etiquetas <abbr> por sí solo no proporciona valor semántico ni desarrollo; el atributo title es obligatorio para que el elemento cumpla su propósito de accesibilidad según este criterio.
• Desarrollar una abreviatura solo después de su primer uso: Si una abreviatura aparece antes que su desarrollo en el orden de lectura (por ejemplo, en un encabezado antes del párrafo del cuerpo que la desarrolla), las personas que se encuentren primero con el encabezado no tendrán ningún mecanismo para entenderla en ese momento. Desarrolla siempre en el primer uso o antes.
• Confiar exclusivamente en información emergente al pasar el ratón: Las informaciones emergentes con CSS o JavaScript que solo aparecen con :hover son inaccesibles para las personas que solo usan teclado, para quienes usan pantallas táctiles y para la mayoría de las configuraciones de lectores de pantalla. El patrón <abbr title> es preferible, o bien las informaciones emergentes también deben activarse con :focus.
• Proporcionar un glosario enlazado pero hacer que el enlace sea difícil de encontrar: Si tu mecanismo de desarrollo es un glosario, el enlace debe estar claramente etiquetado, situado en un lugar destacado y ser accesible mediante teclado. Enterrar un enlace al glosario en un pie de página en texto pequeño o detrás de una sección plegada puede no satisfacer el requisito de un mecanismo utilizable.
• Desarrollar abreviaturas de forma inconsistente — solo algunas apariciones marcadas: Si utilizas <abbr title> para un acrónimo en una sección pero dejas instancias sin marcar en otras partes de la misma página, las personas que navegan directamente a esas secciones mediante la búsqueda o puntos de referencia se encontrarán con formas abreviadas sin explicación.
• Suponer que todas las abreviaturas se entienden de forma universal: Las abreviaturas específicas de un dominio que resultan obvias para las personas profesionales («EBITDA» en finanzas, «API» en desarrollo de software, «BKT» en contextos gubernamentales turcos) pueden ser completamente opacas para las personas ajenas a esos dominios, incluidas las que usan tecnología de apoyo o visitan la página por primera vez.
• Colocar el desarrollo solo en el texto alternativo de las imágenes en lugar de en el texto: Si una abreviatura aparece en el texto alternativo de una imagen como desarrollo pero el texto visible muestra solo la abreviatura, es posible que el mecanismo no sea accesible para todas las personas (por ejemplo, quienes usan modos de lectura del navegador). Los desarrollos deben estar disponibles en el texto programático del propio documento.
• Usar valores de title incorrectos o abreviados: El atributo title de un elemento <abbr> debe contener el desarrollo completo, no otra abreviatura ni una explicación parcial. Escribir title='HTML lang' en lugar de title='HyperText Markup Language' no satisface el criterio.
• No tener en cuenta las abreviaturas en contenido dinámico: El contenido cargado mediante AJAX, desplazamiento infinito o enrutamiento de aplicaciones de una sola página puede introducir nuevas abreviaturas después de la carga inicial de la página. Cualquier contenido dinámico inyectado en el DOM también debe cumplir: las abreviaturas en secciones generadas dinámicamente necesitan los mismos mecanismos de desarrollo que el contenido estático.
• Tratar los acrónimos que se han convertido en palabras comunes como siempre exentos: La excepción para abreviaturas que funcionan como palabras («laser», «radar») es limitada. Términos como «URL» o «PDF» son muy conocidos en contextos tecnológicamente avanzados, pero pueden seguir siendo opacos para personas mayores, personas con discapacidades cognitivas o personas de diferentes contextos culturales. En caso de duda, proporciona el desarrollo: nunca perjudica a quienes ya conocen el término.

Relación con la normativa de accesibilidad de Turquía

La Circular Presidencial 2025/10 de Turquía, publicada en el Boletín Oficial n.º 32933 el 21 de junio de 2025, establece obligaciones obligatorias de accesibilidad digital alineadas con las WCAG 2.2. La circular abarca una amplia gama de tipos de entidades: instituciones públicas y organismos gubernamentales de todos los niveles, plataformas de comercio electrónico, bancos e instituciones financieras, hospitales y proveedores de servicios sanitarios, empresas de telecomunicaciones con 200,000 o más abonados, agencias de viajes autorizadas, empresas de transporte privadas y escuelas privadas autorizadas por el Ministry of National Education (MoNE).

La circular exige el cumplimiento principalmente del Nivel AA de las WCAG 2.2. El Criterio 3.1.4 de las WCAG — Abreviaturas es un criterio de Nivel AAA y, por tanto, no es un requisito legal directo según el texto actual de la Circular Presidencial 2025/10. Sin embargo, la conformidad de Nivel AAA no es meramente aspiracional: tiene un peso práctico y reputacional significativo en el panorama digital turco.

Para las entidades del sector público, los hospitales y las instituciones educativas que atienden a poblaciones diversas —muchas de las cuales pueden tener una familiaridad limitada con abreviaturas burocráticas o médicas—, implementar el 3.1.4 es una cuestión de verdadera calidad de servicio. El lenguaje administrativo y jurídico turco está lleno de siglas («SGK» para Sosyal Güvenlik Kurumu, «KDV» para Katma Değer Vergisi, «ÖTV» para Özel Tüketim Vergisi) que resultan naturales para las personas funcionarias pero confusas para el público en general, especialmente para personas mayores, usuarias rurales o visitantes primerizos de un portal.

Los bancos, proveedores de telecomunicaciones y plataformas de comercio electrónico sujetos a la circular reforzarían su postura de accesibilidad —y la confianza en su marca— desarrollando las abreviaturas utilizadas en descripciones de productos financieros, resúmenes de contratos, tablas de tarifas y condiciones de servicio. Los documentos financieros, en particular, están llenos de abreviaturas que pueden ocultar información crítica a las personas consumidoras que necesitan tomar decisiones informadas.

Las organizaciones que busquen una declaración formal de conformidad con WCAG 2.2 AAA —ya sea para demostrar liderazgo en el mercado, satisfacer requisitos de contratación de socios internacionales o cumplir las expectativas de contratos especializados en salud pública o educación— deberían implementar el 3.1.4 como práctica estándar. El SDK de superposición de Accsible ayuda a los equipos a implementar y auditar patrones de desarrollo de abreviaturas y puede configurarse para mostrar orientación durante los flujos de trabajo de creación de contenido, ayudando a las organizaciones a mantener el cumplimiento en contenido actualizado dinámicamente a escala.