DEV Community: Adrian Benavente

Accesibilidad: desafíos en la era de la Inteligencia Artificial

Adrian Benavente — Fri, 22 Sep 2023 15:04:46 +0000

De algo no podemos dudar, la Inteligencia Artificial (IA) avanza a pasos agigantados y no parece que vaya a experimentar un retroceso en un futuro cercano -ni lejano-, más bien todo lo contrario.

En lo personal, no puedo evitar medir la tecnología en función de lo que puede aportarle a la humanidad. Y al margen de ser un defensor de la IA como una herramienta de trabajo más, que nos aleja de roles utilitarios y redime de tareas repetitivas, permitiéndonos habitar más el plano de la abstracción y de las ideas, esa es para mí solo una de las tantas formas en que puede mejorar la calidad de vida de la gente.

Resulta tentador pensar que el potencial está en la capacidad de integrarse a los productos de apoyo, y no estaríamos del todo errados. Por ejemplo, un software de asistencia podría ser capaz de generar textos alternativos o captions de un video donde no hayan sido incluidos. Bien, esto ya ocurre, pero hoy uno de los principales problemas radica en la baja precisión de los resultados. Además, esto eleva su costo tanto económico como de recursos, ya que se necesita un poder de cómputo mayor.

Y aquí se desprende una pregunta inevitable, ¿no deberíamos nosotros como desarrolladores tomar medidas para quitar esa carga de encima al usuario, sirviéndonos de la IA para proveer experiencias digitales accesibles e inclusivas más satisfactorias?

Dado mi interés particular por la accesibilidad web, una de las primeras inquietudes que vinieron a mi mente fue acerca de cuán provechosa podría resultar la inteligencia artificial para generar descripciones automatizadas de imágenes. Para este artículo, elegí enfocarme en ese escenario en específico con el fin de intentar ilustrar, con un caso cotidiano, de qué manera podría representar un gran beneficio pero también profundizar aún más la brecha de inclusión y convertirse en un mecanismo silencioso de replicar y reforzar sesgos si no se toman las acciones adecuadas. Sobre el final veremos cómo este desafío también se traslada a otros terrenos.

Aclaro de antemano que no soy un experto en Machine Learning ni Inteligencia Artificial, si no un desarrollador web volcado a la accesibilidad tratando de ver hacia dónde va el mundo digital, y qué o a quiénes podríamos estar dejándonos en el camino. Ahora sí, vamos a sumergirnos de lleno en este asunto.

Descripción de imágenes

Sabemos que las redes sociales ya desde hace bastante ofrecen la posibilidad de añadir manualmente texto alternativo a las imágenes, pero lamentablemente aun hoy es minoritaria la porción de gente que se toma ese trabajo, y aun son menos los que cuentan con conocimiento acerca de cuáles son las consideraciones y prácticas recomendadas a la hora de redactar un texto alternativo útil. Con lo cual ya vemos asomar aquí una necesidad. En tal caso, ¿podemos los autores de contenido simplemente delegar esta tarea en una herramienta automatizada y desentendernos por completo?

La respuesta a priori pareciera ser un "no" rotundo si tenemos en cuenta que se requiere ciertos datos periféricos para nutrir al modelo a entrenar y prevenir resultados sesgados. Estos datos deberían contemplar cosas tales como el entorno, expresiones, emociones, y sobre todo, que los mismos provengan de imágenes que reflejen variedad, y eso incluye a personas con diversidad funcional, de género, de etnia, etc.

Existen herramientas online y plugins que permiten crear texto alternativo empleando inteligencia artificial, y de hecho es una funcionalidad implementada desde hace un buen tiempo en redes sociales como Instagram y Facebook, pero en todos los casos tienen bastantes limitaciones a la fecha de la redacción de este artículo. Suelen fallar en la mayoría de los aspectos que se mencionaron en el párrafo anterior, a menudo proporcionando información insuficiente, reducida a apenas una descripción superficial. Y ni hablar de los gráficos de representación de datos, quizás el apartado donde encontramos mayor déficit en lo que a alternativas textuales se refiere, a pesar de que está habiendo progresos.

Más allá de si pueden o no brindar el contexto necesario para entender una imagen, el punto es que, por ahora, estas herramientas no predicen qué detalles son importantes para el usuario; y no se trata de algo menor. Claro que se espera que esto evolucione a futuro, pero aun no parece que se esté hablando lo suficiente del tema, y toda potencial barrera de acceso al contenido debería ser abordada desde la fase más temprana del desarrollo.

Cuáles detalles serán más relevantes por sobre otros, dependerá de varios factores. Algo a valorar podría ser aquello que deseaba comunicar quien creó la imagen. Además, es fundamental conocer el tipo de contenido que consumen los usuarios según la plataforma y de qué manera lo hacen. Una imagen publicada en una red social requiere una descripción distinta a la de un sitio web portfolio para fotógrafos, o un portal sobre ciencia, porque los intereses de cada público no son los mismos.

Por todo lo mencionado, en la actualidad todavía es indispensable la intervención humana en la revisión del output antes de la publicación. Pero mientras tratamos de concientizar a los creadores de contenido sobre la importancia de involucrarse en ello, tenemos que estar preparados para encontrarnos con que, en un principio, una gran parte creerá que la generación automatizada será suficiente. Esto desemboca inevitablemente en la discusión acerca de la Inteligencia Artificial Explicable[¹] como parte de un derecho universal, el derecho a la explicación, tal como se lo contempla en el Reglamento General de Protección de Datos (GDPR) de la Unión Europea. Al menos el usuario final debería poder conocer, de forma clara y transparente, el proceso de toma de decisiones que llevó a la IA al resultado que se le presenta, y así de paso ayudarlo a identificar posibles sesgos.

Ahora bien, que sea posible automatizar por completo esta tarea a futuro es algo esperable, pero creo que nos encontramos en un momento crucial de la historia para garantizar que, cuando llegue ese futuro, su implementación realmente resulte un aporte valioso para la inclusión digital.

Entonces, ¿además de evitar los sesgos durante la fase de entrenamiento, de qué otra forma podríamos garantizar descripciones relevantes? Una buena idea sería permitirle al usuario acceder a una descripción más amplia si así lo desea, mediante un enlace por ejemplo. O bien proporcionar filtros que le permitan refinar el nivel de detalle de los textos alternativos generados. También, una característica que poseen varias aplicaciones y sitios web es mostrar una advertencia cuando una descripción fue generada automáticamente; aunque esto sirva como medida adicional, por sí sola sigue siendo insuficiente. Por supuesto que, en los tiempos que corren, lo ideal sería que el software fuese capaz de reconocer y adaptarse a las preferencias del usuario a nivel de sistema o navegador, aun queda mucho camino por recorrer en ese sentido.

Conclusiones

