Me ha interesado bastante este artículo sobre una «craft crisis» en el mundo del diseño, pero no por el mundo del diseño. Ni el inicio del artículo: personalmente, saltaría directamente hasta How we got here. El artículo va de cómo, desde el mundo del diseño, si bien no hace falta saber escribir código, perder el contacto íntimo con la parte técnica representa un problema, y sí es necesario tener una «alfabetización estratégica» (y ojo, que el artículo deja el listón de esa alfabetización considerablemente alto)… A media lectura me ha parecido que, de hecho, no hablaba del diseño (o al menos no estrictamente de las personas que etiquetamos como diseñadores, gráficos / de interacción / …), sino de cualquier campo que dependa de otro para implementar lo que sea: si delegas absolutamente el conocimiento, flaco favor el que te haces, y traspasas buena parte del poder a diseño / desarrollo / el departamento que sea que hay entre tú y el producto / servicio a entregar.
Por lo que respecta a novedades-ya-no-tan-novedosas de CSS, llego a 12 CSS features you can use today with no build step (es de septiembre :-S), entre las cuales el anidado en CSS sin pre ni postprocesadores, :has(), subgrid, espacios de color OKLCH (todas baseline widely available desde hace más de un año), container queries (aún más viejas: baseline widely available desde hace dos), cascade layers (tres años ya) o :is() y :where() (cuatro). No quiero mirar cuánto no se usan, porque me deprimo (aunque igual el «mal de muchos» me consolaría un poco).
Por su parte, la consultoría de accesibilidad Tetralogical publica su Accessible components library, con su documentación y, sobre todo, los requisitos de accesibilidad, los escenarios de prueba y los tests automatizados. Incluyen acordeón, migas de pan («breadcrumbs«), cuadro de diálogo, «disclosure«, paginación, pestañas y entrada de texto, documentando los correspondientes criterios de éxito de las WCAG 2.2.
Otro de accesibilidad. Me entero por este hilo (de hace como un mes) de Bluesky de Eric Bailey de la última edición (la undécima, parece ser) de la «survey» sobre el uso de lectores de pantalla de WebAIM. Documento de interés muy alto, y no dejéis de leer tampoco el hilo de Bluesky, que la interpretación de Bailey es de lectura casi obligatoria para los que (como yo) no sabemos tanto como querríamos.
Y cerramos con accesibilidad… e IA. En mayo (sí, estas entradas deberían llamarse «devLecturas a punto de caducar)) en el blog de GitHub publicaban una historia sobre el desarrollo de un agente (de IA) de accesibilidad de propósito general. Con la precaución necesaria al leer una historia sobre agentes IA de una compañía que quiere vender agentes IA, resulta interesante. El objetivo era que el robot fuera capaz de (i) responder a las preguntas de los desarrolladores, y (ii) detectar y corregir problemas de accesibilidad simples y objetivos (los adjetivos son importantes). Para mayo, el agente había revisado tres mil quinientas pull requests y resuelto (según las métricas de GitHub, claro) un 68% de problemas. El texto enlaza a una evaluación de la accesibilidad de lo que producen los modelos grandes de lenguaje que, para sorpresa de nadie, no es para tirar cohetes (o sí, dependiendo de hacia dónde se apunten dichos cohetes, claro), fruto de este proyecto (que parece que lleva unos meses sin tocarse). A pesar de ser GitHub, el autor, Eric Bailey (le acabáis de «ver» en el párrafo anterior), tiene un recorrido importante en esto de la accesibilidad, y el planteamiento y conclusiones hacen que valga la pena leer sobre los aspectos que se pueden automatizar en cuestiones de accesibilidad.
