Accesibilidad y diseño inclusivo - Patrones
Obtenga más información acerca de la equidad bien arquitectónica → Accesibilidad con Lightning y Experience Cloud
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Estándares de diseño | ✅ WCAG 2.2 Nivel AA es la barra de accesibilidad mínima para trabajo personalizado (Experience Cloud, LWC, temas personalizados), verificada por el equipo de construcción |
| Plataforma | Estándares de diseño | ✅ Principio perceptible: Existen alternativas de texto para imágenes e iconos; los subtítulos acompañan a los vídeos |
| Plataforma | Estándares de diseño | ✅ Principio operativo: Todas las funciones son operables solo a través del teclado, sin requerir ratón o toque: las tecnologías de asistencia de control por voz y acceso de conmutación se basan en el mismo modelo de teclado/enfoque |
| Plataforma | LWC | ✅ Los componentes web Lightning estándar se utilizan según lo diseñado, proporcionando accesibilidad de línea base automáticamente |
| Plataforma | LWC | ✅ Los componentes personalizados implementan accesibilidad explícita validada a través de pruebas con lectores de pantalla |
| Plataforma | Planes de prueba | ✅ Las pruebas de accesibilidad se incluyen en todas las fases de prueba (no ad hoc u opcional) |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Estándares de diseño | ⚠️ WCAG 2.2 Nivel AA se trata como opcional o “agradable de tener” en vez de requisito mínimo |
| Plataforma | Estándares de diseño | ⚠️ Las imágenes y los iconos carecen de alternativas de texto; los vídeos carecen de subtítulos |
| Plataforma | Estándares de diseño | ⚠️ La funcionalidad requiere interacción del ratón o táctil sin alternativa de teclado |
| Plataforma | LWC | ⚠️ Los componentes personalizados se crean sin implementación o validación de accesibilidad |
| Plataforma | LWC | ⚠️ Los componentes de entrada personalizados utilizan elementos div y estilo CSS sin significado semántico o accesibilidad de teclado |
| Plataforma | Planes de prueba | ⚠️ Las pruebas de accesibilidad son ad hoc, opcionales o solo se realizan antes del inicio (no durante todo el desarrollo) |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | LWC | ✅ Los elementos HTML semánticos (encabezado, navegación, principal, aparte, pie de página, artículo, sección) se utilizan en componentes web Lightning personalizados |
| Plataforma | LWC | ✅ Los puntos de referencia, funciones y propiedades de ARIA se aplican donde HTML semántico por sí solo no puede transmitir el comportamiento de la interfaz |
| Plataforma | LWC | ✅ Las actualizaciones de contenido dinámico utilizan regiones en vivo de aria anunciando cambios a usuarios lectores de pantalla |
| Plataforma | LWC | ✅ Los componentes interactivos personalizados tienen definiciones de funciones explícitas que coinciden con su comportamiento |
| Plataforma | LWC | ✅ Las etiquetas de formulario están explícitamente asociadas con todas las entradas de formulario utilizando elementos de etiqueta apropiados o atributos aria-labeledby |
| Plataforma | LWC | ✅ Los componentes de entrada Lightning están configurados con atributos de etiqueta requeridos que proporcionan asociación de etiquetas integrada |
| Plataforma | Planes de prueba | ✅ Las pruebas se realizan con lectores de pantalla reales: JAWS y NVDA en Windows, VoiceOver en macOS e iOS, TalkBack en Android |
| Plataforma | Planes de prueba | ✅ Las pruebas manuales con tecnología de asistencia real se realizan por personas que comprenden cómo navegan los usuarios de lectores de pantalla |
| Plataforma | Estándares de diseño | ✅ El texto del marcador de posición nunca se utiliza como la única etiqueta porque los marcadores de posición desaparecen en el enfoque y proporcionan contexto insuficiente para los lectores de pantalla |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | LWC | ⚠️ Significado de tiras de marcado con alto contenido de la jerarquía de contenido forzando a los usuarios lectores de pantalla a navegar linealmente |
| Plataforma | LWC | ⚠️ ARIA no se utiliza donde HTML semántico por sí solo no puede transmitir el comportamiento de la interfaz |
| Plataforma | LWC | ⚠️ Las actualizaciones de contenido dinámico no utilizan regiones en vivo de aria; los usuarios de lectores de pantalla pierden cambios importantes |
| Plataforma | LWC | ⚠️ Los componentes interactivos personalizados carecen de definiciones de funciones explícitas; los lectores de pantalla las anuncian incorrectamente |
| Plataforma | LWC | ⚠️ Las entradas de formulario carecen de asociación de etiquetas explícita; el texto del marcador se utiliza como etiqueta única |
| Plataforma | Planes de prueba | ⚠️ Las herramientas de accesibilidad automatizada se utilizan exclusivamente; no se realizan pruebas manuales del lector de pantalla |
| Plataforma | Planes de prueba | ⚠️ Las pruebas se realizan por usuarios videntes que no están familiarizados con cómo navegan los usuarios del lector de pantalla en realidad |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Estándares de diseño | ✅ La funcionalidad completa es accesible a través del teclado sin requerir la interacción del ratón o táctil en ningún punto de las trayectorias del usuario |
| Plataforma | LWC | ✅ El orden de enfoque lógico sigue el formato visual y el flujo de interacción |
| Plataforma | LWC | ✅ Cuando se carga contenido dinámico o se abren los modales, el enfoque se gestiona programáticamente para guiar a los usuarios del teclado a nuevo contenido |
| Plataforma | LWC | ✅ Los componentes de modal y emergente mueven el enfoque al título de modal o primer elemento interactivo al abrir; devuelven el enfoque al botón de desencadenador al cerrar |
| Plataforma | Estándares de diseño | ✅ Los indicadores de enfoque visibles muestran claramente qué elemento tiene enfoque de teclado en todo momento |
| Plataforma | Estándares de diseño | ✅ Los indicadores de enfoque cumplen el requisito de contraste 3:1 frente al contenido circundante |
| Plataforma | LWC | ✅ Los usuarios pueden navegar dentro y fuera de todos los componentes utilizando solo el teclado sin quedar atrapados |
| Plataforma | LWC | ✅ Los diálogos de modal atrapan el enfoque dentro del modal mientras están abiertos (evitando el acceso a contenido oculto) pero liberan el enfoque en cerrar |
| Plataforma | Estándares de diseño | ✅ Los accesos directos del teclado para acciones frecuentes evitan conflictos con accesos directos del lector de pantalla y accesos directos del navegador |
| Plataforma | Estándares de diseño | ✅ Los accesos directos de una sola letra solo se activan cuando componentes específicos tienen enfoque (no globalmente) para evitar conflictos con comandos de navegación del lector de pantalla |
| Plataforma | Documentación | ✅ Todos los accesos directos de teclado personalizados están documentados en contenido de ayuda accesible |
| Plataforma | Planes de prueba | ✅ Los pasos de prueba incluyen la navegación solo con teclado por todas las trayectorias de usuarios sin utilizar el ratón o el toque |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Estándares de diseño | ⚠️ La funcionalidad requiere interacción del ratón o táctil; los usuarios solo con teclado no pueden completar tareas clave |
| Plataforma | LWC | ⚠️ El orden de enfoque no sigue el formato visual lógico; la ficha de usuarios a través de elementos en secuencia inesperada |
| Plataforma | LWC | ⚠️ Modals abiertos sin gestión de enfoque; los usuarios del teclado están varados en botón de desencadenador ahora oculto |
| Plataforma | LWC | ⚠️ El cierre de modal no devuelve el enfoque al botón de desencadenador; los usuarios deben buscar su lugar en la página |
| Plataforma | Estándares de diseño | ⚠️ Los indicadores de enfoque se suprimen por motivos estéticos; los usuarios no pueden ver qué elemento tiene enfoque |
| Plataforma | Estándares de diseño | ⚠️ Los indicadores de enfoque tienen un contraste insuficiente (<3:1) |
| Plataforma | LWC | ⚠️ Los usuarios quedan atrapados en regiones de interfaz sin mecanismo de escape (trampas de teclado) |
| Plataforma | LWC | ⚠️ El contenido integrado (iframes, widgets externos) captura de forma permanente el enfoque del teclado |
| Plataforma | Estándares de diseño | ⚠️ Los accesos directos de una sola letra se activan de forma global en conflicto con los comandos de navegación de una sola letra del lector de pantalla |
| Plataforma | Documentación | ⚠️ Los accesos directos de teclado personalizados no están documentados; los usuarios no pueden descubrirlos |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | Estándares de diseño | ✅ Relación de contraste mínima de 4,5:1 para texto normal de menos de 18 puntos o 14 puntos en negrita |
| Plataforma | Estándares de diseño | ✅ Relación de contraste mínima de 3:1 para texto grande y para componentes y gráficos de la interfaz de usuario significativos (bordes de formulario, iconos informativos); los elementos puramente decorativos y desactivados están exentos |
| Plataforma | Experience Cloud | ✅ Los temas personalizados y los sitios de Experience Cloud con marca incluyen validación de contraste explícita utilizando herramientas de desarrollo de navegador o comprobadores automatizados |
| Plataforma | Estándares de diseño | ✅ El tamaño del texto al 200% es compatible sin pérdida de contenido o funcionalidad (requisito WCAG) |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | Estándares de diseño | ⚠️ Los índices de contraste de texto caen por debajo de 4,5:1 (texto normal) o 3:1 (componentes de texto grande e interfaz de usuario) |
| Plataforma | Experience Cloud | ⚠️ Los temas personalizados se implementan sin validación de contraste; los usuarios de baja visión no pueden leer contenido |
| Plataforma | Estándares de diseño | ⚠️ El tamaño del texto más allá del 200% rompe formatos perdiendo contenido o funcionalidad |
Patrones
| Dónde buscar | Qué buen aspecto tiene |
|---|---|
| Plataforma | CI/CD | ✅ La exploración de accesibilidad de núcleo de eje o Lighthouse está integrada en oportunidades en curso de CI/CD que detectan problemas estructurales en cada implementación |
| Plataforma | CI/CD | ✅ Las compilaciones fallan cuando se detectan problemas de accesibilidad críticos |
| Plataforma | Planes de prueba | ✅ Las pruebas manuales con lectores de pantalla, navegación solo con teclado y zoom del navegador al 200% se realizan regularmente durante todo el desarrollo |
| Plataforma | Planes de prueba | ✅ Las pruebas revelan problemas de interacción incluyendo pedidos de anuncios confusos, fallos de gestión de enfoque y trampas de teclado |
| Plataforma | Negocio | ✅ Los usuarios con discapacidades se incluyen en pruebas de capacidad de uso durante todo el proceso de diseño |
| Plataforma | Negocio | ✅ Las pruebas de capacidad de uso revelan barreras prácticas que las pruebas expertas automatizadas y manuales no superan |
| Plataforma | Planes de prueba | ✅ Se realizan pruebas automatizadas (~57% de los problemas por volumen), pruebas manuales (problemas de interacción) y pruebas de usuario (barreras del mundo real) |
Antipatrones
| Dónde buscar | Aspecto negativo |
|---|---|
| Plataforma | CI/CD | ⚠️ La exploración de accesibilidad no está integrada en las oportunidades en curso de CI/CD |
| Plataforma | CI/CD | ⚠️ Las construcciones continúan a pesar de problemas críticos de accesibilidad |
| Plataforma | Planes de prueba | ⚠️ No se realizan pruebas manuales con tecnología de asistencia; solo se utiliza el escaneo automatizado |
| Plataforma | Negocio | ⚠️ Los usuarios con discapacidades no están incluidos en pruebas de capacidad de uso |
| Plataforma | Planes de prueba | ⚠️ El escáner de accesibilidad automatizado se ejecuta una vez antes del inicio y las pruebas de accesibilidad se consideran realizadas |