DEV Community: Franklin

Notas desde el pase: El nombre que ya era correcto

Franklin — Sat, 03 Oct 2026 12:22:18 +0000

También disponible en Inglés

La afirmación a prueba

El ensayo del jueves sostuvo que ARIA es una intervención semántica: debe suministrar lo que el documento nativo no expresa por sí mismo, no reemplazar lo que sí expresa. La afirmación se probó contra dos errores enviados a producción en el mismo control de navegación: un aria-label que reemplazó un nombre accesible correcto, y un <div role="button"> sustituyendo a un control que ya existía como <button>.

Esta Nota desarmó ambos, una pieza a la vez, y confirmó qué queda una vez que todo lo innecesario se retira.

Reducción uno: El botón

Tal como se envió a producción:

<button aria-label="Dismiss navigation panel">
  Close menu
</button>

Antes de tocar nada, recorre el cálculo del nombre accesible de la forma en que el navegador realmente lo ejecuta. aria-labelledby: no presente. aria-label: presente, valor "Dismiss navigation panel". El cálculo se detiene allí. Nunca llega al contenido del propio botón, porque nada le exige seguir buscando una vez que un paso anterior ya produjo una respuesta.

Quita el único atributo:

<button>
  Close menu
</button>

Recorre el cálculo de nuevo. aria-labelledby: no presente. aria-label: no presente. Contenido: "Close menu", y <button> es uno de los roles de los que el cálculo lee un nombre directamente. Ese es el nombre accesible ahora. Siempre pudo haberlo sido. No se agregó nada para producirlo. El único cambio fue eliminar lo que lo estaba superando en prioridad.

Reducción dos: El Div

El segundo control de la misma revisión, completo:

<div role="button" tabindex="0" class="menu-close">
  Close menu
</div>

const closeControl = document.querySelector('.menu-close');

closeControl.addEventListener('click', closeMenu);
closeControl.addEventListener('keydown', (event) => {
  if (event.key === 'Enter' || event.key === ' ') {
    event.preventDefault();
    closeMenu();
  }
});

Quita primero el handler de keydown, deja todo lo demás:

<div role="button" tabindex="0" class="menu-close">
  Close menu
</div>

document.querySelector('.menu-close').addEventListener('click', closeMenu);

El div todavía se anuncia como un botón. Todavía es alcanzable mediante Tab. El clic todavía cierra el menú. Presiona Enter o Espacio en su lugar, y no sucede absolutamente nada: role="button" nunca vino con la activación por teclado que un botón real proporciona de forma automática. Ese siempre fue el trabajo del handler de keydown, y es la única pieza que acaba de salir.

Quita el resto y cambia el elemento:

<button class="menu-close">
  Close menu
</button>

document.querySelector('.menu-close').addEventListener('click', closeMenu);

Un listener, sin cambios. Sin atributo role, sin tabindex, sin handler de keydown. Tab todavía lo alcanza. El clic todavía cierra el menú. Enter y Espacio también lo cierran, porque un botón nativo dispara el mismo evento click en respuesta a los tres, sin que se le ordene hacerlo. El div necesitaba dos asignaciones de eventos separadas para cubrir lo que la etiqueta ahora cubre con una.

Si la afirmación se mantuvo

Ambas reducciones llegan a la respuesta que predice la tesis del ensayo: un documento cuyas semánticas tienen la cantidad justa, ni más ni menos. El botón nunca necesitó una etiqueta: el contenido ya estaba haciendo ese trabajo, y lo único que se interponía en su camino era un atributo agregado para satisfacer una lista de verificación. El div nunca necesitó ser un div. Llevaba un role, un tabindex y un handler de keydown para simular un comportamiento que <button> siempre iba a proporcionar por sí solo, por una asignación de evento menos de las que el div jamás logró manejar.

Ninguna de las dos correcciones agregó nada. Ambas restaron exactamente la pieza que sustituía a algo que la plataforma ya tenía, y el resultado en cada caso no fue una versión más pequeña de lo mismo. Fue la cosa funcionando correctamente por primera vez.

Artículo de referencia:

El navegador ya cuenta con una arquitectura de accesibilidad. La mayoría de los proyectos la ignoran.

Notes from the Pass: The Name That Was Already Right

Franklin — Sat, 03 Oct 2026 12:19:33 +0000

Also available in Español

The Claim Being Tested

Thursday's essay argued that ARIA is a semantic intervention: it should supply what the native document doesn't already express, not replace what it does. The claim was tested against two shipped mistakes on the same navigation control — an aria-label that replaced a correct accessible name, and a <div role="button"> standing in for a control that already existed as <button>.

This Note takes both apart, one piece at a time, and confirms what's left once everything unnecessary comes off.

Reduction One: The Button

As shipped:

<button aria-label="Dismiss navigation panel">
  Close menu
</button>

Before touching anything, walk the accessible name computation the way the browser actually runs it. aria-labelledby: not present. aria-label: present, value "Dismiss navigation panel." The computation stops there. It never reaches the button's own content, because nothing requires it to keep looking once an earlier step has already produced an answer.

Remove the one attribute:

<button>
  Close menu
</button>

Walk the computation again. aria-labelledby: not present. aria-label: not present. Content: "Close menu," and <button> is one of the roles the computation reads a name from directly. That's the accessible name now. It always could have been. Nothing was added to produce it. The only change was removing the thing that had been outranking it.

Reduction Two: The Div

The same review's second control, in full:

<div role="button" tabindex="0" class="menu-close">
  Close menu
</div>

const closeControl = document.querySelector('.menu-close');

closeControl.addEventListener('click', closeMenu);
closeControl.addEventListener('keydown', (event) => {
  if (event.key === 'Enter' || event.key === ' ') {
    event.preventDefault();
    closeMenu();
  }
});

Strip the keydown handler first, leave everything else:

<div role="button" tabindex="0" class="menu-close">
  Close menu
</div>

document.querySelector('.menu-close').addEventListener('click', closeMenu);

The div still announces as a button. It's still reachable by Tab. Click still closes the menu. Press Enter or Space instead, and nothing happens at all — role="button" never came with the keyboard activation a real button provides automatically. That was always the keydown handler's job, and it's the only thing that just left.

Strip the rest, and change the element:

<button class="menu-close">
  Close menu
</button>

document.querySelector('.menu-close').addEventListener('click', closeMenu);

One listener, unchanged. No role attribute, no tabindex, no keydown handler. Tab still reaches it. Click still closes the menu. Enter and Space close it too, because a native button fires the same click event in response to all three, without being told to. The div needed two separate event bindings to cover what the tag now covers with one.

Whether the Claim Held

Both reductions land on the answer the essay's thesis predicts: a document whose semantics are the correct amount, no more and no less. The button never needed a label — content had already been doing that job, and the only thing standing in its way was an attribute added to satisfy a checklist. The div never needed to be a div. It was carrying a role, a tabindex, and a keydown handler to simulate behavior <button> was always going to provide on its own, for one less event binding than the div ever managed.

Neither fix added anything. Both subtracted exactly the piece that was substituting for something the platform already had, and the result in each case wasn't a smaller version of the same thing. It was the thing working correctly for the first time.

Reference Article:

The Browser Already Has an Accessibility Architecture. Most Projects Ignore It.

Notas desde el pase: Cada menú apuntaba a la misma fila

Franklin — Sat, 03 Oct 2026 12:16:14 +0000

También disponible en Inglés

La afirmación a prueba

El ensayo del martes sostuvo que el anclaje implícito ya resuelve el caso ordinario del popover sin costo alguno. Un popover vinculado a su propio activador (trigger) no necesita nombres, ni scoping, ni nada más. La brecha solo aparece cuando un requisito real sale de ese caso y, aun así, solo en combinación con algo fácil de pasar por alto: la estructura del DOM heredada de antes de que la plataforma resolviera el recorte de superposiciones (overlay clipping), cuando las superposiciones debían vivir separadas de aquello que las activaba.

Esta Nota reproduce exactamente esa combinación —un nombre de anchor compartido y un popover ubicado como hermano en lugar de descendiente— a lo largo de un grid de múltiples filas real, y confirma si aplicar el scope realmente corrige cada fila y no solo la que se probó por casualidad.

Míralo romperse

Cuatro filas, cada una con su propio menú de acciones, construidas de la manera descrita en el ensayo:

<div class="grid">
  <div class="grid-row">
    Q3 Report <button popovertarget="menu-1">⋮</button>
  </div>
  <menu id="menu-1" popover>
    <button>Rename</button><button>Archive</button><button>Delete</button>
  </menu>

  <div class="grid-row">
    Q4 Report <button popovertarget="menu-2">⋮</button>
  </div>
  <menu id="menu-2" popover>
    <button>Rename</button><button>Archive</button><button>Delete</button>
  </menu>

  <div class="grid-row">
    Annual Summary <button popovertarget="menu-3">⋮</button>
  </div>
  <menu id="menu-3" popover>
    <button>Rename</button><button>Archive</button><button>Delete</button>
  </menu>

  <div class="grid-row">
    Budget Draft <button popovertarget="menu-4">⋮</button>
  </div>
  <menu id="menu-4" popover>
    <button>Rename</button><button>Archive</button><button>Delete</button>
  </menu>
