Accesibilidad web en 2026: qué exige la ley y cómo adaptar tu página

La accesibilidad web ya no es un “extra de diseño”. En 2026, con la ley europea en vigor desde junio de 2025, una página que no se puede usar con teclado, con lector de pantalla o con bajo contraste no es solo una mala experiencia: en muchos negocios es un riesgo legal y un agujero de conversión. Esta guía explica qué exige de verdad la normativa en España, qué criterios WCAG fallan más y cómo adaptar una web de pyme —en Granada o en cualquier otra ciudad— sin rehacerla desde cero.

1. Qué es la accesibilidad web (y qué no es)

La accesibilidad web es la capacidad de una página de ser percibida, operada y comprendida por el mayor número de personas posible: con ceguera o baja visión, daltonismo, sordera, movilidad reducida, temblor, dislexia, o simplemente con el móvil al sol y una mano ocupada. No es un plugin de “alto contraste” ni un widget flotante que promete cumplir la ley con un clic.

En la práctica, una web accesible es una web usable en condiciones reales. Si el menú no se abre con teclado, el botón “Enviar” no tiene nombre, el vídeo arranca con sonido o el texto gris sobre beige no se lee, estás perdiendo clientes. Una parte de ellos tiene una discapacidad reconocida. Otra parte —más grande de lo que imaginas— está en un contexto temporal: gafas olvidadas, brazo ocupado, conexión lenta, edad.

Cuatro principios (POUR) que sí sirven para decidir

• Perceptible: el contenido se puede ver u oír. Texto alternativo, subtítulos, contraste.
• Operable: se puede usar sin ratón, sin gestos imposibles y sin trampas de teclado.
• Comprensible: el idioma está declarado, los errores se explican, el flujo no es un laberinto.
• Robusto: funciona con navegadores, lectores de pantalla y tecnologías de apoyo actuales.

Si un rediseño solo discute paletas y “wow”, esos cuatro puntos suelen caer. En tendencias de diseño web ya apuntábamos que el diseño inclusivo no es moda: es el suelo. En 2026 es, además, el suelo legal para mucha actividad digital.

2. La ley europea en 2026: a quién aplica

El Acto Europeo de Accesibilidad (Directiva (UE) 2019/882) se traspuso en España con la Ley 11/2023, de 8 de mayo. La fecha que importa no es la de publicación: es el 28 de junio de 2025. Estamos más de un año después. Quien esperaba “a ver si se retrasa” ya no tiene ese argumento.

No obliga a toda web de España. Obliga a determinados productos y servicios puestos en el mercado europeo, entre ellos —y esto es lo que más toca a pymes— los servicios de comercio electrónico dirigidos a consumidores, además de banca al por menor, transporte de viajeros, comunicaciones electrónicas, acceso a medios audiovisuales y libros electrónicos.

Microempresas: la exención que más se malinterpreta

La directiva exime, con carácter general, a las microempresas que prestan servicios: menos de 10 personas y volumen de negocio anual o balance no superior a 2 millones de euros. Un estudio de 4 personas en Granada con una web corporativa y un formulario no es, por tamaño, el objetivo típico de un expediente. Una tienda online que factura por encima de ese umbral y vende a consumidores en la UE, sí puede estarlo.

Matices que importan:

• La exención habla de servicios. Quien introduce en el mercado productos cubiertos (terminales, lectores de e-book, etc.) no se libra por ser pequeño.
• Un portal solo B2B (extranet de proveedores, sin venta al consumidor) suele quedar fuera del núcleo de “comercio electrónico” al consumidor. Si la tienda es pública, asume que aplica.
• Marketplaces y grandes clientes pueden exigirte accesibilidad por contrato aunque la ley te exima.
• Hay un régimen transitorio hasta 28 de junio de 2030 para ciertos productos ya en uso al prestar servicios. No es una prórroga general de “no hagas nada hasta 2030”.

3. WCAG 2.2 y EN 301 549: el listón técnico

El listón legal europeo se apoya en la norma armonizada EN 301 549, alineada de forma práctica con las WCAG 2.1 nivel AA del W3C. Las WCAG 2.2 (recomendación desde octubre de 2023) añaden criterios que en 2026 ya son de sentido común: destinos de clic más grandes, ayuda consistente, sin arrastrar obligatorio, mejor autenticación.

