Objetivo: Proporcionar alternativas de texto para todo el contenido no textual para que pueda transformarse en otras formas que las personas puedan leer, incluyendo letra grande, braille, voz, símbolos o lenguaje más simple.

Por qué es importante (Beneficio para el usuario):

• Permite a las personas ciegas o con baja visión comprender el contenido de imágenes y elementos gráficos a través de lectores de pantalla.
• Permite a los usuarios con discapacidades cognitivas procesar la información en un formato de texto más simple y adaptable.
• Mejora el SEO (Optimización para Motores de Búsqueda) y la indexación de imágenes por parte de los motores de búsqueda.

Qué verificar / Cómo implementar:

• **Imágenes informativas:** Para cada imagen que transmita un significado, el atributo `alt` debe contener una descripción concisa y significativa de su contenido o función.

  <img src="grafico.png" alt="Gráfico de ventas trimestrales con un aumento del 15% en el cuarto trimestre">

• **Imágenes decorativas:** Si una imagen es puramente estética y no añade información (ej: bordes, fondos), el atributo `alt` debe dejarse vacío (`alt=""`).

  <img src="sfondo.jpg" alt="">

• **Iconos/Botones de imagen:** Si un icono es clickable, el atributo `alt` (o `aria-label`) debe describir la acción del botón, no solo la imagen (ej: `alt="Buscar"` para una lupa).
• **Gráficos/Diagramas complejos:** Además del texto alternativo, proporcionar una "descripción larga" (ej: a través de `aria-describedby` o un enlace a una página separada) que explique el contenido informativo en detalle.
• **Contenido de audio/video:** Ofrecer transcripciones completas (para audio) y/o descripciones detalladas (para videos mudos o solo visuales).

Errores comunes a evitar:

• Omitir completamente el atributo `alt`.
• Usar texto `alt` genérico o redundante (ej: `alt="imagen"`, `alt="foto.jpg"`, `alt="haga clic aquí"`).
• Texto `alt` demasiado largo o que incluye detalles innecesarios para el contexto.
• No proporcionar transcripciones o descripciones para contenido multimedia importante.

Herramientas útiles para las pruebas:

• **Extensiones del navegador:** Axe DevTools, Lighthouse, WAVE, Web Developer (para ver el texto alt).
• **Lector de pantalla:** Navegar por la página con un lector de pantalla (ej: NVDA, JAWS, VoiceOver) para escuchar cómo se leen las alternativas de texto.
• **Desactivar imágenes:** En la configuración del navegador, desactivar la carga de imágenes para ver el texto alternativo en su lugar.

Objetivo: Proporcionar una alternativa para el contenido pregrabado de solo audio o solo video para que toda la información transmitida sea accesible para aquellos que no pueden percibirla.

Por qué es importante (Beneficio para el usuario):

• Los usuarios sordos o con problemas de audición graves pueden acceder al contenido de audio a través de una transcripción de texto.
• Los usuarios ciegos o con baja visión pueden acceder al contenido visual a través de una descripción de texto.
• Permite la consulta en entornos donde el audio/video no es utilizable (ej: lugares públicos, conexiones lentas).

Qué verificar / Cómo implementar:

• **Contenido de solo audio:** Ofrecer una transcripción de texto completa del diálogo y de todos los sonidos significativos (ej: música, efectos de sonido importantes) presentes en el audio. La transcripción debe ser fácilmente accesible y asociada con el audio (ej: debajo del reproductor o a través de un enlace).
• **Contenido de solo video:** Proporcionar una descripción de texto detallada de todos los eventos visuales e información significativos presentados en el video (ej: acciones, objetos, texto en pantalla).

Errores comunes a evitar:

• No proporcionar ninguna alternativa de texto para audio o video.
• Transcripciones incompletas o que omiten sonidos importantes.
• Descripciones de video genéricas que no capturan el significado visual.

Herramientas útiles para las pruebas:

• **Revisión manual:** Comparar cuidadosamente el audio/video con la transcripción/descripción para verificar la integridad y precisión.
• **Participación del usuario:** Hacer que personas con discapacidades visuales o auditivas lo prueben.

Objetivo: Proporcionar subtítulos sincronizados para todo el contenido de audio pregrabado en videos, incluyendo diálogos y sonidos no verbales significativos.

Por qué es importante (Beneficio para el usuario):

• Permite a las personas sordas o con problemas de audición acceder al contenido de audio de los videos.
• Útil en entornos ruidosos o donde no se puede escuchar el audio.
• Facilita la comprensión para hablantes no nativos o personas con dificultades cognitivas.

Qué verificar / Cómo implementar:

• **Subtítulos sincronizados:** Asegurarse de que los subtítulos estén disponibles y perfectamente sincronizados con el audio y el video.
• **Contenido completo:** Los subtítulos deben incluir todo el diálogo hablado y, cuando sea significativo, los sonidos no verbales (ej: `[música dramática]`, `[aplausos]`).
• **Formato apropiado:** Usar formatos de subtítulos compatibles (ej: WebVTT, SRT) y asegurar que el reproductor de video permita la activación/desactivación y personalización (si es posible).

Errores comunes a evitar:

• Falta total de subtítulos.
• Subtítulos inexactos, incompletos o con errores de transcripción.
• Sincronización incorrecta (subtítulos que aparecen demasiado pronto o demasiado tarde).
• Omisión de sonidos no verbales importantes.

Herramientas útiles para las pruebas:

• **Prueba manual:** Ver el video con el audio apagado y verificar la comprensión a través de los subtítulos.
• **Lector de pantalla:** Verificar que el reproductor sea accesible y que los subtítulos no interfieran.

Objetivo: Para videos pregrabados con una pista de audio, proporcionar una descripción de audio que narre el contenido visual esencial para usuarios ciegos, o una alternativa de texto completa.

Por qué es importante (Beneficio para el usuario):

• Permite a las personas ciegas o con baja visión comprender la información visual no explicada en el diálogo de audio.
• Ofrece una experiencia de contenido multimedia completa a todos los usuarios.

Qué verificar / Cómo implementar:

• **Descripción de audio:** Integrar una pista de audio adicional que describa escenas visuales, acciones, texto en pantalla y otros detalles visuales relevantes no presentes ya en el diálogo principal.
• **Alternativa de texto multimedia:** Alternativamente, proporcionar una transcripción de texto completa que incluya tanto el diálogo como una descripción detallada del contenido visual.

Errores comunes a evitar:

• Falta de descripción de audio para videos que la requieren.
• Descripción de audio incompleta o demasiado corta.

Herramientas útiles para las pruebas:

• **Prueba manual:** Ver el video con los ojos cerrados y verificar si la descripción de audio le permite comprender toda la información visual importante.