</div>

.grid-row {
  anchor-name: --row-anchor;
}

[popover] {
  position-anchor: --row-anchor;
  position-area: right;
}

Haz clic en el : de "Q3 Report". El menú se abre —popovertarget maneja esa parte correctamente sin importar qué suceda— y se posiciona junto a "Budget Draft", la última fila del grid. Haz clic en el : de "Annual Summary". La misma posición. Haz clic en el de "Q4 Report". La misma posición de nuevo. Cada menú, de cada fila, cae exactamente en el mismo lugar: dondequiera que se ubique el último .grid-row.

Por qué nada lo detuvo

Cada <menu popover> se ubica directamente después de su propio .grid-row, como hermano; ambos son hijos de .grid. Ninguno contiene al otro. Cuando el navegador resuelve position-anchor: --row-anchor para cualquiera de los cuatro menús, busca primero el ancestro más cercano que lleve ese nombre y no encuentra ninguno, porque ningún menú está anidado dentro de una fila. Sin un ancestro que preferir, la resolución cae en la única regla que queda en pie: el último elemento del documento que lleve ese nombre de anchor. Las cuatro filas comparten exactamente el mismo nombre, establecido a través de la misma clase que cada fila ya utiliza para su diseño (layout). "Budget Draft" gana siempre, para cada menú, independientemente del botón en el que se haya hecho clic.

La solución

Nada cambia respecto al nombre del anchor, ni tampoco sobre el botón. Cada fila y su propio menú se envuelven juntos, y el nombre del anchor se limita a ese contenedor (wrapper):

<div class="grid">
  <div class="row-wrapper">
    <div class="grid-row">
      Q3 Report <button popovertarget="menu-1">⋮</button>
    </div>
    <menu id="menu-1" popover>
      <button>Rename</button><button>Archive</button><button>Delete</button>
    </menu>
  </div>

  <div class="row-wrapper">
    <div class="grid-row">
      Q4 Report <button popovertarget="menu-2">⋮</button>
    </div>
    <menu id="menu-2" popover>
      <button>Rename</button><button>Archive</button><button>Delete</button>
    </menu>
  </div>

  <!-- Annual Summary y Budget Draft, mismo patrón -->
</div>

.grid-row {
  anchor-name: --row-anchor;
}

.row-wrapper {
  anchor-scope: --row-anchor;
}

[popover] {
  position-anchor: --row-anchor;
  position-area: right;
}

.row-wrapper es ahora el ancestro común que contiene tanto a un .grid-row como a su propio menú, y a nada más. Limitar --row-anchor a este contenedor significa que cada menú solo puede resolver el nombre dentro del subárbol de su propio wrapper. El anchor con nombre idéntico de cualquier otra fila deja de existir en lo que respecta a ese menú.

Haz clic de nuevo en el ⋮ de "Q3 Report". Se posiciona junto a "Q3 Report". Haz clic en el de "Annual Summary". Se posiciona junto a "Annual Summary". La solución no es específica de la fila que se probó primero: cada wrapper lleva la misma regla de scoping, por lo que cada fila obtiene el mismo resultado correcto, de forma independiente.

Si la afirmación se sostuvo

La afirmación del ensayo era que el anclaje implícito ya maneja el caso ordinario sin costo alguno, y que el costo real aparece solo donde un requisito sale de él mientras viejos hábitos estructurales se quedan sin examinar. Ambas mitades se sostuvieron. Anclar a la fila en lugar de al botón nunca fue el error: ese era un requisito real que el anclaje implícito genuinamente no puede cubrir. El error que nadie cometió a propósito fue dejar el menú donde siempre solían vivir las superposiciones de la era de JavaScript: junto a su activador, sin estar dentro de nada, porque esa solía ser la única forma de evitar que fuera recortado. El navegador no falló al buscar un ancestro. No había ninguno que encontrar.

Aplicar scope no requirió tocar el nombre del anchor, ni el botón, ni la relación con el popover. La única pieza que tuvo que cambiar fue exactamente la pieza que nadie tenía motivos para volver a mirar hasta que un grid con más de una fila demostró lo contrario.

Artículo de referencia

Los popovers nativos no reemplazaron a las bibliotecas de JS; reemplazaron al código de unión.

Notes from the Pass: Every Menu Pointed at the Same Row

Franklin — Sat, 03 Oct 2026 12:06:11 +0000

Also available in Español

The Claim Being Tested

Tuesday's essay argued that implicit anchoring already solves the ordinary popover case for free. A popover tethered to its own trigger needs no naming, no scoping, nothing. The gap only opens when a real requirement steps outside that case, and even then, only in combination with something easy to miss: DOM structure inherited from before the platform solved overlay clipping, when overlays had to live apart from whatever triggered them.

This Note reproduces that exact combination — a shared anchor name, a popover sitting as a sibling instead of a descendant — across a real multi-row grid, and confirms whether scoping actually fixes every row, not just the one that happened to get tested.

Watch It Break

Four rows, each with its own action menu, built the way the essay described:

<div class="grid">
  <div class="grid-row">
    Q3 Report <button popovertarget="menu-1">⋮</button>
  </div>
  <menu id="menu-1" popover>
    <button>Rename</button><button>Archive</button><button>Delete</button>
  </menu>

  <div class="grid-row">
    Q4 Report <button popovertarget="menu-2">⋮</button>
  </div>
  <menu id="menu-2" popover>
    <button>Rename</button><button>Archive</button><button>Delete</button>
  </menu>

  <div class="grid-row">
    Annual Summary <button popovertarget="menu-3">⋮</button>
  </div>
  <menu id="menu-3" popover>
    <button>Rename</button><button>Archive</button><button>Delete</button>
  </menu>

  <div class="grid-row">
    Budget Draft <button popovertarget="menu-4">⋮</button>
  </div>
  <menu id="menu-4" popover>
    <button>Rename</button><button>Archive</button><button>Delete</button>
  </menu>
</div>

.grid-row {
  anchor-name: --row-anchor;
}

[popover] {
  position-anchor: --row-anchor;
  position-area: right;
}

Click "Q3 Report" 's ⋮. The menu opens — popovertarget handles that part correctly no matter what — and positions itself against "Budget Draft," the last row in the grid. Click "Annual Summary" 's ⋮ instead. Same position. Click "Q4 Report" 's. Same position again. Every menu, from every row, lands in exactly the same place: wherever the last .grid-row happens to sit.

Why Nothing Stopped It

Each <menu popover> sits directly after its own .grid-row, as a sibling, both children of .grid. Neither one contains the other. When the browser resolves position-anchor: --row-anchor for any of the four menus, it looks for the nearest ancestor carrying that name first, and finds none, because no menu is nested inside any row. With no ancestor to prefer, resolution falls through to the only rule left standing: the last element in the document with that anchor name. All four rows share the identical name, set through the same class every row already uses for its layout. "Budget Draft" wins every time, for every menu, regardless of which button was actually clicked.

The Fix

Nothing about the anchor name changes, and nothing about the button. Each row and its own menu get wrapped together, and the anchor name gets scoped to that wrapper:

<div class="grid">
  <div class="row-wrapper">
    <div class="grid-row">
      Q3 Report <button popovertarget="menu-1">⋮</button>
    </div>
    <menu id="menu-1" popover>
      <button>Rename</button><button>Archive</button><button>Delete</button>
    </menu>
  </div>

  <div class="row-wrapper">
    <div class="grid-row">
      Q4 Report <button popovertarget="menu-2">⋮</button>
    </div>
    <menu id="menu-2" popover>
      <button>Rename</button><button>Archive</button><button>Delete</button>
    </menu>
  </div>

  <!-- Annual Summary and Budget Draft, same pattern -->
</div>

.grid-row {
  anchor-name: --row-anchor;
}

.row-wrapper {
  anchor-scope: --row-anchor;
}

[popover] {
  position-anchor: --row-anchor;
  position-area: right;
}

.row-wrapper is now the common ancestor holding both a .grid-row and its own menu, and nothing else's. Scoping --row-anchor to it means each menu can only resolve the name within its own wrapper's subtree. Every other row's identically-named anchor stops existing as far as that menu is concerned.

Click "Q3 Report" 's ⋮ again. It positions against "Q3 Report." Click "Annual Summary" 's. It positions against "Annual Summary." The fix isn't specific to whichever row got tested first — every wrapper carries the same scoping rule, so every row gets the same correct result, independently.

Whether the Claim Held

The essay's claim was that implicit anchoring already handles the ordinary case for free, and the real cost shows up only where a requirement steps outside it while old structural habits go un-examined. Both halves held. Anchoring to the row instead of the button was never the mistake — that was a real requirement implicit anchoring genuinely can't serve. The mistake nobody made on purpose was leaving the menu where JavaScript-era overlays always used to live: next to its trigger, not inside anything, because that used to be the only way to keep it from being clipped. The browser didn't fail to find an ancestor. There wasn't one to find.

