Accesibilidad web: lista de comprobación para pymes y tiendas

Imagine a una clienta que usa un lector de pantalla. Encuentra las zapatillas que quiere, elige la talla y pulsa lo que cree que es el botón de la cesta. Su lector de pantalla dice «botón». Nada más. Hay tres en la página y ninguno tiene nombre, así que se va, y usted nunca sabrá por qué.

La mayoría de los problemas de accesibilidad en las webs de pequeñas empresas son así: invisibles para el propietario y un callejón sin salida para el cliente. Esta lista es para quienes gestionan una web en Shopify, WooCommerce, Wix o Squarespace sin un desarrollador en plantilla.

¿Tiene que ser accesible la web de mi pequeña empresa?

Si vende a consumidores de la UE, probablemente sí. La Ley Europea de Accesibilidad (se abre en una pestaña nueva) cubre los servicios de comercio electrónico desde el 28 de junio de 2025. La exención principal es para las microempresas que prestan servicios: empresas con menos de 10 personas en plantilla y un volumen de negocios anual o un balance general anual de no más de 2 millones de euros. En España, la Ley 11/2023 (se abre en una pestaña nueva) mantiene esa exención en su artículo 3.3.

Comercio electrónico significa aquí vender a distancia, a través de una web o una app, «a petición individual de un consumidor, al objeto de celebrar un contrato con el consumidor» (artículo 3, punto 30). Una tienda online o un motor de reservas encajan. La exención solo cubre los servicios: quien vende productos incluidos, como lectores de libros electrónicos, sigue sujeto a las normas sobre productos (artículo 4, apartado 5). Tampoco sirve de nada estar fuera de la UE, porque una tienda británica que vende a clientes en Francia está incluida por esas ventas (artículo 3, punto 4). Nuestra guía sobre la Ley Europea de Accesibilidad repasa las leyes nacionales y las multas.

En el Reino Unido, la Equality Act 2010 (se abre en una pestaña nueva) exige ajustes razonables para las personas con discapacidad, pero no fija una norma técnica para las webs. En EE. UU., la guía de marzo de 2022 (se abre en una pestaña nueva) del Departamento de Justicia dice que las empresas abiertas al público deben hacer accesible lo que ofrecen en internet y que normas como las WCAG «ofrecen orientaciones útiles». Diga lo que diga la ley, un cliente que no puede terminar la compra no compra.

¿Cuáles son los problemas de accesibilidad más comunes en las webs?

Predominan seis fallos. En el WebAIM Million 2026 (se abre en una pestaña nueva), un análisis automático de las páginas de inicio del millón de webs principales realizado en febrero de 2026, el 95,9 % de las páginas tenía fallos WCAG detectados, con una media de 56,1 errores por página. El texto con poco contraste fue el problema más frecuente: apareció en el 83,9 % de las páginas de inicio.

Las WCAG, las Pautas de Accesibilidad para el Contenido Web, son la norma en la que se basan estas comprobaciones; la mayoría de las leyes remiten a su nivel AA, y nuestra guía de las WCAG 2.2 explica la última versión. Varias de las comprobaciones de abajo no las puede juzgar ningún escáner.

¿Todo el mundo puede leer sus textos y entender sus imágenes?

Empiece por aquí, porque son arreglos baratos y casi todos los puede hacer usted en el editor de la web. El texto necesita suficiente contraste, las imágenes que transmiten información necesitan texto alternativo y nada debería depender solo del color. Según Colour Blind Awareness (se abre en una pestaña nueva), alrededor de 1 de cada 12 hombres y 1 de cada 200 mujeres tienen alguna alteración de la visión del color.

• Contraste. El texto normal necesita una relación de contraste de al menos 4,5:1 (se abre en una pestaña nueva) con su fondo, y el texto grande, al menos 3:1. Pruebe sus colores, incluido el texto sobre las fotos de los banners, en un verificador gratuito. Nuestra guía sobre el contraste de color muestra soluciones que respetan su marca.
• Texto alternativo de los productos. Describa lo que necesita saber quien compra: «Jersey de lana azul marino con cuello vuelto de canalé, vista frontal» es mejor que «imagen de producto 1». Empiece por sus diez productos más vendidos.
• Imágenes decorativas. Un adorno de fondo debe tener el texto alternativo vacío para que los lectores de pantalla lo salten. Algunas plataformas rellenan un alt vacío con el nombre del archivo, así que compruebe la suya.
• Solo el color. «Agotado» indicado solo con una muestra de color en gris, o un campo obligatorio marcado solo en rojo, no llega a todo el mundo. Mire la página con el filtro de escala de grises del móvil y añada una palabra o un icono allí donde se pierda el significado.
• Zoom. Con el zoom del navegador al 200 %, el texto debe crecer sin solaparse ni cortarse, y el menú debe seguir funcionando.
• Idioma de la página. Cualquier verificador gratuito avisa si falta la declaración de idioma. Es un ajuste de la plantilla o un cambio de una línea.