Objetivo: Proporcionar subtítulos sincronizados para todo el contenido de audio en vivo en videos.

Por qué es importante (Beneficio para el usuario):

• Esencial para que las personas sordas o con problemas de audición graves accedan a eventos en vivo.
• Permite la participación en tiempo real en seminarios web, transmisiones en vivo, conferencias.

Qué verificar / Cómo implementar:

• **Subtítulos en tiempo real:** Implementar una solución para la generación de subtítulos en tiempo real (ej: a través de transcriptores humanos, tecnologías de reconocimiento de voz con revisión).
• **Precisión y sincronización:** Asegurarse de que los subtítulos sean lo más precisos y sincronizados posible, teniendo en cuenta los desafíos del contenido en vivo.

Errores comunes a evitar:

• Falta de subtítulos para contenido en vivo.
• Subtítulos generados automáticamente con un alto porcentaje de errores.

Herramientas útiles para las pruebas:

• **Prueba manual:** Monitorear la calidad y puntualidad de los subtítulos durante un evento en vivo.

Objetivo: Proporcionar una descripción de audio para todo el contenido de video pregrabado. Este criterio es un requisito más estricto que el 1.2.3, solicitando una descripción de audio para todos los videos, incluso si ya existe una pista de audio principal.

Por qué es importante (Beneficio para el usuario):

• Asegura que las personas ciegas reciban toda la información visual importante.

Qué verificar / Cómo implementar:

• **Inclusión de descripción de audio:** Asegurarse de que todos los videos pregrabados tengan una pista de descripción de audio, aunque sea breve, que narre el contenido visual significativo.

Errores comunes a evitar:

• Falta de descripción de audio.

Herramientas útiles para las pruebas:

• **Prueba manual:** Escuchar el video con la descripción de audio activada para evaluar su integridad.

Objetivo: Asegurar que la estructura, las relaciones y el significado del contenido sean comprensibles no solo visualmente, sino también programáticamente (a través del código). Esto permite a las tecnologías de asistencia interpretar correctamente la jerarquía y el rol de los elementos de la página.

Por qué es importante (Beneficio para el usuario):

• **Navegación mejorada:** Permite a los usuarios de lectores de pantalla navegar por la página de manera eficiente (ej: saltando de encabezado en encabezado o explorando listas).
• **Comprensión contextual:** Ayuda a todos los usuarios a comprender la relación entre los diferentes elementos de la página (ej: etiquetas vs. campos de formulario, celdas vs. encabezados de tabla).
• **Consistencia y personalización:** Asegura que el contenido se presente de manera consistente y significativa, facilitando también la personalización por parte del usuario.

Qué verificar / Cómo implementar:

• **Jerarquía de encabezados (<h1> - <h6>):**
  • Usar etiquetas de encabezado para una estructura lógica (solo un <h1> por página).
  • No omitir niveles de encabezado (ej: de <h1> a <h3>).
• **Listas (<ul>, <ol>, <dl>):**
  • Usar elementos semánticos para todas las listas.
  • Evitar simular listas con simples divs o párrafos.
• **Formularios:**
  • Siempre asociar <label> con cada control de entrada usando `for` e `id`.
  • Agrupar controles relacionados (ej: botones de radio) con <fieldset> y <legend>.
• **Tablas de datos (<table>, <th>, <caption>):**
  • Usar tablas solo para datos tabulares, nunca para diseño.
  • Identificar encabezados (<th> con `scope`) y proporcionar un <caption>.
• **Roles ARIA (Aplicaciones de Internet Ricas Accesibles):**
  • Usar atributos ARIA para definir roles, propiedades y estados de componentes de interfaz de usuario complejos o personalizados.

Errores comunes a evitar:

• **Jerarquía visual engañosa:** Usar solo estilos visuales (negrita, tamaño de fuente) para encabezados sin usar etiquetas <h1>-<h6>.
• **Etiquetas faltantes o no asociadas:** Campos de formulario sin <label> o con `label` no correctamente vinculado.
• **Tablas usadas para diseño:** Mal uso del elemento <table> para posicionamiento visual.
• **Estructura no semántica:** Crear listas u otros elementos estructurales usando solo <div> o <p> sin los elementos semánticos correctos.

Herramientas útiles para las pruebas:

• **Extensiones de navegador de accesibilidad:** Axe DevTools, Lighthouse, WAVE Evaluation Tool.
• **Lector de pantalla:** NVDA, JAWS (Windows), VoiceOver (macOS).
• **Validador HTML:** Servicio de validación de marcado W3C.

Objetivo: Asegurar que cuando la secuencia del contenido (presentación visual) afecta su significado, el orden de lectura e interacción programático también sea significativo y lógico. Esto es crucial para los usuarios que acceden al contenido en un orden diferente al visual (ej: con lectores de pantalla).

Por qué es importante (Beneficio para el usuario):

• **Consistencia lógica:** Asegura que el contenido tenga sentido, independientemente de cómo se perciba (visualmente, a través de un lector de pantalla, navegación con teclado).
• **Navegación eficiente:** Ayuda a los usuarios de tecnología de asistencia a seguir el flujo lógico del documento sin confusión ni saltos inesperados.
• **Experiencia de usuario mejorada:** Previene la frustración y la desorientación para todos los usuarios, especialmente en diseños complejos.

Qué verificar / Cómo implementar:

• **Orden de lectura lógico:** La secuencia DOM (Modelo de Objeto de Documento) debe reflejar el orden lógico del contenido previsto por el autor. Lo que aparece primero visualmente generalmente debe ir primero en el código.
• **Contenido relacionado:** Si el contenido está relacionado (ej: una pregunta y sus opciones de respuesta), asegurarse de que estén cerca en el código HTML para mantener su relación.
• **Diseño CSS:** Evitar el uso de CSS para reordenar elementos de tal manera que el orden visual sea drásticamente diferente del orden DOM, especialmente para elementos interactivos o informativos. Si lo hace, verificar cuidadosamente la accesibilidad.
• **Prueba de contenido linealizado:** Imaginar leer la página sin CSS; ¿el contenido sigue teniendo sentido? ¿El desplazamiento con el teclado (tabulación) sigue una ruta lógica?

Errores comunes a evitar:

• **Discrepancia orden visual/DOM:** El orden de los elementos en el código HTML no coincide con el orden lógico o visual, lo que causa confusión para los lectores de pantalla.
• **Contenido disperso:** La información relacionada (ej: una advertencia y el botón para cerrarla) está posicionada muy separada en el código HTML.
• **Reordenamiento extremo a través de CSS/JavaScript:** Mal uso de propiedades CSS como `order` en flexbox/grid o manipulaciones de JavaScript que alteran en gran medida el orden visual en relación con el DOM, sin considerar el orden de tabulación o el orden de lectura.