Scoping didn't require touching the anchor name, the button, or the popover relationship. The one piece that had to change was exactly the piece nobody had reason to look at again until a grid with more than one row proved it wrong.

Reference Article:

Native Popovers Didn't Replace JS Libraries — They Replaced Glue Code

El navegador ya cuenta con una arquitectura de accesibilidad. La mayoría de los proyectos la ignoran.

Franklin — Thu, 01 Oct 2026 19:29:49 +0000

Hermano estructural de El navegador ya tiene una arquitectura. La mayoría de los proyectos la ignoran: la misma distinción, en una capa diferente.

También disponible en Inglés

El problema

Una auditoría de accesibilidad da un resultado limpio. Cada control interactivo tiene un role. Cada icono tiene una etiqueta. El escáner automatizado muestra una puntuación aprobatoria y el equipo continúa.

Luego, un usuario de lector de pantalla intenta cerrar un panel de navegación. Escucha "Descartar panel de navegación" anunciado en un elemento que dice visiblemente "Cerrar menú". Nada se interrumpe. El control sigue funcionando; presionar Enter todavía cierra el panel. Pero el usuario al que se le dijo que escuchara "Cerrar" escuchó algo completamente diferente y tuvo que adivinar.

Nadie eliminó una etiqueta. Alguien agregó una, específicamente para que el escáner dejara de señalar el control como no etiquetado. La auditoría se volvió más silenciosa. El control se volvió más difícil de usar.

Por qué existe el problema

Las herramientas de accesibilidad existen porque los fallos de accesibilidad son, de otro modo, invisibles para la mayoría de las personas que construyen un producto. Una etiqueta faltante, un role que nadie definió, un orden de enfoque (focus) que atrapa a un usuario de teclado: nada de eso aparece en una revisión visual de QA. Los escáneres automatizados y las listas de verificación de cumplimiento surgieron para detectar exactamente ese punto ciego, y detectan una categoría real de fallo: un botón compuesto solo por un icono que un lector de pantalla anuncia simplemente como "botón".

Para esa categoría específica, aria-label existe por una razón real. Un control de solo icono —un glifo de papelera sin texto visible— no le da al navegador nada a partir de lo cual calcular un nombre. No hay contenido para que el cálculo del nombre accesible lea. aria-label llena un espacio que de otro modo permanecería vacío.

El problema comienza cuando la misma lista de verificación que señala correctamente un botón de icono sin etiqueta también señala un <button> que ya tiene texto visible, y la solución aplicada es idéntica en ambos casos: agregar un aria-label. Uno de esos elementos no tenía nada con qué trabajar. El otro ya tenía un nombre. La lista de verificación no distingue entre los dos casos porque, desde la perspectiva del escáner, ambos solo necesitaban un aria-label para dejar de ser señalados.

El primer principio

El navegador no espera a que ARIA le diga qué es algo. Los elementos HTML nativos ya llevan funciones (roles) y comportamientos implícitos: un <button> es un botón para el árbol de accesibilidad antes de que cualquier atributo lo toque, de la misma manera que ya es ejecutable mediante clic y enfocable antes de que cualquier JavaScript lo toque. El árbol de accesibilidad se deriva del propio HTML, el mismo documento que el navegador ya está procesando para todo lo demás.

Los nombres accesibles siguen su propia secuencia definida, verificada en orden: primero aria-labelledby, luego aria-label, después el propio contenido del elemento, y finalmente los fallbacks restantes. Un <button>Close menu</button> obtiene su nombre del tercer paso de esa lista, su contenido, porque no hay nada anterior en la secuencia que lo reclame primero. En el momento en que se agrega un aria-label, ese paso anterior gana en su lugar, y el contenido que un usuario vidente realmente lee nunca se llega a alcanzar.

ARIA no es una capa de accesibilidad separada sobre el DOM. Es un conjunto de entradas que el mismo cálculo ya ejecuta, uno que resulta tener prioridad sobre el contenido cuando está presente, independientemente de si el contenido ya estaba diciendo lo correcto.

Demostrando el principio

Un control compuesto solo por un icono, sin nada más que le dé nombre:

<button aria-label="Delete item">
  <svg aria-hidden="true"><!-- trash can icon --></svg>
</button>

Nada aquí entra en conflicto con nada. El <svg> está oculto del árbol de accesibilidad, no hay contenido de texto para que el cálculo lo encuentre, y aria-label proporciona el único nombre disponible. Este es el caso para el que se creó ARIA.

Ahora el mismo atributo, en un control que ya tenía contenido:

<button aria-label="Dismiss navigation panel">
  Close menu
</button>

Visualmente, nada cambió. Un usuario vidente todavía lee "Close menu". Programáticamente, el nombre accesible ahora es "Dismiss navigation panel". El contenido no desapareció del DOM. Simplemente dejó de ser lo que alcanza el cálculo del nombre, porque aria-label se sitúa antes en la secuencia y el cálculo se detiene en la primera coincidencia.

Mismo atributo. Misma sintaxis. Uno llena un espacio vacío. El otro reemplaza algo que ya era correcto.

El punto de dolor

Esto se envió a producción en un control de navegación global: un <button> nativo con texto visible que decía "Close menu". Una revisión de accesibilidad lo señaló durante una fase de cumplimiento, no porque careciera de nombre, sino porque la lista de verificación utilizada exigía un aria-label explícito en cada control interactivo, independientemente de si ya había uno disponible en el contenido. La etiqueta agregada fue "Dismiss navigation panel", escrita para ser más descriptiva que el propio texto corto del botón.

El control visible y el nombre programático ya no describían la misma cosa. Un usuario vidente lee "Close menu". Un lector de pantalla anuncia "Dismiss navigation panel". El software de control por voz que escucha la palabra que un usuario realmente puede ver —el mecanismo que el criterio Label in Name de las WCAG existe para proteger— no tiene nada con qué coincidir. El usuario dice "hacer clic en cerrar menú" a un control que, en lo que respecta al árbol de accesibilidad, ya no se llama así.

La misma revisión también agregó role="button" a un <div> en otra parte de la misma navegación, reemplazando a un segundo control que el equipo quería que se viera igual. El role es una declaración, no una transferencia. <div role="button"> le dice al árbol de accesibilidad que anuncie el elemento como un botón. No le otorga a ese <div> el manejo nativo de teclado de un botón, su comportamiento de enfoque predeterminado ni su activación integrada con Enter y Espacio, cosas que el <button> ya proporciona sin tener que pedírselo. El div se anuncia correctamente y no hace casi nada correctamente una vez que el teclado lo alcanza.

El Notas desde el Pase del sábado elimina el aria-label del control de navegación y observa cómo el nombre accesible vuelve a ser "Close menu" por sí solo, y luego verifica qué le falta realmente al <div role="button"> frente a lo que un <button> nativo habría proporcionado gratis.

La lección más amplia

Este no es un argumento contra aria-label, ni contra ARIA en general. El botón compuesto solo por un icono al principio de este artículo lo necesitaba; no había nada más que leer. El fallo aquí no fue usar el atributo. Fue usarlo sin verificar si el navegador ya tenía una respuesta.

Cada anotación agregada a un documento es una afirmación sobre lo que la plataforma aún no sabe. A veces esa afirmación es correcta: un icono sin texto realmente no tiene nada con qué nombrarse a sí mismo. A veces no lo es, y la anotación sobrescribe algo que el navegador ya estaba calculando correctamente, considerado presente en una lista de verificación de cualquier manera.

ARIA es una intervención semántica. Debe suministrar lo que el documento nativo no expresa por sí mismo, no reemplazar lo que sí expresa. La pregunta que vale la pena hacerse antes de agregar algo de esto no es si el control necesita más información de accesibilidad. Es si el navegador ya tiene la información y simplemente no se le ha preguntado aún.

The Browser Already Has an Accessibility Architecture. Most Projects Ignore It.

Franklin — Thu, 01 Oct 2026 19:26:26 +0000

Structural sibling to The Browser Already Has an Architecture. Most Projects Ignore It. — same distinction, different layer.

Also available in Español

The Problem

An accessibility audit comes back clean. Every interactive control has a role. Every icon has a label. The automated scanner shows a passing score, and the team moves on.

Then a screen reader user tries to close a navigation panel. They hear "Dismiss navigation panel" announced on an element that visibly says "Close menu." Nothing crashes. The control still works; pressing Enter still closes the panel. But the user who was told to listen for "Close" heard something else entirely, and had to guess.

Nobody removed a label. Someone added one, specifically to make the scanner stop flagging the control as unlabeled. The audit got quieter. The control got harder to use.

Why the Problem Exists

Accessibility tooling exists because accessibility failures are otherwise invisible to most of the people building a product. A missing label, a role nobody set, a focus order that traps a keyboard user: none of it shows up in a visual QA pass. Automated scanners and compliance checklists emerged to catch exactly that blind spot, and they catch a real category of failure: an icon-only button that announces as nothing but "button" to a screen reader.