¿Se puede usar su web con el teclado?

Mucha gente navega sin ratón: usuarios de lectores de pantalla, personas con temblor o movilidad reducida en las manos y cualquiera a quien se le acaba de estropear el trackpad. Aparte el ratón y pulse Tab. Debería llegar a cada enlace, botón y campo de formulario en un orden lógico, ver siempre dónde está y no quedarse nunca atascado.

• Foco visible. Un contorno debe mostrar qué elemento está activo, y una cabecera fija o una burbuja de chat no deben taparlo (criterio 2.4.11 Foco no oculto de las WCAG 2.2). Muchas plantillas eliminan el contorno por estética; un desarrollador puede recuperarlo.
• Sin trampas. Abra con el teclado el menú, el selector de talla, las ventanas emergentes y la galería de imágenes, elija algo e intente salir. Escape debería cerrar las ventanas emergentes.
• Nombres para los iconos. Cada enlace y botón con icono necesita un nombre que el lector de pantalla pueda anunciar, como «Cesta, 2 artículos». Sustituya «Haga clic aquí» por palabras que digan adónde lleva el enlace.
• Enlace para saltar y encabezados. Lo ideal es que la primera pulsación de Tab muestre un enlace «Saltar al contenido». En la encuesta de WebAIM de 2024 a usuarios de lectores de pantalla (se abre en una pestaña nueva), el 71,6 % dijo que recorre primero una página larga por sus encabezados, así que use niveles de encabezado reales, no texto en negrita.
• Objetivos táctiles. Las WCAG 2.2 piden objetivos de al menos 24 por 24 píxeles CSS, o suficiente espacio a su alrededor (criterio de conformidad 2.5.8 (se abre en una pestaña nueva)).

¿Todo el mundo puede completar sus formularios, la cesta y el pago?

En el proceso de pago, los problemas de accesibilidad le cuestan dinero directamente, así que pruébelo de principio a fin, incluido lo que pasa cuando algo sale mal. Cada campo necesita una etiqueta visible, los errores deben explicar el problema con palabras e iniciar sesión no debería depender de pruebas de memoria ni de acertijos. Las páginas de su proveedor de pagos también cuentan.

• Etiquetas, no textos de ejemplo. El texto de ejemplo (placeholder) desaparece en cuanto se empieza a escribir y a menudo es demasiado claro para leerlo. Cada campo necesita una etiqueta que siga visible.
• Mensajes de error. Envíe el formulario vacío. Cada error debe estar escrito («Introduzca un código postal, por ejemplo, 28001»), junto a su campo y anunciado, no limitarse a poner un borde en rojo.
• No pregunte dos veces. Ofrezca «La dirección de facturación es la misma» en lugar de obligar a volver a escribir la dirección de envío. Las WCAG 2.2 lo convirtieron en un requisito de nivel A, el 3.3.7 Entrada redundante.
• Inicio de sesión. Permita pegar contraseñas y códigos de un solo uso y usar gestores de contraseñas. Bloquear el pegado incumple el criterio de autenticación accesible (se abre en una pestaña nueva) de las WCAG 2.2, salvo que ofrezca otra forma de entrar.
• CAPTCHA. En la encuesta de WebAIM de 2024, los usuarios de lectores de pantalla situaron el CAPTCHA como el elemento más problemático de la web. Si necesita protegerse de bots, evite los acertijos visuales y ofrezca siempre una alternativa no visual.
• Límites de tiempo. Si una cesta o una reserva caducan, avise y permita ampliar el plazo.

Si partes del proceso de pago son de su plataforma o de su proveedor de pagos, pruébelas igualmente, comunique los problemas e inclúyalos como problemas conocidos.

