Respuesta breve
Aceptar una web son unas horas de comprobación con lista, no la impresión que deja la portada. Empiece por el teléfono con datos móviles, siga los formularios hasta el destinatario, aplique WCAG 2.2 y envíe una sola lista de incidencias.
La aceptación de una web, en breve
La aceptación es una revisión estructurada de la web terminada frente a lo que usted encargó, hecha antes del pago final y antes de firmar nada. Ocupa unas horas y se hace con una lista escrita, no con la impresión que deja la portada.
El orden importa: primero el teléfono con una conexión débil, después el contenido de las páginas frente al briefing, después los formularios hasta el destinatario, después las comprobaciones de WCAG 2.2 y, por último, navegación, carga y panel de administración.
Aceptar no consiste en repartir culpas. Sirve para dejar por escrito qué funciona y qué hay que corregir, y para confirmar que esa lista cabe dentro de las rondas de revisión que su paquete incluye realmente, en lugar de desbordarlas.
A continuación hay doce bloques de comprobación. Cada uno se puede hacer sin herramientas especiales: basta con un teléfono, un portátil, un navegador y una hora en la que nadie le interrumpa con preguntas de otro asunto.
Qué preparar antes de empezar a probar
Antes del primer clic, reúna tres documentos: el briefing o el pliego, la lista de páginas y funciones que entraban en el alcance, y los correos donde se acordaron cambios durante el proyecto. Sin eso, la revisión acaba siendo una conversación sobre gustos.
Pida la dirección exacta que va a revisar. Puede ser un dominio de pruebas o el definitivo, pero tiene que ser la misma para usted y para el proveedor; de lo contrario acabarán discutiendo sobre dos versiones distintas de la misma página.
Tenga a mano dos dispositivos: su teléfono de siempre y un portátil. No revise solo en el equipo de trabajo, con internet rápido de oficina y un monitor ancho, porque enseña la web en condiciones que sus visitantes quizá no tengan nunca.
Abra una tabla vacía con estas columnas: página, qué ocurre, qué esperaba, dispositivo y navegador, prioridad. Se escribe sobre la marcha, y no dos días después intentando reconstruir de memoria cómo estaba formulado aquel fallo.
Empiece por el teléfono y una conexión lenta
Abra la web en el teléfono antes que en el portátil. Los fallos de maquetación que pasan desapercibidos en una pantalla ancha se ven de inmediato en una estrecha, y conviene encontrarlos ahora y no en el mensaje de un cliente.
Apague el Wi-Fi y navegue por la red móvil, a ser posible en un sitio con poca cobertura. Ahí deja de ocultar cosas el internet rápido de la oficina: la espera hasta el primer texto legible, la maquetación que salta, las imágenes que llegan al final.
En el teléfono compruebe tres cosas: si el texto cabe sin desplazamiento lateral, si el dedo acierta de verdad en botones y enlaces, y si una cabecera fija o un aviso de consentimiento tapa justo aquello por lo que se entra en la página.
La documentación de rendimiento de MDN trata también el rendimiento percibido, no solo la velocidad de carga: la sensación de que la interfaz responde. Esa sensación es lo que usted comprueba al abrir la web en la calle y no en la mesa del desarrollador.
Contenido: el briefing frente a la página publicada
Coja la lista de páginas del briefing y recórrala línea por línea. Cada página prometida tiene que existir, abrirse desde un enlace directo y contener el bloque por el que se encargó, y no un párrafo de relleno provisional heredado de la maqueta.
Lea los textos buscando erratas, precios antiguos, el nombre de otra empresa y restos de datos de demostración. Conviene recordarlo aquí: VITON13 no redacta el contenido del cliente ni las traducciones, así que revisar las palabras sigue siendo responsabilidad suya.
Contraste los datos de contacto en todos los sitios donde aparecen: cabecera, pie, página de contacto, datos estructurados y mensaje que se muestra al enviar el formulario. Un dígito equivocado en el teléfono le cuesta en silencio las llamadas que debía traer.
Mire las imágenes aparte: productos correctos, sin marcas de agua de bancos de fotos, orientación acorde con el diseño. Revise también su texto alternativo: en WCAG 2.2 es el criterio 1.1.1, Contenido no textual, de nivel A.
Formularios de principio a fin: hasta el destinatario
Un formulario se acepta cuando la solicitud llega a la persona que la contesta, y no cuando el botón responde al clic. Probar hasta el botón es aceptar media función y enterarse del resto por un cliente que ya se ha perdido.
Envíe una solicitud de prueba con datos reales y siga todo el recorrido: pantalla de agradecimiento, correo al buzón de la empresa, correo al cliente y registro en el CRM o en la hoja de cálculo, si eso entraba en el alcance.
Después rompa el formulario a propósito: envíelo vacío, escriba letras en el campo de teléfono, use una dirección sin arroba, adjunte un archivo demasiado grande. Los mensajes de error deben ser texto junto al campo y decir qué hay que cambiar.
En términos de WCAG 2.2 son los criterios 3.3.1, Identificación de errores, y 3.3.2, Etiquetas o instrucciones, de nivel A, más 3.3.3, Sugerencias ante errores, de nivel AA. Un borde rojo y la palabra Error, sin nada más al lado, no los cumple.
Accesibilidad: comprobaciones de WCAG 2.2 que puede hacer usted
WCAG 2.2 es una Recomendación del W3C con tres niveles de conformidad: A, AA y AAA. Si su contrato no nombra ninguno, trabaje con AA y tenga en cuenta que buena parte de sus criterios se comprueban a mano, sin auditor y sin herramientas de pago.
El contraste del texto, según el criterio 1.4.3 de nivel AA, es de 4,5:1 para el texto normal y de 3:1 para el texto grande. Los bordes de los campos, los iconos y los controles de interfaz caen bajo el criterio 1.4.11, con un umbral de 3:1.
El criterio 2.5.8, Tamaño del objetivo (mínimo), de nivel AA e incorporado en la versión 2.2, pide un área de pulsación de al menos 24 por 24 píxeles CSS, con las excepciones que el propio criterio enumera. Mire los iconos pequeños del pie y las flechas de las galerías.
Otras dos incorporaciones de la 2.2 corresponden a la revisión de formularios: 3.3.7, Entrada redundante, de nivel A, según el cual no se deben volver a pedir sin motivo datos ya introducidos en el mismo proceso, y 3.3.8, Autenticación accesible, de nivel AA, si hay inicio de sesión.
Teclado, foco y ampliación
Aparte la mano del ratón y recorra la portada con la tecla Tab. Debería ver en todo momento dónde está el foco, el orden debería coincidir con el visual, y los menús, las ventanas modales y los reproductores tienen que dejarle salir.
Son los criterios 2.1.1, Teclado, y 2.1.2, Sin trampas para el foco del teclado, de nivel A, más 2.4.7, Foco visible, de nivel AA. La versión 2.2 añadió 2.4.11, Foco no oculto (mínimo), de nivel AA, que conviene probar contra cabeceras fijas y barras de cookies.
Pruebe la ampliación: agrande el texto al 200 por ciento, ya que el criterio 1.4.4 de nivel AA exige que el contenido y las funciones sigan siendo utilizables. Después estreche la ventana del navegador hasta unos 320 píxeles CSS y confirme que no aparece desplazamiento horizontal.
Si la interfaz usa arrastre, como reordenar tarjetas, un control deslizante o una zona para soltar archivos, el criterio 2.5.7 de nivel AA pide una alternativa con un solo puntero que no exija arrastrar, salvo que el gesto sea esencial para la tarea.
Navegación, enlaces y estados de error
Recorra todos los elementos del menú y todos los enlaces del pie. Cada uno tiene que llevar a una página que existe en esta web, y no a un borrador, ni al dominio del proveedor, ni a una página que usted pidió retirar hace semanas.
Escriba una dirección que sepa que no existe. Debería aparecer una página 404 con el diseño del sitio, con el menú y con una salida hacia la portada, y no un mensaje del servidor ni una pantalla en blanco con una línea técnica.
Revise los estados vacíos: una búsqueda sin resultados, un carrito sin productos, un catálogo filtrado hasta quedarse sin nada. En cada caso el visitante tiene que entender qué ha pasado y qué puede hacer a continuación.
Mire también la fontanería: el título de la pestaña debe cambiar en cada página y describirla, criterio 2.4.2 de nivel A, y el idioma de la página debe estar declarado, criterio 3.1.1 del mismo nivel.
Velocidad y comportamiento de carga
La velocidad se juzga en el mismo teléfono y en la misma red, y no en un informe hecho en condiciones ideales. Abra la web en frío, sin datos guardados previamente, y observe cuánto tarda en aparecer el primer texto legible.
Fíjese en los desplazamientos de maquetación. Si ya se lee un texto y luego una imagen o un banner tardío lo empuja hacia abajo, eso es un defecto de aceptación y no una peculiaridad. Esos saltos provocan pulsaciones erróneas y hacen perder el punto de lectura.
Las herramientas de desarrollo del navegador incluyen una limitación de red que simula una conexión lenta. La documentación de rendimiento de MDN insiste en medir tanto la carga como la respuesta de la interfaz, y no una única cifra de titular.
No exija una puntuación concreta en una herramienta externa si no estaba en el contrato. Formule el hallazgo como comportamiento: en el teléfono, con datos móviles, la primera pantalla aparece bastante más tarde que en el portátil. Eso sí se puede verificar.
El panel de administración: ¿puede editar sin romper nada?
Entre con su propia cuenta y no con la del desarrollador. Confirme que tiene el rol de propietario o administrador y que ve todas las secciones que se comentaron como algo que usted mismo iba a editar después del lanzamiento.
Haga una edición real: cambie un titular en una página, añada un párrafo, suba una imagen, guarde y compruebe el resultado en la versión pública. Si para algo de eso hace falta un desarrollador, esta parte del trabajo todavía no está aceptada.
Compruebe que editar no rompe la maquetación: un titular largo debe partirse en varias líneas y no salirse de su bloque, y una imagen con un tamaño imprevisto debe seguir encajando. Pegue a propósito una palabra larguísima y un párrafo larguísimo.
Acuerde el límite. El contenido lo edita usted; las plantillas y la lógica las cambia el proveedor. En Soporte técnico continuo, a $290 al mes, el volumen de ese trabajo se acuerda al inicio de cada ciclo.
Cómo redactar la lista de incidencias y ajustarla a las rondas
Envíe un solo mensaje con una sola lista, y no diez mensajes a lo largo del día. Cada punto indica página, dispositivo, qué ocurrió y qué esperaba, y lleva una captura cuando se pueda. Un mensaje que dice que algo queda raro vuelve convertido en pregunta.
Divida la lista en dos: lo que impide usar la web y lo que ahora preferiría de otra manera. Lo primero son defectos y lo segundo son peticiones nuevas, y cada grupo afecta de forma distinta al calendario y a las revisiones ya pagadas.
El número de rondas depende del paquete y no se traslada de uno a otro. Sitio para lanzamiento, a $380 y con un plazo de 3-5 días laborables, incluye 2 rondas antes del lanzamiento. Desarrollo de producto, a $880 en 2-3 semanas, incluye 2 rondas por cada función entregada.
Site Fix Pack, a $70 y en 1-2 días laborables, es 1 ronda y hasta cinco correcciones acordadas, con revisión en móvil y escritorio y una lista de antes y después en la entrega. Launch Site Express, a $520 y en 2 días laborables, es 1 ronda tras la primera compilación completa.
Firma y qué ocurre después de la aceptación
Firme cuando los puntos de su lista estén cerrados y vueltos a comprobar en el mismo teléfono con el que empezó. La segunda pasada lleva bastante menos tiempo que la primera, porque para entonces ya se conoce el recorrido por el sitio.
Deje por escrito qué queda fuera del trabajo: el contenido y las traducciones, si por acuerdo corren de su parte, o las aplicaciones móviles nativas y el licenciamiento de pagos, que no forman parte de Desarrollo de producto.
Decida qué pasa después con la web. Los arreglos puntuales tras el lanzamiento encajan en Site Fix Pack, mientras que las actualizaciones prioritarias, un ritmo semanal de publicaciones y el mantenimiento técnico corresponden a Soporte técnico continuo, a $290 al mes, con ciclo mensual y 30 días de preaviso para detenerlo.
Y guarde la propia lista de verificación. Dentro de seis meses, cuando acepte el siguiente trabajo o cambie de proveedor, un recorrido que ya ha hecho le ahorra una tarde y zanja la discusión sobre qué se considera terminado.
Lista práctica
- Abra la web en su propio teléfono con datos móviles y no con el Wi-Fi de la oficina.
- Recorra la lista de páginas del briefing y marque lo que falta o sigue siendo un texto provisional.
- Envíe una solicitud de prueba y sígala hasta el buzón de la empresa, hasta el cliente y hasta el CRM.
- Recorra la portada con la tecla Tab y confirme que el foco se ve y que las ventanas modales le dejan salir.
- Compruebe el contraste del texto y los tamaños de objetivo con los criterios 1.4.3, 1.4.11 y 2.5.8.
- Reúna todos los hallazgos en una tabla priorizada y envíela en un único mensaje.
Preguntas frecuentes
¿Cuánto tiempo lleva aceptar una web?
Cuente con unas horas de trabajo sin interrupciones, no con un vistazo rápido. El tiempo se va en recorrer una lista escrita desde el teléfono y el portátil, enviar solicitudes de prueba y anotar lo que encuentra. Repartirlo en dos sesiones está bien; enviar los hallazgos en diez mensajes sueltos, no.
¿Con qué dispositivo conviene empezar?
Con su propio teléfono y datos móviles, no con el Wi-Fi de la oficina. Un monitor ancho con internet rápido oculta los fallos de maquetación en pantalla estrecha, las imágenes que llegan tarde y la espera hasta el primer texto legible.
¿Cuántas rondas de revisión incluyen los paquetes de desarrollo?
Depende del paquete y nunca se traslada de uno a otro. Site Fix Pack, a $70 y en 1-2 días laborables, incluye 1 ronda. Sitio para lanzamiento, a $380 y en 3-5 días laborables, incluye 2 rondas antes del lanzamiento. Desarrollo de producto, a $880 en 2-3 semanas, incluye 2 rondas por cada función entregada. Launch Site Express, a $520 y en 2 días laborables, incluye 1 ronda tras la primera compilación completa.
¿Qué hago si aparecen problemas después de firmar?
Las correcciones pequeñas y bien descritas encajan en Site Fix Pack, a $70: hasta 5 arreglos acordados en 1-2 días laborables, con revisión en móvil y escritorio y una lista de antes y después en la entrega. No cubre páginas nuevas, rediseño ni migraciones. Para un ritmo continuado está Soporte técnico continuo, a $290 al mes, con ciclo mensual y 30 días de preaviso para detenerlo, donde el volumen se acuerda al inicio de cada ciclo.
¿Hacen falta las comprobaciones de accesibilidad en una web pequeña?
Las comprobaciones de WCAG 2.2 que aquí se enumeran no requieren auditor ni herramientas de pago: contraste, orden de tabulación, foco visible, tamaño de objetivo y errores claros en los formularios. De paso detectan problemas corrientes de usabilidad, porque un control demasiado pequeño y un mensaje de error sin explicación estorban a todo el mundo.