Si bien elegí enfocarme en un caso típico, el problema de los sesgos introducidos en los modelos de Machine Learning genera una brecha de inclusión transversal a gran parte de las implementaciones de inteligencia artificial actuales. Por poner un ejemplo, tanto los asistentes de voz como los programas de speech-to-text (voz a texto), tienen problemas para reconocer correctamente el habla si esta no se ajusta a cierta "norma". Personas con Parkinson, tartamudos, sordos, personas con Síndrome de Down, ELA, o parálisis cerebral, encuentran una barrera a la hora utilizar estas tecnologías.

Del lado de los desarrolladores de software nos encontramos con que asistentes de código basados en inteligencia artificial como GitHub Copilot, al usar como fuente de datos el código open source disponible en GitHub, arrastra consigo todas las malas prácticas de accesibilidad del pasado. Y este punto es importante: si la data que alimenta a las IA proviene del pasado, pertenece, por ende, a un pasado que -y aquí coincidiremos la mayoría- era menos inclusivo.

Para muestra un botón. La organización WebAIM realiza anualmente un análisis de cerca de un millón de sitios web en busca de errores de accesibilidad[²]. En el último análisis de febrero de 2023, en el 96.3% de los casos se detectaron fallos de conformidad con las WCAG 2, siendo dos de los principales la falta de textos alternativos y de etiquetas de formulario. Esto representa un decremento del 1.5% en los últimos cuatro años[³].

Por lo pronto, veo al menos dos caminos, generar modelos universales y diversos, o especializados para incluir a los grupos minoritarios. Lo que está claro es que si no tomamos una medida ya mismo al respecto, estaremos perpetuando y reforzando estos sesgos, provocando más y más exclusión.

Por suerte, ya hay varios proyectos en marcha. En el área del reconocimiento de voz, cabe destacar Project Euphonia de Google[⁴] y el Speech Accessibility Project de la Universidad de Illionis[⁵].

Es insoslayable que la inteligencia artificial está abriendo posibilidades que nos invitan a soñar con un mundo digital más inclusivo. Todavía estamos a tiempo, es solo una cuestión de aprender de los errores del pasado y poner las prioridades en su lugar, moviendo la accesibilidad al comienzo de nuestro flujo de trabajo.

Lectura adicional:

Referencias:

[¹]: Inteligencia artificial explicable - Wikipedia, la enciclopedia libre

[²]: WebAIM: The WebAIM Million - The 2023 report on the accessibility of the top 1,000,000 home pages

[³]: WebAIM: The WebAIM Million - The 2023 report on the accessibility of the top 1,000,000 home pages

[⁴]: Project Euphonia

[⁵]: Speech Accessibility Project

La espera terminó: el elemento DIALOG alcanza pleno soporte

Adrian Benavente — Tue, 19 Apr 2022 14:12:10 +0000

Primero sería Firefox 98, en marzo de este año, quien se sumaría a darle soporte¹, y Safari haría lo propio al poco tiempo con su más reciente versión, la 15.4², pasando así el elemento <dialog> de HTML5 a ser soportado por todos los navegadores modernos³.

Especificaciones principales

Categoría a la que pertenece: Contenido de flujo⁴, seccionado raíz⁵.
Contenido permitido: Contenido de flujo.
Interfaz de DOM: HTMLDialogElement.

Contexto de uso

Se usa para representar un cuadro de diálogo o ventana modal, ya sea para informar algo importante al usuario, como para involucrarlo en alguna acción o toma de decisiones. Están inspirados en los que vemos comúnmente en todos los sistemas operativos.

Problemas que resuelve

Las soluciones mágicas que nos trae, además de tener un impacto positivo del lado del usuario, mejoran también la experiencia de desarrollo. Veamos algunas.

Accesibilidad y experiencia de usuario

El diálogo se cierra al presionar la tecla Esc, interacción que cualquier usuario, tenga una discapacidad o no, agradecerá siempre.

Por defecto, el foco se coloca automáticamente sobre el primer elemento enfocable que exista dentro, a no ser que se indique otro explícitamente usando el atributo autofocus.

Al cerrarse el diálogo, el foco vuelve a donde se encontraba antes (típicamente el botón o elemento que disparó su apertura).

Por otro lado, para que las tecnologías de apoyo, como los lectores de pantalla, comuniquen al usuario el propósito del diálogo, es suficiente con usar aria-labelledby en el elemento, apuntando al id del título del mismo, o sumistrar el texto directamente mediante aria-label. Si este no fuese lo suficientemente descriptivo, se puede recurrir a aria-describedby⁶.

<dialog aria-labelledby="dialog-title">
    <h1 id="dialog-title">Agregar a la billetera</h1>
    ...
</dialog>

<dialog aria-label="Agregar a la billetera">
    ...
</dialog>

De esta forma, al abrirse el diálogo, se anunciará su título seguido de la palabra "diálogo" (si no se provee, se anuncia solamente "diálogo"). Además, huelga decir que ya nos podemos olvidar del uso de role="dialog", ya que, al ser una etiqueta semántica, su rol es implícito, pudiendo únicamente cambiarse por el más específico role="alertdialog"⁷ ⁸.

Interacción y estilos

Invocando el método show() del elemento, se muestra el diálogo sin impedir la navegación por el resto del documento, mientras que showModal() confina al usuario, realizando focus trap, hasta tanto se ejecute el método close(); al accionarse un botón, por ejemplo, o si se pulsa Esc. Además, showModal() agrega una capa de overlay para ocultar el contenido subyacente, la cual puede ser accedida por CSS para su personalización, mediante el pseudoelemento ::backdrop⁹.

Si se busca conocer el estado (abierto o cerrado) del diálogo, se puede consultar el atributo (implícito) open del elemento, el cual retorna un booleano. Una advertencia: ¡nunca se debería modificar el valor de este atributo o removerlo! En primer lugar, porque el navegador perdería por completo el rastro del estado, produciendo varios efectos no deseados¹⁰; y en segundo lugar, ¿por qué querrías hacerlo, si al final se controla "automágicamente"?

Conclusiones

A estas alturas, y si eres alguien con ciertos conocimientos de accesibilidad, te resultarán más que evidentes las ventajas que trae de serie este elemento. Hasta ahora, debíamos tener una serie de consideraciones que, si se descuidaban, fácilmente nuestras modales podían volverse una pesadilla para la accesibilidad. Otra opción era buscar una librería que proporcione diálogos accesibles, a cambio de ceder el control sobre nuestro markup, o terminar invirtiendo en personalización el tiempo que se pretendió ahorrar en un principio.
En cualquier caso, había que cerciorarse de que se cumpla con lo siguiente:

Indicar el rol: para que las tecnologías de apoyo puedan anunciar que se trata de un diálogo.
Atrapar el foco -aplica para ventanas modales-: Se trata, hoy por hoy, de una labor prácticamente artesanal, y consiste en hacer que, al avanzar el foco con la tecla tabuladora (Tab), tras haber alcanzado el último elemento interactivo del diálogo, este vuelva a posarse sobre el primero; y a la inversa, al retroceder con Shift + Tab, impidiendo que el usuario navegue a otras partes del documento por fuera de la ventana modal.
Bloquear el resto del documento: por la misma razón que en el caso anterior: en una ventana modal, queremos que el usuario se concentre en una acción específica. Para esto, la práctica más común es volver el resto del contenido invisible para los usuarios de tecnologías de asistencia cuando la modal está visible, añadiendo aria-hidden="true" mediante JS a un contenedor principal, colocando por fuera al elemento que hace las veces de diálogo; además, conviene agregar a este último el atributo aria-modal="true", de esa forma los productos de apoyo avisarán que el resto del contenido está inactivo. Luego, hay que recordar cambiar a aria-hidden="false" o remover el atributo por completo del nodo cuando la modal se cierre.
Controlar el estado abierto/cerrado: para impedir la creación de diálogos duplicados o permitir volver a abrir un diálogo cerrado; para lo mencionado en el punto anterior sobre el bloqueo del documento.
Conservar la referencia del elemento que abrió el diálogo: para devolver el foco a su sitio original al cerrarlo.

Probablemente nos hayamos encontrado realizando estas tareas de manera repetitiva en el pasado. Bueno, se podría decir que ya no tendremos que preocuparnos más por ellas.

Sin embargo, como sucede con toda nueva característica, conviene que sea usada con prudencia y proporcionando algún tipo de fallback para agentes de usuario más antiguos: versiones de navegadores aun vivas o tecnologías de apoyo cuyo ciclo de actualización es más lento. Una buena opción, bastante robusta, puede ser a11y-dialog. También existe un polyfill publicado por el equipo de Chrome. No nos olvidemos que la retrocompatibilidad también forma parte de la accesibilidad.

Donar

WCAG 3.0 (Silver), cocinando el futuro de la accesibilidad digital

Adrian Benavente — Wed, 10 Nov 2021 22:16:24 +0000

WCAG, por sus siglas Web Content Accessibility Guidelines (W3C Accessibility Guidelines a partir de la versión 3.0), son una serie de recomendaciones (pautas) desarrolladas por el Accessibility Guidelines Working Group, que es, a su vez, miembro de la WAI. No nos adentraremos en explicar qué es la WAI ya que no está dentro del alcance de este artículo. Dichas pautas adquirieron el estatus de Estándar ISO/IEC, registrado bajo el código 40500 en 2012, y se han convertido una de las principales referencias a la hora de crear una experiencia satisfactoria para todos los usuarios de la web por igual, sin importar sus condiciones físicas o mentales.

WCAG 2.0 vio la luz en 2008. La versión 2.1 (2018), adicionó algunos nuevos criterios. La 2.2 aun es borrador, se espera se convierta en recomendación para lo que resta de 2021.

Codename "Silver"

La siguiente versión mayor, la 3.0, también se encuentra en borrador. El nombre en clave de este proyecto antes de ser publicado era Silver, ya que ese es el nombre del grupo de trabajo a cargo. Su fecha de lanzamiento está planificada para 2023, y tiene objetivos muy concretos.

Abrazar nuevas tecnologías 🧑‍💻

Se busca incorporar documentación para libros digitales, PDF, aplicaciones para teléfonos móviles, y tecnologías emergentes como la realidad virtual, la realidad aumentada y la Web of Things. Muchas de las cuales no existían, o no estaban tan avanzadas cuando se redactó WCAG 2.0.

De manera que, por cada error que arroje un test, se nos ofrecerá una serie de métodos distintos para resolverlo, dependiendo de a qué tecnología estemos apuntando.

Se deja de utilizar el término web unit, que hace referencia a la URI específica de un documento, y en su lugar se introducen los conceptos de vistas y procesos; un proceso son los pasos secuenciales que tiene que completar el usuario para realizar una determinada tarea. Ajustándose así a la forma en que funcionan las aplicaciones en el presente.

Mayor inclusión 🫂

La idea es atender a las necesidades de más grupos de diversidades funcionales en los que las pautas de WCAG 2 no están tan enfocadas. Por ejemplo, existe un gran número de criterios de conformidad para personas con discapacidad visual, pero menos de 10 para personas con discapacidad auditiva.

Similar es el caso de las personas con discapacidad del habla, quienes han encontrado en los asistentes virtuales una nueva barrera tecnológica.

También se pondrá un mayor enfásis en las personas con discapacidad cognitiva.

Accesibilidad para todo el mundo 🌎

La idea es que más individuos, empresas y organizaciones logren que sus productos, o el contenido que crean, sean accesibles. Para ello, se renovó el sitio web de la documentación con un formato más amigable y claro. Se evita abrumar al lector, utilizando acordeones, para que pueda concentrarse mejor, mostrando solo aquello que le interese. A esto se le suma el uso de iconografía mejorada acompañando los textos.

Project managers, formuladores de políticas u otros puestos que no sean de ingeniería y desarrollo, se encontrarán con una versión en lenguaje de alto nivel, despojada de tecnicismos, para que puedan llevarse la información que necesiten para trabajar.

Un feedback más útil 🛠️

Los test se realizarán primero de manera atómica, a nivel de vistas, componentes o bloques de contenido. Cada uno de estos recibirá un puntaje de 0% a 100%.

Estos resultados, junto con el número de errores críticos, arrojarán un puntaje final que va de 0 a 4. Se aprueba con un promedio total de 3.5 entre todas las categorías funcionales, siempre y cuando ninguna tenga una puntuación menor a 3.5; es decir, no se puede promediar 3.5 en el total pero que una de las categorías haya obtenido un score de 1. Esto significa que se aceptará un cierto número errores no críticos, brindando mayor flexibilidad que el actual "pasa" o "no pasa", todo esto sin sacrificar exigencia, ya que un solo error crítico arrojará un puntaje de 0 y no se podrá alcanzar la conformidad.

Estos son los umbrales propuestos para los resultados de las pruebas (pueden cambiar):

Muy pobre (0): Cualquier error crítico o menos del 50% de las pruebas relacionadas pasan
Deficiente (1): Sin errores críticos, aprox. del 50% al 79% de las pruebas relacionadas pasan
Regular (2): Sin errores críticos, aprox. pasan del 80% al 89% de las pruebas relacionadas
Bueno (3): Sin errores críticos, aprox. pasan del 90% al 98% de las pruebas relacionadas
Excelente (4): Sin errores críticos, aprox. Pasan del 99% al 100% de las pruebas relacionadas