¿Y los banners de cookies, las ventanas emergentes y los chats?

Para sus clientes, los scripts de terceros forman parte de su web. Un banner de cookies que no se puede cerrar con el teclado bloquea todas las páginas, y una ventana emergente del boletín que roba el foco en mitad del pago puede hacerle perder una venta. Pruebe cada script que haya añadido y pregunte a los proveedores por la accesibilidad antes de instalar uno nuevo.

• Banner de cookies. ¿Puede llegar con Tab a los botones de aceptar y rechazar, leerlos con un zoom del 200 % y seguir después donde estaba?
• Ventanas emergentes. El foco debe entrar en la ventana, quedarse dentro hasta que se cierre y volver después. Escape debería cerrarla.
• Widgets de chat. El botón necesita un nombre, la ventana debe abrirse y cerrarse con el teclado y, en el móvil, no debería quedar encima de «Pagar ahora».
• Carruseles. Todo lo que se mueve solo durante más de cinco segundos necesita una forma de pausarlo, detenerlo u ocultarlo (WCAG 2.2 (se abre en una pestaña nueva), criterio de conformidad 2.2.2).
• Contenidos incrustados. Los widgets de reseñas, los mapas y las herramientas de reserva también están en su página. Comunique los fallos al proveedor.

¿Sus vídeos, PDF y cartas funcionan para todo el mundo?

Los vídeos necesitan subtítulos, el audio necesita una transcripción y la información importante no debería estar solo en un PDF o una imagen. Un restaurante cuya carta es un PDF escaneado, o una tienda cuya guía de tallas es la foto de una tabla, deja fuera a los usuarios de lectores de pantalla y a cualquiera que necesite ampliar en el móvil.

• Subtítulos y transcripciones. Corrija los subtítulos automáticos antes de publicar. Los pódcasts necesitan una versión en texto.
• Imágenes de texto. Ponga las cartas, las listas de precios, las guías de tallas y los horarios en una página web normal. Si tiene que usar un PDF, expórtelo con encabezados y etiquetas desde su procesador de textos en lugar de escanear una copia impresa.
• Archivos antiguos. La EAA no le obliga a corregir los documentos ofimáticos ni el audio y vídeo pregrabados publicados antes del 28 de junio de 2025, ni los contenidos archivados que ya no actualiza (artículo 2, apartado 4). Los archivos nuevos sí están incluidos.

¿Qué puedo corregir yo y cuándo necesito un desarrollador o una auditoría?

La mayoría de los problemas de contenido los puede corregir usted en el gestor de contenidos: texto alternativo, encabezados, texto de los enlaces, colores, subtítulos y muchas etiquetas de formulario. Los problemas de la plantilla, como la falta de estilos de foco, las trampas de teclado o los desplegables a medida, necesitan un desarrollador. Una auditoría tiene más sentido cuando lo básico ya está corregido, o antes de publicar un rediseño.

¿Qué papel tiene un widget como el nuestro? Un panel para visitantes como SiteAccessible permite subir el contraste, agrandar el texto o activar una guía de lectura. Eso ayuda a algunos visitantes, pero no tacha nada de esta lista: un botón sin nombre sigue sin nombre y una trampa de teclado sigue siendo una trampa. Corrija primero la web y considere el widget un extra.

¿Cómo dejo constancia de lo que he hecho?

Lleve un registro sencillo de qué ha probado, cuándo, qué ha corregido y qué sigue sin funcionar, y publique un resumen honesto en una declaración de accesibilidad. Si le afecta la EAA, también tiene que publicar cómo cumple su servicio los requisitos de accesibilidad, normalmente en sus condiciones generales o en un documento equivalente.

Esa segunda obligación procede del anexo V de la directiva; la ley nacional fija el formato. Nuestra guía para redactar una declaración de accesibilidad incluye un modelo que puede adaptar. Después, mantenga la rutina:

1. Pase la lista por sus tres páginas clave y haga una captura de cada fallo.
2. Corrija usted mismo los elementos de contenido esta semana.
3. Encargue a un desarrollador los elementos de la plantilla y del pago, empezando por los peores.
4. Vuelva a probar cada corrección con el teclado, además de con un verificador.
5. Publique o actualice su declaración, con la fecha.
6. Repita cada vez que añada una app, cambie de plantilla o lance una nueva página de destino.