Empiece por lo que un cliente necesita hacer: encontrar un producto o servicio, entender la información y ponerse en contacto con usted o completar un pedido. Si una persona que usa el teclado no puede abrir el menú, o un lector de pantalla no identifica los campos de consulta, hay reparaciones concretas que encargar antes de seguir puliendo el aspecto visual.

Para una web existente de una pequeña empresa en Estados Unidos, empezaría por un recorrido que funcione, una lista breve de barreras reproducibles y un acuerdo escrito sobre qué se corregirá y volverá a probar. Eso permite decidir mejor que un distintivo sin explicación de las comprobaciones realizadas.

Esta guía ayuda a definir esa primera intervención. No es una evaluación completa de accesibilidad ni un dictamen jurídico sobre su empresa.

Entienda la orientación de Estados Unidos y acuerde un objetivo técnico

El Departamento de Justicia de Estados Unidos sostiene que la ADA se aplica a los bienes y servicios ofrecidos en línea por los negocios considerados establecimientos abiertos al público. Su orientación sobre accesibilidad web explica que las barreras digitales pueden impedir el acceso de personas con discapacidad. Las obligaciones concretas de su empresa requieren una valoración jurídica; esta guía no puede determinarlas por su tamaño o dirección web.

Para encargar el trabajo, pida que se indique la norma y el nivel evaluados. Las WCAG son una norma técnica con criterios comprobables. WCAG 2.2 nivel AA es un objetivo útil para conversar sobre una intervención nueva. Deje escritos la versión, el nivel y el alcance acordados, en lugar de aceptar una promesa indefinida de «cumplimiento de la ADA».

Un objetivo técnico, un informe de pruebas limitado y una conclusión jurídica son cosas distintas. No suponga que un plazo aplicable a una web gubernamental sea el plazo de su negocio privado.

Pruebe un recorrido completo del cliente

Elija un recorrido real: inicio → servicio o producto → consulta, reserva o pago. Incluya lo que ocurre después de abrir el formulario, no solo la primera pantalla. Use un entorno de pruebas o un envío de prueba acordado para no generar un pedido real.

La tabla propone una primera lista de reparaciones. No incluye todos los requisitos de las WCAG.

Qué probar Qué barrera registrar Qué pedir
Deje el ratón. Use Tab y Mayús+Tab, y las teclas apropiadas para cada control. No puede alcanzar o accionar el menú, una opción de producto o el botón de consulta. Haga que las funciones habituales sean utilizables con teclado. Repita todo el recorrido, incluida la apertura y el cierre de los controles.
Observe por dónde se mueve el teclado. Pierde su posición porque el control activo no tiene ninguna señal visible. Añada un indicador visible de foco a enlaces y controles; compruébelo sobre los fondos reales de la página.
Examine los campos antes y después de escribir. La indicación desaparece al escribir, o el lector de pantalla no identifica el campo. Use etiquetas claras, asociadas a sus campos, e instrucciones. El texto de ejemplo dentro del campo no sustituye bien a una etiqueta permanente.
Deje un campo obligatorio vacío o introduzca un valor inválido en una prueba controlada. Solo aparece un borde rojo, o no puede localizar y corregir el error. Explique el error con texto y facilite su corrección. Repita las pruebas de validación y errores, además del caso correcto.
Mida el contraste del texto, los precios y los botones. Las letras claras se confunden con el fondo. Para WCAG AA, el texto normal necesita generalmente 4,5:1; el texto grande, 3:1. Son criterios para texto, con excepciones; no una regla idéntica para cualquier gráfico.
Amplíe la página y examine una ventana estrecha. Un panel fijo tapa el formulario o los párrafos exigen desplazarse lateralmente. Compruebe el reajuste a una anchura equivalente a 320 píxeles CSS, sin perder información ni funciones. Hay excepciones concretas para contenido que necesita dos dimensiones, como ciertas tablas.

Después, pida a alguien que conozca las tecnologías de apoyo que recorra la secuencia con un lector de pantalla. Un control puede parecer correcto y tener un nombre incorrecto, o no anunciar un cambio importante. Anote el navegador y la tecnología utilizados para que el desarrollador pueda reproducir el hallazgo.

Incluya el contenido y los servicios externos