Las pruebas holísticas, o sea, las que están centradas en la experiencia del usuario y no en la funcionalidad, aun no han sido claramente definidas en el borrador.

Niveles de conformidad menos ambigüos 🥇

La forma de medir la conformidad ha sido reformulada, reemplazando los niveles A, AA y AAA por Bronze, Silver y Gold, ya que el sistema vigente ha demostrado no siempre ser confiable: hay usuarios que logran realizar sus tareas con éxito en sitios que no cumplen con el nivel AA, mientras que otros fracasan en utilizar sitios que lo hacen a rajatabla. De esta forma, se busca también utilizar un vocabulario más familiar para todo individuo, y alentar así a quienes hacen sitios web y producen contenido a querer superarse y hacerlo cada vez mejor.

Redes sociales 🗣️

Mejorar la accesibilidad de las redes sociales, es otra de las metas. Cuando se publicó WCAG 2.0 en 2008, el contenido de la web no se actualizaba al ritmo de hoy en día. Resulta complicado para los administradores de este tipo de plataformas medir su nivel de accesibilidad. Se espera que el nuevo sistema de puntuación les brinde un panorama más claro para que puedan saber dónde están parados, dentro un un espectro.

Cambio de acrónimo

Por último, cabe mencionar que se cambiará el acrónimo de Web Content Accessibility Guidelines, para pasar a ser W3C Accessibility Guidelines. Esto se decidió, por un lado porque la mayoría de la gente tiene asociada mentalmente a la W3C con estas pautas, pero sobre todo para no limitarlas únicamente al contenido de la web, ampliando así su alcance a otras tecnologías, como ya mencionamos antes.

Referencias

Colaborar

Buy Me a Coffee
Invitame un café en cafecito.app

El problema de las SPA y la accesibilidad... y cómo solucionarlo

Adrian Benavente — Sun, 07 Nov 2021 22:04:55 +0000

Las SPA son aplicaciones o sitios que, en lugar de hacer una petición al servidor cada vez que el usuario interactúa con la página, los contenidos se cargan una única vez y son mostrados de manera dinámica por JavaScript en el momento en que sean requeridos, ya sea en su totalidad o de manera parcial y asíncrona, sin necesidad de recargar toda la página. Esto permite una navegación más fluida, con menor consumo de recursos, similar a la de una aplicación nativa.

A su vez, a los desarrolladores nos permitió granularizar mucho más nuestra arquitectura, dejando de pensar en páginas, para pasar a verlo todo en términos de componentes. También facilitó la depuración de errores ya que todo lo que necesitamos es un navegador y las developer tools del framework o librería que estemos usando.

Sin embargo, y a pesar de todas sus bondades, de las que solo nombré las más superficiales ya que este no es un artículo dedicado enteramente a las SPA, se podría decir que de cierto modo hicieron la web menos accesible por defecto.

Claro que, echarle toda la culpa de esto a las SPA, no sería lo más razonable. Un cambio de paradigma no es más que una nueva manera de pensar y hacer las cosas. Por eso quiero compartir una serie de implementaciones que deberemos hacer desde el comienzo del proceso del desarrollo, que, junto con las verificaciones básicas de siempre, garantizarán que nuestras SPA cumplan con el principio 2 de las WCAG 2.0 que es ser operables.

Manejo del foco

Como la pestaña no se recarga al navegar entre vistas, el lector de pantalla no avisará de ningún cambio de contenido a no ser que se le indique explícitamente. Para ello, una técnica muy común es ubicar el foco en el primer encabezado.

function onNavigate() {
    document.getElementById('titulo-seccion').focus();
}

Pero las etiquetas de encabezado no son elementos enfocables, por lo que hay que otorgarles esta característica, colocándoles el atributo tabindex. Le daremos un valor de -1, para evitar que interfiera en el flujo de navegación de la tecla TAB.

<section>
    <h2 id="titulo-seccion" tabindex="-1">Título de la sección</h2>
    <p>Aquí el contenido...</p>
</section>

Lo anterior también aplica a los casos en donde un botón o enlace realiza un scroll dentro de la vista, hasta otra parte de la misma. Siempre se debería poner el foco donde comienza el contenido al que llevaremos al usuario.

Título del documento

Al existir un único documento HTML, este tendrá siempre el mismo título. El usuario podría no saber en qué pantalla se encuentra, en caso de irse a otra pestaña del navegador y luego volver. Por eso, debemos modificar el texto de la etiqueta <title> mediante JS, al cambiar de vista, para que refleje el contenido de esta.

document.title = "Mi maravilloso sitio | Quiénes somos"

Semántica HTML

A veces, los frameworks de desarrollo de SPA, si no son bien utilizados, pueden forzar malas prácticas como el uso excesivo de etiquetas <div>, lo que puede degradar o hasta arruinar por completo la experiencia de usuarios de tecnologías asistivas. Mantener siempre una correcta semántica HTML, resulta imprescindible.

<header>
  <h1>Mi página</h1>
  <nav>
    <ul>
      <li>
        <a href="/home">Inicio</a>
      </li>
      <li>
        <a href="/nosotros">Nosotros</a>
      </li>
      <li>
        <a href="/portfolio">Portfolio</a>
      </li>
      <li>
        <a href="/contacto">Contacto</a>
      </li>
    </ul>
  </nav>
</header>
<main>
  <section>
    <h2>Nosotros</h2>
    <p>Bla, bla...</p>
  </section>
  ...
</main>
<footer>
  <p>@adrian.benavente.dev</p>
</footer>

Conclusión

La tecnología avanza y con ella las formas de desarrollar software, y las tecnologías de asistencia también hacen lo propio para acompañar esta evolución. Seguro que en un futuro próximo cada vez encontraremos un mejor soporte para SPA por parte de los distintos agentes de usuario que utilizan las personas con discapacidades, o, tal vez, las herramientas de desarrollo de SPA incorporen mejoras de accesibilidad. Mientras tanto, no podemos simplemente sentarnos a esperar que esto suceda, y mucho menos, cuando ocurra, dejar de lado la retrocompatibilidad.

Por último, no olvidemos que, según las WCAG, en una declaración de conformidad un documento es o no es accesible, pero nunca puede ser parcialmente accesible; en ese caso se considera que no lo es, y se lo excluye. Ahora bien, una SPA consta de un solo documento. ¿Se va entendiendo el punto?

ACTUALIZACIÓN: el borrador de WCAG 3.0 ya incorpora los conceptos de vistas y estados, desprendiéndose de términos como página o documento, acortando así la brecha con el vocabulario actual y ajustándose para incluir a las SPA. Sin embargo, esta versión no verá la luz antes de 2023.

Colaborar

Buy Me a Coffee
Invitame un café en cafecito.app

CSS4 no existe, son tus padres disfrazados

