Dé a cada botón, enlace y campo de formulario un nombre que una persona y un programa puedan leer. Un botón toma su nombre de su texto, un enlace de su texto de enlace, y un campo de formulario de una etiqueta visible ligada a él en el código.
La primera revisión toma unos diez minutos, y no necesita ser desarrollador para empezar.
Quizá haya oído que los agentes de IA pronto reservarán citas y comprarán cosas en los sitios web. Así que, la pregunta que importa es si el formulario de contacto, de reserva, de cotización o de pago de su propio sitio tiene sentido para una herramienta que no lo ve como lo ve un cliente. Un lector de pantalla enfrenta el mismo problema, y las soluciones son las mismas.
Empiece por la única página que le genera dinero. Si unos cuantos botones resultan sin nombre, es una reparación pequeña, y no requiere un rediseño.
Puntos clave
Los botones necesitan texto claro, los enlaces necesitan un texto de enlace descriptivo, y cada campo de formulario necesita una etiqueta visible ligada a él con un for y un id que coincidan.
Ejecute Lighthouse en su página de contacto, revise un botón y un campo en la pestaña Accessibility (Accesibilidad) de Chrome, y luego recorra el formulario con el teclado.
Las etiquetas faltantes y los botones de solo icono sin nombre son ediciones pequeñas; los widgets personalizados, los sistemas de reserva o de pago y las fallas repetidas son donde la ayuda pagada vale lo que cobra.
Dé a cada botón, enlace y campo un nombre que las personas y los programas puedan leer
Un software identifica un control por su nombre accesible, que W3C describe como el texto corto que un programa usa para etiquetarlo. Con los controles nativos de HTML, rara vez escribe ese nombre por separado. Escribe palabras normales y visibles, y el navegador las transmite. La guía de W3C sobre nombres y descripciones dice que un botón normalmente toma su nombre de su texto, y un enlace, de su texto de enlace.
Un campo de formulario funciona un poco distinto. El tutorial de formularios de W3C indica «Provide labels to identify all form controls» (Ponga etiquetas para identificar todos los controles de formulario), y cubre los campos de texto, las casillas, los botones de radio y las listas desplegables. El valor for de la etiqueta debe coincidir exactamente con el id del campo, o los dos no quedan conectados. WCAG 2.2 pide lo mismo en términos sencillos: el criterio de éxito 3.3.2 exige etiquetas o instrucciones cuando el contenido pide información a las personas.
Un ejemplo corto muestra el patrón. Un campo con la etiqueta «Correo electrónico» tiene una etiqueta visible con esas palabras, y la etiqueta apunta al id del input. Un botón dice «Enviar mensaje» en su propio texto. Un enlace dice «Lea nuestra guía de precios», no «Haga clic aquí». Esa es toda la idea.
Cuando el diseño no puede mostrar texto, como con un icono pequeño, W3C permite que aria-label o aria-labelledby den el nombre. Sin embargo, el texto visible y el HTML nativo van primero, porque el patrón de botón calcula por defecto la etiqueta de un botón a partir de su texto.
Encuentre los botones sin nombre y los campos sin etiqueta en unos diez minutos
Puede hacer esta revisión hoy en su página de contacto, con un navegador gratuito. La documentación de Chrome cubre cada herramienta: Lighthouse para el informe automático, y la pestaña Accessibility de DevTools para los detalles de un solo control.
- Abra la página: Cargue su página de contacto, de reserva o de cotización en Chrome.
- Ejecute Lighthouse: Presione Ctrl+Shift+I, abra el panel de Lighthouse, seleccione solo Accessibility y ejecute el informe.
- Lea los elementos de formulario y de botón: Busque fallas como «Buttons do not have an accessible name» (los botones no tienen un nombre accesible), «Form elements do not have associated labels» (los elementos de formulario no tienen etiquetas asociadas), «Links do not have discernible names» (los enlaces no tienen nombres distinguibles) y «Elements with visible text labels have matching accessible names» (los elementos con etiquetas de texto visibles tienen nombres accesibles coincidentes).
- Inspeccione un control: Seleccione un botón o un campo marcado en el panel Elements (Elementos), abra la pestaña Accessibility y active Show accessibility tree (mostrar el árbol de accesibilidad) para ver el nombre que Chrome calculó para él.
- Recorra la página con Tab: Presione Tab desde la barra de direcciones y observe cómo se mueve el foco. Cada enlace, botón, campo, menú y diálogo debe recibirlo, en un orden lógico, con un contorno de foco que pueda ver.
- Envíe el formulario con el teclado: Complételo, provoque un error a propósito y luego envíelo. El error debe señalar el campo correcto, y el mensaje de éxito debe ser fácil de ver.
Lighthouse es automático y detecta muchas fallas, pero no puede probarlo todo, y la guía de puntuación de Chrome lo reconoce. La revisión con el teclado cubre lo que el informe no ve. Una puntuación de 100 es una buena señal, pero no es prueba de que el formulario funcione para todas las personas ni para todos los agentes.
Arregle los problemas habituales de los constructores sin rehacer el sitio
Los constructores de sitios web y las plantillas de página tienden a repetir el mismo puñado de errores. Son fáciles de detectar cuando ya conoce su forma, y cada uno tiene una reparación estándar. El tamaño del trabajo varía desde una edición de una línea hasta un proyecto pequeño, así que conviene clasificar lo que encuentre antes de llamar a alguien.
Botones de solo icono
Un botón de menú, de cerrar, de buscar o de calendario dibujado como icono a menudo no tiene texto, así que un lector de pantalla no tiene nada que anunciar. Agregue texto visible donde el diseño lo permita. Si no lo permite, dé al botón un aria-label preciso, como «Abrir menú», y asegúrese de que siga funcionando con el teclado.
Campos con solo marcador de posición (placeholder)
El texto del marcador aparece dentro del campo y desaparece en cuanto alguien escribe. Agregue una etiqueta visible que se quede en la página, y deje el marcador solo como ejemplo del formato. El texto colocado cerca de un campo que solo parece una etiqueta puede no estar conectado a él en el código, así que revíselo con la pestaña Accessibility.
Elementos div clicables
Un div con estilo de botón no le dice al software que es un botón, y puede no responder al teclado. Reemplácelo con un botón o un enlace real donde pueda. Si no puede, necesitará agregarle a mano un rol, el comportamiento del teclado, el foco y el estado, lo cual es más trabajo.
Ventanas emergentes y diálogos
Una ventana emergente necesita un nombre, el foco debe pasar a ella cuando se abre, permanecer dentro mientras está abierta y regresar a la página cuando se cierra. El patrón de diálogo de W3C describe ese comportamiento. Pruebe cualquier ventana emergente de boletín o de cookies con el teclado, porque los controles del fondo que siguen accesibles detrás de ella son una falla común.
| Problema | Arreglo típico | Tamaño habitual del trabajo |
|---|---|---|
| Campo sin etiqueta | Agregar una etiqueta visible con un for y un id que coincidan | Edición pequeña por campo |
| Botón de solo icono | Agregar texto visible o un aria-label preciso | Pequeño |
| Enlace vacío | Escribir un texto de enlace descriptivo | Pequeño |
| Campo con solo marcador de posición | Agregar una etiqueta visible permanente | De pequeño a mediano, según el constructor |
| Div clicable | Cambiarlo por un botón o un enlace real | Mediano |
| Ventana emergente sin nombre ni manejo del foco | Ponerle nombre y manejar el foco | De mediano a grande |
| Widget de terceros | Pedir al proveedor una versión accesible, o reemplazarlo | Varía |
Los tamaños son aproximados y dependen de su constructor y de su tema. Un formulario hecho con un plugin que no puede editar puede necesitar una solicitud al proveedor en lugar de un cambio de código, y eso conviene saberlo antes de planear un fin de semana de arreglos.
Ponga el problema en proporción con lo que midió WebAIM
Estas brechas son comunes, así que encontrar algunas en su propio sitio no significa que haya hecho algo inusual. El informe Million de WebAIM, de febrero de 2025, hizo revisiones automáticas en las páginas de inicio de un millón de sitios web y contó las fallas que detectó. Estas cifras son de WebAIM, y cubren las páginas de inicio, no cada página de contacto o de pago.
| Falla detectada | Porcentaje de un millón de páginas de inicio |
|---|---|
| Etiquetas faltantes en campos de formulario | 48.2% |
| Enlaces vacíos | 45.4% |
| Botones vacíos | 29.6% |
El informe Million de WebAIM también encontró más páginas que fallan en contraste bajo y en descripciones de imágenes faltantes, pero esas quedan fuera de botones y formularios. Las tres fallas de la tabla aparecen en una ejecución de Lighthouse. Son fallas detectadas por un escaneo automático de páginas de inicio.
Concentre su esfuerzo donde los agentes de IA y los lectores de pantalla sí se benefician
Agregar aria-label a cada control no vuelve legible un sitio para los agentes de IA por sí solo. W3C recomienda primero el HTML nativo y el texto visible, y ARIA solo donde el elemento nativo se queda corto.
Del lado del agente, el anuncio de OpenAI sobre su Computer-Using Agent del 23 de enero de 2025 dice que el agente interpreta capturas de pantalla y trabaja con interfaces gráficas, incluidos botones, menús y campos de texto. Las etiquetas visibles claras y el texto de los botones importan para un agente así, y deben coincidir con lo que dice el código. La ficha técnica de Operator de OpenAI describe tareas como reservar citas y comprar boletos, y no promete que toda interfaz vaya a funcionar.
La documentación de DevTools de Chrome describe el árbol de accesibilidad como un subconjunto de la estructura de la página que contiene información útil para los lectores de pantalla. Construir controles con elementos nativos, etiquetas visibles y nombres correctos ayuda a ese árbol, y ayuda hoy a las personas que usan tecnología de asistencia. Ningún estándar publicado garantiza que un agente termine una reserva o una compra, así que trate los beneficios para los agentes como posibles y el beneficio para los lectores de pantalla como seguro.
Si quiere la visión completa, una lista de verificación de accesibilidad web cubre el resto de la página, y puede ver qué agentes de IA visitan su sitio web para saber si llega alguno. Las preguntas sobre si ChatGPT y la IA de Google pueden leer su sitio web son aparte de las etiquetas de formularios, y los agentes de compra con IA y su tienda en línea es donde entra el proceso de pago.
Guarde su dinero cuando unos pocos arreglos son todo lo que necesita
Si su ejecución de Lighthouse muestra dos botones sin nombre y un campo sin etiqueta, arréglelos usted mismo o pídale a quien mantiene el sitio que haga las ediciones. Un puñado de elementos pequeños no justifica un rediseño completo.
La ayuda profesional vale lo que cobra cuando los problemas se extienden más allá de una sola página. Eso incluye problemas repetidos en varias plantillas, widgets personalizados, sistemas de reserva o de pago de un tercero, páginas multilingües, validaciones complicadas o los mismos problemas que regresan después de cada actualización. En esos casos, el valor está en la reparación sistemática, las pruebas en todas las plantillas, los resultados por escrito y el mantenimiento, y no en un ajuste secreto de IA.
Termine la semana con un plan breve. Pruebe su formulario de contacto o de reserva el lunes. Arregle los elementos pequeños para el miércoles. Decida el viernes si el resto necesita una revisión específica. La guía web de ADA.gov señala las WCAG como un estándar técnico útil para los servicios web accesibles, lo que lo convierte en una referencia sensata para esa revisión. Los nombres accesibles ayudan a los usuarios de lectores de pantalla y pueden ayudar a algunos agentes de navegador, pero ningún resultado está garantizado.
¿Pueden leerse sus botones y formularios?
Elija una respuesta para empezar.
1. ¿Qué le da a un campo de formulario su nombre accesible de la forma más limpia?
2. ¿Qué le indica una puntuación de 100 en Lighthouse?
3. ¿Qué situación justifica más pagar ayuda profesional?
Preguntas frecuentes sobre botones y formularios legibles
¿Qué es un nombre accesible?
Es el texto corto que el software usa para identificar un control, como «Enviar mensaje» en un botón o «Correo electrónico» en un campo.
¿Cómo debo etiquetar un campo de formulario?
Use una etiqueta visible y ligue el campo a ella con un valor for que coincida con el id del campo. El tutorial de formularios de W3C describe ese patrón.
¿Puede un texto de marcador de posición reemplazar a una etiqueta?
No. El marcador de posición desaparece mientras alguien escribe. Use una etiqueta que se quede en la página y deje el marcador solo como ejemplo del formato.
¿Cómo etiqueto un botón de solo icono?
Agregue texto visible donde el diseño lo permita. Si no lo permite, dé al botón un nombre preciso con aria-label o aria-labelledby, como «Abrir menú».
¿Lighthouse prueba que mi sitio es accesible?
No. Lighthouse detecta muchas fallas de forma automática, pero no puede probarlo todo. Agregue una revisión con el teclado al formulario y, cuando pueda, pruébelo también con un lector de pantalla.
¿Qué debo arreglar primero?
Arregle primero las etiquetas faltantes y los botones y enlaces sin nombre. Después revise el acceso con el teclado, el foco visible, los mensajes de error de los formularios y el comportamiento de las ventanas emergentes.
Hacia adelante
Cada botón, enlace y campo de formulario necesita un nombre que una persona y un programa puedan leer. Los botones y los enlaces lo toman de su texto, y los campos lo toman de una etiqueta visible ligada a ellos en el código. Una ejecución de Lighthouse, una mirada a la pestaña Accessibility de Chrome y una pasada con el teclado por el formulario le muestran dónde están las brechas. Los culpables habituales de los constructores son los botones de solo icono, los campos con solo marcador de posición, los divs clicables y las ventanas emergentes sin nombre.
El beneficio es un formulario que más visitantes pueden terminar, incluidas las personas que usan lectores de pantalla, teclado o control por voz, y posiblemente algunos agentes de navegador. Nadie puede prometer que un agente completará una reserva en su sitio, pero un formulario con nombres claros le da una oportunidad justa, y a sus visitantes humanos les da una mejor experiencia.
Si su revisión encuentra problemas en varias plantillas, widgets personalizados o un sistema de reservas, Web Leveling puede revisar las páginas que importan y arreglarlas como parte de nuestro trabajo de diseño web, y le diremos con claridad cuando bastan unas pocas ediciones pequeñas. Trabajamos con pequeñas y medianas empresas en todo el país y en el extranjero. Cuéntenos qué formulario le preocupa, y empezaremos por ahí.
Términos
Palabras usadas en esta publicación
Toque un término para ver qué significa.
Nombre accesible. El texto corto que el software usa para identificar un botón, un enlace o un campo de formulario.
Árbol de accesibilidad. Un subconjunto de la estructura de la página que contiene la información útil para los lectores de pantalla, y que se muestra en la pestaña Accessibility de Chrome.
Lector de pantalla. Software que lee una página en voz alta o en una pantalla braille para las personas que no pueden ver la pantalla.
aria-label. Un atributo que da un nombre accesible cuando un control no tiene texto visible.
Marcador de posición. Texto de ayuda que aparece dentro de un campo de formulario vacío y desaparece en cuanto alguien escribe.
Lighthouse. Una herramienta de auditoría gratuita integrada en Chrome que ejecuta revisiones automáticas de accesibilidad en una página.