Una foto de producto, un diagrama y un adorno requieren tratamientos distintos. Una imagen informativa necesita una alternativa textual adecuada; una imagen puramente decorativa no debería añadir lectura innecesaria. El tutorial de imágenes de W3C explica la diferencia. Si las especificaciones o los horarios solo aparecen dentro de una imagen, publique también la información esencial como texto de la página.

En una demostración hablada, revise los subtítulos en vez de dar por correctas las palabras automáticas. Los subtítulos también deben comunicar los sonidos no verbales relevantes. Pruebe los controles del reproductor dentro del recorrido del cliente.

Siga después los pasos externos: reservas, pagos, chat o catálogo descargable. Inclúyalos en el inventario y determine quién puede modificarlos. «Eso depende de otro proveedor» identifica un problema de responsabilidad, pero no permite al cliente reservar.

Si un documento o servicio bloquea el acceso, acuerde una vía utilizable para obtener la información o el servicio mientras se resuelve la causa. Identifíquela como medida provisional y mantenga abierta la incidencia original.

Convierta las observaciones en una lista de reparaciones

Describa cada problema de forma que otra persona pueda repetirlo. «La accesibilidad es mala» apenas ayuda al proveedor. Un registro útil incluye:

  • Página y tarea: dirección exacta y lo que el cliente intentaba hacer.
  • Pasos: teclas, datos o ajustes con los que apareció el problema.
  • Resultado esperado y real: qué debería ocurrir y qué impidió terminar.
  • Evidencia: grabación breve o descripción clara, navegador y entorno de prueba.
  • Responsable y comprobación: quién lo corregirá y qué pasos se repetirán.

Mi orden sugerido es resolver primero las consultas, reservas y compras bloqueadas; después, los menús, formularios y plantillas compartidos; finalmente, el resto del contenido. Una reparación compartida puede ayudar a muchas páginas, pero conviene comprobar ejemplos representativos. Esta propuesta sigue la idea práctica de priorizar reparaciones provisionales sin perder de vista el trabajo completo.

No convierta el número de avisos en una medida de gravedad sin mirar la tarea. Un formulario de consulta inutilizable puede importar más al cliente que muchos avisos repetidos de escaso impacto.

Contrate un alcance definido y acepte evidencias

Un encargo podría decir: «Evalúe el menú, la plantilla de producto y el recorrido de consulta frente al objetivo WCAG acordado. Incluya teclado, lector de pantalla, errores del formulario y el paso de reserva externo. Indique las páginas y estados probados, ejecute las reparaciones acordadas y entregue evidencias anteriores y posteriores, con las limitaciones pendientes». Es un ejemplo de alcance, no una garantía de conformidad completa.

Separe en el presupuesto evaluación, implementación y comprobación posterior. Pregunte qué plantillas, documentos, idiomas y servicios externos están incluidos. Acuerde quién corregirá los problemas del contenido o de un complemento, y cómo se comunicará lo que siga pendiente.

Al aceptar la entrega, repita los pasos que fallaban. Pida direcciones, métodos, incidencias cerradas y pendientes. Un escaneo ayuda a detectar algunos problemas; una puntuación limpia o una capa automática instalada no demuestra que todo el recorrido funcione. Las comprobaciones iniciales de W3C cubren solo parte de la accesibilidad.

Cuando sea posible, incorpore personas con discapacidad junto con la evaluación de la norma. W3C advierte contra generalizar a partir de muestras limitadas. Una prueba satisfactoria no representa a todos los clientes ni acredita la conformidad de todo el sitio.

Mantenga operativo lo que ha corregido

Asigne a alguien la recepción de avisos de accesibilidad y publique una forma clara de contactarlo. Tras cambiar un menú, formulario, plantilla o sistema de reservas, repita el recorrido afectado. Revise también el contenido nuevo: una plantilla accesible no impide subir una lista de precios que solo sea una imagen.

Si aún está localizando problemas, empiece por la lista general de revisión de una web de empresa. Si va a contratar ayuda, use la guía para evaluar a un diseñador web para acordar alcance y entrega. Lleve después una pregunta concreta al proveedor: «¿Puede este cliente completar esta tarea y puede mostrarme la comprobación posterior?»