Adrian Benavente — Fri, 05 Feb 2021 19:39:38 +0000

Nos encanta la reacción que nos produce oír hablar de CSS4, ¿qué bien suena, verdad?, es una buena forma de entusiasmar a quienes recién llegan al front o reniegan en las redes de CSS y sus limitaciones. Pero, en el fondo, a nuestro desarrollador web interior algo le hace ruido; el mismo que nos recuerda que los frameworks pasan pero la web es para siempre. ¿Qué sabe, entonces, esa voz interior que a nuestro orgulloso ego le gustaría silenciar? Que CSS4 no existe, son tus padres disfrazados...

Un repaso

Pensar siquiera en CSS4 va en contra de la dinámica de la web actual, ya que esta no evoluciona de manera lineal. Por ende, tampoco CSS. Repasemos cómo es que funciona la cosa...

En los albores de la world wide web, el progreso de CSS no era muy vertiginoso que digamos, por lo cual la W3C podía darse el lujo de publicar documentos unitarios, es por eso que CSS1 y CSS2 sí existieron. Sin embargo, posteriormente a la versión 2.1, su desarrollo se estaba acelerando tanto que se decidió dividirlo en módulos, cada uno de estos en manos de un grupo de trabajo aparte¹. Y es así como nace CSS3. Ya no a partir de un documento concreto, si no más bien como la necesidad de fijar una versión sobre la cual cimentar este nuevo paradigma.

A lo largo de su desarrollo, dichos módulos van atravesando distintas etapas o niveles de maduración²:

Editor's Draft (ED): Primer borrador presentado por una o más personas. No necesariamente respaldado por la W3C.
Working Draft (WD): La W3C lo publica para revisión por la comunidad de desarrolladores, tanto interna como externa.
Candidate Recommendation (CR): Ha tenido la aceptación suficiente como para empezar a testearlo en entornos no productivos.
Proposed Recommendation (PR): Ha madurado lo suficiente y ha sido debidamente testeado como para considerar su implementación definitiva.

Superado este último estadío, se convierte en Recomendación de la W3C (REC), y la pelota de ahí en más pasa a estar en el campo de los navegadores y cuán rápido le brinden soporte (teléfono para Safari). Al no haber una sincronicidad en el avance del desarrollo de los módulos, necesitaríamos que todos o la mayoría de ellos se encontrasen en el mismo nivel, para así poder hablar de una nueva versión de CSS, lo cual (spoiler alert) no va a ocurrir.

Mirando el vaso medio lleno

Un momento, no todo es drama, mientras estábamos lamentándonos por la no llegada de CSS4, pasaron un montón de cosas emocionantes en CSS que no las supimos celebrar debidamente por estar esperando la tierra prometida. Pero todavía estamos con vida, tenemos una nueva oportunidad, hagamos una mirada retrospectiva de algunos de los hitos que ocurrieron desde el ya mentado CSS3 hasta acá:

Flexbox (sí, ya nos parece viejo, pero ocurrió durante este período)
Grid (el sueño de todo maquetador hecho realidad)
CSS Shapes (por fin superamos la era de los cuadrados)
Propiedad gap para Flexbox
Nuevos modos de color (RGB para seres humanos)
Custom properties, que a su vez son variables (CSS no es un lenguaje de progr...)
Detección de features y preferencias de usuario (golazo de la inclusión y la accesibilidad)

¡Y son solo algunos de una larga lista³! No voy a ahondar en cada una de estas features porque este artículo se volvería kilométrico, pero todas cuentan con suficiente documentación al alcance de una búsqueda desde nuestro navegador.

CSSWhatever, una mirada al futuro

Entonces, ¿qué podemos esperar, ahora que ya entendimos cómo va la cosa y estamos más relajados respecto de este tema? Bueno, acá una serie de novedades que están por venir en un futuro próximo:

Propiedad aspect-ratio (sí, basta de hacks horribles para mantener el aspect ratio de los iframes) (solo Chrome por ahora)⁴
Función de color hwb() (ya hice un post sobre esto)
Anidación de selectores y selector de padre (sí, eso que actualmente hacemos con preprocesadores)⁵
Subgrid (grillas que reconocen y heredan las propiedades de su grilla padre) (de momento solo en Firefox)⁶
Pseudo-selector :is() (se le puede pasar una lista de selectores separada por coma, sería como lo opuesto a :not())⁷
Scroll snap (RIP Slick Carousel) (por ahora solo funciona en navegadores de la familia Chromium)⁸
Houdini (API de bajo nivel para meternos en las entrañas del motor de CSS y crear nuevas propiedades con un comportamiento totalmente definido por nosotros)⁹

Conclusiones

El desarrollo de CSS no es lineal y, en parte, está bien que así sea, porque nos permite ir implementando las nuevas características e ir mejorando progresivamente nuestras apps y sitios sin la necesidad de esperar la llegada de una gran especificación monolítica, algo que volvería mucho más lento el crecimiento de la web.

Por último, te animo a dejar abajo en los comentarios qué otras features recientes pasé por alto que te hayan gustado y cuáles esperás ver en un futuro próximo. Gracias por leerme.

Y si te agradan mis artículos, toda colaboración es un incentivo.

Referencias

CSS Modules en Vue.js - ¿Qué son y por qué deberíamos empezar a usarlos?

Adrian Benavente — Tue, 29 Dec 2020 03:30:59 +0000

En la teoría...

Según su definición oficial¹, los CSS Modules son archivos CSS que, con la ayuda de bundlers como Webpack, Parcel o Browserify, nos permiten escribir estilos que luego se convertirán en nombres de clase únicos e irrepetibles, compuestos por nombre del archivo, class name y un hash aleatorio, en cuya generación no intervendremos ni nos interesa saber cómo ocurre, aunque, para quienes tengan curiosidad, les dejo la referencia: GitHub - css-modules/icss: Interoperable CSS — a standard for loadable, linkable CSS. Cabe aclarar que no se trata de una especificación técnica dentro de CSS, si no de un paso en el "building" de nuestra aplicación.

En la práctica...

Cuando estamos trabajando en Vue, al encontrarse con un módulo CSS, el bundler tomará los nombres de clase que hayamos declarado y les agregará el nombre del componente delante, y el ya mencionado hash al final, asegurando así un encapsulamiento de estilos completo, quedando de esta forma: .{NombreDelComponente}_{nombreDeClase}_{hash}.

Un ejemplo sencillo, con fines puramente ilustrativos, de cómo se implementa:

<!-- MiComponente.vue -->
<template>
    <div :class="$style.container">
        <h2 :class="$style.title">Título</h2>
        <h3 :class="$style.subtitle">Subtítulo</h3>
        <p :class="$style.paragraph">
            Lorem ipsum dolor sit amet... etc...
        </p>
    </div>