Traducción para un negocio: no hace falta memorizar códigos de criterio. Sí hace falta que diseño y desarrollo trabajen contra AA, no contra “se ve bonito en Figma con el ratón”. Un informe WAVE o Lighthouse en verde no es un certificado de conformidad. Es un primer filtro.

• A: el mínimo para no excluir del todo (alternativas de texto, teclado básico).
• AA: el nivel que piden administración, EN 301 549 y casi todo pliego serio. Aquí hay que estar.
• AAA: excelente, no siempre realista en una pyme (contrastes extremos, lenguaje muy controlado).

Si estás rediseñando, pide AA en el alcance. Sale más barato que parchear un año después. El coste de hacerlo bien entra en un proyecto de diseño y desarrollo, no en un “kit de accesibilidad” de 49 €.

4. Ver, oír, leer: contraste, texto e imágenes

La mayoría de fallos que vemos en webs de Granada no son de ARIA avanzada. Son de percepción: texto que no se lee, imágenes que no se describen, color que es el único indicador.

Contraste y tipografía

• Texto normal: contraste mínimo 4.5:1 frente al fondo. Texto grande (aprox. 18 px bold o 24 px regular): 3:1.
• Componentes de interfaz (bordes de input, iconos que son el único medio): 3:1.
• El gris “elegante” sobre crema que tanto gusta en branding artesanal suele romper AA. Se puede mantener paleta de Granada (terracota, tinta, lino) si el texto de lectura es más oscuro.
• No desactives el zoom. user-scalable=no o maximum-scale=1 es un clásico de plantillas que hay que borrar.
• El tamaño de cuerpo en móvil no debería bajar de ~16 px. Quien recorta a 13 px “para que quepa más” está diseñando para su monitor, no para el cliente.

Imágenes, iconos y media

• Fotos con información (equipo, producto, mapa, infografía): alt descriptivo. Decorativas: alt="".
• Un icono de WhatsApp o carrito sin texto visible necesita nombre accesible (aria-label o texto visually-hidden). “Button” no es un nombre.
• Vídeo: subtítulos. Si el mensaje está solo en el audio, hace falta transcripción o captions. El autoplay con sonido es hostil y, a menudo, contrario a las directrices.
• No uses color como único canal: un error de formulario no puede ser solo el borde rojo.

5. Teclado, foco y lectores de pantalla

Si no puedes recorrer la web solo con Tab, Enter y Escape, no es accesible. Punto. Ratón y gesto táctil no son un plan B para quien no puede usarlos, y tampoco para quien navega más rápido con teclado.

• Orden de foco: sigue el orden visual y de lectura (arriba → abajo, izquierda → derecha). Un tabindex="5" inventado es una trampa.
• Foco visible: el anillo de foco no es “feo”. Si lo quitas con outline: none sin reemplazo, incumples operable. Un anillo de 2–3 px con el color de acento es diseño, no un accidente de CSS.
• Menús y modales: Escape cierra. El foco no se escapa detrás del overlay. Al cerrar, el foco vuelve al botón que abrió.
• Skip link: “Saltar al contenido” al inicio. En sitios con mega-menú, ahorra 20 tabulaciones.
• Trampa de teclado: un slider o un mapa embebido que captura Tab para siempre. Hay que poder salir.

Los lectores de pantalla (NVDA, VoiceOver, TalkBack) necesitan HTML con sentido: un h1 por página, headings en orden, listas de verdad, botones que son button y enlaces que son a con href. Un div con onclick no es un botón. ARIA no repara un DOM mal planteado; lo maquilla.

Declarar el idioma en <html lang="es"> parece menor. Sin eso, el lector pronuncia el castellano como si fuera inglés. Es de las correcciones más baratas que existen.

6. Formularios, errores y checkout

El formulario de contacto y el checkout son donde la accesibilidad se convierte en dinero. Un lead perdido no aparece en Search Console. Aparece como silencio.