For exactly that category, aria-label exists for a real reason. An icon-only control — a trash can glyph with no visible text — gives the browser nothing to compute a name from. There's no content for the accessible name computation to read. aria-label fills a gap that would otherwise sit empty.

The trouble starts when the same checklist that correctly flags an unlabeled icon button also flags a <button> that already has visible text, and the fix applied is identical either way: add an aria-label. One of those elements had nothing to work with. The other already had a name. The checklist doesn't distinguish between the two cases, because from the scanner's perspective, both just needed an aria-label to stop being flagged.

The First Principle

The browser doesn't wait for ARIA to tell it what something is. Native HTML elements already carry implicit roles and behavior — a <button> is a button to the accessibility tree before any attribute touches it, the same way it's already clickable and focusable before any JavaScript touches it. The accessibility tree is derived from the HTML itself, the same document the browser is already parsing for everything else.

Accessible names follow their own defined sequence, checked in order: aria-labelledby first, then aria-label, then the element's own content, then a few remaining fallbacks. A <button>Close menu</button> gets its name from the third step down that list, its content, because nothing earlier in the sequence is present to claim it first. The moment an aria-label is added, that earlier step wins instead, and the content a sighted user actually reads never gets reached.

ARIA isn't a separate accessibility layer sitting on top of the DOM. It's a set of inputs the same computation already runs, one that happens to take precedence over content when it's present, whether or not content was already saying the right thing.

Demonstrating the Principle

An icon-only control, with nothing else to name it:

<button aria-label="Delete item">
  <svg aria-hidden="true"><!-- trash can icon --></svg>
</button>

Nothing here conflicts with anything. The <svg> is hidden from the accessibility tree, there's no text content for the computation to find, and aria-label supplies the only name available. This is the case ARIA was built for.

Now the same attribute, on a control that already had content:

<button aria-label="Dismiss navigation panel">
  Close menu
</button>

Visually, nothing changed. A sighted user still reads "Close menu." Programmatically, the accessible name is now "Dismiss navigation panel." The content didn't disappear from the DOM. It simply stopped being the thing the name computation reaches, because aria-label sits earlier in the sequence and the computation stops at the first match.

Same attribute. Same syntax. One fills a gap. The other replaces something that was already correct.

The Pain Point

This shipped on a global navigation control: a native <button> with visible text reading "Close menu." An accessibility review flagged it during a compliance pass, not because it lacked a name, but because the checklist in use called for an explicit aria-label on every interactive control, regardless of whether one was already available from content. The label added was "Dismiss navigation panel," written to be more descriptive than the button's own short text.

The visible control and the programmatic name no longer described the same thing. A sighted user reads "Close menu." A screen reader announces "Dismiss navigation panel." Voice-control software listening for the word a user can actually see — the mechanism WCAG's Label in Name criterion exists to protect — has nothing to match. The user says "click close menu" to a control that, as far as the accessibility tree is concerned, isn't named that anymore.

The same review also added role="button" to a <div> elsewhere in the same navigation, standing in for a second control the team wanted to look the same. The role is a declaration, not a transfer. <div role="button"> tells the accessibility tree to announce the element as a button. It doesn't give that <div> a button's native keyboard handling, its default focus behavior, or its built-in activation on Enter and Space, all of which <button> already provides without being asked. The div announces correctly and does almost nothing correctly once a keyboard reaches it.

Saturday's Notes from the Pass strips the aria-label back off the navigation control and watches the accessible name return to "Close menu" on its own, then checks what the <div role="button"> is actually missing against what a native <button> would have supplied for free.

The Broader Lesson

This isn't a case against aria-label, or against ARIA generally. The icon-only button earlier in this piece needed it; there was nothing else to read. The failure here wasn't using the attribute. It was using it without checking whether the browser already had an answer.

Every annotation layered onto a document is a claim about what the platform doesn't already know. Sometimes that claim is correct — an icon with no text genuinely has nothing to name itself with. Sometimes it isn't, and the annotation overwrites something the browser was already computing correctly, counted as present on a checklist either way.

ARIA is a semantic intervention. It should supply what the native document doesn't already express, not replace what it does. The question worth asking before adding any of it isn't whether the control needs more accessibility information. It's whether the browser already has the information, and just hasn't been asked yet.

Los popovers nativos no reemplazaron a las bibliotecas de JS; reemplazaron al código de unión.

Franklin — Tue, 29 Sep 2026 11:16:28 +0000

Hermano estructural de Los Cascade Layers no reemplazaron la especificidad — Reemplazaron la negociación: la misma distinción, en una capa diferente.

También disponible en Inglés

El problema

Llega un ticket de soporte con una captura de pantalla: un data grid, docenas de filas, y un menú de acciones —renombrar, archivar, eliminar— abierto en el lugar equivocado. No por unos pocos píxeles. Está anclado a la última fila de la tabla, sin importar en el botón de qué fila se hizo clic. Clic en el menú de la fila dos, posición de la fila cuarenta. Clic en la fila veinte, el mismo resultado.

Nadie escribió un bug que dijera "usa siempre la última fila". El equipo ya había hecho la parte más difícil y moderna correctamente: atributos popover nativos en lugar de un menú desplegable administrado por JavaScript, CSS anchor positioning en lugar de coordenadas calculadas manualmente. El menú está exactamente donde el código le dijo que estuviera. El código simplemente no declaró la relación que todos asumieron que contenía.

Por qué existe el problema

Antes de que el navegador proporcionara un top layer de propósito general para este tipo de superposición (overlay), un elemento anclado a algo enterrado dentro de un contenedor con desplazamiento (scrollable) o recortado (clipped) tenía un problema real: podía quedar cortado, oculto detrás de otra cosa o atrapado dentro de una región de desplazamiento que no coincidía con el resto de la página. La solución habitual era estructural. Renderizar la superposición en otro lugar, adjunta al final de <body> o donde viviera un contenedor portal compartido, de modo que su posición en el DOM ya no coincidiera con su posición en la interfaz. JavaScript se encargaba de todo lo que el DOM ya no expresaba por sí mismo: mostrarlo, ocultarlo, calcular dónde debía ubicarse en relación con lo que lo activaba, y mantener esa posición actualizada a medida que la página se desplazaba o cambiaba de tamaño.

Eso no era un truco para corregir un error. Era una respuesta correcta a un navegador que realmente carecía de una forma de propósito general para que este tipo de superposición escapara al recorte de sus ancestros. La superposición tenía que vivir separada de su disparador (trigger), porque vivir cerca de él era lo que causaba el problema.

El primer principio

La plataforma ahora separa varias responsabilidades que las implementaciones de superposición más antiguas tenían que reconstruir en JavaScript. El atributo popover, combinado con popovertarget en un control, le da al navegador una relación declarativa entre el control y el popover. Al abrirse, el popover entra al top layer del navegador, fuera de las restricciones habituales de recorte y apilamiento de sus ancestros, y esa relación con el activador (invoker) también proporciona una referencia de anchor implícita.

El CSS anchor positioning maneja el enlace espacial de forma independiente: un elemento posicionado se puede ubicar en relación con un anchor sin que JavaScript calcule las coordenadas.

El límite importante aparece cuando un componente necesita un anchor explícito en lugar del propio control activador del popover. Los nombres de anchor explícitos no se limitan automáticamente al subárbol DOM (subtree) de un componente. Cuando múltiples anchors exponen el mismo nombre, un elemento posicionado mediante anchor puede resolverse con respecto al último anchor coincidente en el orden del código fuente.

anchor-scope cambia esa relación al restringir explícitamente dónde se puede resolver un anchor con nombre.

Por lo tanto, el navegador puede asumir el límite de la superposición y la mecánica de posicionamiento sin eliminar la responsabilidad arquitectónica. HTML establece la relación de interacción. CSS establece la relación espacial y su alcance (scope). La pregunta restante es si el DOM realmente declara el límite del que depende el componente.

Demostrando el principio

Redúcelo a dos elementos repetidos, cada uno con un anchor y un hermano posicionado:

<div class="item-wrapper">
  <div class="item">
    <div class="thumbnail"></div>
  </div>
  <div class="badge" popover></div>
</div>

<div class="item-wrapper">
  <div class="item">
    <div class="thumbnail"></div>
  </div>
  <div class="badge" popover></div>
</div>

.thumbnail {
  anchor-name: --thumb;
}

.badge {
  position-anchor: --thumb;
  position-area: top right;
}

.thumbnail y .badge son hermanos dentro de cada .item-wrapper. Comparten el mismo nombre de anchor explícito, pero ese nombre no se limita automáticamente al subárbol del wrapper. Sin un anchor scope, los nombres --thumb repetidos permanecen visibles para los elementos posicionados en cualquier otra parte del documento. Cuando múltiples anchors comparten ese nombre, el elemento posicionado se resuelve con respecto al último anchor coincidente en el orden del código fuente.

.item-wrapper {
  anchor-scope: --thumb;
}

Una sola línea establece el límite faltante. Ahora cada .badge puede resolver --thumb solo dentro de su propio .item-wrapper, por lo que el nombre de anchor idéntico ya no es ambiguo entre los componentes repetidos.

