Accesibilidad web: características clave comparadas

Web accessibility is defined by four measurable characteristics — perceptible, operable, understandable and robust — articulated according to the 13 level A and AA criteria of WCAG 2.2 which are required by the EN 301 549 standard in Europe. These four characteristics work as evaluation criteria: any widget, tool or framework is judged based on how many it meets and with what solidity.

Key Takeaways

• The four WCAG characteristics (perceptible, operable, understandable, robust) are the assessment framework, not a slogan: each one groups verifiable criteria with documented techniques.
• Level AA is the practical goal for most projects: it covers contrast, keyboard, form labels, structure and error messages, and it is the threshold that refers to European legislation.
• No automatic tool detects more than a fraction of real problems; manual testing with keyboard and screen reader remains irreplaceable.
• Choosing an “accessible” widget or framework requires checking its behavior with the keyboard, its focus management and its ARIA semantics, not just its marketing.
• Compliance is an ongoing process linked to the product lifecycle, not a one-time audit that is archived.

Qué significa realmente “características de accesibilidad web”

El término “características” se usa de dos formas que conviene separar. La primera es normativa: las WCAG organizan sus criterios de éxito en cuatro principios o características —perceptible, operable, comprensible y robusta— conocidos como POUR por sus iniciales en inglés.

La segunda es práctica: cuando un desarrollador dice que un componente “tiene buenas características de accesibilidad”, normalmente se refiere a un conjunto de comportamientos concretos (navegación por teclado, roles ARIA correctos, contraste suficiente, texto alternativo). Ambas lecturas se necesitan: la primera da el marco de evaluación, la segunda da los detalles implementables.

Las WCAG 2.2, publicadas por el W3C en 2023, mantienen los cuatro principios y añaden criterios como el tamaño mínimo de objetivo (2.5.8) y la coherencia de ayuda (3.2.6). El nivel A agrupa los criterios mínimos; el AA añade los más relevantes para la mayoría de sitios; el AAA es aspiracional y rara vez exigible en su totalidad. Para un sitio XHTML/CSS orientado a España o Latinoamérica, el objetivo realista es AA, porque es el nivel que referencia el estándar armonizado europeo EN 301 549 y, por extensión, la Directiva (UE) 2016/2102 sobre accesibilidad de sitios del sector público.

Las cuatro características WCAG, una por una

Perceptible

La característica perceptible exige que la información sea presentable de formas que el usuario pueda percibir, independientemente de sus sentidos. En la práctica se traduce en alternativas textuales para contenido no textual (1.1.1), subtítulos y transcripciones para multimedia (1.2.x), estructura semántica que no dependa solo de la posición o el color (1.3.1), contraste mínimo de 4.5:1 para texto normal y 3:1 para texto grande (1.4.3), y contenido que siga siendo legible al ampliar al 200 % sin scroll horizontal (1.4.10). Un error frecuente en sitios XHTML antiguos es usar tablas de maquetación o imágenes de texto: ambas rompen la perceptibilidad porque el orden de lectura y la escalabilidad se pierden.

Operable

La característica operable garantiza que todos los componentes de la interfaz funcionen con teclado y con tecnologías de asistencia. Los criterios clave son accesibilidad completa por teclado (2.1.1), ausencia de trampas de foco (2.1.2), tiempo ajustable (2.2.1), mecanismos para pausar contenido en movimiento (2.2.2), navegación con enlaces de salto y títulos de página descriptivos (2.4.1, 2.4.2), orden de foco lógico (2.4.3) y tamaño de objetivo suficiente (2.5.8). Aquí es donde fallan la mayoría de menús desplegables, modales y carruseles: capturan el foco y no lo devuelven, o dependen de eventos de ratón (onmouseover) sin equivalente de teclado.

Related: UserWay — Widget de accesibilidad con plan gratuito para empezar hoy mismo.

Comprensible

La característica comprensible aborda que el contenido y el funcionamiento de la interfaz sean entendibles. Incluye el idioma de la página declarado con el atributo lang (3.1.1), etiquetas y ayudas de entrada en formularios (3.3.2), identificación y descripción de errores (3.3.1, 3.3.3), navegación coherente entre páginas (3.2.3) y, en WCAG 2.2, coherencia de ayuda (3.2.6). Un formulario que marca un campo en rojo pero no explica qué falló incumple esta característica aunque sea visualmente claro para quien no tiene discapacidad.

Robusta

La característica robusta exige que el contenido funcione con una amplia variedad de agentes de usuario, incluidos los actuales y futuros. El criterio central es el análisis sintáctico correcto (4.1.1, obsoleto en WCAG 2.2 pero relevante en XHTML) y el nombre, función y valor para componentes de interfaz (4.1.2). En la práctica significa escribir HTML válido, usar elementos nativos siempre que existan y recurrir a ARIA solo cuando no haya alternativa, siguiendo la primera regla de ARIA: no usar ARIA si un elemento HTML nativo ya hace el trabajo.

Tabla comparativa: cómo evaluar herramientas y widgets frente a las cuatro características

Característica	Qué comprobar en una herramienta o widget	Señal de alarma
Perceptible	Genera alternativas textuales, respeta contraste, no depende del color	Solo valida imágenes, ignora estructura y contraste
Operable	Navegación por teclado, gestión de foco, sin trampas	Requiere ratón o no cierra con Escape
Comprensible	Etiquetas, mensajes de error, idioma declarado	Marca errores sin texto explicativo
Robusta	HTML válido, roles ARIA correctos, funciona en varios navegadores	Usa div con onclick en lugar de button

