---
schema_version: "1"
id: 8486227e7e13e76899539041fd076d7c85aa7149f195608c6754163b8008664c
title: Accesibilidad y diseño inclusivo - Patrones
collection: architect
version: current
locale: es-mx
portal_url: https://docs.salesforce.com/architect/current/es-mx/well-architected/guides/fairness-accessibility-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/es-mx/well-architected/guide/fairness-accessibility-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 262d51de29d1e6781255b46013a7b5b69224524a7162254d921f14968cab7eec
products:
  - Marco bien estructurado
  - Architect Site Content Repo
---
# Accesibilidad y diseño inclusivo - Patrones

<br>

Obtenga más información acerca de [la equidad](/docs/architect/es-mx/well-architected/guide/fairness.html) bien arquitectónica → [Accesibilidad con Lightning y Experience Cloud](/docs/architect/es-mx/well-architected/guide/fairness.html#accessibility-with-lightning-and-experience-cloud)

## Cumplimiento de WCAG 2.2 AA

**Patrones**

| Dónde buscar | Qué 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 títulos acompañan a videos   |
| 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 como están diseñados, 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 están incluidas en todas las fases de prueba (no ad hoc u opcionales)                                                               |

**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 videos carecen de tí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)              |

## Arquitectura de lector de pantalla

**Patrones**

| Dónde buscar | Qué 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                            | ✅ Las marcas, 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 se asocian explícitamente con todas las entradas de formulario utilizando elementos de etiqueta apropiados o atributos aria-labelledby                         |
| Plataforma \| LWC                            | ✅ Los componentes de entrada Lightning están configurados con atributos de etiqueta requeridos proporcionando 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 lectores de pantalla |

**Antipatrones**

| Dónde buscar | Aspecto negativo |
| --- | --- |
| Plataforma \| LWC                            | ⚠️ Tiras de marcado con gran número de divisiones que significan desde 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 del lector 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 de posición se utiliza como etiqueta única                     |
| Plataforma \| Planes de prueba                     | ⚠️ Las herramientas de accesibilidad automatizadas se utilizan exclusivamente; no se realizan pruebas manuales con lectores 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         |

## Navegación por el teclado

**Patrones**

| Dónde buscar | Qué aspecto tiene |
| --- | --- |
| Plataforma \| Estándares de diseño               | ✅ La funcionalidad completa es accesible a través del teclado sin requerir interacción del ratón o táctil en ningún punto en las trayectorias de los usuarios                       |
| 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 cuadros modales, el enfoque se gestiona programáticamente para guiar a los usuarios del teclado a nuevo contenido                                |
| Plataforma \| LWC                            | ✅ Los componentes de cuadro modal y emergente mueven el enfoque al título del cuadro modal o al primer elemento interactivo al abrir; devuelven el enfoque al botón 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 modales atrapan el enfoque dentro del modal mientras están abiertos (evitando el acceso a contenido oculto) pero el enfoque de la versión se centra 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 navegación solo con teclado por todas las trayectorias de usuarios sin utilizar el ratón o el tacto                                                 |

**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 atraviesa 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 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 permanentemente 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 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                                     |

## Contraste y diseño visual

**Patrones**

| Dónde buscar | Qué 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 o 14 puntos en negrita                                                                |
| Plataforma \| Estándares de diseño               | ✅ Relación de contraste mínima de 3:1 para texto de gran tamaño y para gráficos y componentes significativos de la interfaz de usuario (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 cambio de tamaño de 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 con visión reducida no pueden leer contenido |
| Plataforma \| Estándares de diseño               | ⚠️ El cambio de tamaño de texto más allá del 200% rompe formatos perdiendo contenido o funciones                       |

## Pruebas y validación de accesibilidad

**Patrones**

| Dónde buscar | Qué 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 de 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 \| Negocios                       | ✅ Los usuarios con discapacidades se incluyen en pruebas de capacidad de uso durante todo el proceso de diseño                                                   |
| Plataforma \| Negocios                       | ✅ Las pruebas de capacidad de uso revelan barreras prácticas que las pruebas expertas automatizadas y manuales pierden                                            |
| 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 oportunidades en curso de CI/CD                                          |
| Plataforma \| CI/CD                          | ⚠️ Las construcciones continúan a pesar de problemas de accesibilidad críticos                                                   |
| Plataforma \| Planes de prueba                     | ⚠️ No se realizan pruebas manuales con tecnología de asistencia; solo se utiliza la exploración automatizada             |
| Plataforma \| Negocios                       | ⚠️ 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 |