La parte importante no es que el navegador haya aprendido de repente qué es un componente. La parte importante es que el componente finalmente declaró el límite del que dependía la relación del anchor.

El punto de dolor

Esto surgió en un data grid en producción: filas repetidas, cada una con un botón de acción al final que abre un menú. El menú debía alinearse con el propio borde derecho de la fila, de forma consistente, independientemente de dónde se ubicara exactamente el botón dentro de la fila. Eso hizo que la opción más simple de la plataforma fuera insuficiente: el anchor implícito de un popover sigue a su propio control activador, pero el control aquí era un botón pequeño, no la fila en sí. Anclar a la fila significaba nombrarla explícitamente, lo cual fue una decisión razonable y deliberada. Los popovers asociados con un activador reciben una referencia de anchor implícita a ese activador; una asociación de anchor explícita es un mecanismo separado.

Lo que no se reconsideró fue dónde vivía el menú en el marcado (markup). Antes de que el equipo adoptara el atributo popover nativo, sus componentes de superposición siempre se renderizaban como hermanos de lo que los activaba, un nivel más arriba en el DOM: un hábito estructural de cuando una superposición anidada cerca de una fila corría el riesgo de ser recortada por el propio overflow: hidden de esa fila. El comportamiento de top layer del atributo nativo hizo que ese riesgo desapareciera. La ubicación como hermano nunca se volvió a examinar, porque nada en el cambio a popover parecía requerirlo. Los popovers abiertos se colocan en el top layer y no se ven influenciados por el estilo de posición ni por el overflow de sus ancestros.

Cada fila compartía el mismo nombre de anchor, definido a través de la misma clase que cada fila ya usaba para su diseño (layout). El menú de ninguna fila estaba dentro de la fila a la que pertenecía, y el nombre de anchor explícito no estaba limitado al subárbol de esa fila.

Sin ese límite presente, el nombre de anchor repetido permaneció visible en todo el grid. La resolución cayó hasta el último anchor coincidente en el documento. Cada menú, en cada fila, apuntaba al mismo lugar, porque el DOM no tenía un scope declarado para la relación.

La solución no tocó ni el nombre del anchor ni el botón. Envolvió cada fila y su propio menú en un contenedor compartido, el ancestro más pequeño que contenía a ambos, y limitó el nombre del anchor a ese contenedor:

.row-wrapper {
  anchor-scope: --row-anchor;
}

El Notas desde el Pase del sábado reproduce el menú fuera de lugar exactamente como se envió a producción, confirma por qué el navegador no tenía nada que preferir y muestra la solución con scope manteniéndose en cada fila del grid, no solo en la que se estaba probando.

La lección más amplia

Esta no es una historia sobre CSS anchor positioning estando incompleto. El anclaje implícito cubre el caso ordinario —un popover vinculado a su propio activador— sin pedir una sola línea de nombres o de scoping. El trabajo arquitectónico adicional aparece cuando un requisito real sale de ese caso. La plataforma puede establecer la relación de superposición, pero una relación de anchor explícita aún necesita un límite explícito.

Aquí, el problema no era que la plataforma no pudiera posicionar el menú. Era que el DOM conservaba una estructura de la implementación previa a popover sin declarar el límite de componente que la nueva relación de posicionamiento requería.

El Artículo 4 encontró la misma forma en el código de la aplicación: lógica que seguía administrando una responsabilidad que el navegador ya había asumido. Este es ese mismo patrón apareciendo en la estructura en lugar del comportamiento. Una forma de DOM construida para resolver un problema no deja de existir automáticamente una vez que el problema que resolvió desaparece. Se queda ahí, correcta por hábito, hasta que algo construido sobre un supuesto más nuevo choca directamente contra ella.

Adoptar una característica de la plataforma no es solo cuestión de cambiar un script por un atributo. Es una invitación a preguntar qué partes de la estructura circundante se construyeron para compensar una limitación que ese atributo acaba de eliminar, y cuáles de esas partes aún deben estar allí, ahora declaradas a propósito en lugar de heredadas por accidente.

Native Popovers Didn't Replace JS Libraries — They Replaced Glue Code

Franklin — Tue, 29 Sep 2026 11:02:49 +0000

Structural sibling to Cascade Layers Didn't Replace Specificity — They Replaced Negotiation — same distinction, different layer.

Also available in Español

The Problem

A support ticket comes in with a screenshot: a data grid, dozens of rows, and an action menu — rename, archive, delete — hanging open in the wrong place. Not off by a few pixels. It's anchored against the last row in the table, regardless of which row's own button was clicked. Click row two's menu, row forty's position. Click row twenty's, same result.

Nobody wrote a bug that says "always use the last row." The team had already done the harder, more modern part correctly: native popover attributes instead of a JavaScript-managed dropdown, CSS anchor positioning instead of manually computed coordinates. The menu is exactly where the code told it to be. The code just didn't declare the relationship everyone assumed it contained.

Why the Problem Exists

Before the browser provided a general-purpose top layer for this kind of overlay, an element anchored to something buried inside a scrollable or clipped container had a real problem: it could be cut off, hidden behind something else, or trapped inside a scroll region that didn't match the rest of the page. The common fix was structural. Render the overlay somewhere else, appended to the end of <body> or wherever a shared "portal" container lived, so its position in the DOM no longer matched its position in the interface. JavaScript then handled everything the DOM no longer expressed on its own — showing it, hiding it, computing where it should sit relative to whatever triggered it, keeping that position updated as the page scrolled or resized.

That wasn't a workaround for a mistake. It was a correct response to a browser that genuinely lacked a general-purpose way for this kind of overlay to escape ancestor clipping. The overlay had to live apart from its trigger, because living close to it was the thing causing the problem.

The First Principle

The platform now separates several responsibilities that older overlay implementations had to reconstruct in JavaScript. The popover attribute, paired with popovertarget on a control, gives the browser a declarative relationship between the control and the popover. When opened, the popover enters the browser's top layer, outside the normal clipping and stacking constraints of its ancestors, and that invoker relationship also provides an implicit anchor reference.

CSS anchor positioning handles spatial tethering separately: a positioned element can be placed relative to an anchor without JavaScript calculating coordinates.

The important boundary appears when a component needs an explicit anchor rather than the popover's own invoking control. Explicit anchor names are not automatically scoped to a component's DOM subtree. When multiple anchors expose the same name, an anchor-positioned element can resolve against the last matching anchor in source order.

anchor-scope changes that relationship by explicitly restricting where a named anchor can be resolved.

The browser can therefore own the overlay boundary and the positioning mechanics without removing architectural responsibility. HTML establishes the interaction relationship. CSS establishes the spatial relationship and its scope. The remaining question is whether the DOM actually declares the boundary the component depends on.

Demonstrating the Principle

Reduce it to two repeated items, each with an anchor and a positioned sibling:

<div class="item-wrapper">
  <div class="item">
    <div class="thumbnail"></div>
  </div>
  <div class="badge" popover></div>
</div>

<div class="item-wrapper">
  <div class="item">
    <div class="thumbnail"></div>
  </div>
  <div class="badge" popover></div>
</div>

.thumbnail {
  anchor-name: --thumb;
}

.badge {
  position-anchor: --thumb;
  position-area: top right;
}

.thumbnail and .badge are siblings inside each .item-wrapper. They share the same explicit anchor name, but that name is not automatically limited to the wrapper's subtree. Without an anchor scope, the repeated --thumb names remain visible to positioned elements elsewhere in the document. When multiple anchors share that name, the positioned element resolves against the last matching anchor in source order.

.item-wrapper {

  anchor-scope: --thumb;

}

One line establishes the missing boundary. Each .badge can now resolve --thumb only within its own .item-wrapper, so the identical anchor name is no longer ambiguous across the repeated components.

The important part isn't that the browser suddenly learned what a component is. The important part is that the component finally declared the boundary the anchor relationship depended on.

The Pain Point

This surfaced in a production data grid: repeating rows, each with a trailing action button opening a menu. The menu needed to align to the row's own right edge, consistently, regardless of exactly where the button sat inside the row. That made the platform's simplest option insufficient: a popover's implicit anchor follows its own invoking control, but the control here was a small button, not the row itself. Anchoring to the row meant naming it explicitly, which was a reasonable, deliberate call. Popovers associated with an invoker receive an implicit anchor reference to that invoker; an explicit anchor association is a separate mechanism.

What wasn't reconsidered was where the menu itself lived in the markup. Before the team adopted the native popover attribute, their overlay components had always rendered as a sibling to whatever triggered them, one level up in the DOM — a structural habit from when an overlay nested near a row risked being clipped by that row's own overflow: hidden. The native attribute's top-layer behavior made that risk disappear. The sibling placement never got revisited, because nothing about switching to popover seemed to require it. Open popovers are placed in the top layer and aren't influenced by ancestor overflow or position styling.

Every row shared the same anchor name, set through the same class every row already used for its layout. No row's menu sat inside the row it belonged to, and the explicit anchor name wasn't scoped to that row's subtree.