Herramientas útiles para las pruebas:

• **Navegación con teclado:** Navegar por toda la página usando solo la tecla Tab (y Shift+Tab para volver) para verificar que el foco se mueva en un orden lógico y significativo.
• **Lector de pantalla:** Escuchar el contenido con un lector de pantalla (ej: NVDA, JAWS, VoiceOver) para asegurar que la secuencia de lectura sea la esperada y comprensible.
• **Inspección del código:** Examinar el orden de los elementos en el DOM (usando las herramientas de desarrollo del navegador) y compararlo con el orden visual.

Objetivo: Las instrucciones proporcionadas para comprender y operar el contenido no deben depender únicamente de las características sensoriales de los componentes (forma, tamaño, color, ubicación, orientación o sonido).

Por qué es importante (Beneficio para el usuario):

• Permite a personas con ceguera, daltonismo o discapacidades cognitivas comprender las instrucciones incluso si no perciben ciertas características sensoriales.
• Asegura que las direcciones sean claras y sin ambigüedades para todos.

Qué verificar / Cómo implementar:

• **Instrucciones redundantes:** Si usa color para indicar el estado (ej: rojo para error), siempre agregue un indicador de texto o un icono (ej: "Campo obligatorio faltante" o un icono de advertencia).
• **Formas/Tamaños:** Si las instrucciones se refieren a formas o tamaños ("Haga clic en el botón redondo"), agregue una alternativa de texto ("Haga clic en el botón 'Enviar pedido'").
• **Posición/Orientación:** Evite instrucciones como "Haga clic en el icono de la derecha" o "Mire el menú de arriba" sin proporcionar una alternativa de texto específica para el elemento.

Errores comunes a evitar:

• Decir "haga clic en el botón rojo" sin proporcionar el texto del botón.
• Indicar campos obligatorios solo con un asterisco rojo, sin una frase como "(obligatorio)".

Herramientas útiles para las pruebas:

• **Prueba manual:** Intentar comprender las instrucciones sin mirar colores o formas.
• **Simulación de daltonismo:** Usar extensiones del navegador para simular diferentes formas de daltonismo y verificar la claridad de la información.

Objetivo: El color no debe ser el único medio visual para transmitir información, indicar una acción, solicitar una respuesta o distinguir un elemento visual.

Por qué es importante (Beneficio para el usuario):

• Las personas daltónicas o con problemas de percepción del color pueden comprender toda la información.
• Mejora la claridad y usabilidad para todos los usuarios, incluso en condiciones de poca luz o en pantallas de baja calidad.

Qué verificar / Cómo implementar:

• **Redundancia:** Si la información se transmite a través del color, debe haber otro indicador (ej: texto, icono, subrayado para enlaces). * *Ejemplo:* En lugar de "Los campos rojos son obligatorios", use "Los campos rojos con un asterisco (*) son obligatorios".
• **Enlaces:** Los enlaces deben tener un indicador adicional además del color cuando no estén en el cuerpo del texto (ej: subrayado o un icono al pasar el ratón/enfocarse).
• **Gráficos:** En los gráficos, además de los colores, use patrones, etiquetas de texto o iconos para distinguir diferentes series de datos.

Errores comunes a evitar:

• Indicar un error solo coloreando de rojo el texto del mensaje o el campo.
• Usar el color para mostrar el estado (ej: elemento seleccionado) sin otro indicador visual.

Herramientas útiles para las pruebas:

• **Extensiones de simulación de daltonismo:** Colorblinding, NoCoffee.
• **Prueba manual:** Convertir la página a escala de grises para ver si toda la información sigue siendo clara.

Objetivo: Si algún audio en una página web se reproduce automáticamente durante más de 3 segundos, debe haber un mecanismo disponible para pausar, detener o controlar el volumen independientemente del volumen general del sistema.

Por qué es importante (Beneficio para el usuario):

• Los usuarios que utilizan lectores de pantalla u otras ayudas auditivas pueden encontrar el audio inesperado distractor o que cubra el audio de su ayuda.
• Mejora la usabilidad general, evitando sonidos repentinos que pueden asustar o molestar a los usuarios.

Qué verificar / Cómo implementar:

• **Controles visibles:** Asegurarse de que haya botones claros y visibles (Pausa, Detener, Silenciar) para el audio que se reproduce automáticamente.
• **Sin reproducción automática:** La mejor práctica es evitar por completo la reproducción automática de audio. Deje que el usuario decida cuándo iniciar el audio.

Errores comunes a evitar:

• Audio que comienza automáticamente y no se puede detener o silenciar.

Herramientas útiles para las pruebas:

• **Prueba manual:** Visitar la página y verificar inmediatamente si el audio comienza y si puede controlarlo fácilmente.

Objetivo: Asegurar una relación de contraste suficiente entre el texto (y el texto en imágenes) y su fondo, para garantizar la legibilidad para personas con discapacidad visual o daltonismo.

Por qué es importante (Beneficio para el usuario):

• Aumenta la legibilidad para personas con baja visión o daltonismo.
• Mejora la legibilidad para todos los usuarios en condiciones de iluminación adversas (ej: luz solar intensa) o en pantallas de baja calidad.

Qué verificar / Cómo implementar:

• **Texto normal:** La relación de contraste debe ser de al menos **4.5:1** para texto de tamaño normal.
• **Texto grande:** Para texto grande (al menos 18pt / 24px, o 14pt / 18.66px y negrita), la relación de contraste debe ser de al menos **3:1**.
• **Logotipos y elementos decorativos:** No se aplica a logotipos o texto que forma parte de una imagen puramente decorativa.

Errores comunes a evitar:

• Texto claro sobre un fondo claro o texto oscuro sobre un fondo oscuro con contraste insuficiente.
• Fondos con patrones o imágenes que reducen el contraste del texto.

Herramientas útiles para las pruebas:

• **Analizadores de contraste:** Contrast Checker (en línea), Colour Contrast Analyser (aplicación de escritorio), extensiones del navegador como Axe DevTools o Lighthouse.

Objetivo: Asegurar que el texto se pueda redimensionar hasta un 200% sin pérdida de contenido o funcionalidad, y sin requerir el uso de desplazamiento horizontal.

Por qué es importante (Beneficio para el usuario):

• Esencial para personas con baja visión que necesitan texto más grande para leer.
• Mejora la usabilidad para todos los usuarios en varios dispositivos y tamaños de pantalla.

Qué verificar / Cómo implementar:

• **Zoom del navegador:** Probar la página haciendo zoom en el navegador hasta el 200% (ej: Ctrl + Más o Cmd + Más).
• **Unidades relativas:** Usar unidades relativas para los tamaños de fuente (ej: `em`, `rem`, `%`, `vw`) en lugar de unidades de píxeles fijos (`px`).
• **Diseño adaptable (Responsive Design):** Asegurarse de que el diseño se adapte correctamente y no requiera desplazamiento horizontal.

Errores comunes a evitar:

• Texto superpuesto o que desaparece con un zoom del 200%.
• Que se requiera el desplazamiento horizontal para leer todo el texto.

Herramientas útiles para las pruebas:

• **Zoom del navegador:** Probar directamente con la función de zoom del navegador.

Objetivo: Evitar el uso de imágenes de texto a menos que el texto sea puramente decorativo o forme parte de un logotipo/nombre de marca. Cuando las imágenes de texto sean necesarias, proporcionar una alternativa de texto para todo el contenido presentado visualmente en la imagen.

Por qué es importante (Beneficio para el usuario):

• El texto en las imágenes no se puede redimensionar, personalizar ni leer con lectores de pantalla.
• Mejora el SEO ya que el texto es directamente buscable.

Qué verificar / Cómo implementar:

• **Texto real:** Preferir el texto real con estilos CSS siempre que sea posible.
• **Texto alternativo (Alt Text):** Si el uso de una imagen de texto es inevitable, asegurar un atributo `alt` completo que replique el texto de la imagen.

Errores comunes a evitar:

• Usar imágenes para encabezados, párrafos o instrucciones importantes.

Herramientas útiles para las pruebas:

• **Desactivar imágenes:** Desactivar la visualización de imágenes en el navegador para identificar imágenes de texto.

Objetivo: El contenido debe poder presentarse sin pérdida de información o funcionalidad, y sin requerir desplazamiento bidimensional, cuando se redimensiona al 400% de ancho o alto sin aumentar la longitud de línea (diseño adaptable).

Por qué es importante (Beneficio para el usuario):

• Crucial para usuarios con baja visión que amplían el contenido significativamente.
• Mejora la usabilidad en pantallas pequeñas o al usar lupas de pantalla.

Qué verificar / Cómo implementar:

• **Zoom 400%:** Probar la página haciendo zoom hasta el 400% (generalmente equivalente a un ancho de viewport de 320 píxeles CSS para un navegador de escritorio).
• **Sin desplazamiento horizontal:** Asegurarse de que no aparezca ninguna barra de desplazamiento horizontal con un zoom del 400%. Se permite el desplazamiento vertical.
• **Diseño adaptable (Responsive Layout):** Implementar un diseño fluido y adaptable que se ajuste correctamente a varios tamaños de pantalla y niveles de zoom.
• **Ajuste de contenido:** El texto y los bloques de contenido deben ajustarse para adaptarse al ancho disponible.

Errores comunes a evitar:

• Diseños de ancho fijo que se rompen o requieren desplazamiento horizontal al hacer zoom.
• Contenido que se desborda de los contenedores o se superpone a niveles de zoom altos.

Herramientas útiles para las pruebas:

• **Zoom del navegador:** Usar la función de zoom nativa del navegador.
• **Herramientas de desarrollo:** Usar las herramientas de desarrollo del navegador para simular diferentes viewports (ej: establecer el ancho del viewport a 320px).

Objetivo: Asegurar que la presentación visual de los componentes de la interfaz de usuario (ej: botones, campos de entrada, casillas de verificación, deslizadores) y los objetos gráficos (ej: partes de diagramas o infografías) tengan una relación de contraste de al menos 3:1 con respecto a los colores adyacentes.

Por qué es importante (Beneficio para el usuario):

• Ayuda a los usuarios con baja visión o daltonismo a percibir y comprender los elementos interactivos y gráficos esenciales.
• Mejora la detectabilidad y la usabilidad de los controles.

Qué verificar / Cómo implementar:

• **Componentes interactivos:**
  • **Estado predeterminado:** Asegurar un contraste de 3:1 para los bordes o indicadores visuales de los componentes interactivos (ej: un borde de botón gris sobre un fondo blanco).
  • **Estado de enfoque/hover:** Cuando un elemento se pasa el ratón o se enfoca, su cambio visual también debe cumplir el contraste de 3:1.
• **Objetos gráficos:**
  • La información gráfica esencial (ej: partes distintas de un gráfico, iconos que transmiten significado) debe tener un contraste de 3:1 con los colores adyacentes.

Errores comunes a evitar:

• Botones o campos de formulario que se mezclan demasiado con el fondo debido a un contraste insuficiente.
• Iconos apenas visibles contra su fondo.

Herramientas útiles para las pruebas:

• **Analizadores de contraste de color:** Las mismas herramientas que para el contraste de texto (Colour Contrast Analyser, Axe DevTools).
• **Herramientas de diseño:** Usar herramientas de diseño (ej: Figma, Sketch) con complementos de accesibilidad para verificar el contraste durante el diseño.

Objetivo: Asegurar que los usuarios puedan ajustar el espaciado del texto (altura de línea, espaciado entre letras, espaciado entre palabras, espaciado entre párrafos) sin perder contenido o funcionalidad, y sin requerir desplazamiento horizontal.

Por qué es importante (Beneficio para el usuario):

• Crucial para usuarios con dislexia, discapacidades cognitivas o baja visión que se benefician de un mayor espaciado para mejorar la legibilidad.
• Admite hojas de estilo personales y extensiones de navegador que modifican la presentación del texto.

Qué verificar / Cómo implementar:

• **Unidades relativas:** Usar unidades CSS relativas (ej: `em`, `rem`) para la altura de línea, el espaciado entre letras, el espaciado entre palabras y el espaciado entre párrafos. Evitar los valores de píxeles fijos.
• **Sin recorte/superposición:** Cuando se aumenta el espaciado del texto (ej: a través de una extensión del navegador o una hoja de estilo personalizada), asegurarse de que el texto no se superponga, se corte o desaparezca.
• **Sin desplazamiento horizontal:** El diseño debe adaptarse sin introducir desplazamiento horizontal.

Requisitos de espaciado específicos (de Entender WCAG 2.1):

• Altura de línea (interlineado) de al menos 1.5 veces el tamaño de la fuente.
• Espaciado después de los párrafos de al menos 2 veces el tamaño de la fuente.
• Espaciado entre letras (kerning) de al menos 0.12 veces el tamaño de la fuente.
• Espaciado entre palabras de al menos 0.16 veces el tamaño de la fuente.

Errores comunes a evitar:

• Usar unidades absolutas (`px`) para el espaciado, impidiendo la personalización del usuario.
• Diseños ajustados que no pueden adaptarse a un mayor espaciado, lo que lleva a superposiciones.

Herramientas útiles para las pruebas:

• **Herramientas de desarrollo del navegador:** Cambiar manualmente las propiedades CSS para el espaciado del texto para observar el efecto.
• **Extensiones del navegador:** Text Spacing Bookmarklet, o extensiones que permiten inyectar CSS personalizado, para simular un mayor espaciado.

Objetivo: Asegurar que el contenido adicional que se muestra al pasar el ratón o al enfocar (ej: tooltips, submenús, pop-ups) pueda cerrarse, sea perceptible y permanezca visible el tiempo suficiente para que los usuarios puedan interactuar con él.

Por qué es importante (Beneficio para el usuario):

• Permite a los usuarios con discapacidades motoras mover el ratón sin perder el contenido.
• Asegura que los usuarios que solo usan el teclado puedan acceder e interactuar con el contenido.
• Da a los usuarios con discapacidades cognitivas o baja visión suficiente tiempo para percibir y procesar la información.

Qué verificar / Cómo implementar:

• **Descartable:** El contenido debe poder cerrarse sin mover el cursor o el foco del teclado, a menos que indique un error de entrada o no oculte otro contenido. Ejemplos: presionar la tecla Esc, o un botón de cerrar.
• **Pasable el ratón (Persistencia al Pasar el Ratón/Enfocar):** Si al mover el ratón o el foco del elemento disparador el contenido adicional desaparece, ese contenido debe ser pasable el ratón para que el usuario pueda mover su puntero sobre él para mantenerlo visible e interactuar con él.
  * **Persistente:** El contenido debe permanecer visible hasta que el usuario lo cierre explícitamente, o hasta que muevan el foco o el puntero lejos del disparador *y* del propio contenido.

Errores comunes a evitar:

• Tooltips que desaparecen tan pronto como el ratón se mueve del disparador, impidiendo la interacción.
• Submenús que se cierran demasiado rápido.
• Contenido al enfocar no accesible a través del teclado.

Herramientas útiles para las pruebas:

• **Navegación con teclado:** Usar solo el teclado para acceder e interactuar con elementos que muestran contenido al pasar el ratón/enfocar.
• **Prueba del ratón:** Mover el ratón lentamente para ver si el contenido persiste y si puede interactuar con él.

Objetivo: Toda la funcionalidad del contenido debe ser operable a través de una interfaz de teclado sin requerir tiempos específicos para las pulsaciones individuales. Esto es esencial para los usuarios que no pueden usar un ratón u otros dispositivos de puntero.

Por qué es importante (Beneficio para el usuario):

• Esencial para usuarios con discapacidades motoras que no pueden usar el ratón.
• Permite la navegación a usuarios de lectores de pantalla y a aquellos que prefieren la interacción con el teclado.
• Mejora la eficiencia para usuarios avanzados que dependen de los atajos de teclado.

Qué verificar / Cómo implementar:

• Todos los elementos interactivos: Asegúrese de que todos los elementos interactivos (botones, enlaces, campos de formulario, ventanas emergentes, menús, carruseles, reproductores multimedia) se puedan activar y operar utilizando solo el teclado (Tab, Enter, Barra espaciadora, teclas de flecha).
• Orden de tabulación lógico: El orden del enfoque del teclado (al presionar Tab) debe ser lógico e intuitivo, siguiendo el flujo visual de la página.
• Sin trampas de teclado: Los usuarios deben poder mover el enfoque de cualquier componente utilizando solo una interfaz de teclado. Evite situaciones en las que el enfoque quede "atrapado" en un widget.
• Elementos HTML estándar: Prefiera los elementos HTML estándar (<button>, <a>, <input>) ya que tienen accesibilidad de teclado incorporada.
• Atributos ARIA para componentes personalizados: Para componentes de interfaz de usuario personalizados creados con elementos no semánticos (por ejemplo, <div>), use roles ARIA (role), estados (aria-expanded) y propiedades (tabindex) apropiados para hacerlos operables con el teclado y exponer su funcionalidad a las tecnologías de asistencia.

Errores comunes a evitar:

• Elementos interactivos que solo se pueden hacer clic con el ratón (por ejemplo, un <div> con un evento `onclick` pero sin `tabindex`).
• Orden de tabulación ilógico que salta por la página.
• Modales o widgets personalizados que atrapan el enfoque del teclado, impidiendo que los usuarios los cierren o interactúen con otras partes de la página.

Herramientas útiles para la prueba:

• Prueba manual: Navegue por toda la página utilizando solo la tecla `Tab` (y `Shift+Tab` para retroceder). Use `Enter` y `Barra espaciadora` para activar elementos.
• Extensiones del navegador: Axe DevTools, Lighthouse (pueden identificar algunos problemas de operabilidad del teclado).
• Lector de pantalla: Pruebe con un lector de pantalla (por ejemplo, NVDA, JAWS, VoiceOver) para asegurarse de que la navegación y la interacción funcionen como se espera.

Objetivo: Si el enfoque del teclado se puede mover a un componente de la página utilizando una interfaz de teclado, entonces el enfoque también se puede mover de ese componente utilizando solo una interfaz de teclado, y, si requiere más que las teclas de flecha o tab sin modificar u otros métodos de salida estándar, se le informa al usuario el método para mover el enfoque.

Por qué es importante (Beneficio para el usuario):

• Evita que los usuarios que dependen únicamente del teclado se queden atascados en partes específicas de la página, lo que provoca frustración e incapacidad para completar tareas.
• Garantiza una experiencia de navegación fluida y predecible.

Qué verificar / Cómo implementar:

• Tecla Escape: Para diálogos modales, ventanas emergentes o cualquier superposición temporal, asegúrese de que la tecla `Esc` los cierre y devuelva el enfoque al elemento anterior.
• Tab/Shift+Tab: Cuando el enfoque entra en un componente (por ejemplo, un menú complejo, un carrusel con controles internos), asegúrese de que al presionar `Tab` (o `Shift+Tab`) el enfoque eventualmente se moverá fuera de ese componente al siguiente (o anterior) elemento enfocable de la página.
• Instrucciones: Si un componente personalizado requiere una combinación de teclas específica (que no sean las estándar Tab/Esc/flechas) para salir, informe claramente al usuario (por ejemplo, "Presione Ctrl+E para salir de esta sección").

Errores comunes a evitar:

• Se abre un diálogo modal y el usuario puede tabular a través de los elementos dentro de él, pero no puede tabular *fuera* de él o cerrarlo con `Esc`.
• Widgets personalizados que tienen ciclos de tabulación internos pero no hay forma de salir de ellos al resto de la página.