• Etiquetas visibles asociadas con for/id. El placeholder no es una etiqueta: desaparece al escribir y no la leen igual de bien.
• Errores en texto, junto al campo, no solo en un toast de 3 segundos. Enlaza el mensaje con aria-describedby.
• Autocompletado: nombre, email, teléfono, dirección con los tokens correctos (autocomplete="email", etc.). Ayuda a todo el mundo y a los gestores de contraseñas.
• Campos obligatorios anunciados (texto “obligatorio”, no solo un asterisco rojo).
• Captchas: reCAPTCHA invisible o alternativas. Un captcha solo de imágenes es una barrera clásica.
• Tiempo: si la sesión del carrito caduca, avisa y permite extender. No vacíes el carrito en silencio.
• Destino de clic: WCAG 2.2 pide áreas de toque suficientes. Botones de 24 px en móvil son un filtro involuntario contra mayores y contra quien va andando por Recogidas.

En ecommerce, identificación y pago tienen mención expresa en el marco del EAA. No basta con “Stripe está embebido”: el flujo alrededor (resumen, gastos de envío, errores de tarjeta, volver atrás) también tiene que ser operable. Más contexto de plataforma en Shopify vs WooCommerce.

7. Accesibilidad y SEO: la misma base

Google no “premia la accesibilidad” con un factor mágico separado. Premia páginas que entiende y que la gente puede usar. Casi todo lo que pide AA ayuda al rastreo y a los AI Overviews:

• HTML semántico y headings: el mismo esqueleto que usa un crawler y un lector de pantalla.
• Texto alternativo: indexación de imágenes y contexto. “IMG_4032” no posiciona ni informa.
• Enlaces con ancla clara: “pincha aquí” es malo para SEO y para el lector. “Ver planes de SEO local” es mejor.
• Idioma y canonical: señales de entidad limpias. Un lang mal puesto no ayuda a nadie.
• Core Web Vitals: layouts que no saltan (CLS) y respuestas a la interacción (INP) son experiencia. Lo desarrollamos en la guía de INP y CWV.
• Vídeos y transcripciones: más texto indexable y más comprensión del tema.

Los errores típicos de SEO técnico —títulos duplicados, contenido vacío, menús infinitos en JS— también son errores de comprensión. Si te interesa el lado de indexación, empieza por errores SEO comunes. Accesibilidad no sustituye una estrategia de posicionamiento; evita que esa estrategia aterrice en una web que una parte de Granada no puede usar.

8. Cómo auditar tu web en una tarde

No necesitas un laboratorio. Necesitas un orden y no mentirte con el “en mi Chrome se ve bien”.

Un informe útil no es un PDF de 80 fallos “menor”. Es una lista priorizada: bloqueantes (no se envía el formulario), graves (contraste del cuerpo, menú inaccesible), menores (landmarks, iframe sin título). Arreglar 8 bloqueantes vale más que maquillar 40 avisos de Lighthouse.

9. Errores que vemos en pymes

• El overlay milagroso: un widget de “accesibilidad” que cambia contrastes encima de una web rota. No cumple EN 301 549. A veces empeora el lector de pantalla.
• Carruseles de hero que no se pausan y se llevan el foco. El usuario con atención reducida no llega al CTA.
• Fuentes iconográficas sin nombre: el menú hamburguesa es un cuadrado mudo.
• Modales de cookies que no se pueden aceptar con teclado y tapan el skip link. Ironía máxima: el banner legal bloquea la web.
• Contraste del footer y de los legales en gris 40 %: justo las páginas que un auditor o un cliente mayor sí lee.
• Animaciones de scroll sin respeto a prefers-reduced-motion. Mareo no es “branding inmersivo”.
• PDFs escaneados como “nuestra carta” o “tarifas”. Si el contenido vive solo en imagen, no existe para el lector ni para Google.
• Confundir “bonito en Dribbble” con usable: texto de 11 px, links subrayados quitados, hover-only en desktop.

10. Checklist de 30 días

Si tienes un sitio pequeño (una web de servicios en Granada, 8–15 URLs), este ritmo es realista. Si tienes un catálogo de 2.000 productos, prioriza plantillas: ficha, listado, carrito, checkout.

Semana 1 — Bloqueantes

• Teclado en home, contacto y (si hay) checkout. Corregir trampas y foco invisible.
• lang="es", un h1, skip link, título de página único y descriptivo.
• Etiquetas de formulario y errores en texto. Quitar captcha imposible o sustituirlo.
• Banner de cookies operable y que no robe el foco al cargar.

Semana 2 — Percepción

• Contraste del cuerpo, botones y campos. Subir tinta si el branding es claro.
• Alts de imágenes de producto y equipo. Decorativas a alt vacío.
• Zoom 200 % y tamaños de toque en móvil.
• Vídeo de portada: sin autoplay con sonido; subtítulos si lleva mensaje.

Semana 3 — Estructura y plantillas

• Headings en orden en las plantillas (no un h1 por slide del slider).
• Landmarks: header, nav, main, footer. Un main por página.
• Estados de hover/focus/active visibles. Respeta prefers-reduced-motion.
• PDFs clave: HTML equivalente o PDF etiquetado. No “foto de la tarifa”.

Semana 4 — Verificación

• axe o WAVE en las URLs de dinero. Cero bloqueantes.
• Pasada con NVDA o VoiceOver del flujo de contacto.
• Declaración de accesibilidad (aunque sea breve): qué cumple, qué no, contacto para incidencias. En sector cubierto por ley, no es un adorno.
• Si vas a migrar o rediseñar, mete AA en el mapa de URLs. No lo dejes para “fase 2”. La migración sin perder SEO y la accesibilidad se planifican juntas.

El presupuesto de una web accesible no es una línea mágica aparte: es diseño, front y contenidos bien hechos. Si estás comparando rangos, mira cuánto cuesta una página web y exige que AA entre en el alcance, no como extra opcional el viernes anterior al lanzamiento.

11. Preguntas frecuentes

¿Mi web de autónomo en Granada está obligada por la ley europea?
Depende del servicio y del tamaño. La Ley 11/2023 cubre ciertos productos y servicios (el ecommerce B2C es el caso más habitual en pymes). Las microempresas que prestan servicios (menos de 10 personas y ≤ 2 millones de euros) suelen estar exentas. Un abogado o tu asesoría te lo confirma con tu CNAE y tus cifras. Accesible sigue siendo rentable aunque estés exento.

¿WCAG 2.2 es lo que pide la ley en España?
El referente armonizado es EN 301 549, alineado de forma práctica con WCAG 2.1 AA. WCAG 2.2 es la recomendación vigente del W3C y el listón que usamos en proyectos nuevos: no contradice 2.1 y cubre huecos (toques, arrastre, autenticación). Pedir 2.2 AA en un rediseño de 2026 es razonable.

¿Un plugin de WordPress “de accesibilidad” me hace cumplir?
No. Puede ayudar con tamaños de fuente o contrastes temporales. No repara un menú inaccesible, un formulario sin etiquetas ni un checkout roto. Cumplir es HTML, CSS, JS y contenido. El plugin no firma la conformidad.

¿La accesibilidad perjudica el diseño de marca?
Al contrario: obliga a decidir tipografía, color y jerarquía de verdad. Las paletas de STUDIOGRX (tinta, terracota, lino) cumplen AA cuando el texto de lectura no se queda en gris medio. El “diseño inaccesible” casi siempre es falta de sistema, no un estilo valiente.

¿Cómo se relaciona con el SEO local?
Una ficha de Google y unas reseñas no arreglan una landing que un usuario mayor no puede enviar. El pack local trae el clic; la página tiene que completar la acción. Si trabajas Granada, combina esta guía con la de SEO local.

¿Cuánto tarda adaptar una web ya publicada?
Una web de servicios bien hecha: días o pocas semanas si el HTML no es un caos. Un ecommerce heredado con plantilla de 2018: hay que tocar tema, checkout y fichas. A veces sale más barato un rediseño con mapa que 40 parches. Lo vemos en la primera auditoría.

Siguiente paso

La accesibilidad web en 2026 es ley para quien vende online a consumidores por encima del umbral de microempresa, y es sentido común para el resto: teclado, contraste, formularios y HTML semántico. Si quieres que auditemos las URLs que sí generan clientes y dejemos un plan AA realista —sin widget milagroso—, escribe a STUDIOGRX. Te decimos qué es bloqueante y qué puede esperar al siguiente sprint.