Esta tabla sirve como lista de criterios para decidir entre opciones. Una herramienta que solo cubre la columna “perceptible” es útil como primer filtro, pero no como certificación.

Worth a look: AudioEye — Accesibilidad gestionada: automatización combinada con revisión humana.

Herramientas y su relación con las características

Las herramientas automáticas de evaluación —como axe DevTools, WAVE o Lighthouse— detectan sobre todo problemas de las características perceptible y robusta: texto alternativo ausente, contraste insuficiente, atributos ARIA mal formados, jerarquía de encabezados. Su cobertura es parcial por diseño: no pueden juzgar si un texto alternativo es descriptivo, si el orden de foco tiene sentido o si un mensaje de error es comprensible. La documentación de Deque sobre axe y la guía de WebAIM sobre evaluación automática coinciden en que ninguna herramienta sustituye la revisión humana.

Manual testing covers what the tools do not see. A minimal procedure includes: navigating the entire page only with Tab and Shift+Tab, verifying that the focus is always visible, testing with a screen reader (NVDA or VoiceOver), zooming to 200% and verifying that nothing overlaps, and disabling CSS to confirm that the order of content makes sense. This last step reveals problems of the understandable characteristic that no tool points out.

Cómo elegir según el tipo de proyecto

Un sitio institucional o de sector público en España debe apuntar a AA y documentar la conformidad, porque la normativa lo exige. Un blog personal puede priorizar perceptible y operable, que resuelven la mayoría de barreras reales.

Una aplicación web compleja con componentes interactivos necesita invertir en robusta y operable, porque los widgets personalizados son la principal fuente de fallos. La decisión no es “cuántas características cumplo” sino “qué características son críticas para mis usuarios y mi obligación legal”.

For frameworks and component libraries, practical evaluation involves testing the component with a keyboard before adopting it. A custom “select” that doesn’t respond to arrows, a modal that doesn’t trap focus correctly, or a tooltip that only appears with hover are signals that the library prioritizes appearance over operability. The W3C ARIA Authoring Practices Guide documentation describes the expected patterns for each widget and provides the baseline for comparison.

Errores frecuentes al interpretar las características

El primer error es tratar las cuatro características como una lista de verificación binaria. La conformidad es acumulativa y contextual: un sitio puede cumplir 40 criterios y fallar en uno que bloquea por completo a un usuario.

Related: IAAP CPACC / WAS Certification — La certificación profesional que acredita tu experiencia en accesibilidad.

El segundo error es confiar en el “overlay” o widget de accesibilidad que promete arreglar el sitio con un script; estos productos no corrigen el HTML subyacente y han sido criticados por la comunidad y por informes de organismos de discapacidad. El tercer error es auditar una sola vez: el contenido cambia, los componentes se actualizan y la conformidad se degrada. La accesibilidad es un proceso integrado en el ciclo de desarrollo, con pruebas en cada entrega.

Frequently Asked Questions

¿Cuáles son las cuatro características de la accesibilidad web según las WCAG?

The WCAG organizes its criteria into four principles: perceptible, operable, understandable, and robust, known as POUR. Each principle groups verifiable success criteria with levels A, AA and AAA. This structure is maintained in WCAG 2.2 and is the basis for evaluating any site or component.

¿Qué nivel de conformidad WCAG debería cumplir mi sitio?

Para la mayoría de sitios, el nivel AA es el objetivo práctico y el que referencia la legislación europea a través del estándar EN 301 549. El nivel A cubre lo mínimo y el AAA es difícil de alcanzar en su totalidad. Si tu sitio es del sector público en la UE, el AA es exigible.

If you are shopping: accessiBe — Superposición de IA que promete cumplimiento WCAG en 48 horas.

¿Las herramientas automáticas bastan para cumplir las características de accesibilidad?

No. Las herramientas automáticas detectan una parte de los problemas, sobre todo de contraste, texto alternativo y ARIA mal formado, pero no pueden evaluar si un texto alternativo es adecuado o si el orden de foco tiene sentido. La revisión manual con teclado y lector de pantalla es imprescindible para una conformidad real.

¿Qué diferencia hay entre accesibilidad y usabilidad?

Accessibility ensures that people with disabilities can perceive, operate, understand and use content; usability seeks to ensure that the experience is efficient and satisfying for any user. They overlap: an accessible site is usually more usable, but a usable site is not necessarily accessible.

¿Los widgets o overlays de accesibilidad arreglan mi sitio automáticamente?

No corrigen el HTML subyacente ni los problemas de estructura, foco o semántica. La comunidad de accesibilidad y diversos informes los han cuestionado porque pueden dar una falsa sensación de conformidad. La solución pasa por corregir el código y los componentes, no por superponer un script.

¿Cómo empiezo a mejorar la accesibilidad de un sitio XHTML/CSS existente?

Empieza por lo que más impacto tiene: HTML válido y semántico, texto alternativo en imágenes, contraste suficiente, navegación completa por teclado y etiquetas en formularios. Después audita con una herramienta automática y complementa con pruebas manuales. Documenta los criterios cubiertos y repite el proceso en cada cambio relevante.

P.S. A few readers have asked which superposición de accesibilidad (overlay) we actually reach for — it's accessiBe; take a look here if you want the current details.