Inline Editing

Un campo editable que visualmente no se distingue de texto estático obliga al usuario a hacer prueba-y-error para descubrir qué puede modificar. El mínimo viable es un cambio de cursor a text, un borde visible al hover y un ícono de lápiz junto al valor. Revelar la editabilidad solo en hover es un affordance oculto: carga riesgo de descubribilidad porque el usuario puede no encontrarlo nunca a menos que otro señalizador insinúe su existencia. PatternFly acompaña el hover con highlight de fondo más tooltip, nunca lo deja invisible.

Cuando un campo pasa de lectura a edición la transformación debe ser explícita: aparece un input real con borde, fondo y caret, y surgen los controles de confirmar/cancelar. Mantener el mismo aspecto en ambos modos, o peor, mostrar siempre inputs activos, confunde al usuario sobre si ya está editando. Atlassian advierte que sin un readView y un editView custom alineados, las vistas no coinciden y la transición queda inconsistente. El estado de edición y el de lectura deben diferir en al menos dos señales visuales.

Elegir entre guardar explícito y autosave no es estético: es de riesgo del dato. Inputs con valores críticos (nombres, precios, fechas de contrato) deben requerir confirmación explícita (Enter o botón) para evitar guardados accidentales al perder el foco; GitHub Primer reserva el guardado automático para controles imperativos (toggles, single-select) y exige explícito para los declarativos (text inputs, checkboxes). El autosave en blur solo es aceptable en campos simples y de bajo impacto con undo fácil. Nunca mezcles ambos patrones en un mismo formulario: GitLab dispara autosave en blur o 3 s tras la última pulsación, lo que primero ocurra.

Escape es el contrato universal de "deshacer lo que acabo de empezar". En cualquier campo inline editable, presionar Escape debe salir del modo edición y restaurar el valor exacto que había antes, sin guardar cambios parciales. El patrón de grid del WAI-ARIA APG lo refuerza: Escape restaura la navegación del grid y, si había contenido en edición, puede deshacer las ediciones. Hacer que Escape guarde, o que desactive el input sin restaurar el valor, viola la expectativa del usuario y puede causar pérdida de datos.

La validación inline debe operar dentro del campo en edición, mostrando el error cerca (mensaje bajo el input o tooltip al lado) sin afectar otras celdas ni forzar a reescribir. El error debe explicar el problema y cómo resolverlo, y el campo no debe cerrarse al detectarlo: permanece abierto en modo edición para que el usuario corrija. Atlassian recomienda incluso mantener la vista de edición abierta en blur para áreas de texto, y borra los mensajes de error en cuanto se cumple el criterio. Nunca descartes el valor del usuario en silencio cuando falla la validación.

En grids editables la navegación opera en dos modos: navegación (las flechas mueven el foco entre celdas) y edición (las teclas operan dentro del input). El WAI-ARIA APG define la transición: Enter o F2 activan la edición en la celda enfocada; un segundo F2 o Escape restauran la navegación; Tab/Shift+Tab mueven entre widgets dentro de la celda. Mientras las flechas mueven el foco entre celdas, no están disponibles para mover el caret. El foco nunca debe quedar atrapado dentro de una celda: violaría WCAG 2.1.2 (No Keyboard Trap, Nivel A).

Un error de red o servidor al guardar una edición inline no debe resultar en pérdida silenciosa del trabajo. El campo debe quedar en estado de error con el valor intentado conservado, mostrando un mensaje persistente con opción de reintentar. GitHub Primer es tajante: si el guardado falla, el dato del usuario debe preservarse en el formulario y debe recibir feedback del fallo. GitLab muestra un toast "Failed to save changes" con reintento manual que permanece visible hasta que el guardado tenga éxito. Revertir al valor original sin avisar es pérdida de datos desde la perspectiva del usuario.

La transición lectura↔edición es puramente visual y resulta invisible a tecnología asistiva sin los atributos ARIA correctos. Las celdas en lectura llevan aria-readonly="true" y las editables false; MDN aclara que con aria-readonly="true" el usuario puede leer pero no fijar el valor del widget. Los errores de validación se vinculan con aria-describedby y se anuncian vía aria-live="polite" sobre una región que realmente cambia. Un div contenteditable sin rol ni aria-label deja al lector anunciando "editar" genérico, sin contexto del campo ni del valor.

<td role="gridcell" aria-readonly="true">María</td>

<!-- al editar -->
<input
  aria-label="Nombre del contacto"
  aria-describedby="err-nombre" />
<span id="err-nombre"
  role="alert" aria-live="polite">Nombre requerido</span>

<div contenteditable="true">María</div>

<!-- sin role, sin aria-readonly,
     sin aria-label ni live region -->
<!-- el lector anuncia "editar"
     genérico; los errores no se oyen -->