Herramientas útiles para la prueba:

• Prueba manual: Use solo el teclado para interactuar con todos los componentes, especialmente aquellos que abren superposiciones o administran el enfoque interno. Intente quedarse "atascado" y verifique los métodos de salida.
• Herramientas de desarrollo del navegador: Inspeccione los valores de `tabindex` y los oyentes de eventos JavaScript para la gestión del enfoque.

Objetivo: Asegúrese de que cuando cualquier componente de la interfaz de usuario recibe el enfoque del teclado, haya una indicación visible de ese enfoque.

Por qué es importante (Beneficio para el usuario):

• Crucial para usuarios de teclado videntes (incluidos aquellos con baja visión o discapacidades cognitivas) para saber dónde están en la página y con qué elemento están interactuando actualmente.
• Ayuda a la navegación y reduce la frustración.

Qué verificar / Cómo implementar:

• Indicador de enfoque visible: Cada elemento interactivo (enlaces, botones, campos de formulario, etc.) debe tener un indicador de enfoque claramente visible cuando se navega a él con el teclado (por ejemplo, usando la tecla `Tab`).
• Estilos de enfoque personalizados: Es aceptable eliminar el contorno de enfoque predeterminado del navegador siempre que se proporcione un indicador de enfoque personalizado que sea igual o más visible.
• Estilo de enfoque: El estilo de enfoque debe ser prominente (por ejemplo, borde grueso, color contrastante, sombra). Evite los estilos de enfoque demasiado sutiles o que se mezclen con el fondo.

Errores comunes a evitar:

• Usar `outline: none;` en CSS sin proporcionar una alternativa visible.
• Indicadores de enfoque que tienen un contraste insuficiente.

Herramientas útiles para la prueba:

• Prueba manual: Navegue por toda la página con la tecla `Tab` y observe atentamente el indicador de enfoque.
• Extensiones del navegador: Axe DevTools, Lighthouse (pueden detectar la falta de estilo de enfoque).

Objetivo: El idioma humano predeterminado de cada página web debe poder determinarse programáticamente.

Por qué es importante (Beneficio para el usuario):

• Permite que los lectores de pantalla pronuncien correctamente el contenido en el idioma apropiado.
• Mejora la experiencia de los usuarios que utilizan herramientas de traducción.

Qué verificar / Cómo implementar:

• Atributo `lang`: Asegúrese de que el atributo `lang` esté establecido en la etiqueta `<html>` con el código de idioma correcto (por ejemplo, `<html lang="es">`).
• Consistencia: El atributo `lang` debe reflejar el idioma principal real del contenido de la página.

Errores comunes a evitar:

• Omitir completamente el atributo `lang`.
• Establecer el atributo `lang` en un idioma incorrecto (por ejemplo, `lang="en"` para una página en español).

Herramientas útiles para la prueba:

• Extensiones del navegador: Axe DevTools, Lighthouse (marcarán los atributos `lang` faltantes o incorrectos).
• Inspección manual del código: Vea el código fuente de la página para verificar la etiqueta `<html lang="...">`.

Objetivo: El idioma humano de cada pasaje o frase en el contenido debe poder determinarse programáticamente.

Por qué es importante (Beneficio para el usuario):

• Permite que los lectores de pantalla cambien la pronunciación de palabras o frases extranjeras dentro del texto principal.
• Mejora la precisión de las herramientas de traducción para contenido en idiomas mixtos.

Qué verificar / Cómo implementar:

• Atributo `lang` para elementos específicos: Si una sección de texto, una palabra o una frase está en un idioma diferente del idioma principal de la página, enciérrelo en un elemento HTML (por ejemplo, `<span>`, `<p>`, `<div>`) y aplique el atributo `lang` con el código de idioma correcto.

  <p>El restaurante ofrece un delicioso <span lang="fr">Coq au Vin</span>.</p>

Errores comunes a evitar:

• No declarar el idioma de palabras o frases extranjeras, lo que provoca que los lectores de pantalla las pronuncien incorrectamente.

Herramientas útiles para la prueba:

• Lector de pantalla: Pruebe frases en diferentes idiomas para asegurar la pronunciación correcta.
• Inspección manual del código: Busque instancias de texto extranjero y verifique si el atributo `lang` se aplica correctamente.

Objetivo: Cambiar la configuración de cualquier componente de la interfaz de usuario no debe causar automáticamente un cambio de contexto, a menos que el usuario haya sido avisado del comportamiento antes de usar el componente.

Por qué es importante (Beneficio para el usuario):

• Evita cambios inesperados y desorientación, especialmente para usuarios con discapacidades cognitivas o motoras, o aquellos que usan lectores de pantalla.
• Proporciona una experiencia de usuario predecible y estable.

Qué verificar / Cómo implementar:

• Sin envío automático: No envíe automáticamente un formulario ni navegue a una nueva página únicamente cuando un campo de formulario gane el enfoque o cambie su valor (por ejemplo, seleccionar un elemento de un menú desplegable no debe enviar el formulario inmediatamente sin un botón de "Enviar").
• Advertencias claras: Si un componente *debe* activar un cambio de contexto al enfocar o cambiar el valor (por ejemplo, un menú desplegable de "Saltar a"), informe claramente al usuario sobre este comportamiento de antemano (por ejemplo, "Seleccionar una opción lo llevará a una nueva página").
• Controles dedicados para acciones: Los elementos interactivos que activan acciones (como los botones "Ir" para los desplegables o "Aplicar filtros") deben requerir una acción explícita del usuario (clic, enter) en lugar de cambios implícitos al enfocar.

Errores comunes a evitar:

• Menús desplegables que envían automáticamente el formulario cuando se selecciona una opción.
• Campos de formulario que, al recibir el enfoque, activan automáticamente JavaScript para realizar una acción (por ejemplo, mostrar una sección oculta que desplaza el contenido inesperadamente).

Herramientas útiles para la prueba:

• Prueba manual: Navegue a través de los campos de formulario y elementos interactivos usando el teclado (tecla Tab) y observe si se producen cambios de contexto inesperados.
• Prueba de ratón: Haga clic en varios campos de formulario y controles para asegurarse de que no se activen acciones inesperadas al ganar el enfoque.

Objetivo: Cambiar la configuración de cualquier componente de la interfaz de usuario no debe causar automáticamente un cambio de contexto, a menos que el usuario haya sido avisado del comportamiento antes de usar el componente.

Por qué es importante (Beneficio para el usuario):

• Evita cambios inesperados y desorientación, especialmente para usuarios con discapacidades cognitivas o motoras, o aquellos que usan lectores de pantalla.
• Proporciona una experiencia de usuario predecible y estable.

