Conditional Visibility

Cuando un radio o checkbox revela campos adicionales, esos campos deben aparecer directamente debajo de la opción que los activa, no al final del formulario ni en un panel lateral. El patrón GOV.UK "conditional reveal" posiciona cada bloque revelado como hijo visual inmediato de su disparador (dentro de .govuk-radios__conditional), preservando la relación semántica y espacial entre la pregunta original y la derivada. Esa proximidad reduce la carga cognitiva: el usuario nunca pierde el contexto de por que apareció ese campo.

Los <select> ocultan sus opciones hasta desplegarse, lo que impide rastrear cual opción activo un campo revelado. Los radios mantienen todas las opciones visibles y dejan ver el disparador sin abrir ningun control adicional. Además, los selects personalizados son notoriamente difíciles de hacer accesibles: su semántica nativa varia entre plataformas y su comportamiento en móvil difiere del de desktop. GOV.UK usa exclusivamente radios y checkboxes (nunca selects) para su patrón de conditional reveal.

Los lectores de pantalla no perciben cambios visuales de visibilidad sin señales programaticas. El control disparador debe llevar aria-expanded="true/false" y aria-controls apuntando al id del bloque revelado, para que el lector anuncie "expandido" o "contraido" al cambiar de estado. GOV.UK documenta que sin estos atributos su patrón "fails WCAG 2.2 success criterion 4.1.2 Name, role, value", porque el usuario podría completar el form sin haber llenado el campo revelado que nunca le fue anunciado.

<input type="radio"
  aria-expanded="true"
  aria-controls="company-block">

<div id="company-block">
  <input name="company">
</div>

<input type="radio">
  /* sin aria-expanded */
  /* sin aria-controls */

<div style="display:none">
  <input name="company">
</div>

En un reveal inline (misma página, no un nuevo paso), mover el foco programaticamente al primer campo revelado interrumpe el flujo natural del teclado: el usuario salta abruptamente hacia abajo en el DOM y pierde el contexto de donde estaba. El comportamiento correcto es que el foco permanezca en el radio/checkbox y el usuario navegue al campo revelado con Tab. Robar el foco con focus() es especialmente confuso para usuarios de lectores de pantalla que exploran el contexto circundante con flechas; ese método se reserva para resultados de acciones explicitas (dialogos, errores).

Revelar multiples campos o un sub-formulario completo desde un radio aumenta la carga cognitiva y confunde a los usuarios de lectores de pantalla, que no perciben visualmente la estructura emergente. GOV.UK define como umbral máximo "a single input field" para el reveal inline: "If the related question is complicated or has more than one part, show it on the next page in the process instead." Cuando la pregunta derivada tiene varias partes, es más claro y accesible dirigir al usuario a una pantalla dedicada con esa pregunta en contexto propio.

Si un campo es obligatorio para completar la tarea (el email de notificación, el RFC para factura), ocultarlo detras de un reveal aumenta el riesgo de que el usuario intente enviar sin haberlo llenado. El error de validación que aparece sobre un campo invisible, o que el usuario no supo que existia, viola el espiritu de WCAG 3.3.1 Error Identification: el item en error debe identificarse y describirse en texto. Los campos verdaderamente criticos deben estar visibles por defecto o en pasos dedicados con indicación clara de que son necesarios.

Cuando un usuario llena un campo revelado, cambia de opción (colapsando ese campo) y luego regresa a la opción original, el valor debe restaurarse automáticamente. Borrarlo al colapsar obliga a reingresarlo, lo que es especialmente penoso en campos de texto largo. La lógica correcta es ocultar el campo del DOM pero conservar su valor en estado (JavaScript o atributo hidden), y eliminarlo solo al enviar si la condición no esta activa. La validación de campos relacionados también depende de esto.

WCAG 3.2.2 On Input prohibe que cambiar el valor de un control cause automáticamente un cambio de contexto: navegar a otra página, enviar el form o abrir una ventana sin aviso previo. Revelar campos en la misma página al seleccionar un radio NO viola este criterio, siempre que el layout general permanezca estable y el usuario no sea redirigido. W3C cita como ejemplo valido un form que muestra campos distintos según el tipo de evento. Lo que si lo viola es un <select> que recarga la página o un fetch que reemplaza secciones mayores del form.