</template>
<script>
...
</script>
<style module>
.container {
    max-width: 1200px;
    margin: auto;
}
.title {
    font-weight: bold;
}
.subtitle {
    color: darkgray;
    font-style: italic;
}
.paragraph {
    font-family: Helvetica, arial, sans-serif,
    line-height: 130%;
}
</style>

El HTML final sería algo como esto...

<div class="MiComponente_container_h342kj">
    <h2 class="MiComponente_title_g0921s">Título</h2>
    <h3 class="MiComponente_subtitle_a298vn">Subtítulo</h3>
    <p class="MiComponente_paragraph_y030mw">
        Lorem ipsum dolor sit amet... etc...
    </p>
</div>

Y los estilos...

.MiComponente_container_h342kj {
    max-width: 1200px;
    margin: auto;
}
.MiComponente_title_g0921s {
    font-weight: bold;
}
.MiComponente_subtitle_a298vn {
    color: darkgray;
    font-style: italic;
}
.MiComponente_paragraph_y030mw {
    font-family: Helvetica, arial, sans-serif,
    line-height: 130%;
}

Aquí ya comienzan a asomar sus ventajas, permitiéndonos abstraernos por completo del resto de nuestra aplicación y empezar a pensar en cada componente como un universo aparte.

Preprocesadores

También se puede utilizar con preprocesadores (por ej.: <style lang="scss" module>), en cuyo caso debemos tener en cuenta que la anidación está permitida siempre y cuando respetemos la sintáxis de Vue para CSS Modules a la hora de acceder a nuestras clases (<h2 :class="$style.title">). De lo contrario, no funcionaría:

<template>
    <div :class="$style.container">
        <h2 class="title">Título</h2>
    </div>
<template>
<script>
...
</script>
<style lang="scss" module>
.container {
    max-width: 1280px;
    margin: auto;
    .title { /* ❌ ¡será ignorada! */
        font-weight: bold;
    }
}
</style>

Múltiples clases

Siempre que estemos usando "binding" de clases en Vue y necesitemos asignar varias a un mismo elemento, debemos hacerlo en forma de array. Pues bien, con CSS modules no es la excepción: <button :class="[$style.clase1, $style.clase2, $style.clase3, ...]">.

La propiedad 'composes'

Sin duda una feature muy útil de los CSS Modules es la posibilidad de heredar reglas de otro selector, de manera muy similar al @extend de Scss, utilizando la propiedad composes²:

.serifFont {
  font-family: Georgia, serif;
}

.display {
  composes: serifFont;
  font-size: 30px;
  line-height: 35px;
}

Configuración de Webpack

Si nuestro proyecto usa una configuración manual de Webpack, los CSS Modules se pueden habilitar simplemente añadiendo la siguiente regla:

{
  module: {
    rules: [
      // ... otras reglas
      {
        test: /\.css$/,
        use: [
          'vue-style-loader',
          {
            loader: 'css-loader',
            options: {
              modules: true,
              localIdentName: '[local]_[hash:base64:8]'
            }
          }
        ]
      }
    ]
  }
}

En el caso de los frameworks más comunes, suelen venir habilitados por defecto.

Naming de clases

Aunque nada nos impide definir clases en kebab case (.mi-clase-kebab-case), por convención se recomienda utilizar siempre camel case (.miClaseCamelCase), ya que esto permite acceder a la misma desde el template utilizando notación de puntos ($style.miClaseCamelCase), de lo contrario deberíamos usar sintáxis de corchetes que es menos legible ($style['mi-clase-kebab-case']).

En el JS

Como podemos intuir, cada vez que declaramos una clase, esta se convierte en una propiedad del objeto $style que se añade al scope global al estar trabajando con CSS Modules. La misma guardará como valor el nombre único auto generado, de manera tal que si, por alguna razón, quisiéramos acceder a la misma desde el JS del componente, podríamos hacer lo siguiente:

document.querySelector(`.${this.$style.nombreDeMiClase}`);

Diferencia con "Scoped"

Si bien ambos cumplen la misma función, scoped tiene una serie de desventajas con respecto a CSS Modules:

Legibilidad

Para encapsular, Vue utiliza el atributo data seguido de -v- y un hash único por componente en cada elemento, lo que ensucia mucho los HTML y CSS finales³:

<template>
  <div>
    <h1>Title <small>(small)</small></h1>
    <div>
      <div class="test">Test</div>
    </div>
    <p>Content 1</p>
    <p>Content 2</p>
  </div>
</template>

<style scoped>
h1 {
  font-weight: bold;
}

.test {
  color: red;
}
</style>

HTML generado

<div data-v-5b2d5ecc="">
    <h1 data-v-5b2d5ecc="">Title <small data-v-5b2d5ecc="">(small)</small></h1>
    <div data-v-5b2d5ecc="">
        <div data-v-5b2d5ecc="" class="test">Test</div>
    </div>
    <p data-v-5b2d5ecc="">Content 1</p>
    <p data-v-5b2d5ecc="">Content 2</p>
</div>

Como vemos, con esta estrategia se agregan los atributos data incluso en aquellos elementos que no llevan CSS 👎.

CSS generado

h1[data-v-5b2d5ecc] {
  font-weight: bold;
}
.test[data-v-5b2d5ecc] {
  color: red;
}

Especificidad

Por más que, a nivel de componente, los estilos están encapsulados de forma segura, podrían existir, en el HTML final, nombres de clase repetidos, lo que puede resultar confuso de leer si no se sigue un patrón de class naming como puede ser BEM o SMACSS.

Compatibilidad

Por último, los estilos de tipo scoped son específicos de Vue, mientras que CSS Modules son un estándar y pueden ser utilizados en cualquier proyecto JS que use bundlers como Webpack, Parcel o Browserify.

Comparativa con React

Por último, solo a modo de comparación, un breve vistazo a su implementación en React, donde podemos ver que la misma es todavía más similar a la descrita en la documentación oficial¹:

CSS

/* MiComponente.module.css */
.title {
    font-weight: 900;
    text-decoration: underline;
}
.paragraph {
    font-family: Roboto, arial, sans-serif;
}

Importante: el archivo de estilos debe llevar .module antes de la extensión (por ej.: MiComponente.module.css ó MiComponente.module.scss).

JSX

// MiComponente.jsx
import React from "react";
import styles from "MiComponente.module.css";

const MiComponente = () => (
    <>
        <h2 className={styles.title}>Título</h2>
        <p className={styles.paragraph}>
            Lorem ipsum dolor sit amet...
        </p>
    </>
);
export default MiComponente;

Conclusión

CSS Modules es una librería que ha estado adquiriendo mucha popularidad en los últimos tiempos⁴ ya que integra CSS con Javascript como nunca antes se vió, y soluciona el problema del specificity hell, haciendo nuestro flujo de trabajo mucho más productivo.