Qué verificar / Cómo implementar:

• Sin envío automático al introducir: No envíe automáticamente un formulario ni navegue a una nueva página únicamente cuando el valor de un campo de formulario cambie (por ejemplo, tan pronto como el usuario escribe un carácter en un campo de texto, o selecciona una opción en un menú desplegable).
• Advertencias claras: Si un componente *debe* activar un cambio de contexto al introducir (por ejemplo, un menú desplegable de "Saltar a"), informe claramente al usuario sobre este comportamiento de antemano (por ejemplo, "Seleccionar una opción lo llevará a una nueva página").
• Botones de acción dedicados: Las acciones que causan cambios de contexto (como el envío de formularios, el filtrado de resultados o la navegación) deben ser activadas por acciones explícitas del usuario, como hacer clic en un botón de "Enviar" o presionar Enter.

Errores comunes a evitar:

• Cuadros de búsqueda que envían automáticamente la consulta después de cada carácter escrito.
• Opciones de filtrado que actualizan automáticamente los resultados o redirigen la página inmediatamente después de la selección, sin un botón de "Filtrar" o "Aplicar".

Herramientas útiles para la prueba:

• Prueba manual: Interactúe con todos los campos de formulario y controles de entrada, escribiendo o seleccionando valores, y observe si se producen cambios de contexto inesperados sin una acción explícita del usuario (por ejemplo, presionar un botón de enviar).

Objetivo: Los mecanismos de navegación que se repiten en varias páginas web dentro de un conjunto de páginas web aparecen en el mismo orden relativo cada vez que se repiten, a menos que un cambio sea iniciado por el usuario.

Por qué es importante (Beneficio para el usuario):

• Mejora la previsibilidad y reduce la carga cognitiva, permitiendo a los usuarios (especialmente aquellos con discapacidades cognitivas o usuarios de lectores de pantalla) aprender y anticipar la navegación.
• Promueve la eficiencia al permitir a los usuarios encontrar rápidamente los enlaces de navegación deseados.

Qué verificar / Cómo implementar:

• Navegación principal: Los menús (por ejemplo, navegación global, navegación de la barra lateral) deben aparecer en el mismo orden relativo en todas las páginas donde estén presentes.
• Navegación del pie de página: Los enlaces en el pie de página deben mantener un orden coherente en todas las páginas.
• Omitir navegación: Si un usuario elige reordenar o personalizar la navegación (por ejemplo, a través de una vista personalizada), esto está permitido. Sin embargo, la presentación predeterminada debe ser coherente.

Errores comunes a evitar:

• Cambiar el orden de los elementos del menú principal de una página a otra sin que el usuario lo inicie.
• Reorganizar el orden de los enlaces en el pie de página en diferentes secciones del sitio web.

Herramientas útiles para la prueba:

• Prueba manual: Navegue por varias páginas del sitio web e inspeccione visualmente el orden de los elementos de navegación repetidos. Use un lector de pantalla para verificar también el orden programático.

Objetivo: Los componentes que tienen la misma funcionalidad dentro de un conjunto de páginas web se identifican de forma coherente.

Por qué es importante (Beneficio para el usuario):

• Reduce la carga cognitiva y la confusión al garantizar que las funcionalidades familiares siempre se etiqueten y presenten de manera similar.
• Mejora la previsibilidad y la facilidad de aprendizaje, especialmente para usuarios con discapacidades cognitivas.
• Ayuda a los usuarios que confían en la memoria muscular o en las señales visuales para localizar funciones.

Qué verificar / Cómo implementar:

• Etiquetas de texto: Si un botón realiza la misma acción (por ejemplo, "Buscar"), su etiqueta de texto debe ser consistentemente "Buscar" en todas las páginas, no "Encontrar" en una página y "Consultar" en otra.
• Iconos: Los iconos utilizados para la misma funcionalidad deben ser consistentes (por ejemplo, una lupa para buscar). Si un icono tiene una etiqueta de texto, esa etiqueta también debe ser consistente.
• Texto alternativo: El texto alternativo (por ejemplo, atributo `alt` para imágenes, `aria-label`) para componentes funcionalmente idénticos debe ser consistente.

Errores comunes a evitar:

• Usar diferentes términos para la misma acción (por ejemplo, "Añadir al carrito" en la página del producto, "Comprar ahora" en la página de categoría, "Realizar pedido" en la página de pago para la misma acción de "compra").
• Variar los iconos para la misma función sin razones claras.

Herramientas útiles para la prueba:

• Prueba manual: Revise todas las páginas del sitio web y compare sistemáticamente las etiquetas de texto, los iconos y los textos alternativos para funcionalidades similares.

Objetivo: Si se detecta automáticamente un error de entrada, se identifica el elemento que está en error y se describe el error al usuario en texto.

Por qué es importante (Beneficio para el usuario):

• Ayuda a los usuarios con discapacidades cognitivas, baja visión o usuarios de lectores de pantalla a identificar y comprender fácilmente qué salió mal y cómo solucionarlo.
• Reduce la frustración y mejora la tasa de éxito de los envíos de formularios.

Qué verificar / Cómo implementar:

• Descripción textual clara: Proporcione un mensaje de error claro y conciso en texto que explique la naturaleza del error (por ejemplo, "Se requiere la dirección de correo electrónico", "La contraseña debe tener al menos 8 caracteres").
• Asociación programática: El mensaje de error debe estar asociado programáticamente con el campo en error (por ejemplo, usando `aria-describedby` para vincular el campo de entrada a su mensaje de error, o `aria-invalid="true"` en el campo mismo).
• Identificación visual: Resalte visualmente el campo erróneo (por ejemplo, con un borde rojo) además del mensaje de texto. Sin embargo, el color por sí solo no debe ser el único indicador (WCAG 1.4.1).
• Ubicación: Los mensajes de error deben colocarse cerca del campo al que se refieren, preferiblemente justo debajo o al lado.

Errores comunes a evitar:

• Mensajes de error genéricos como "Error al enviar el formulario".
• Resaltar errores solo con color (por ejemplo, simplemente cambiando el campo a rojo sin un mensaje de texto).
• Mensajes de error que están visualmente lejos del campo relevante.

Herramientas útiles para la prueba:

• Extensiones del navegador: Axe DevTools, Lighthouse (excelentes para detectar mensajes de error faltantes o asociaciones programáticas).
• Lector de pantalla: Pruebe el envío de formularios con errores para asegurarse de que los mensajes de error se lean en voz alta y se asocien correctamente con sus campos.

Objetivo: Se proporcionan etiquetas o instrucciones cuando el contenido requiere la entrada del usuario.

Por qué es importante (Beneficio para el usuario):

