Accessibility
Capacidad de usar una experiencia
Accessibility describe aquí el grado en que personas con diversas discapacidades, capacidades, métodos de entrada y tecnologías de asistencia pueden percibir, comprender, navegar y operar una experiencia digital. Es una definición de trabajo del Atlas, no una fórmula normativa W3C. Incluye condiciones visuales, auditivas, motoras, del habla, cognitivas y neurológicas, y combinaciones; no equivale a soportar un lector de pantalla.
La introducción de WAI sitúa accesibilidad en personas que encuentran barreras al utilizar productos Web. Lectores, magnificación, control por voz y switches ofrecen modos diferentes de interacción. Ni una tecnología ni un perfil de usuario representan a todos. Cambios de capacidad y condiciones de uso también pueden volver valiosos mecanismos alternativos, sin establecer una clasificación rígida de personas.
Usability, accessibility e inclusion se relacionan sin ser sinónimos. Usability examina uso eficaz y satisfactorio en contexto; inclusive design amplía participación y diversidad en el proceso; accessibility mantiene atención específica a barreras y capacidades de personas con discapacidad. Un diseño responsive solo adapta presentación a condiciones de layout: no demuestra operación por teclado, comprensión o compatibilidad con asistencia.
WCAG orienta evaluación, no agota el concern
Estado revisado 2026-10-24: WCAG 2.2 es W3C Recommendation y la versión WCAG 2 más reciente que W3C recomienda utilizar. Añade criterios a 2.1 con la excepción documentada de 4.1.1 Parsing, obsoleto y retirado. No afirmar simplemente que invalida versiones anteriores ni que todo markup inválido produce necesariamente la misma barrera.
La visión general WAI conserva WCAG 2.0, 2.1 y 2.2 como estándares existentes. ISO/IEC 40500:2025 corresponde a la edición de octubre de 2023 de WCAG 2.2; no confundir esa relación con identidad de todas las revisiones posteriores. Normas y políticas pueden referir ediciones distintas. Este canonical no determina obligaciones legales ni afirma que AA sea exigible en todas las jurisdicciones.
WCAG organiza su framing mediante cuatro principios: Perceivable, Operable, Understandable y Robust. Preguntan si la información puede percibirse, la funcionalidad operarse, la experiencia comprenderse y la representación interpretarse de forma compatible. POUR es organización WCAG, no taxonomía universal de accessibility.
Los niveles A, AA y AAA agrupan criterios y requisitos de conformidad; no significan malo, bueno y accesibilidad perfecta. Conformidad requiere evaluar alcance y procesos pertinentes, no promediar un porcentaje de checks. Pasar numerosas verificaciones automatizadas no elimina barreras de una interacción real ni demuestra que toda persona pueda completar cualquier tarea.
Semántica como contrato de interacción
Estructura semántica comunica qué es un control, cómo se llama, su estado y sus relaciones. Un div con apariencia de botón no adquiere por estilo comportamiento de teclado ni semántica de botón. Preferir HTML nativo adecuado evita reconstruir responsabilidades que ya ofrece la plataforma; no significa que todo elemento nativo sea correcto en cualquier composición.
El browser deriva del DOM, semántica y estado información expuesta mediante APIs de accesibilidad de plataforma; tecnologías de asistencia consumen esa representación. El accessibility tree no es una captura visual ni una copia literal del DOM. Orden, relaciones y contenido disponibles importan aunque la pantalla parezca correcta. Validación sintáctica sola no demuestra que el contrato descrito coincida con la tarea.
Estado de fuentes: WAI-ARIA 1.2 es Recommendation; 1.3 sigue como Working Draft. ARIA expresa roles, estados y propiedades, sin implementar lógica de interacción. APG advierte sobre semántica incorrecta: declarar un rol compromete comportamiento esperado. Añadir atributos no compensa teclado ausente ni actualizaciones incoherentes; tampoco se trata de evitar ARIA cuando aporta semántica necesaria.
Nombres y descripciones accesibles permiten identificar controles con significado. Nombre accesible y etiqueta visible necesitan alineación, especialmente para quienes usan voz. Describir finalidad no consiste en repetir el tipo de widget. Estado expanded, selected, invalid o busy tiene que corresponder al comportamiento observable, no quedar congelado tras un cambio de UI.
Como preguntas de diseño Atlas, no una taxonomía normativa:
| Aspecto del control | Pregunta que debe poder responderse |
|---|---|
| Rol y nombre | ¿Qué es y qué acción o información identifica? |
| Estado y valor | ¿Qué está seleccionado, expandido, ingresado o pendiente ahora? |
| Relaciones | ¿Qué etiqueta, instrucción, error o región explica este control? |
| Operación | ¿Cómo se alcanza, utiliza y abandona con las entradas soportadas? |
Teclado, foco y navegación dinámica
La guía de teclado APG distingue navegación entre componentes y operación dentro de ellos. Tab no es la única tecla ni todo elemento debe recibir tabindex=0. Funcionalidad pertinente necesita caminos operables sin depender exclusivamente de pointer/touch, evitando trampas y secuencias arbitrarias que vuelvan impracticable completar una tarea.
Foco es estado de interacción con consecuencias de navegación: necesita orden lógico y señal visible. Apertura/cierre de diálogo, eliminación de un item, error y cambio de vista requieren decidir dónde continúa el usuario. Mover siempre al primer elemento o devolver siempre al origen no resuelve todos los casos. La estructura y el propósito de la acción gobiernan esa decisión.
Un cambio asíncrono puede reemplazar el control que se estaba utilizando o actualizar su valor sin una acción adicional del usuario. Conservar una referencia técnica al componente no demuestra continuidad de foco. Definir qué estados pueden desaparecer, cómo se comunica el resultado y qué camino queda disponible ayuda a coordinar UI y efectos sin secuestrar navegación cada vez que llegan datos.
Una transición SPA puede no proporcionar automáticamente el contexto de una navegación completa. Título, landmarks y foco deben seguir representando la vista actual. Actualizar una región sin contexto puede dejar al usuario en una interfaz que cambió sin que pueda interpretarla. La semántica de foco HTML aporta mecanismos; el contrato del recorrido sigue siendo responsabilidad de la aplicación.
client-state-management organiza quién conserva estado; aquí importa además su exposición semántica. unidirectional-data-flow puede hacer explícitas transiciones sin asegurar entrada, foco o anuncios correctos. Cambios relevantes pueden requerir notificación mediante mecanismos como live regions, pero anunciar cada actualización produce ruido. Elegir información, oportunidad y prioridad según significado de la tarea, no aplicar aria-live a toda pantalla.
Contenido, formularios y variación de presentación
Los formularios WAI conectan etiquetas, instrucciones, agrupación y feedback. Placeholder no sustituye toda esa información. Error necesita significado, asociación al campo/proceso y recuperación posible; no basta un borde rojo. Mantener valores tras rechazo puede evitar trabajo repetido, conservando restricciones de seguridad y autoridad del sistema.
Las alternativas de imágenes dependen de función y contexto: contenido informativo, decorativo y controles plantean necesidades distintas. Para audio y video, captions, transcripciones o audio description responden a información y medios concretos. La presencia de un atributo o archivo no demuestra equivalencia informativa; revisar qué necesita conocer la persona para continuar.
Contraste es importante y no resume accessibility. El color no debe ser la única señal para distinguir información o indicar acción. Reflow, aumento de texto y espaciado pueden cambiar distribución: conservar información y funcionalidad importa más que una captura perfecta en tamaño predeterminado. No imponer aquí valores de un design system universal.
Motion derivado de interacción puede dificultar uso; considerar preferencias de movimiento reducido y excepciones de funcionalidad esencial. Límites temporales requieren evaluar aviso, ajuste o extensión y las excepciones pertinentes. Seguridad o reglas comerciales pueden limitar opciones; no convertir esa posibilidad en excusa para omitir análisis del recorrido.
WCAG 2.2 incorpora preocupaciones como Target Size (Minimum), alternativas a dragging y Accessible Authentication (Minimum). Sus condiciones y excepciones importan: no reducirlas a un número universal de píxeles o a prohibir toda contraseña. Interacciones predecibles, instrucciones claras y recuperación también reducen barreras cognitivas sin depender solamente del nivel de lectura.
Componer una experiencia, no controles aislados
rendering-strategies cambia dónde/cuándo aparece representación, no su accesibilidad garantizada. SSR, static y CSR pueden producir resultados correctos o incorrectos. Hydration puede modificar DOM, foco y nombres después de un HTML inicial adecuado; evaluar solo la respuesta servidor deja fuera comportamiento que la persona realmente utiliza.
micro-frontends conserva autonomía de entrega, pero Browse, Checkout y Account componen una experiencia. Landmarks, jerarquía de headings, identificadores, foco y anuncios no pueden diseñarse ignorando el resultado conjunto. Varias aplicaciones que se declaran cada una como único contenido principal pueden generar navegación confusa. La frontera del equipo no delimita el perjuicio para el usuario.
Pueden necesitarse convenciones compartidas de navegación, componentes y semántica, sin obligar a una biblioteca central universal. Un design system aporta vocabulario y comportamientos reutilizables; no verifica automáticamente cada composición, extensión o contenido. interfaces permite explicitar qué promete una pieza y qué conserva el integrador, incluyendo cambios compatibles y evidencia de comportamiento.
mobile-architecture añade servicios de accesibilidad, touch, escalado de texto y form factors de plataforma. No asumir que Android/iOS exponen APIs idénticas ni trasladar todo criterio Web directamente a cada widget nativo. web-performance examina demoras, feedback y estabilidad que pueden obstaculizar uso: rápido no significa accesible y quitar semántica por una mejora pequeña no conserva capacidad del usuario.
internationalization exige revisar lenguaje, dirección, etiquetas y mensajes localizados. La versión accesible en inglés puede dejar de serlo con expansión de texto, nombre traducido incoherente o cambio de orden. Ambas preocupaciones se cruzan sin ser una subcategoría de la otra; el recorrido completo necesita conservar significado y operación en sus variantes soportadas.
Evaluación y decisiones desde el diseño
La evaluación WAI combina herramientas y juicio humano. Checks automáticos y lint detectan ciertas clases de fallos; no infieren siempre alternativa textual útil, foco lógico o comprensión de una tarea. Inspeccionar accessibility tree ayuda con exposición semántica, sin demostrar por sí solo comportamiento con cada tecnología. Ningún producto ni porcentaje de checks certifica la experiencia completa.
Revisión manual de teclado, ampliación y flujos reales complementa pruebas browser/tecnología de asistencia pertinentes a la audiencia. Un tester o lector no representa todas las combinaciones. Involucrar personas con discapacidad puede descubrir barreras no previstas y no sustituye evaluación de criterios. testability ayuda a preparar escenarios y evidencia repetible; no obliga a un catálogo infinito de dispositivos.
Estas decisiones pertenecen a requirements, diseño, contenido, interacción, entrega y mantenimiento. Un sistema de widgets propio, navegación global o modal layer puede fijar restricciones caras de reparar. architectural-drivers y quality-attribute-scenarios permiten explicar qué persona intenta qué tarea y bajo qué condiciones debe conseguirlo. No basta agregar una revisión al final del release ni asignar todo a un especialista.
La deuda puede crecer cuando un componente defectuoso se replica o cuando cambios posteriores rompen garantías antes verificadas. technical-debt ayuda a discutir remediación y consecuencias, sin inventar otra escala de madurez. Definir responsables de componentes, integración y contenido conserva capacidad de actuar sobre defectos; compartir responsabilidad no significa dejarla sin dueño.
Una aceptación útil puede describir completar checkout con teclado, reconocer un error y corregirlo sin perder datos relevantes. Necesita alcance, condiciones y evidencia, además del nombre del criterio asociado cuando corresponda. Cambiar contenido, traducción o versión de un componente puede invalidar evidencia anterior aunque el flujo comercial siga pasando tests. Mantener esa relación entre cambio y reevaluación evita convertir un informe puntual en garantía permanente.
Commerce: preservar contexto y posibilidad de completar
En este ejemplo Atlas, Catalog → Product → Cart → Checkout debe sostener estructura de headings/landmarks y alternativas de imagen pertinentes. «Agregar al cart» necesita un nombre comprensible asociado al producto; una colección de botones visualmente iguales puede resultar ambigua fuera de su contexto. No se afirma conformidad del ejemplo ni del sitio Atlas.
Al modificar cantidad, conservar foco utilizable y actualizar cantidad, precio y estado semántico. Decidir qué confirmación merece anuncio, sin leer cada cambio transitorio. Si el servidor rechaza disponibilidad, distinguir rechazo de una espera pendiente y ofrecer recuperación coherente. Una transición de estado técnicamente válida sigue siendo insuficiente si la persona no puede reconocerla ni continuar.
En Checkout, error de tarjeta requiere texto entendible, asociación y acceso para corregirlo; el borde rojo solo no comunica todo. Cuando un diálogo modifica el recorrido, su cierre necesita continuidad de foco según contexto. Un timeout de sesión puede exigir aviso o extensión donde corresponda, sin anunciar pago fallido cuando Payments solo dejó resultado incierto.
Browse, Checkout y Account pueden pasar pruebas aisladas y fallar al componerse por landmarks repetidos, widgets inconsistentes o anuncios competidores. Revisar el flujo integrado y variantes localizadas. La síntesis Atlas es conservar capacidad de completar tareas en cada cambio: semántica, interacción, contenido y evidencia cuentan conjuntamente. frontend-and-client-architecture conecta las decisiones vecinas sin reemplazar los estándares citados.