With that boundary absent, the repeated anchor name remained visible across the grid. Resolution fell through to the last matching anchor in the document. Every menu, on every row, pointed at the same place, because the DOM had no declared scope for the relationship.

The fix didn't touch the anchor name or the button. It wrapped each row and its own menu in a shared container, the smallest ancestor holding both, and scoped the anchor name to it:

.row-wrapper {

  anchor-scope: --row-anchor;

}

Saturday's Notes from the Pass reproduces the misplaced menu exactly as it shipped, confirms why the browser had nothing to prefer, and shows the scoped fix holding across every row in the grid, not just the one being tested.

The Broader Lesson

This isn't a story about CSS anchor positioning being incomplete. Implicit anchoring covers the ordinary case — a popover tethered to its own trigger — without asking for a single line of naming or scoping. The additional architectural work appears when a real requirement steps outside that case. The platform can establish the overlay relationship, but an explicit anchor relationship still needs an explicit boundary.

Here, the problem wasn't that the platform couldn't position the menu. It was that the DOM retained a structure from the pre-popover implementation without declaring the component boundary the new positioning relationship required.

Article 4 found the same shape in application code: logic that kept managing a responsibility the browser had already taken over. This is that pattern showing up in structure instead of behavior. A DOM shape built to solve a problem doesn't automatically stop existing once the problem it solved goes away. It sits there, correct by habit, until something built on a newer assumption runs straight into it.

Adopting a platform feature isn't only a matter of swapping an attribute in for a script. It's an invitation to ask which parts of the surrounding structure were built to compensate for a limitation that attribute just removed, and which of those parts still need to be there, now declared on purpose instead of inherited by accident.

Notas desde el pase: La referencia que quedó obsoleta

Franklin — Sat, 26 Sep 2026 10:43:09 +0000

También disponible en Inglés

La afirmación a prueba

El ensayo del jueves sostuvo que el navegador no solo renderiza elementos nativos: para un conjunto definido de ellos, también implementa y mantiene el contrato de interacción correspondiente, y el código de la aplicación que reimplementa ese mismo contrato asume una obligación que la plataforma ya estaba cumpliendo. La afirmación específica: un focus trap personalizado y un <dialog> nativo pueden no diferir mucho en un diff, pero difieren en quién es responsable cuando el contenido del modal cambia después de abrirse.

Esta Nota prueba eso directamente. El mismo fallo —nuevo contenido cargándose en un modal abierto— ejecutado contra ambas implementaciones, para ver si la diferencia es real o puramente retórica.

El trampa anterior

La versión personalizada enumera los elementos enfocables del modal una sola vez, al abrirse, y verifica cada pulsación de Tab contra dos de ellos:

function openModal(modal) {
  previouslyFocused = document.activeElement;
  modal.classList.add('is-open');

  const focusable = modal.querySelectorAll(FOCUSABLE_SELECTOR);
  first = focusable[0];
  last = focusable[focusable.length - 1];
  first?.focus();

  modal.addEventListener('keydown', trapFocus);
}

function trapFocus(event) {
  if (event.key !== 'Tab') return;
  if (event.shiftKey && document.activeElement === first) {
    event.preventDefault();
    last.focus();
  } else if (!event.shiftKey && document.activeElement === last) {
    event.preventDefault();
    first.focus();
  }
}

first y last no son posiciones. Son referencias a dos nodos del DOM específicos, capturados en el momento en que se abrió el modal.

Ahora se resuelve una solicitud y la lista de opciones se vuelve a renderizar para mostrar la nueva elección:

optionsList.innerHTML = renderOptions(updatedOptions);

innerHTML no actualiza los nodos existentes. Los descarta y construye unos nuevos, incluyendo aquello a lo que apuntaba last. La variable sigue conservando una referencia. El nodo al que se refiere ya no existe en ninguna parte de la página.

document.activeElement nunca podrá volver a ser igual a esa referencia. La próxima vez que un usuario navegue con Tab hacia adelante desde la nueva opción final, la segunda condición de trapFocus fallará en silencio. No se dispara ningún preventDefault(). Nada arroja un error. El orden de tabulación nativo del navegador simplemente toma el control, llevando el foco directamente más allá del modal hacia lo que siga en el documento: una página aún atenuada por una capa superpuesta (overlay) que ya no tiene ningún control real sobre hacia dónde va el foco.

El nuevo contrato

Reconstruye el mismo modal sobre <dialog> y ejecútalo a través del mismo re-render:

<dialog id="preferences">
  <form method="dialog">
    <div class="options">
      <!-- options render here -->
    </div>
    <button autofocus>Save</button>
  </form>
</dialog>

const optionsContainer = dialog.querySelector('.options');

dialog.showModal();
// later, a request resolves
optionsContainer.innerHTML = renderOptions(updatedOptions);

optionsContainer está delimitado a la lista de opciones a propósito: el re-render nunca alcanza al botón Save, que es lo único en este diálogo que no se reevalúa por sí solo. El orden de enfoque secuencial (a lo que responde Tab) se calcula de nuevo en cada pulsación de tecla, razón por la cual la nueva opción se vuelve accesible sin que ningún código note que llegó. autofocus no es ese tipo de mecanismo: el navegador lo busca exactamente una vez, cuando se ejecuta showModal(). Un elemento agregado después de eso, incluso con autofocus definido, necesita una llamada explícita a .focus(); la plataforma no lo captará por sí sola como lo hace con el orden de Tab.

Nada aquí almacena en caché un elemento inicial o final, por lo que nada puede quedar obsoleto. showModal() no calcula una captura instantánea de los descendientes enfocables al momento de abrirse. Hace que todo lo que esté fuera del diálogo sea inerte mientras permanezca abierto, lo que significa que el espacio de búsqueda del orden de Tab del navegador se limita a lo que realmente está dentro del diálogo, evaluado de nuevo en cada pulsación de tecla. Reemplaza el contenido de la lista de opciones a mitad de apertura y la siguiente pulsación de Tab seguirá considerando solo lo que esté actualmente allí, incluida la nueva opción. No hay ninguna referencia que invalidar, porque nunca se tomó ninguna.

Qué cambió de lugar, qué no

Responsabilidad	Personalizada (Hand-rolled)	`<dialog>`
Contención del foco	Referencias en caché, verificadas en cada keydown	Estructural: el fondo es inerte, nada que almacenar en caché
Restauración del foco al cerrar	Almacenada y restaurada manualmente	Automática al cerrar, independientemente de cómo se cierre
Escape para descartar	Verificación explícita de keydown	Automática
Fondo inerte / apilamiento (stacking)	`aria-hidden` manual, `z-index` manual	Automática: capa superior nativa (native top layer)
Objetivo de foco inicial	Llamada imperativa `.focus()`	Declarativa: `autofocus`, sigue siendo una decisión de autoría
Descartar al hacer clic en el fondo	Verificación explícita de clic externo	Sigue siendo explícita: `<dialog>` no tiene un comportamiento predeterminado para esto

Cuatro responsabilidades se trasladan directamente a la plataforma. Una pasa de ser una decisión en tiempo de ejecución a una declarativa: sigue siendo decisión de la aplicación, solo que más ligera de llevar. Una no cambia en absoluto: hacer clic fuera de un <dialog> no hace nada por sí solo, y cerrarlo de esa manera aún requiere el mismo tipo de listener que necesitaba la versión personalizada.

Si la afirmación se sostuvo

La afirmación del ensayo no era que <dialog> tenga menos errores. Era que reimplementar un contrato que la plataforma ya posee significa asumir la responsabilidad de su corrección indefinidamente, incluyendo casos que el código original nunca anticipó. Este es exactamente ese caso. El trap personalizado no falló por mal código. Falló porque "verificar contra una referencia en caché" es una estrategia con un punto ciego específico y permanente, y un re-render eventualmente lo iba a encontrar.

<dialog> no cierra ese punto ciego con mejor código. Lo cierra al no tener una caché en primer lugar: toda la categoría de fallo a la que estaba expuesta la versión personalizada no se aplica a un mecanismo que reevalúa la capacidad de enfoque en vivo. Esas son las cuatro filas que se trasladaron por completo. Las dos que no lo hicieron —elegir un objetivo de foco inicial y manejar el clic en el fondo— son decisiones específicas de lo que contiene un diálogo dado, no algo que la plataforma pudiera asumir en nombre de la aplicación aunque intentara hacerlo.

Artículo de referencia:

El HTML no necesita más reinvención, necesita confianza en la plataforma

Notes from the Pass: The Reference That Went Stale

Franklin — Sat, 26 Sep 2026 10:37:39 +0000

Also available in Español

The Claim Being Tested

Thursday's essay argued that the browser doesn't only render native elements — for a defined set of them, it also implements and maintains the interaction contract that goes with them, and application code that reimplements the same contract takes on an obligation the platform was already fulfilling. The specific claim: a hand-rolled focus trap and a native <dialog> might not differ much in a diff, but they differ in who's on the hook when the modal's contents change after it opens.

This Note tests that directly. The same failure — new content loading into an open modal — run against both implementations, to see whether the difference is real or just rhetorical.

The Old Trap

The hand-rolled version enumerates the modal's focusable elements once, at open, and checks every Tab press against two of them:

function openModal(modal) {
  previouslyFocused = document.activeElement;
  modal.classList.add('is-open');

  const focusable = modal.querySelectorAll(FOCUSABLE_SELECTOR);
  first = focusable[0];
  last = focusable[focusable.length - 1];
  first?.focus();

  modal.addEventListener('keydown', trapFocus);
}

function trapFocus(event) {
  if (event.key !== 'Tab') return;
  if (event.shiftKey && document.activeElement === first) {
    event.preventDefault();
    last.focus();
  } else if (!event.shiftKey && document.activeElement === last) {
    event.preventDefault();
    first.focus();
  }
}

first and last aren't positions. They're references to two specific DOM nodes, captured the moment the modal opened.

Now a request resolves, and the options list re-renders to show the new choice:

optionsList.innerHTML = renderOptions(updatedOptions);

innerHTML doesn't update the existing nodes. It discards them and builds new ones — including whatever last was pointing at. The variable still holds a reference. The node it refers to no longer exists anywhere in the page.

document.activeElement can never equal that reference again. The next time a user tabs forward off the new final option, trapFocus's second condition silently fails. No preventDefault() fires. Nothing errors. The browser's native Tab order simply takes over, carrying focus straight past the modal into whatever comes next in the document — a page still dimmed by an overlay that no longer has any actual say in where focus goes.

The New Contract

Rebuild the same modal on <dialog>, and run it through the identical re-render:

<dialog id="preferences">
  <form method="dialog">
    <div class="options">
      <!-- options render here -->
    </div>
    <button autofocus>Save</button>
  </form>
</dialog>

const optionsContainer = dialog.querySelector('.options');

dialog.showModal();
// later, a request resolves
optionsContainer.innerHTML = renderOptions(updatedOptions);

optionsContainer is scoped to the options list on purpose — the re-render never reaches the Save button, which is the one thing in this dialog that isn't re-evaluated on its own. Sequential focus order (what Tab responds to) is computed fresh at every keypress, which is why the new option becomes reachable without any code noticing it arrived. autofocus isn't that kind of mechanism — the browser looks for it exactly once, when showModal() runs. An element added after that, even with autofocus set, needs an explicit .focus() call; the platform won't pick it up on its own the way it does for Tab order.

Nothing here caches a first or last element, so nothing can go stale. showModal() doesn't compute a snapshot of focusable descendants at open time. It makes everything outside the dialog inert for as long as it stays open, which means the browser's Tab order search space is limited to what's actually inside the dialog, evaluated fresh at every keypress. Replace the options list's contents mid-open, and the next Tab press still only considers whatever is currently there, new option included. There's no reference to invalidate, because none was ever taken.

What Moved, What Didn't

Responsibility	Hand-rolled	`<dialog>`
Focus containment	Cached references, checked on every keydown	Structural — background is inert, nothing to cache
Restoring focus on close	Manually stored and restored	Automatic on close, however it closes
Escape to dismiss	Explicit keydown check	Automatic
Inert background / stacking	Manual `aria-hidden`, manual z-index	Automatic — native top layer
Initial focus target	Imperative `.focus()` call	Declarative — `autofocus`, still an authoring decision
Dismiss on backdrop click	Explicit click-outside check	Still explicit — `<dialog>` has no default for this

Four responsibilities move to the platform outright. One moves from a runtime decision to a declarative one — still the application's call, just a lighter one to carry. One doesn't move at all: clicking outside a <dialog> does nothing on its own, and closing it that way still needs the same kind of listener the hand-rolled version needed.

Whether the Claim Held

The essay's claim wasn't that <dialog> has fewer bugs. It was that reimplementing a contract the platform already owns means owning its correctness indefinitely, including cases the original code never anticipated. This is exactly that case. The hand-rolled trap didn't fail because of bad code. It failed because "check against a cached reference" is a strategy with a specific, permanent blind spot, and a re-render was always going to find it eventually.

<dialog> doesn't close that blind spot with better code. It closes it by not having a cache in the first place — the entire category of failure the hand-rolled version was exposed to doesn't apply to a mechanism that re-evaluates focusability live. That's the four rows that moved outright. The two that didn't — choosing an initial focus target, handling a backdrop click — are decisions specific to what a given dialog contains, not something the platform could own on the application's behalf even if it tried to.

Reference Article:

HTML Doesn't Need More Reinvention — It Needs Platform Trust

Notas desde el pase: La pregunta que seis componentes no pudieron responder

Franklin — Sat, 26 Sep 2026 10:22:06 +0000

Also available in Inglés

La afirmación a prueba

El ensayo del martes sostuvo que la arquitectura de componentes puede organizar el código fuente sin reemplazar la estructura del documento que produce, y que el fallo no está en dividir una página en componentes, sino en dividir una sola decisión entre componentes sin verificar si alguno de ellos conservó suficiente información para tomarla. El ejemplo fue el nivel de un encabezado, decidido a seis componentes de distancia de la posición en la página que debió haberlo establecido.

La cadena

Seis componentes, compuestos de la forma en que realmente se usarían:

<DashboardLayout>
  <CardGroup>
    <Card title="Active Subscriptions">
      {/* subscription list */}
    </Card>
  </CardGroup>
</DashboardLayout>

Cada capa realiza un solo trabajo:

function DashboardLayout({ children }) {
  return (
    <main>
      <h1>Dashboard</h1>
      {children}
    </main>
  );
}

function CardGroup({ children }) {
  return <div className="card-grid">{children}</div>;
}

function Card({ title, children }) {
  return (
    <div className="card">
      <CardHeader title={title} />
      <div className="card-body">{children}</div>
    </div>
  );
}

function CardHeader({ title }) {
  return (
    <div className="card-header">
      <Typography variant="subheading">{title}</Typography>
    </div>
  );
}

function Typography({ variant, children }) {
  return <Heading variant={variant}>{children}</Heading>;
}

function Heading({ variant, children }) {
  const Tag = variant === 'subheading' ? 'h6' : 'h2';
  return <Tag>{children}</Tag>;
}

Al renderizarse, esto produce exactamente lo que describió el ensayo:

<main>
  <h1>Dashboard</h1>
  <div class="card-grid">
    <div class="card">
      <div class="card-header">
        <h6>Active Subscriptions</h6>
      </div>
      <div class="card-body">...</div>
    </div>
  </div>
</main>

Seis preguntas, la misma respuesta

Haz a cada capa las mismas dos preguntas. ¿Sabe dónde se ubica esta sección en la estructura general de la página? ¿Sabe qué etiqueta HTML tendrá su encabezado?

DashboardLayout conoce la estructura. Renderiza el único <h1> de la página, lo que significa que también sabe implícitamente que todo lo que renderice como children pertenece jerárquicamente debajo de ese <h1>. No conoce la etiqueta: nunca toca un encabezado directamente, solo delega lo que recibe.
CardGroup no conoce ninguna de las dos cosas. Es un contenedor de cuadrícula (grid wrapper). No sabe que está dentro de un dashboard y no tiene ninguna opinión sobre los encabezados.
Card no conoce ninguna de las dos cosas. Borde, padding, un CardHeader, un cuerpo. Tampoco hay lógica de encabezados aquí.
CardHeader conoce la cadena de texto —"Active Subscriptions"— pero no en qué lugar de la página se ubica la tarjeta que la contiene. No decide una etiqueta. Le pasa el texto a Typography con una instrucción de estilo: renderiza esto como un subencabezado (subheading).
Typography conoce la instrucción de estilo, no la estructura, y tampoco decide una etiqueta. Existe para que el sistema de diseño tenga un solo lugar que defina cómo se ve un subheading. Transmite la propiedad variant directamente.
Heading es donde subheading realmente se convierte en <h6>. Esta es la única capa en toda la cadena donde se elige una etiqueta real, y también es la capa más alejada de la página, la que no tiene forma de saber que "Active Subscriptions" terminará seis niveles por debajo de un título de página que nunca ha visto.

Seis capas, seis respuestas idénticas a la segunda pregunta, hasta que la sexta cambia, exactamente en la capa menos equipada para responderla correctamente.

Dos caminos de regreso

Pasar el nivel de forma explícita. Entrega a cada capa una propiedad level y pásala directamente, sin cambios, desde la cima:

function DashboardLayout({ children }) {
  return (
    <main>
      <h1>Dashboard</h1>
      {children}
    </main>
  );
}

function CardGroup({ level, children }) {
  return <div className="card-grid">{children}</div>;
}

function Card({ level, title, children }) {
  return (
    <div className="card">
      <CardHeader level={level} title={title} />
      <div className="card-body">{children}</div>
    </div>
  );
}

function CardHeader({ level, title }) {
  return (
    <div className="card-header">
      <Typography level={level}>{title}</Typography>
    </div>
  );
}

function Typography({ level, children }) {
  return <Heading level={level}>{children}</Heading>;
}

function Heading({ level, children }) {
  const Tag = `h${level}`;
  return <Tag>{children}</Tag>;
}

<DashboardLayout>
  <CardGroup level={2}>
    <Card level={2} title="Active Subscriptions">
      {/* subscription list */}
    </Card>
  </CardGroup>
</DashboardLayout>

El estilo visual se omite en esta versión para mantener visible el paso de level; en la práctica viajaría por la misma ruta, pero bajo su propia propiedad, separada de la estructura tal como sostuvo el ensayo.

El costo de esta solución: CardGroup, Card, CardHeader y Typography tuvieron que cambiar, a pesar de que ninguno tenía un interés real en la decisión. Agrega un séptimo contenedor a la cadena el próximo trimestre y también tendrá que recordar pasar level, o la cadena se romperá de nuevo en un lugar diferente.

Rastrearlo a través de contexto. Deja que las capas que nunca tuvieron un interés en la decisión se mantengan exactamente como estaban en "La cadena": CardGroup, Card, CardHeader y Typography permanecen intactas, sin simplificar ni reescribir. Solo cambian dos componentes:

const HeadingLevelContext = createContext(1);

function DashboardLayout({ children }) {
  return (
    <main>
      <h1>Dashboard</h1>
      <HeadingLevelContext.Provider value={2}>
        {children}
      </HeadingLevelContext.Provider>
    </main>
  );
}

function Heading({ children }) {
  const level = useContext(HeadingLevelContext);
  const Tag = `h${level}`;
  return <Tag>{children}</Tag>;
}

DashboardLayout establece el nivel una sola vez. Heading lo lee desde el contexto en lugar de adivinarlo a partir de una cadena variant. Nada en el medio necesita saber que el contexto existe.

El costo aquí es diferente, no inexistente. Leer Heading de forma aislada ya no te dice qué etiqueta renderiza: debes saber que existe un proveedor (provider) en algún lugar superior del árbol. La primera solución es más fácil de rastrear leyendo solo las propiedades (props). La segunda pide a menos componentes participar en una decisión que nunca les perteneció.

Si la afirmación se sostuvo

La afirmación del ensayo de leer era que la arquitectura de componentes organiza el código fuente y no puede, por sí sola, reemplazar la estructura del documento, y que el fallo es una decisión dividida entre componentes, no un componente roto. Seis capas, recorridas una a una, nunca produjeron una sola capa que conservara ambas mitades de la información que la decisión necesitaba. DashboardLayout tenía la estructura. Heading tenía la etiqueta. Nada en el medio tenía ambas.

Ambas soluciones confirman también la segunda mitad de la afirmación. Ninguna reduce los seis componentes a menos. Una transmite el contexto faltante a través de todos ellos. La otra lo transmite solo a través de los dos que realmente lo necesitaban. De cualquier manera, la solución nunca se trató de cuántos componentes existen. Se trató de a cuál se le entrega la información que le faltaba.

Artículo de referencia:

Por qué los árboles DOM con abstracción de componentes se vuelven más difíciles de leer

Notes from the Pass: The Question Six Components Couldn't Answer

Franklin — Sat, 26 Sep 2026 10:20:06 +0000

Also available in Español

The Claim Being Tested

Tuesday's essay argued that component architecture can organize source code without being able to replace the structure of the document it produces — and that the failure isn't dividing a page into components, it's dividing a single decision across components without checking whether any one of them was left holding enough information to make it. The example was a heading level, decided six components away from the page position that should have set it.

This Note runs that exact six-component chain, asks the same question at every layer, and marks precisely where the decision and the context it needed come apart. Then it puts them back together two different ways, without touching the number of components in the chain.

The Chain

Six components, composed the way they'd actually be used:

<DashboardLayout>
  <CardGroup>
    <Card title="Active Subscriptions">
      {/* subscription list */}
    </Card>
  </CardGroup>
</DashboardLayout>

Each layer does one job:

function DashboardLayout({ children }) {
  return (
    <main>
      <h1>Dashboard</h1>
      {children}
    </main>
  );
}

function CardGroup({ children }) {
  return <div className="card-grid">{children}</div>;
}

function Card({ title, children }) {
  return (
    <div className="card">
      <CardHeader title={title} />
      <div className="card-body">{children}</div>
    </div>
  );
}

function CardHeader({ title }) {
  return (
    <div className="card-header">
      <Typography variant="subheading">{title}</Typography>
    </div>
  );
}

function Typography({ variant, children }) {
  return <Heading variant={variant}>{children}</Heading>;
}

function Heading({ variant, children }) {
  const Tag = variant === 'subheading' ? 'h6' : 'h2';
  return <Tag>{children}</Tag>;
}

Rendered, this produces exactly what the essay described:

<main>
  <h1>Dashboard</h1>
  <div class="card-grid">
    <div class="card">
      <div class="card-header">
        <h6>Active Subscriptions</h6>
      </div>
      <div class="card-body">...</div>
    </div>
  </div>
</main>

Six Questions, Same Answer

Ask every layer the same two questions. Does it know where this section sits in the page's outline? Does it know what HTML tag its heading will become?

DashboardLayout knows the outline. It renders the page's only <h1>, which means it also implicitly knows that whatever it renders as children belongs below that <h1> in the hierarchy. It doesn't know the tag — it never touches a heading itself, only hands off to whatever it's given.

CardGroup knows neither. It's a grid wrapper. It doesn't know it's inside a dashboard, and it has no opinion about headings at all.

Card knows neither. Border, padding, a CardHeader, a body. No heading logic lives here either.

CardHeader knows the string — "Active Subscriptions" — but not where the card holding it sits on the page. It doesn't decide a tag. It hands the string to Typography with a styling instruction: render this like a subheading.

Typography knows the styling instruction, not the outline, and doesn't decide a tag either. It exists so the design system has one place that says what "subheading" looks like. It forwards variant straight through.

Heading is where "subheading" actually becomes <h6>. This is the only layer in the entire chain where a real tag name gets chosen — and it's also the layer furthest from the page, the one with no way to know that "Active Subscriptions" will land six levels below a page title it has never seen.

Six layers, six identical answers to the second question, until the sixth one flips — at exactly the layer least equipped to answer it correctly.

Two Ways Back

Thread the level explicitly. Give every layer a level prop and pass it straight through, unchanged, from the top:

function DashboardLayout({ children }) {
  return (
    <main>
      <h1>Dashboard</h1>
      {children}
    </main>
  );
}

function CardGroup({ level, children }) {
  return <div className="card-grid">{children}</div>;
}

function Card({ level, title, children }) {
  return (
    <div className="card">
      <CardHeader level={level} title={title} />
      <div className="card-body">{children}</div>
    </div>
  );
}

function CardHeader({ level, title }) {
  return (
    <div className="card-header">
      <Typography level={level}>{title}</Typography>
    </div>
  );
}

function Typography({ level, children }) {
  return <Heading level={level}>{children}</Heading>;
}

function Heading({ level, children }) {
  const Tag = `h${level}`;
  return <Tag>{children}</Tag>;
}

<DashboardLayout>
  <CardGroup level={2}>
    <Card level={2} title="Active Subscriptions">
      {/* subscription list */}
    </Card>
  </CardGroup>
</DashboardLayout>

Visual styling is left out of this version to keep the level-threading visible — in practice it would travel the same path level does now, just under its own prop, separate from structure the way the essay argued it should be.

The cost of this fix: CardGroup, Card, CardHeader, and Typography all had to change, even though none of them ever had a stake in the decision. Add a seventh wrapper to the chain next quarter, and it has to remember to forward level too, or the chain breaks again in a new place.

Track it through context instead. Let the layers that never had a stake in the decision stay exactly as they were in "The Chain" — CardGroup, Card, CardHeader, and Typography are untouched, not simplified, not rewritten. Only two components change:

const HeadingLevelContext = createContext(1);

function DashboardLayout({ children }) {
  return (
    <main>
      <h1>Dashboard</h1>
      <HeadingLevelContext.Provider value={2}>
        {children}
      </HeadingLevelContext.Provider>
    </main>
  );
}

function Heading({ children }) {
  const level = useContext(HeadingLevelContext);
  const Tag = `h${level}`;
  return <Tag>{children}</Tag>;
}

DashboardLayout establishes the level once. Heading reads it from context instead of guessing at it from a variant string. Nothing in between needs to know the context exists.

The cost here is different, not absent. Reading Heading in isolation no longer tells you what tag it renders — you have to know a provider exists somewhere above it in the tree. The first fix is easier to trace by reading props alone. The second one asks fewer components to participate in a decision they never owned.

Whether the Claim Held

The essay's claim was that component architecture organizes source code and cannot, on its own, replace the structure of the document — and that the failure is a decision split across components, not a component that's broken. Six layers, walked one at a time, never produced a single layer holding both halves of the information the decision needed. DashboardLayout had the outline. Heading had the tag. Nothing in between had either.

Both fixes confirm the second half of the claim too. Neither one reduces six components to fewer. One threads the missing context through all of them. The other threads it through none but the two that actually needed it. Either way, the fix was never about how many components exist. It was about which one gets handed the information it was missing.

Reference Article:

Why Component-Abstracted DOM Trees Become Harder to Read