Mapear el recorrido
Liste entrada, campos obligatorios, ayuda, adjuntos, consentimiento, envío, error, éxito y seguimiento.
GUÍA / PROTOCOLO
Auditar un formulario de principio a fin
Un formulario funciona si la persona entiende la petición, corrige errores y sabe qué se envió.
Respuesta directa
¿Qué revisar además del botón de envío?
Recorra cada estado con teclado y móvil. Compruebe necesidad de cada campo, etiquetas, errores, validación del servidor, conservación de datos y confirmación recibida.
01 / Método de control
Método de control
Probar entradas
Use valores válidos, vacíos, largos, internacionales e incorrectos; revise etiquetas, ejemplos, tabulación y datos conservados.
Verificar servidor
Compruebe validación del servidor, errores concretos, duplicados, fallos de red, reenvíos y espera.
Revisar el resultado
Verifique acuse, destinatario funcional, plazo comunicado, datos guardados y posibilidad de continuar.
EN LA PRÁCTICA
Verificar un recorrido, no solo una captura
Una pantalla legible puede bloquear acciones. Pruebe un objetivo completo: localizar sección, usar control, comprender resultado y volver. Registre el primer obstáculo y su efecto.
¿Qué comprobar primero?
Elija la situación observada. Cada opción indica un primer control, la prueba útil y su límite.
Funciona con ratón, pero no con teclado
- Primer control
- Repita una tarea con Tab, Mayús+Tab, Intro y las teclas esperadas del componente. Siga el foco y compruebe cómo entra y sale de menús o diálogos.
- Prueba que conservar
- Paso, tecla, control activo, estado abierto o cerrado y punto exacto de bloqueo o confusión.
- Límite que recordar
- Un orden de foco lógico no certifica toda la accesibilidad. Revise también nombres, estados anunciados y lectura del contenido.
Un formulario rechaza datos sin explicar el motivo
- Primer control
- Provoque un error y revise etiqueta, formato esperado y mensaje asociado. Compruebe que pueda corregirse sin perder los demás valores útiles.
- Prueba que conservar
- Campo, valor de prueba no sensible, mensaje, relación con el campo, foco y resultado corregido.
- Límite que recordar
- Un mensaje visible puede no estar asociado al campo ni anunciarse a tiempo. Pruebe también envío, confirmación e indisponibilidad.
El texto desborda o cuesta leerlo
- Primer control
- Reduzca la anchura, amplíe el texto y repita la tarea. Identifique qué componente obliga a desplazar toda la página horizontalmente y sepárelo de una tabla que necesita dos dimensiones.
- Prueba que conservar
- Anchura, zoom, idioma, componente, texto oculto y necesidad real de desplazamiento en dos direcciones.
- Límite que recordar
- Una captura móvil no cubre todos los zooms, idiomas y estados. La excepción de una tabla no justifica desbordar toda la página.
Para ampliar
| Situación | Evitar | Corrección útil |
|---|---|---|
| Navegación | Probar solo con ratón. | Recorrer con teclado y mantener foco visible. |
| Formulario | Depender del texto provisional del campo. | Mantener etiqueta visible y relacionar error y campo. |
| Resultado dinámico | Cambiar una cifra sin contexto. | Mostrar resultado, unidad y cambio realizado. |
Localizar
¿El título describe la tarea?
Actuar
¿El control es accesible y comprensible?
Comprender
¿Son explícitos resultado y siguiente acción?
Control final
Repita el recorrido con Tab, Mayús+Tab y Entrar, y después con zoom al 200 %. Compruebe que el encabezado fijo no oculta por completo el control enfocado. Abra y cierre el menú con el teclado, provoque un error de formulario y compruebe que puede corregirlo. Anote página, acción y obstáculo; estas pruebas no son una certificación WCAG.
Referencias documentales
Consultado el .
Taller de lectura
Confirmación, almacenamiento y entrega requieren pruebas distintas
El caso ficticio DEMO-F22 sigue un envío repetido y una recarga sin transmitir mensajes reales.
Datos y registros ficticios para aprender: ninguno de estos resultados procede de una consulta en directo.
Un contrato explícito de repetición para K1
La aplicación de demostración prevé que dos POST con K1 y contenido idéntico devuelvan R1 sin crear dos expedientes. Este comportamiento se comprueba aparte del estado HTTP.
Primer POST
- Observación del caso
- K1; 303 hacia /recibo/R1
- Qué establece
- Se observa una redirección de confirmación.
- Acción siguiente
- Guardar método, respuesta e identificador no sensible.
Lectura y recarga
- Observación del caso
- GET /recibo/R1; 200; recarga en GET
- Qué establece
- Esta recarga no repite POST en la secuencia.
- Acción siguiente
- Probar también otra presentación, no solo la página.
Segundo POST idéntico
- Observación del caso
- K1; mismo contenido; recibo R1
- Qué establece
- El caso respeta su contrato de agrupación.
- Acción siguiente
- Comparar el registro de proceso; una clave sola no basta.
Estados internos de demostración
- Observación del caso
- 1 expediente guardado; entrega pendiente
- Qué establece
- Se corrobora almacenamiento, no entrega.
- Acción siguiente
- Mostrar «registrado, entrega pendiente» y seguir la etapa siguiente.
¿Qué conclusión está respaldada?
Abra cada propuesta para comparar su diagnóstico. Pueden seguir siendo necesarios otros controles.
303 demuestra que el destinatario recibió el mensaje.
No: no prueba almacenamiento ni entrega.
Recargar sin repetir demuestra que todo doble clic se gestiona.
No: repetir GET y otro POST son controles distintos.
Un expediente guardado, repetición agrupada y entrega sin confirmar.
Adecuado aquí. Un contenido diferente con K1 requiere otro caso según el contrato.
Registro de repetición y tratamiento
Caso: DEMO-F22 POST 1: K1 → 303 → /recibo/R1 GET y recarga: /recibo/R1; 200 POST 2: K1; contenido idéntico; recibo R1 Registro: un expediente guardado Entrega: pendiente Balance: almacenamiento establecido, recepción no establecida
Relacione recibo, almacenamiento y entrega mediante el identificador de prueba. No coloque contenido personal en URL ni pruebas públicas.
Documentación de las reglas, separada de los ejemplos ficticios
02 / Pruebas que conservar
Pruebas que conservar
Matriz de casos
Entradas, estado esperado, mensaje y resultado de cada caso.
Captura del recorrido
Etiquetas, ayuda, foco, errores, resumen y confirmación en móvil y teclado.
Registro depurado
Estado de respuesta, fecha e identificador ficticio sin datos personales reales.
Decisión
Obstáculo, impacto, corrección, responsable y nueva prueba.
Comparar otras situaciones y ejercicios
PUNTO DE CONTROL
Antes de concluir
Una interpretación errónea frecuente y la comprobación que ayuda a evitarla.
Conclusión precipitada
Un formulario que funciona en una prueba interna puede seguir siendo inutilizable con teclado, en móvil o tras errores de validación.
Comprobación decisiva
Probar cada paso con limitaciones reales: campos obligatorios, errores, conservación de valores, confirmación, uso con teclado y estado del servicio de envío.
TRAS LA REVISIÓN
Decidir según el hallazgo
Un error borra campos ya escritos
Trate la pérdida como fallo del recorrido. Conserve valores no sensibles, sitúe el foco en los errores y repita.
Aparece éxito sin recepción verificable
No dé el recorrido por terminado. Revise respuesta y tratamiento real con datos ficticios y corrija el mensaje.
Decisión y trazabilidad
Decisión y trazabilidad
Qué debe permitir decidir la comprobación y qué conservar para revisar esa decisión.
Prueba suficiente
Pruebe datos válidos, errores, teclado, móvil, valores conservados y confirmación. El éxito de la interfaz no prueba la entrega del correo.
Siguiente decisión
Corrija el primer paso roto y repita el envío completo con destinatario autorizado. Mida accesibilidad y entrega por separado.
Casos de control detallados
Situaciones tipo para preparar un control. No describen misiones realizadas ni observaciones reales.
Un mensaje de éxito no demuestra la recepción
Qué examinar
Distinga envío del navegador, aceptación del servidor y recepción en el sistema destinatario. Utilice un entorno y un destino de prueba autorizados para seguir cada etapa.
Decisión y acción
Describa el resultado al nivel realmente observado. Si solo confirma aceptación, no afirme entrega demostrada; investigue la etapa pendiente y un mecanismo adecuado de recuperación.
Prueba que conservar
Guarde identificadores de prueba no sensibles, horas y estados observados sin copiar secretos ni datos personales innecesarios.
Un error borra las respuestas introducidas
Qué examinar
Pruebe validación rechazada, interrupción de red y regreso al formulario. Compruebe campos conservados, mensajes asociados y posibilidad de corregir y enviar sin empezar de nuevo.
Decisión y acción
Restituya un estado comprensible y conserve valores útiles según su sensibilidad. No coloque el contenido del formulario en una URL para compensar una pérdida de estado.
Prueba que conservar
Guarde secuencia, campos afectados, mensaje mostrado y resultado del segundo intento con valores de prueba.
El rechazo borra la entrada útil
Qué examinar
Probar datos inválidos y revisar errores, idioma y campos conservados.
Decisión y acción
Conservar datos no sensibles útiles sin provocar un envío real.
Prueba que conservar
Entrada de prueba, rechazo esperado, foco y recuperación.
Revisión antes de decidir
Estas preguntas completan el método. Ayudan a determinar lo respaldado sin eliminar las reservas del registro.
Error y recuperación
En un entorno de prueba, ¿explica la entrada inválida el problema sin perder otros campos útiles? Revise teclado, idioma y retorno tras fallo del servidor.
Ver una decisión comentada
Ejemplo ficticio: el estado se refiere únicamente al criterio y alcance descritos.
- Observación ficticia
- Tras un error de dirección de prueba, el formulario borra también asunto y mensaje válidos.
- Estado declarado
- Discrepancia observada
- Decisión y próximo control
- Conserve los datos útiles y explique el error del campo. Repita la recuperación con datos ficticios.
Envío sin duplicación
¿Pueden una doble activación o respuesta tardía generar dos operaciones? Distinga éxito mostrado, recepción confirmada y procesamiento final sin usar datos personales reales.
Ver una decisión comentada
Ejemplo ficticio: el estado se refiere únicamente al criterio y alcance descritos.
- Observación ficticia
- El navegador muestra éxito tras dos activaciones; no se observó el número de tratamientos del servidor.
- Estado declarado
- No comprobado
- Decisión y próximo control
- Mantenga sin verificar la unicidad. En pruebas, relacione identificador, recepción y tratamiento final.
Validación en servidor
En pruebas, ¿se rechaza una petición inválida sin validación del navegador? Un mensaje del cliente no garantiza el tratamiento del servidor.
Documentación consultada : MDN · Constraint validation ·
Ver una decisión comentada
Ejemplo ficticio: el estado se refiere únicamente al criterio y alcance descritos.
- Observación ficticia
- El servidor rechaza una solicitud inválida sin validación del navegador; no se crea tratamiento.
- Estado declarado
- Verificado en este alcance
- Decisión y próximo control
- Conserve entrada ficticia, respuesta y observación del servidor. Repita al cambiar validación o tratamiento.
HERRAMIENTAS / REGISTROS
Información que registrar
Pruebe éxito, error de entrada y fallo de servidor con datos de prueba identificados. Compruebe que el mensaje refleja el resultado real y permite recuperar la entrada.
- Fecha de consulta y zona horaria
- URL exacta
- Tarea / etapa del recorrido
- Dispositivo / navegador
- Resultado esperado
- Resultado observado
- Criterio de validación
- Decisión / próxima acción
- Responsable del control
- Próximo control
03 / FAQ
Preguntas frecuentes
¿Basta validar con JavaScript?
No. Mejora la respuesta inmediata, pero también se necesita validación en el servidor.
¿Señalar campos obligatorios?
Sí, antes de escribir y en el mensaje de error.
¿Qué hacer tras un error?
Explicar la corrección, asociar el mensaje al campo y conservar los demás valores.
¿Cómo probar sin datos sensibles?
Use casos ficticios y registros minimizados.
¿Cómo probar sin enviar solicitudes reales?
Proporcionar un entorno o canal de prueba adecuado y datos fictivos. Sin embargo, el método debe permitir verificar los pasos reales que condicionan la recepción y el tratamiento.
04 / Referencias oficiales
Referencias oficiales
Describir un contexto
REFERENCIAS DOCUMENTADAS
Autocompletado: leer los tokens en el orden correcto
Dos direcciones de un formulario pueden requerir valores distintos aunque sus campos tengan el mismo nombre. autocomplete describe una finalidad y un grupo; no sustituye la etiqueta visible ni la validación. Los ejemplos ilustran la gramática HTML, no identidades ni datos de contacto recopilados.
| Referencia | Valor o forma | Qué identifica |
|---|---|---|
| section-* | 1 | El prefijo section- va primero. Su valor distingue un grupo; el navegador no debe deducir de él parentescos ni significados comerciales. |
| shipping | billing | 2 | shipping o billing indica el destino de los datos. Ambos tokens no pueden coexistir en la misma lista. |
| home | work | mobile | fax | pager | 3 | home, work, mobile, fax o pager puede preceder a un campo de contacto como email o tel-national. work postal-code no sigue esta gramática. |
| name | postal-code | email | … | 4 | Una lista detallada necesita un token de finalidad. address-line1 address-line2 aporta dos donde se espera uno; no describe dos campos. |
| webauthn | 5 | webauthn al final puede indicar credenciales de clave pública con mediación condicional. El atributo no implementa por sí solo la autenticación. |
| on | off | single token | on y off, solos en un campo visible aplicable, son modos generales, no finalidades detalladas. No se permiten como tales en input type=hidden. |
Leer 16 ejemplos de tokens
Los ejemplos tratan campos visibles del tipo indicado. Aíslan la gramática: no ejecutan autocompletado ni autenticación.
<input type="text" autocomplete="section-primary shipping work email">
Lista detallada ordenada · Grupo, destino, contacto y finalidad: orden del ejemplo ACT publicado.
| Atributo autocomplete | Tipo de campo | Lectura | Interpretación |
|---|---|---|---|
| section-primary shipping work email | text | Lista detallada ordenada | Grupo, destino, contacto y finalidad: orden del ejemplo ACT publicado. |
| section-blue shipping postal-code | text | Lista detallada ordenada | Dos grupos permiten separar direcciones de envío manteniendo la finalidad postal-code. |
| section-red shipping postal-code | text | Lista detallada ordenada | Dos grupos permiten separar direcciones de envío manteniendo la finalidad postal-code. |
| billing postal-code | text | Lista detallada ordenada | Destino y finalidad; el grupo de sección es opcional. |
| mobile tel-national | tel | Lista detallada ordenada | El modificador de contacto precede a una finalidad telefónica. |
| current-password webauthn | password | Lista detallada ordenada | Ejemplo ACT: finalidad de contraseña seguida del token de credencial de clave pública. |
| given-name | text | Lista detallada ordenada | Basta una finalidad; los prefijos son opcionales. |
| on | text | Modo general | Modo general sin finalidad detallada; la regla ACT 73f2c2 excluye este caso de su ámbito. |
| off | text | Modo general | Modo general sin finalidad detallada; la regla ACT 73f2c2 excluye este caso de su ámbito. |
| work shipping email | Lista incorrecta | El modificador de contacto precede al destino: orden incorrecto. | |
| work,email | Lista incorrecta | La coma no separa tokens en esta lista HTML. | |
| address-line1 address-line2 | text | Lista incorrecta | Dos finalidades distintas ocupan un lugar que admite solo una. |
| shipping | text | Lista incorrecta | El destino solo no aporta ninguna finalidad. |
| work photo | text | Lista incorrecta | work no puede modificar photo: no es un campo de contacto. |
| email invalid | Lista incorrecta | El token adicional invalid no se permite después de la lista. | |
| current-password webauthn invalid | password | Lista incorrecta | El token adicional invalid no se permite después de la lista. |
Qué conservar en el expediente
Un orden correcto no demuestra que la finalidad corresponda al campo, que se complete automáticamente ni que el formulario cumpla WCAG 1.3.5. El criterio trata determinadas informaciones sobre el usuario y depende de la tecnología. Los ejemplos no examinan formularios externos.
Documentación primaria
Documentación consultada el .
Comprobaciones complementarias
PROFUNDIZACIÓN / PRÁCTICA
Probar los formularios con casos realistas
Un formulario aparece normalmente, pero rechaza una entrada legítima o confirma un envío que no termina. La prueba de funcionamiento distingue la calidad de entrada, validación y tratamiento final.
Actualizado el .
Comprobaciones prioritarias
Probar campos obligatorios, formatos, longitud, errores, consentimiento y doble presentación. Utilizar datos de prueba y controlar el resultado real sin transmitir contenido confidencial.
Errores de interpretación
Un botón activo o un mensaje de éxito no es suficiente para demostrar el fin del tratamiento. Los casos de expiración de la sesión y de inaccesibilidad también deben permanecer comprensibles.
Documento de trabajo que conservar
El fichero de prueba de funcionamiento conserva datos de prueba no sensibles, paso, resultado esperado y resultado observado. Cada corrección se acompaña de un control completo del recorrido.