Afortunadamente, su curva de aprendizaje es ínfima y, sin duda, es una herramienta que vale la pena añadir a nuestro stack.

HWB, una mordida al futuro de CSS

Adrian Benavente — Sat, 17 Oct 2020 18:56:54 +0000

Se encuentra publicada en la especificación de Color Nivel 4 de CSS, una nueva función de color con una lógica más intuitiva para seres humanos: se trata de HWB (por las siglas Hue, Whiteness, Blackness). Esta forma de definir colores se asemeja más a lo que vemos en la rueda de color de un color picker, donde primero elegimos un tono de referencia y a partir de este nos movemos hacia el negro o el blanco, hasta lograr el color deseado.

Parece ser que, desde el equipo de Sass, están barajando la posibilidad de introducir su propia versión, como parte del módulo color, lo que nos permitirá empezar a utilizar por adelantado una feature del futuro, creada respetando los specs de CSS4, sumándole todas las ventajas de estar trabajando con este potente superset de CSS. Esta decisión de no incluirla en el scope global va en sintonía con la filosofía de Sass de nunca incorporar una sintáxis CSS que aún no esté soportada por todos los navegadores modernos. En los casos de rgb(), hsl(), y sus variantes rgba() y hsla(), estas pueden invocarse desde el ámbito global ya que cuentan con un soporte total.

Entonces, ¿cómo será implementada? Veámoslo...

hwb()

Al igual que el método hsl(), recibe tres argumentos obligatorios:

Un número (de 0 a 360) que representa en grados la posición del tono en la rueda de color.
Un número (0% - 100%), expresado en porcentaje, definiendo la cantidad de blanco.
un número (0% - 100%), expresado en porcentaje, definiendo la cantidad de negro.

...y un cuarto parmámetro opcional, siendo este un número de 0 a 1 (aceptando decimales, obviamente) que corresponde al valor de $alfa, es decir, la opacidad, donde 0 (cero) es transparencia total y 1 (uno) opacidad total; su valor por defecto es 1.

Los parámetros los podemos pasar separados por comas o espacios, como sucede con rgb() y hsl().

@use "sass:color";

selector {
    background: color.hwb(270, 20%, 40%); // esto es válido
    background: color.hwb(270 20% 40%); // esto también
}

Sin embargo, si queremos pasarle el cuarto parámetro (valor de alfa), deberemos sí o sí separarlos con coma, de lo contrario veremos un error en el compilador. Esta función compila a rgb() en el CSS resultante.

whiteness() y blackness()

Funcionan igual que saturation() y lightness() si estuviésemos usando el modelo hsl, es decir que: recibiendo cualquier color CSS válido retornará su valor de blanco o negro, permitiendo recuperarlo. También forman parte del módulo color.

scale(), adjust() y change()