• Ayuda a todos los usuarios (incluidos aquellos con discapacidades cognitivas, usuarios de lectores de pantalla y usuarios nuevos) a comprender qué entrada se espera en cada campo del formulario.
• Esencial para usuarios que no pueden depender de señales visuales (por ejemplo, texto de marcador de posición que a menudo desaparece al introducir o enfocar).

Qué verificar / Cómo implementar:

• Etiquetas explícitas: Cada campo de entrada (campos de texto, casillas de verificación, botones de radio, desplegables) debe tener un elemento `<label>` claramente asociado.

  <label for="email">Dirección de correo electrónico:</label>
  <input type="email" id="email">

• Asociación programática: El atributo `for` de la etiqueta `<label>` debe coincidir con el `id` del campo de entrada.
• Instrucciones/Ejemplos: Proporcione instrucciones o ejemplos claros para entradas complejas (por ejemplo, "Formato de fecha: DD-MM-AAAA", "La contraseña debe contener al menos una letra mayúscula y un número").
• Texto de marcador de posición: El texto de marcador de posición (el texto dentro de un campo de entrada que desaparece al escribir) *no* debe usarse como la única etiqueta, ya que no siempre está disponible de manera consistente para todos los usuarios.

Errores comunes a evitar:

• Campos de formulario sin ningún elemento `<label>`.
• Usar solo texto de marcador de posición como etiqueta.
• Etiquetas que están visualmente presentes pero no vinculadas programáticamente a la entrada (falta la coincidencia `for`/`id`).

Herramientas útiles para la prueba:

• Extensiones del navegador: Axe DevTools, Lighthouse, WAVE (excelentes para identificar etiquetas faltantes o asociadas incorrectamente).
• Lector de pantalla: Navegue por los formularios con un lector de pantalla para confirmar que el propósito de cada campo se anuncie claramente a través de su etiqueta.
• Prueba de teclado: Haga clic en las etiquetas. Si están correctamente asociadas, al hacer clic en la etiqueta, se enfocará el campo de entrada correspondiente.

Objetivo: Si se detecta automáticamente un error de entrada y se conoce una sugerencia para la corrección, la sugerencia se proporciona al usuario, a menos que ponga en peligro la seguridad o el propósito del contenido.

Por qué es importante (Beneficio para el usuario):

• Ayuda a los usuarios (especialmente a aquellos con discapacidades cognitivas o dislexia) a corregir errores de manera más rápida y eficiente.
• Reduce la frustración y aumenta la probabilidad de que la tarea se complete con éxito.

Qué verificar / Cómo implementar:

• Sugerencias específicas: Para errores comunes donde la corrección es obvia, proporcione una sugerencia específica (por ejemplo, "¿Quiso decir ejemplo@dominio.com?" para un correo electrónico mal escrito, o "La contraseña debe tener al menos una letra mayúscula" si falta).
• Errores de contraseña: Por razones de seguridad, no sugiera correcciones de contraseña específicas (por ejemplo, no repita partes de la contraseña ni dé pistas como "Su contraseña es demasiado corta, necesita agregar 'xyz'"). En su lugar, indique el requisito faltante (por ejemplo, "La contraseña debe tener al menos 8 caracteres", "La contraseña debe incluir un número").
• Autocorrección/Autocompletado: Implemente funciones de autocorrección o autocompletado cuando sea apropiado y beneficioso, siempre que el usuario mantenga el control.

Errores comunes a evitar:

• Simplemente indicar "Entrada inválida" sin ninguna pista sobre cómo solucionarlo.
• Proporcionar sugerencias demasiado vagas o inútiles.

Herramientas útiles para la prueba:

• Prueba manual: Intencionalmente, cometa errores de entrada comunes (por ejemplo, escriba mal un correo electrónico, use un formato de fecha incorrecto) y verifique si se proporcionan sugerencias útiles.

Objetivo: Para las páginas web que implican compromisos legales o transacciones financieras para el usuario, o que modifican o eliminan datos controlables por el usuario en sistemas de almacenamiento de datos, al menos una de las siguientes condiciones es cierta:

• Reversible: Los envíos son reversibles.
• Verificado: Los datos introducidos por el usuario se verifican en busca de errores de entrada y se le brinda al usuario la oportunidad de corregirlos.
• Confirmado: Hay un mecanismo disponible para revisar, confirmar y corregir la información antes de finalizar el envío.

Por qué es importante (Beneficio para el usuario):

• Previene consecuencias graves o irreversibles para los usuarios debido a errores en transacciones críticas (por ejemplo, financieras, legales, eliminación de datos).
• Genera confianza en el sistema.
• Aborda posibles problemas para usuarios con discapacidades cognitivas, motoras o visuales que podrían ser más propensos a cometer errores.

Qué verificar / Cómo implementar:

• Revisar/Editar: Permita a los usuarios revisar y corregir la información antes del envío final.
• Confirmación: Requiera una confirmación explícita del envío (por ejemplo, "¿Está seguro de que desea continuar?").
• Cancelar: Ofrezca la posibilidad de cancelar la transacción o el cambio.
• Validación automática: Utilice la validación en tiempo real cuando sea posible para prevenir errores antes del envío.

Errores comunes a evitar:

• Transacciones irreversibles que no ofrecen ninguna posibilidad de revisión o cancelación.

Herramientas útiles para la prueba:

• Prueba manual: Simule transacciones importantes y verifique la presencia y funcionalidad de los mecanismos de prevención de errores.

Objetivo: En el contenido implementado usando lenguajes de marcado, los elementos tienen etiquetas de inicio y fin completas, los elementos están anidados según sus especificaciones, no hay ID duplicados, y cada ID es único, excepto cuando las especificaciones lo permiten.

Por qué es Importante (Beneficio para el Usuario):

• Garantiza que todos los navegadores y las tecnologías de asistencia puedan analizar (parsear) e interpretar correctamente el contenido.
• Previene comportamientos impredecibles o errores de visualización/funcionalidad.

Qué Verificar / Cómo Implementar:

• Validez HTML/XML: Asegúrate de que el código HTML sea válido y esté bien formado, sin errores de sintaxis.
• IDs Únicos: Cada atributo `id` debe ser único dentro de la página.
• Anidamiento Correcto: Los elementos deben estar anidados correctamente (ej. `` no debe contener otro ``).

Errores Comunes a Evitar:

• Etiquetas no cerradas o abiertas incorrectamente.
• IDs duplicados en la misma página.

Herramientas Útiles para la Prueba:

• Validadores HTML: Servicio de Validación de Marcado W3C, extensiones de navegador como Axe DevTools o Lighthouse (a menudo detectan problemas de análisis).