El Curb Cut Effect: Por qué la accesibilidad no es un favor, es arquitectura básica

Leslie Herrera — Thu, 23 Apr 2026 18:14:43 +0000

No es accesibilidad. Es calidad de software.

Si alguien no puede usar tu producto, no es un edge case.

Es un bug.

El Curb Cut Effect lo explica bien: cuando diseñas para los casos más exigentes, mejoras la experiencia para todos.

De las rampas de Berkeley al `main` de tu proyecto

En los años 70, activistas en Berkeley impulsaron la instalación de rampas en las veredas, evidenciando algo clave: lo que parecía un detalle urbano, para muchas personas era una necesidad básica.

Ese cambio no solo benefició a personas con discapacidad. Terminó mejorando la movilidad de todos: personas con maletas, coches de bebé, repartidores o cualquiera que necesitara moverse con mayor facilidad.

Ese fenómeno se conoce como el Curb Cut Effect.

En el desarrollo de software, nos enfrentamos a las mismas "rampas" y "muros" todos los días.

Diseño Universal: cuando la necesidad de uno mejora la experiencia de todos

El diseño universal no busca crear productos "especiales" para personas con discapacidad; busca crear productos que funcionen para la mayor cantidad de personas posible, sin necesidad de adaptación.

Piénsalo así:

La rampa física: ayuda a la persona en silla de ruedas, pero también al padre con un coche de bebé, al viajero con maletas o a alguien que simplemente quiere moverse más rápido.
La rampa digital: cuando etiquetas correctamente tus componentes y usas HTML semántico, no solo ayudas a un usuario de lector de pantalla.

Situaciones donde tu accesibilidad ayuda a cualquiera:

Contextos ambientales: alguien usando tu app bajo el sol intenso y que depende de un buen contraste.
Limitaciones temporales: una persona con una mano ocupada (o lesionada) que necesita targets accesibles.
Power users: quien navega tu interfaz exclusivamente con teclado.

El código semántico es código de alta calidad

La accesibilidad no es un extra. Es una señal de código bien escrito.

Un botón hecho con un <div> no es solo una mala práctica.

Es un bug.

Un formulario sin <label> no es solo un detalle.

Es una barrera.

Lo que para nosotros puede parecer una decisión técnica menor, para otra persona es la única forma de interactuar con el producto.

Aplicando el "Curb Cut" en tu día a día

Hoy no hay excusas. Puedes mejorar la calidad de tu software con decisiones simples:

Estructura: usa encabezados (H1, H2, H3) en orden lógico.
Interactividad: si se puede hacer clic, debe poder enfocarse y usarse con teclado.
Contenido: incluye texto alternativo (alt) descriptivo en imágenes.
IA como aliada: usa herramientas de IA para auditar accesibilidad o generar descripciones iniciales.

Conclusión: ¿rampas o muros?

El usuario "ideal" no existe.

La web se usa en contextos imperfectos: con distracciones, limitaciones físicas, mala iluminación o conexiones inestables.

Construir software accesible no es hacer un favor.

Es entender el problema completo.

La próxima vez que escribas un componente, pregúntate:

¿Estoy construyendo una rampa… o un muro?

¿Cómo usar Container Queries?

Leslie Herrera — Fri, 19 May 2023 00:45:12 +0000

Este año 2023 ya es posible usar los container queries en nuestros proyectos de CSS, debido a que la mayoría de los navegadores ya lo soportan, se ve bastante genial pero ¿cómo implementarlo?

Vamos a ello 🫡!

Primero, tenemos que tener claro cuál va a ser nuestro elemento HTML "contenedor", en este caso vamos a tener un elemento div con la clase "contenedor" (muy original 😶‍🌫️), lo he colocado en esta etiqueta porque quiero aplicar mis estilos sobre <section>.

<div class="contenedor">
  <section>
    <p>Párrafo 1</p>
    <p>Párrafo 2</p>
  </section>
</div>

Bien! con el HTML listo ahora vamos a declararlo en nuestra hoja de estilos, podemos tener "contenedores anónimos" o también podemos nombrarlos, en este caso vamos a ejemplificar uno con nombre.

A la clase .contenedor debemos entregarle dos propiedades:

container-name: nombre de nuestro container query.
container-type: cómo va comportarse con respecto al "tipo de tamaño" que tendrá nuestro contenedor, que puede ser size o inline-size.

Valores del container-type:

size: considera eje x y eje y, es decir, se va a extender tanto en alto y ancho con respecto al contenedor.
inline-size: considera el eje y, es decir, sólo se va a extender a lo ancho con respecto al contenedor y no considerará el alto.

Nuestro css debería verse así:

.contenedor {
   container-name: mobile;
   container-type: inline-size;
 }

Listo, le hemos entregado las dos propiedades que necesitábamos, también tenemos la forma corta/shorthand de escribirlo 👇:

.contenedor {
   container: mobile / inline-size;
 }

Ahora, al declarar nuestro container-query recién creado, el patrón sería el siguiente 👇:

@container + nombre del contendor + rango del contenedor

En este caso he utilizado el "range-syntax" para indicar que desde 1024px hacia abajo se active la propiedad.

Dentro de este vamos a colocar los estilos que necesitamos:

@container mobile (width <= 1024px) {
   section{
     background-color: red
   }

   p {
    color: pink
   }
 }

¿Cómo "debuggear" mis container queries 🐛?

Si estás usando el browser google chrome, al inspeccionar el sitio web te aparecerá destacado container y allí puedes ver incluso el nombre del container-query aplicado cuando te posicionas sobre el elemento hijo ✨

He preparado un pequeño codepen con este mismo ejemplo para que puedas jugar y probar esta nueva regla tu mismo 😊.

*Nota: si estás usando visual studio code probablemente te vas a encontrar con el warning: "Unknown at rule @container", no te preocupes que ya se levantó el issue con el equipo de VSC y funcionará igualmente.

Espero que te haya ayudado ✨!

DEV Community: Leslie Herrera