Una empresa puede prepararse para WCAG 3 reduciendo hoy el esfuerzo que exige comprender y utilizar su web.

No necesita convertir un borrador en un requisito de contratación ni esperar a una versión definitiva para aclarar instrucciones, ordenar información y probar tareas con personas.

La decisión útil es separar el cumplimiento que corresponda al proyecto de las mejoras de comprensión que ya tienen sentido.

El W3C publicó un nuevo borrador el 10 de septiembre de 2026. Sigue siendo trabajo en desarrollo: sus requisitos pueden cambiar y no sustituye WCAG 2. La noticia abre una conversación interesante para responsables de webs B2B: ¿puede alguien entender una oferta y avanzar sin recordar información dispersa o interpretar continuamente lo que la empresa quiere decir? Consultar la fuente.

La barrera que una captura de pantalla no muestra

Una página puede tener una composición ordenada y exigir demasiado trabajo mental. Ocurre cuando el servicio cambia de nombre entre el menú y el formulario, cuando una condición aparece lejos del precio o cuando el usuario debe comparar opciones cuyos criterios no coinciden.

El problema se aprecia durante una tarea. Alguien busca saber si una empresa instala un equipo en su municipio. Encuentra una página de «soluciones», otra de «cobertura» y un botón «comenzar». Ninguna explica si ese botón solicita información o contrata.

Para avanzar debe reconstruir relaciones que la web debería hacer explícitas.

Esto no autoriza a diagnosticar una discapacidad a partir de un abandono. Tampoco demuestra por sí solo una infracción. Sí permite localizar una barrera de comprensión concreta y corregible. La orientación de W3C sobre necesidades cognitivas ofrece contexto; nuestra propuesta práctica consiste en convertir esa preocupación en tareas observables.

Una ficha de esfuerzo de comprensión

Selecciona una tarea comercial importante. Por ejemplo: averiguar si el servicio cubre el problema de la empresa y preparar una consulta. Revisa el recorrido con cuatro preguntas. No las conviertas en una puntuación de conformidad; son un instrumento de trabajo.

  • Interpretar: ¿hay palabras cuyo significado cambia según la página o etiquetas que no describen la acción?
  • Recordar: ¿debe retenerse una condición de otra sección para completar este paso?
  • Comparar: ¿las alternativas muestran las mismas dimensiones o exigen buscar datos dispersos?
  • Recuperarse: ¿un error explica qué ocurrió y permite continuar sin empezar otra vez?

En cada casilla anota el punto exacto, lo que se esperaba comprender y la modificación propuesta. «El formulario es confuso» no basta. «La etiqueta presupuesto no explica si pedimos una cifra estimada o un límite aprobado» ya permite diseñar una corrección.

Separa la observación de la causa supuesta. Si una persona vuelve tres veces a una página, registra ese comportamiento. La explicación puede ser una etiqueta ambigua, una comparación difícil o una simple necesidad de consultar con un compañero. Preguntar después de la tarea ayuda más que atribuir una causa automáticamente.

Antes de simplificar, conserva lo que cambia una decisión

Reducir esfuerzo no consiste en quitar toda la información difícil. Una condición técnica puede ser esencial. Suprimirla hace la página más corta, pero también menos honesta. Conviene explicar primero qué cambia para el cliente y ofrecer el detalle en el punto donde pueda contrastarlo.

Por ejemplo, sustituir «migración con ventanas de indisponibilidad» por «te cambiamos la web sin problemas» elimina una precaución importante.

Una explicación mejor sería: «Acordaremos qué partes pueden estar temporalmente fuera de servicio durante el cambio y cómo se comprobará la recuperación». Después se puede describir la ventana concreta cuando exista un plan confirmado.

Un caso hipotético: contratar mantenimiento industrial

Imaginemos una empresa de mantenimiento de equipos en Madrid. Su web ofrece «preventivo», «predictivo» y «correctivo». Las tres páginas empiezan con ventajas parecidas. El responsable de compras tiene que deducir cuál encaja y no sabe qué documentación aportar.

La intervención propuesta no cambia los nombres técnicos. Añade una situación de entrada a cada opción: revisiones programadas, análisis de señales de desgaste o atención a una avería existente. Una comparación común explica qué información necesita el equipo para valorar cada solicitud y qué aspectos quedan pendientes de diagnóstico.

El formulario mantiene esas mismas denominaciones. Si alguien no sabe elegir, puede describir su equipo y el síntoma. No se le obliga a emitir un diagnóstico que corresponde al proveedor. La confirmación explica que la consulta se ha registrado y cuál es el siguiente paso realmente acordado.

El resultado de este ejemplo no es una mejora porcentual inventada. Es una hipótesis verificable: debería disminuir la necesidad de pedir ayuda para clasificar la consulta. Antes de extender el cambio, se puede comprobar si personas representativas entienden las opciones y completan el recorrido sin indicaciones del equipo.

Cómo probar sin convertir la sesión en una clase

Entrega un escenario breve y un objetivo. Evita enseñar el menú antes de empezar o explicar qué significa cada término. Si ayudas continuamente, comprobarás la calidad de tu explicación, no la autonomía que ofrece la web.

Registra si la persona encuentra la información, puede contarla con sus palabras y sabe qué ocurrirá después. Permite que use sus herramientas habituales y contempla distintas necesidades de acceso. Una muestra pequeña puede revelar problemas, pero no representa a todo el mercado ni acredita una evaluación completa de accesibilidad.

Cuando aparezca una dificultad, modifica la unidad más pequeña que pueda resolverla. Puede ser una etiqueta, una instrucción, el orden de dos bloques o la ubicación de una condición. Repite la tarea con contenido real.

Una plantilla vacía rara vez reproduce el vocabulario, las excepciones y la densidad del servicio final.

Mirar hacia delante: la claridad como infraestructura

Nuestra reflexión es que la comprensión tendrá valor más allá del diseño visible. Si la oferta se consulta por voz, se resume o se compara en otra interfaz, las relaciones explícitas entre servicio, condición y siguiente paso podrían conservarse mejor que los significados escondidos en una composición.

Es una hipótesis, no una promesa de visibilidad en IA. Ganaría fuerza si las preguntas recibidas muestran menos confusión sobre alcance y si las versiones extraídas mantienen las condiciones esenciales. Se debilitaría si la simplificación elimina matices o genera más consultas equivocadas. Ambos resultados deben poder cambiar la decisión.

Por eso conviene mantener las unidades de información juntas: qué se ofrece, para quién, bajo qué condiciones y qué falta comprobar. La belleza de una página puede ayudar a leerlas; no debería ser el único elemento que permite relacionarlas.

Una mejora que puedes iniciar esta semana

Escoge un servicio, completa la ficha y prueba su consulta con alguien que no participe en el proyecto. Corrige una barrera observada y vuelve a comprobarla. Ese pequeño ciclo aporta una evidencia más útil que declarar preparada para el futuro una web que todavía exige demasiadas interpretaciones.

Para completar esta decisión, consulta Qué cubren las WCAG y qué no demuestra una herramienta automática.