Accesibilidad web: cómo decidir qué mejorar en tu sitio

Una persona llega a tu página de servicios, pero no consigue enviar el formulario: el teclado no alcanza el botón de envío, un aviso de error no se entiende o el contraste hace difícil leer los campos. La información está publicada, pero la tarea no se completa.

La accesibilidad web consiste en reducir esas barreras para que más personas puedan percibir, entender y utilizar un sitio. En este caso práctico hipotético verás cómo pasar de una incidencia concreta a un alcance razonable de mejora. Al terminar podrás decidir qué revisar primero, qué pedir a quien desarrolla tu web y cómo comprobar que un cambio funciona en situaciones reales.

Situación inicial hipotética

Imagina una pequeña empresa de servicios que recibe solicitudes desde su web. Su responsable detecta que algunas personas abandonan el formulario y plantea una petición amplia: «hay que hacer la web accesible».

Esa intención es válida, pero aún no permite tomar decisiones. Una web reúne contenidos, menús, imágenes, formularios y elementos interactivos. Cada parte puede generar una barrera distinta.

Antes de elegir herramientas o cambios visuales, conviene concretar qué debe poder hacer una persona en la web. En este ejemplo, la tarea prioritaria sería:

Encontrar un servicio, leer su información, completar un formulario y saber si la solicitud se ha enviado correctamente.

El objetivo no sería añadir una etiqueta de accesibilidad al sitio, sino facilitar ese recorrido sin obligar a usar un dispositivo, una capacidad o una forma única de navegación.

Problema observable: el recorrido se rompe

En la revisión del escenario hipotético aparecen varios obstáculos. No es necesario que todos estén presentes en tu sitio para que el ejemplo resulte útil:

• Los enlaces del menú se distinguen solo por el color y no muestran con claridad cuál tiene el foco al navegar con teclado.
• Los campos del formulario muestran una frase dentro de la caja, pero no una etiqueta persistente que explique qué dato se pide.
• Si falta un campo obligatorio, el mensaje de error aparece lejos del lugar donde se ha producido el problema.
• Un botón contiene solo un icono y su función no queda clara para quien no ve ese icono o utiliza tecnología de apoyo.
• El mensaje final de envío se muestra brevemente y puede pasar desapercibido.

El denominador común no es estético. Son barreras que dificultan acciones concretas.

Aquí resulta útil separar dos preguntas. La primera es de negocio: ¿qué recorrido debe poder completar una persona? La segunda es de implementación: ¿qué contenido, interacción y comportamiento hay que ajustar para lograrlo? Confundirlas suele llevar a arreglos aislados que no resuelven la tarea completa.

Análisis del objetivo: hacer utilizable una acción importante

En el caso, la empresa decide priorizar el formulario porque es la vía principal para iniciar una conversación. Ese objetivo se puede expresar de forma comprobable:

Una persona debe poder enviar una solicitud, entender los campos requeridos, corregir un error y recibir una confirmación clara.

Esta formulación ayuda a evitar decisiones basadas solo en apariencia. Por ejemplo, aumentar el tamaño de un texto puede ser útil, pero no resolverá un formulario que no se puede recorrer con teclado. Del mismo modo, añadir texto alternativo a una imagen no sustituye una estructura de encabezados que permita comprender la página.

La accesibilidad web suele requerir revisar varios modos de uso: navegación con teclado, lectura de contenidos, interacción con formularios, ampliación del texto y comprensión de avisos. El peso de cada revisión depende de lo que haga tu web.

Si el sitio ofrece reservas, compra, acceso privado o herramientas de gestión, el análisis debe incluir esas tareas y sus estados: qué ocurre antes de empezar, durante el proceso y cuando hay un error. Las obligaciones aplicables a tu actividad o al tipo de servicio deben validarse con el asesoramiento especializado que corresponda; una revisión técnica no sustituye esa valoración.

Alcance propuesto: intervenir donde cambia la experiencia

Con el objetivo definido, el alcance del caso hipotético no sería «revisar todo» sin más. Se concentraría en el recorrido prioritario y en los elementos que lo sostienen:

1. Estructura de la página de servicio. Revisar que los títulos ordenen la información y que los enlaces expliquen a dónde llevan.
2. Navegación con teclado. Comprobar que se puede acceder a los enlaces, campos y botones en un orden comprensible, y que el foco se identifica visualmente. El foco es la señal que indica qué elemento recibirá la siguiente acción del teclado.
3. Formulario. Asociar cada campo con una indicación clara, señalar los datos necesarios y explicar los errores junto a una forma de corregirlos.
4. Botones e iconos. Asegurar que la acción se entiende sin depender únicamente de una imagen, un color o una posición en pantalla.
5. Confirmación de envío. Mostrar un mensaje visible y comprensible que confirme el resultado o indique qué debe revisarse.

Este alcance no presupone una tecnología concreta. Puede requerir cambios de contenido, diseño o código según cómo esté construido el sitio. También conviene dejar fuera, de forma expresa, las áreas que no se hayan revisado todavía. Así evitas dar por resuelto el conjunto de la web cuando la intervención se ha centrado solo en un recorrido.

Solución y comprobación: probar la tarea, no solo los componentes

En el escenario, la aplicación empieza por mejorar la página y el formulario. Se mantiene una etiqueta visible en cada campo, se define un foco reconocible, se aclaran los botones con iconos y se reformulan los mensajes para indicar qué ha fallado y cómo corregirlo.

La comprobación posterior no se limita a confirmar que los cambios están publicados. Se repite la tarea inicial en condiciones distintas:

• recorrer la página y el formulario utilizando solo el teclado;
• ampliar el texto para comprobar si el contenido sigue siendo legible y operable;
• provocar un error de forma intencionada para revisar dónde aparece el aviso y si se entiende;
• enviar una solicitud correcta y confirmar que el resultado queda claro;
• revisar los contenidos y componentes añadidos para que no reintroduzcan la misma barrera.

Estas pruebas no permiten declarar que un sitio será adecuado para todas las personas y todos los contextos. Sí convierten una intención general en criterios visibles de aceptación. Si una persona no puede localizar el campo con error o no sabe si el envío se ha completado, la tarea aún no está resuelta.

También importa mantener las mejoras. Una nueva plantilla, un formulario externo, un cambio de diseño o la carga de contenido pueden modificar el comportamiento previo. Por eso la accesibilidad debe formar parte de las decisiones habituales de evolución de la web, no quedarse en una corrección aislada.

Aprendizajes transferibles para tu web

El caso deja tres ideas aplicables a una pyme o a un negocio autónomo:

• Empieza por una acción esencial para tu actividad: pedir información, reservar, comprar, descargar un documento o acceder a un área privada.
• Describe el resultado esperado desde el punto de vista de quien visita la web. «Poder enviar una solicitud y entender la respuesta» permite decidir mejor que «mejorar la accesibilidad».
• Pide que la solución incluya una forma de comprobarla. Un cambio está mejor definido cuando se puede probar en el recorrido que pretende mejorar.

La accesibilidad web no se resuelve con un único ajuste visual ni con una fórmula genérica. Se trabaja identificando barreras en tareas importantes, priorizando las que impiden avanzar y verificando el resultado con usos reales de la página.

Si no tienes claro qué recorrido revisar primero o qué cambios requiere tu sitio, puedes explicar tu proyecto de desarrollo web para valorar el alcance técnico que tendría una revisión y una mejora proporcionada.