Las funciones que modifican el color de manera directa, ahora además soportan $whiteness y $blackness como argumentos. Podremos, por ejemplo, hacer lo siguiente: color.adjust(#d2e1dd, $blackness: 30%); igual que $saturation y $lightness, aceptan valores negativos.

Esta nueva característica es, de momento, una propuesta que podría volverse realidad y cualquiera puede sumarse a la discusión aportando ideas. ¿Qué opinás de esta nueva feature?

ACTUALIZACIÓN:

Recientemente, esta propuesta fue aceptada como podemos ver en este commit así que podemos empezar a utilizar esta feature a partir de la última versión, la 1.29.

Sass 1.23 - La versión que cambió las reglas del juego

Adrian Benavente — Mon, 07 Sep 2020 05:45:12 +0000

Se está por cumplir un año ya desde el lanzamiento de la versión que quizás introdujo los cambios más significativos en Sass como lenguaje desde la migración de su compilador de Ruby a Dart, y he notado que, sin embargo, este suceso ha pasado bastante desapercibido. Fuera del sitio oficial de Sass, los posteos en internet hablando acerca de esto, así como los videos en YouTube, son escasos por no decir nulos, y ni hablemos de encontrar algo en español. Es por eso que decidí ordenar de la forma más prolija y detallada posible pero sin agobiar al lector, las features más trascendentales que introduce Sass 1.23, y que, según sus desarrolladores, llegaron para quedarse.

Démosle la bienvenida al Module System

Sin lugar a dudas, el salto más importante que ha dado esta versión, y por el cual se la considera una versión bisagra es debido a la deprecación completa (aunque gradual) de la regla @import para la carga de archivos, cediendo el paso al nuevo Module System, cuya implementación gira en torno a la nueva at-rule @use.

Previo a esta versión, cuando usábamos @import, era imposible saber dónde habían sido definidas las funciones, mixins y variables (llamados "miembros" por convención, y así nos referiremos de ahora en adelante) que estábamos invocando dentro de un archivo (a los cuales a partir de ahora es correcto referirse como "namespaces"), ya que el solo hecho de hacer un @import los volvía disponibles dentro de todos los archivos que fueran llamados a continuación.

Esto era un dolor de cabeza para muchos desarrolladores, y un potencial problema en proyectos grandes donde podía llegar a ocurrir que se definieran dos miembros con el mismo nombre. Además, nos obligaba a prestar particular atención al orden de importación, cuando existían múltiples imports, si queríamos que determinados miembros estuvieran disponibles cuando los necesitábamos.

Con esto, de paso, Sass se despega por completo de la colisión confusa con el @import de CSS.

Cambios de la versión

Estos son algunos de los pricipales cambios y mejoras que introdujo la versión 1.23:

Importación de archivos como módulos mediante la regla @use. Mejora el encapsulamiento ya que los miembros de éste solo estarán disponibles dentro del archivo que los está usando, a diferencia de @import que tenía un scope global.

  // some-file.scss
  @import "some-module"; // ❌ disponible dentro de este archivo
  // y de todos los que se importen después

  // some-file.scss
  @use "some-module"; // ✅ disponible solo dentro de este archivo

Con la regla @forward, se podrá hacer que los miembros de otro archivo estén disponibles cuando el archivo actual sea importado con @use, creando de esta manera una API extendida. Sin embargo, el archivo que realiza el @forward no podrá acceder a los miembros de éste, a diferencia de @use, si no que actuará como un simple intermediario. Es decir que podemos hacer lo siguiente:

  // mixins.scss
  @mixin expand {
      display: block;
      width: 100%;
  }

  // foo.scss
  @forward "mixins";

  .foo {
      align-items: center;
      background-color: peru;
      display: flex;
      flex-direction: column-reverse;
  }

  // some-other-file.scss
  @use "foo";

  .expanded {
      @include foo.expand;
  }

Mientras que esto nos daría un error:

  // palette.scss
  $colors: (
      primary: #007BFF,
      secondary: #6C757D,
      success: #DC3545
  );

  // functions.scss
  @use "sass:map";
  @forward "palette";

  @function color($prop) {
      @return map.get(palette.$colors, $prop);
      // => Error: There is no module
      // with the namespace "palette".
  }

Es posible, de ser necesario, decidir de manera selectiva qué variables, mixins o funciones de determinado namespace estarán disponibles, de la siguiente manera:

  // src/_list.scss
  $horizontal-list-gap: 2em;

  @mixin list-reset {
    margin: 0;
    padding: 0;
    list-style: none;
  }

  @mixin list-horizontal {
    @include reset;

    li {
      display: inline-block;
      margin: {
        left: -2px;
        right: $horizontal-list-gap;
      }
    }
  }

  // bootstrap.scss
  @forward "src/list" hide list-reset, $horizontal-list-gap;

...o de forma inversa con show:

  @forward "src/list" show list-horizontal;

Y también algo que es muy interesante es que podemos agregar un prefijo para todos los miembros del namespace:

  // src/_list.scss
  @mixin reset {
    margin: 0;
    padding: 0;
    list-style: none;
  }

  // bootstrap.scss
  @forward "src/list" as list-*;

  // styles.scss
  @use "bootstrap";

  li {
    @include bootstrap.list-reset;
  }

La at-rule @extend se limita al scope del archivo actual cuando se utiliza @use. A diferencia de antes, que al usar @import el @extend quedaba disponible globalmente, en ocasiones haciendo difícil predecir qué reglas estábamos extendiendo.
Usando los modificadores de acceso - ó _ podemos hacer que un miembro sea privado, lo que significa que solo podrá ser utilizado dentro del propio archivo que lo define: $_private-var: value ó $-private-var: value.
Namespaces personalizados mediante el uso de as. Por ejemplo:

  @use "functions" as fn;

  .button {
      background-color: fn.color("success");
  }

...o como top-level module (usar con precaución):

  @use "functions" as *;

  .button {
      background-color: color("success");
  }

Esta última forma tiene la limitación de que, si usamos otro módulo como "top-level module" y este contiene, también, una función llamada color(), el compilador arrojará un error.

También podemos importar un módulo sobreescribiendo el valor de una o más de sus variables. Para ello, primero tenemos que asignarle un valor por defecto al momento de definirla:

  // bootstrap.scss
  $paragraph-margin-bottom: 1rem !default;

  p {
    margin-top: 0;
    margin-bottom: $paragraph-margin-bottom;
  }

Y luego llamar el archivo de esta manera, utilizando la cláusula with que recibirá un mapa con las variables que queramos pisar:

  @use "bootstrap" with (
    $paragraph-margin-bottom: 1.2rem
  );

Las funciones del core de Sass ahora son accedidas a través de módulos nativos: sass:color, sass:list, sass:map, sass:math, sass:meta, sass:selector, y sass:string. Las cargaremos en nuestra hoja de estilos con @use (por ej: @use "sass:map") y las usaremos como cualquier otro módulo, con la sintáxis namespace.function(). Esto se hizo para evitar la colisión con funciones nativas de CSS, lo que les permitirá, en el futuro, agregar nuevas de manera segura.
Se incorporaron, además, algunos mixins al core, que vienen a solucionar algunas malas prácticas del pasado, como los @import anidados, tal es el caso de meta.load-css($url, $with: ()) que sirve para cargar una hoja de estilos de manera dinámica, recibiendo dos parámetros, el primero $url es un string con la url de dicho CSS, y el segundo $with: () es opcional y deberá ser un mapa con la configuración, igual al del ejemplo anterior solo que en este caso las variables no llevan $ adelante. También tenemos meta.module-variables() y meta.module-functions() para acceder a las variables o funciones respectivamente de un determinado módulo. Están disponibles de la misma manera que las built-in functions: @use "sass:meta".

¿Es seguro de usar?

Desde el lanzamiento de esta versión, ya ha pasado casi un año y han salido 3 versiones menores posteriormente (actualmente se encuentra en la 1.26), por lo que es 100% seguro de utilizar en cualquier proyecto nuevo. Sin embargo, hemos de esperar que no nos funcionen las nuevas features en proyectos de más de un año de antigüedad.

Si bien esta versión es completamente retro-compatible, los desarrolladores avisan que @import será eventualmente removido por completo de Sass, pero que dejarán transcurrir un tiempo prudencial para que tengamos chance de migrar.

Por suerte, Sass pone a nuestra disposición una herramienta de migración automatizada, a través de línea de comandos: sass-migrator. Existen varias formas de instalarla, las cuales se detallan aquí.

Migrando nuestro código

Seguiremos las instrucciones para Sass: Migrator de la página oficial, y una vez que tengamos instalada la CLI, simplemente navegamos a la carpeta de nuestro proyecto y hacemos:

sass-migrator module --migrate-deps <path/to/style.scss>

El flag --migrate-deps lo que hace es decirle que migre no solo el archivo específico que le estamos indicando si no además todos los archivos que pudiera estar importando.

Podemos pasarle el flag --verbose para que la consola nos de output sobre los cambios que va realizando sobre los archivos, y el flag --dry-run si queremos que corra el comando de manera "simulada" sin ejecutar realmente los cambios, lo cual tiene sentido usándolo en combinación con el anterior.

Si bien lo anterior bastará para la mayoría de los casos, hay un último flag que puede llegar a ser muy útil para quienes desarrollen alguna biblioteca: --forward, que acepta los valores none(valor por defecto), all y prefixed. Si elegimos --forward=all permitiremos que el usuario de nuestra biblioteca pueda acceder a toda la API (excepto miembros privados) con un solo @use, ya que lo que hará es un @forward de todos los archivos. En el caso de prefixed, básicamente hace un @forward únicamente de los miembros a los que hayamos puesto un prefijo, el cual debemos explicitar de manera obligatoria con el flag adicional --remove-prefix; la herramienta eliminará automáticamente este prefijo. Antes de los módulos, se solía agregar estos prefijos para evitar colisiones de nombres. El ejemplo del sitio de Sass, lo grafica a la perfección:

$ cat style.scss
@import "theme";

@mixin app-inverted {
  color: $app-bg-color;
  background-color: $app-color;
}

$ sass-migrator --migrate-deps module --remove-prefix=app- style.scss
$ cat style.scss
@use "theme";

@mixin inverted {
  color: theme.$bg-color;
  background-color: theme.$color;
}

Debo decir que he realizado unas cuantas migraciones y, en todos los casos, la herramienta es bastante efectiva e inteligente al realizar su labor. En algúna ocasión he tenido que refactorizar un poco a mano pero han sido cosas mínimas que no me han llevado más de unos minutos. Aun así, es recomendable primero probar siempre con --dry-run --verbose, para nuestra tranquilidad.

Referencias: