Smashing Podcast Episodio 4 con Heydon Pickering: ¿Qué son los componentes inclusivos?

Hoy hablo con Heydon Pickering sobre su nuevo libro, Componentes Inclusivos . Heydon es conocido por su trabajo y sus escritos sobre accesibilidad, entonces, ¿qué significa realmente "diseño inclusivo" y dónde entran en juego los componentes? Heydon explica todo esto y más en este episodio. Puede escuchar a continuación o suscribirse dondequiera que obtenga sus podcasts.

Mostrar notas

• El libro Componentes Inclusivos de la Revista Smashing
• El proyecto de Heydon Every Layout con Andy Bell
• Sitio web de Heydon Heydonworks
• Heydon en Twitter

Transcripción

Drew McLellan: es consultor independiente de accesibilidad web, diseñador de interfaces y escritor. Su trabajo se centra en el diseño de experiencias de usuario accesibles, además de escribir y editar para Smashing Magazine. Es el autor del aclamado libro sobre diseño de aplicaciones web accesibles, Apps For All, y acaba de publicar un nuevo libro, Inclusive Components, que trata sobre cómo crear interfaces web accesibles, nuevamente, con Smashing Magazine. Claramente es un experto en el tema del diseño accesible, pero ¿sabías que fue el primer ser humano masculino en saltar el puente del puerto de Sydney en una lancha rápida? Mis amigos de Smashing, denle la bienvenida a Heydon Pickering. Hola Heydon. ¿Cómo estás?

Heydon Pickering: Estoy genial. Estoy en la marca.

Drew: Quería hablarte hoy sobre el tema de tu nuevo libro, Componentes Inclusivos.

Heydon: Sí.

Drew: Obviamente, solo un título de dos palabras, pero siento que cada una de esas palabras hace mucho trabajo pesado. Comenzando por el final, como obviamente es lógico, los componentes, ¿se trata de una especie de diseño basado en componentes? ¿Qué es eso?

Heydon: Sí, así que supongo que ha pasado un tiempo desde que las personas, los desarrolladores front-end, los diseñadores y todos los que colaboran en la creación de interfaces comenzaron a pensar en las cosas en términos de componentes y dividir las cosas en bocados digeribles y reutilizables. Y supongo que si no estás familiarizado con esa forma de trabajar por la razón que sea, realmente es un poco como los componentes electrónicos. Mi padre es ingeniero electrónico. Trabaja en una especie de mundo analógico de placas de circuito y soldadura y todo ese tipo de cosas.

Heydon: De hecho, ha fabricado algunos componentes, componentes muy pequeños, que se han utilizado para regular la corriente que entra en los electroimanes del CERN. Y tenía mucha fe en mí cuando era niño, porque consiguió que les soldara algunas de las piezas. Creo que ese lote ya se ha retirado, así que no se preocupen por mi pobre soldadura, mi pobre soldadura adolescente, por estar más involucrado en el CERN. Pero sí, creo que es análogo a... Oh, hay demasiados análogos allí.

Heydon: Es similar a las placas de circuito analógico en que la idea es que tienes responsabilidades únicas para partes o componentes individuales y, juntos, hacen el circuito y, juntos, aumentan la corriente en el caso de un circuito o, supongo, la interfaz o el resultado de cualquier manera, en un sistema de diseño o en una interfaz como se manifiesta a través de un sistema de diseño. Entonces, Componentes inclusivos porque quería abordar el hecho de que, si bien, quiero decir, la accesibilidad tiende a quedarse atrás en general cuando avanzamos en lo que estamos haciendo en diferentes áreas, y quería traer accesibilidad y, en un sentido más amplio sentido, diseño inclusivo para influir en este tipo de nueva forma de pensar y hacer cosas utilizando componentes o módulos o como quieras llamarlos.

Heydon: Entonces, la idea era llevar la accesibilidad a los sistemas de diseño, pero de la misma manera, pensar sistémicamente cuando se trata de tratar de abordar la accesibilidad. Piense en resolver un tipo de problema en un lugar en términos de accesibilidad y asegurarse de que simplemente se propague alrededor del patrón [inaudible 00:03:16] el sistema de diseño en general.

Drew: En una especie de sentido práctico, ¿cómo se ve realmente trabajar de una manera basada en componentes? ¿Cuál podría ser un ejemplo de un componente?

Heydon: Entonces, hay diferentes formas de concebir y codificar componentes. Tiendo a entrar directamente en el meollo del asunto, más allá de las cosas conceptuales y pienso en cómo podría organizar el código. De hecho, he llegado a centrarme mucho en los elementos personalizados, o si no son elementos personalizados, entonces elementos normales pero con una especie de comportamiento de JavaScript adjunto a ellos de una manera aislada y dividida en componentes. Me gusta mucho la idea de los componentes que son interoperables. Y con eso quiero decir que se pueden usar en diferentes marcos, sistemas, enfoques y pilas técnicas. Y los elementos personalizados son buenos porque son nativos. Puede definirlos en un lugar y luego podrían usarse, por ejemplo, en una aplicación de reacción o podrían usarse en una aplicación de visualización o podrían usarse en una aplicación angular, o cualquier tipo de tecnología de administración de estado más grande que esté utilizando.

Heydon: Entonces, para mí, por lo general, un componente probablemente sea un elemento personalizado. Recientemente trabajé en un proyecto que no se enfoca tanto en la accesibilidad, aunque traté de hacerlo lo más accesible posible, llamado Every Layout, y se trata de tratar de aislar tipos de algoritmos muy específicos para Diseño CSS. Y se definen como elementos personalizados y se despliegan y ejecutan su propio CSS y funcionan como elementos primitivos dentro del sistema más grande.

Drew: Quiero decir, en términos prácticos reales, ¿estamos hablando de que un componente podría ser algo así como un campo de formulario?

Heydon: Sí, entonces podría ser algo tan simple como una entrada. Digamos, como una entrada de texto o podría ser algo complejo como una interfaz de pestañas. Entonces, la idea con Componentes Inclusivos era tomar el concepto de un componente con su único propósito, con suerte, como una entrada de texto, y luego pensar en todas las cosas diferentes que podrían hacer tropezar a diferentes tipos de personas y tratar de evitar ellos. No evites a las personas, evita los problemas. No se trata tanto de incluir personas, se trata de tratar de no excluir arbitrariamente a las personas.

Heydon: Esa parece ser la forma más fácil de abordar un proceso de diseño inclusivo para mí, es identificar los posibles elementos excluyentes de algo e intentar sortearlos. Entonces, con una entrada de texto, con una etiqueta, tienes una serie de cosas diferentes de las que quizás quieras preocuparte. Entonces, para empezar, sabría si está etiquetado correctamente o no. Entonces, ¿está usando un elemento de etiqueta y ese elemento de etiqueta apunta al campo de texto usando un atributo for para que las dos cosas se asocien programáticamente de modo que cuando un usuario de lector de pantalla enfoca la entrada, en realidad escucha que se anuncia la etiqueta? Así que eso es una cosa para hacerlo bien.

Heydon: Luego, en una especie de nivel más visual, asegurarse de que la etiqueta esté claramente asociada con ese campo y no con campos diferentes, y eso es una cuestión de espacio en blanco y ese tipo de cosas. Además, asegurándose de que la etiqueta no lo esté, no está haciendo algo elegante como poner la etiqueta debajo de la entrada de su formulario porque, por ejemplo, cuando aparece un teclado virtual, eso podría oscurecerse. Entonces, está tomando en consideración ese tipo de cosas.

Heydon: Asegurarse de que la entrada en sí tenga un estilo de enfoque, de modo que cuando lo enfoca con un teclado, ya sea que sea un usuario habitual del teclado que usa teclados para navegar o no, asegúrese de que quede claro en el estilo de enfoque que ese es el entrada en la que está enfocado. Asegurarse de que, quiero decir, cosas como autocompletar, preocuparse por eso, si el autocompletar es apropiado y útil en el contexto o si no lo es. Y muchas de estas cosas abordan la discapacidad directamente, pero muchas de ellas son más amplias en términos de usabilidad y solo hacen que las cosas sean lo más comprensibles posible.

Heydon: Muy a menudo, hay una especie de línea muy fina o tal vez borrosa entre lo que aborda la usabilidad para todos y lo que aborda la discapacidad. Y luego, para hacerlo aún más difícil de precisar, las discapacidades cognitivas. Entonces, si algo no es muy útil para alguien que no tiene discapacidades cognitivas, será aún más difícil resolverlo y poder usarlo para alguien que sí tiene ese tipo de desafíos.

Heydon: Así que es solo tratar de pensar en todas esas cosas en un solo lugar. Y realmente, el libro es solo mío, es mi proceso de pensamiento a medida que me acerco a cada uno de ellos. Así que lo hice como un blog para empezar. Y cada patrón o cada componente es una publicación de blog y el texto es solo yo diciendo: “Entonces, abordemos ahora este problema potencial. ¿Cómo hacemos eso? Bien, lo hemos comprobado. Creo que estamos bien allí”. Y, de ninguna manera estoy tratando de decir que estos son perfectos y que he pensado en todo, porque eso no es posible.

Drew: Al igual que adoptar un enfoque basado en componentes sobre cómo trabajas en partes individuales de una interfaz, supongo que te permite profundizar mucho en ese elemento en particular y asegurarte de que realmente lo hayas optimizado de la mejor manera. puede para que sea accesible para todos. ¿Hay algún peligro en hacer eso y hacerlo en muchos componentes diferentes y luego ponerlos todos juntos en una página? ¿Existe el peligro de que pueda crear problemas de los que no estaba al tanto porque los está probando individualmente y no juntos?

Heydon: Ese es un muy buen punto, y en realidad iba a mencionarlo antes. Me alegro de que hayas dicho eso. Entonces, de muchas maneras, creo que, filosóficamente, hemos decidido que necesitamos separar las cosas en estos componentes individuales. Y hay una virtud en hacer eso, porque si está aislado, entonces es más fácil probarlo y tratarlo como una sola cosa. Y puede, en términos de la forma en que trabajamos, hacer que las cosas sean más fáciles de administrar. También debemos considerar el hecho de que, en última instancia, estas cosas tienen que compartir el mismo espacio y unirse en un sistema más grande.

Heydon: Y no creo que, en realidad, se dedique suficiente de nuestro esfuerzo y pensamiento a eso, curiosamente. Creo que dividimos más las cosas en componentes para facilitar nuestra vida como ingenieros, para que sepamos en qué estamos trabajando y en qué momento. Y, claro, a menudo descuidamos el hecho de que estas cosas vivirán en sistemas dinámicos y tienen que ser...

Heydon: Es decir, el proyecto Every Layout, aunque tiene más que ver con el diseño visual y el diseño, se trata de intentar hacer estas pequeñas primitivas de CSS, estas pequeñas primitivas de diseño, de tal manera que puedan autogestionarse algorítmicamente. Es para que puedas sacarlos de una columna estrecha y ponerlos luego en una columna ancha y así será, el propio código determinará cuántos elementos al día debe haber o si debe reconfigurarse de alguna otra manera. Porque no podemos darnos el lujo de estar interviniendo constantemente, y creo que tiene que ser un sistema que se conozca a sí mismo y sea inteligente.

Heydon: Siempre hay cosas de las que te puedes olvidar. Así que tal vez creas una interfaz de pestañas, tienes una fila de pestañas, eliges entre la pestaña y la pestaña corresponde a un panel de pestañas, que abre algo. Y luego, alguien vendrá y dirá: "Bueno, ¿qué pasa si quiero poner una interfaz de pestaña dentro de una interfaz de pestaña, o algún otro componente dentro de una interfaz de toque?"

Heydon: Y, por supuesto, quiero decir, es en parte una preocupación técnica sobre si eso sería posible, pero sí, tienes que tomar la decisión de si vas a hacer las cosas lo más flexibles posible para que sea posible imbricar las cosas de una manera compleja, o simplemente escribir reglas estrictas que digan: "No puedes poner algo aquí porque el nivel de complejidad en términos del código probablemente sería demasiado alto, pero también posiblemente en términos de cómo el usuario puede percibir y usar la cosa”. Estoy totalmente a favor de escribir reglas que digan: "No anide un montón de funciones complejas dentro de sí mismo", porque no es probable que la gente pueda entenderlo, realmente.

Drew: ¿Es posible adoptar un enfoque completamente algorítmico o automatizado para diseñar para la accesibilidad?

Heydon: No lo creo. No. Así que tenemos herramientas automatizadas y no quiero menospreciar las herramientas automatizadas de ninguna manera. Creo que son muy útiles, pero los uso como una especie de sistema de alerta temprana para tratar de tener una idea de dónde están las áreas problemáticas. Entonces, si estuviera haciendo una auditoría para una organización que quisiera algunos consejos sobre cómo hacer que sus productos sean más accesibles. Por lo tanto, es una buena forma de financiación donde están las áreas problemáticas, pero quiero decir, puede tener una interfaz que sea técnicamente 100% accesible, tal vez, según alguna herramienta, incluso una buena herramienta para juzgarla, digamos, contra WCAG. , las pautas de accesibilidad al contenido web o alguna otra especificación de aceptación. Y, a pesar de que es una especie de 100% de todas las casillas marcadas, aún puede ser completamente inutilizable por varias razones.

Heydon: Por ejemplo, volviendo a lo que decíamos antes, puede ser demasiado complejo. Puedes simplemente abrumar a alguien con enlaces y simplemente no hay forma de que puedan superarlo y luego eso se convierte en algo muy tácito y difícil de precisar, pero está destinado a alienar a las personas. Pero también hay, puedes obtener, es muy fácil obtener falsos positivos y cosas así. Tuve una cosa el otro día, dije el otro día, fue el otro mes, estaba trabajando para una organización y, por supuesto, querían tener una escuela de faro 100% accesible y había un iframe que se colocó allí dinámicamente. por un guión analítico o algo así. Ya sabes el tipo de cosas en las que es una especie de código un poco asqueroso, que simplemente se arroja en la página para hacer una tarea como esa.

Heydon: Ahora recomendaría no usar análisis en absoluto, y les recomendé que al menos admitieran el protocolo de no seguimiento para que las personas pudieran optar por no participar. Desafortunadamente, ese protocolo en realidad ya no funciona porque nunca fue realmente compatible. Pero este iframe decía que no tiene título. Entonces, la idea es que si tiene un iframe, debe tener un atributo de título porque esa es la mejor manera de identificar para qué sirve el iframe para un usuario de lector de pantalla. Pero este era un iframe que también estaba configurado para no mostrar ninguno, por lo que ni siquiera era perceptible para un lector de pantalla en primer lugar porque mostrar ninguno, al igual que oculta cosas visualmente en un lector de pantalla, esencialmente lo eliminará del interfaz, por lo que no se encontrará ni se anunciará de ninguna manera.

Heydon: Así que fue un falso positivo. Quiero decir, me estaba pidiendo que identificara un iframe que no estaba allí para ser percibido en primer lugar. Entonces, siempre habrá ese tipo de errores y problemas en las pruebas automatizadas. Pero en última instancia, se trata de saber, aunque supongo que a los programadores no les gusta pensar que están involucrados y lo encuentran un poco asqueroso, pero se trata del comportamiento humano y de cómo la gente entiende las cosas y eso es algo muy difícil de tener simplemente un conjunto de reglas binarias o booleanas.

Heydon: Entonces, quiero decir, hablé con un desarrollador cuando estaba consultando sobre esto hace algún tiempo y seguían diciendo: “Bueno, mientras tengamos pruebas automatizadas, estamos bien, ¿no? Es solo que entonces podemos seguir adelante”. Y dije: “Todavía tienes que probar manualmente. No existe una prueba automatizada que realmente pueda decirle si usar la interfaz con el teclado es imposible de una forma u otra”. Hay una especie de cosas discretas que puede buscar, pero la experiencia general aún es algo que debe ser juzgado por el ser humano. Si.

Drew: A veces, el peligro con las herramientas automatizadas es que miran los elementos de forma aislada o miran una interfaz de forma aislada y no ven el contexto más amplio.

Heydon: Sí.

Drew: Ciertamente, con el uso de Lighthouse para las auditorías de rendimiento, a veces puedo tomar la decisión como desarrollador de incluir, puede haber mucho más CSS del que se usa en esa página y, estrictamente hablando, estoy descargando demasiado CSS, pero en realidad , sé que una vez que se carga ese archivo, cuando el usuario navega a la página siguiente, ya tiene el CSS. Entonces, es una optimización que se está realizando en varias páginas, la herramienta, al mirar una página de forma aislada, la ve como un error.

Heydon: Sí, absolutamente. Está pensando en el futuro y está tomando una decisión, y hasta que lleguemos a la IA avanzada para anticipar eso, entonces sí, realmente necesita seres humanos que lo miren, lo revisen y vayan... Quiero decir, entonces las pruebas automatizadas deberían existir, como digo, una especie de sistema de alerta temprana, un sistema de diagnóstico, pero también debería existir, si está interesado en que su organización realmente se preocupe y haga las cosas más inclusivas y más accesibles, también debe haber capacitación . Tiene que haber preguntas y respuestas.

Heydon: Así que escribiría guiones para "Así es como debería funcionar cuando interactúas con este componente con un teclado" o "Así es como debería funcionar cuando interactúas con él con un lector de pantalla y no paso a través de él". eso. Entonces, cuando haces esto, esto debería suceder. Cuando haces esto, esto debería suceder. Cuando haces esto, debería aparecer esto”, o ese tipo de cosas. Entonces, y el tipo de viaje, como dices, las herramientas automatizadas no son conscientes de eso. Solo ven: "Oh, esto no tiene texto alternativo aquí". Y, de hecho, en muchos casos, tal vez no debería tener texto alternativo. Y tampoco puede juzgar si has escrito bien o no el texto alternativo. Así que creo que una imagen sin todo el texto alternativo es probablemente mejor que una imagen con texto alternativo engañoso o simplemente malo. Y esa es una decisión de juicio de nuevo, ¿no es así?

Drew: Históricamente, una de las cosas con las que he luchado al construir cosas de una manera accesible es mantener actualizado mi conocimiento de las mejores prácticas porque, cada vez que me refiero a cualquier documentación o cualquier tipo de recomendación, es parece que lo que estaba haciendo y pensé que estaba haciendo lo correcto, las recomendaciones han avanzado y ahora debería estar haciendo otra cosa. Y esa es una historia familiar con todas las áreas de trabajo en la web. Pero creo que el peligro está, por supuesto, con los problemas de accesibilidad, es que, si no está siguiendo las mejores prácticas, si deja algo en su interfaz que ahora no es una buena práctica, eso podría estar afectando negativamente a sus usuarios. manera. ¿Un enfoque basado en componentes para construir una interfaz o un sitio, ayuda con eso de alguna manera?

Heydon: Pienso puramente en el sentido de que, debido a que tiene un componente que luego, la idea, por supuesto, en todos los casos y no solo en términos de accesibilidad, es que tiene este componente definido en un lugar que luego se usará en diferentes lugares, al menos cuando los aspectos o la compatibilidad con el navegador o lo que sea cambia y desea actualizar el componente, solo tiene que hacerlo en un lugar y luego, donde sea que se use, se sentirá esa mejora o ese cambio. En ese sentido, creo que ciertamente es más útil tener las cosas divididas en componentes.

Heydon: Pero entonces, sí, como digo, eso no solo afecta la accesibilidad, sino que puede afectar cualquier cosa que cambie. Pero entonces, realmente no estoy seguro de cuánto cambia en su… quiero decir, habrá pocos cambios importantes en términos de accesibilidad HTML, que es, obviamente, un área muy limitada. Pero en términos de la calidad del código o cómo funciona el código, las cosas se introducen en la especificación HTML, obviamente, muy lentamente y no tan lentamente, pero también bastante lentamente en la especificación ARIA. Y luego, gran parte de ARIA simplemente refleja lo que está en el HTML de referencia subyacente de todos modos.

Heydon: Creo que, más que la tecnología, la percepción y comprensión de estas cosas tiende a cambiar con el tiempo. Quiero decir, recientemente, en la encuesta WebAIM reciente, identificaron que los sitios que usaban ARIA eran más inaccesibles que los sitios que no lo usaban. Entonces, esta tecnología concebida específicamente para ayudar a las personas a hacer que los sitios web sean más accesibles, lo estaba empeorando. Entonces, en realidad, es solo una brecha de conocimiento, no una brecha tecnológica o una deficiencia tecnológica. Son personas que simplemente toman la tecnología y la usan mal porque, desafortunadamente, en realidad no entendieron cómo debería funcionar. Con suerte, algunos de mis escritos podrían ayudar con eso. En algunas áreas, de todos modos.

Drew: Pero una especie de sistema bien estructurado basado en componentes te permitiría, una vez que te des cuenta de que algo está desactualizado o que tomaste una mala decisión y ahora lo sabes mejor, te permitiría entrar y arreglarlo más fácilmente. a través de su aplicación.

Heydon: Sí, exactamente. Sí, sí, absolutamente. Quiero decir, todo se trata de eficiencia, ¿no es cierto? Y este principio seco o lo que sea, y mira, es por eso que supongo que originalmente estaba muy entusiasmado con esta oportunidad, porque la gente siempre se queja de que hacer que las cosas sean accesibles es un trabajo extra y es difícil y molesto y todo eso. Entonces, fue una especie de oportunidad para decir: “Bueno, ¿sabes cómo estás haciendo estas cosas realmente, construyendo estos sistemas de componentes de manera eficiente? Obtenga su accesibilidad allí para ese componente que está haciendo, y luego ya no tendrá que preocuparse por la accesibilidad, aparte del cambio o actualización de especificaciones ocasionales o lo que sea”.

Heydon: O simplemente, quiero decir, probablemente la mayor parte del tiempo, la iteración simplemente se basará en los comentarios de los usuarios y la investigación en curso, que, obviamente, debe realizar, en la medida de lo posible, con un grupo diverso de personas. Por lo tanto, debería obtener personas que usan diferentes dispositivos y tienen diferentes hábitos de navegación y usan diferentes tecnologías de asistencia y ese tipo de cosas. Y ya sabes, las cosas están destinadas a surgir todo el tiempo. Creo que realmente he precisado un componente, creo que es realmente sólido como una roca, y luego investigo un poco y descubro que he hecho algunas suposiciones bastante malas. Pero sí, con un sistema de componentes solo tienes que arreglarlo en un lugar.

Drew: ¿Puede un componente ser completamente inclusivo o es un espectro en el que solo estás trabajando cada vez más hacia la inclusión?

Heydon: Sí, sería posible que un componente esté, digamos, libre de errores de WCAC, cumpla con todos los criterios de WCAC, pero como dije, eso solo lo lleva hasta cierto punto y aún podría ser completamente inutilizable o imposible de entender incluso con esos criterios técnicos cumplidos. Así que sí, esto es algo de lo que hablo mucho. Trato de convencer a la gente de que la accesibilidad es como cualquier otra área del diseño, es solo una parte del proceso de diseño y nada puede diseñarse perfectamente, al igual que nada puede ser perfectamente accesible. Desafortunadamente, creo que mucha gente piensa en esto solo en términos de asegurarse de que sea compatible con los lectores de pantalla, lo que obviamente es un alcance muy limitado en términos de accesibilidad e inclusión en general.

Heydon: Entonces, habrá personas, algunas buenas personas con las que he trabajado como en el Grupo Paciello, que dirán: "Bueno, en realidad, quiero ser conocido como una persona UX accesible". Por lo tanto, no se trata solo de este ejercicio de marcar casillas, se trata más de tratar de hacer que la experiencia sea mejor y más valiosa para la mayor cantidad de personas y avanzar más hacia principios más amplios y cosas que son menos binarias. Pero en última instancia, es todo eso, y WCAC y otros criterios similares solo pueden identificar realmente el verdadero y rápido, "Esto está mal", supongo.

Drew: Entonces, si soy un desarrollador, ¿qué debo hacer de manera diferente al abordar la forma en que diseño, planifico y construyo un componente? ¿Hay algo que deba considerar en mi trabajo para asegurarme de que ese componente terminará siendo lo más inclusivo posible?

Heydon: Entonces, quiero decir, dependiendo de lo que estés construyendo, habrá diferentes criterios que deben cumplirse. Entonces, por ejemplo, no todos los componentes tendrán imágenes accesibles con texto alternativo, porque es posible que no use imágenes en absoluto. Puede que solo esté basado en texto o lo que sea. Algunos pueden no ser interactivos. Entonces, en términos de los requisitos específicos, cambiaría entre los componentes, pero espero que algunos de mis escritos y lo que el libro de Componentes Inclusivos te ayuden a hacer es caer o adoptar una disciplina de solo pensar de manera inclusiva.

Heydon: Entonces, cuando te acercas a estas cosas, no solo piensas, bueno, básicamente sales de la mentalidad de "Si funciona para mí, probablemente funcione para todos los demás", porque simplemente no es el caso que el forma en que usted o yo navegamos por las cosas, quiero decir, probablemente haremos las cosas de manera completamente diferente, solo nosotros dos, ¿verdad?

Drew: Cierto.

Heydon: Y somos occidentales, blancos, ingleses como primera lengua. Y entonces, sí, la cantidad de diversidad en términos de las personas que consumen esto, me refiero a que la gente de rendimiento siempre habla de esto también, las personas que están interesadas en abogar por un mejor rendimiento. Está acostumbrado a usar una configuración de alta especificación en una buena red y muchos de sus usuarios o muchos de sus usuarios potenciales seguramente no lo estarán, y lo mismo ocurre con la accesibilidad. Es solo una cuestión de, básicamente, dejar de pensar en ti mismo, de verdad. Literalmente solo eso. Y tratando, obviamente, de llegar más allá de sus colegas inmediatos y personas de su mismo grupo social también.

Heydon: Entonces, con suerte, es realmente solo, "Esto es lo que resolví para estas cosas", y lo que estaba pensando en ese momento. Puede reutilizar algunas de esas ideas y aplicar precisamente lo que he aplicado, si eso es útil o relevante para usted. Con suerte, el libro es más sobre simplemente: “Aquí hay un estudio de caso de una persona que trata de pensar de manera inclusiva. Mira, el tipo de cosas en las que estaban pensando, cuando estás diseñando algo completamente diferente, quizás solo emplees el mismo tipo de pensamiento y trates de abrir tu mente a la diversidad de usuarios y cómo hacen las cosas”.

Drew: Entonces, el libro en sí, ¿cómo decidiste cómo estructurarlo? Parece muy ferozmente práctico, lo que me gusta en un libro, pero ¿cómo lo has estructurado?

Heydon: Al igual que el libro anterior, en realidad era Inclusive Design Patterns y tuve muchos problemas con ese libro, para empezar, porque traté de organizarlo en términos de una especie de criterio abstracto. Así que comencé a hacer un capítulo que trataba sobre la accesibilidad del teclado, pero eso fue muy difícil porque luego tenía que hacerlo, cada vez que hablaba sobre un tipo diferente de accesibilidad del teclado o sobre lo que tenía que pensar, entonces yo Tuvo que conjurar algún tipo de componente y luego deshacerse de ese componente y luego pasar a otra cosa.

Heydon: Entonces, tenía más sentido para mí organizar las cosas en términos de los componentes mismos. Entonces, Inclusive Design Patterns hace esto y ahora Inclusive Components es realmente solo una continuación, que solo cubre diferentes componentes. Es diferente en eso, en términos de características, es un poco diferente porque también incluye ejemplos de código en vivo y otras cosas, que no hice mucho en los libros anteriores. Pero sí, es literalmente, "Vamos a hacer este componente", ya sea una interfaz táctil o una sección plegable o un conmutador de temas o una tarjeta flash de notificación o una tostadora o como se llamen, y luego todo luego se organiza en torno a ese componente.

Heydon: Entonces es, "Esto es lo que estamos haciendo y estas son las cosas que debemos considerar mientras lo hacemos para ser más inclusivos", porque así es como trabajo yo y así es como trabajan otras personas. Y tan pronto como comencé a hacerlo así, realmente era solo yo trabajando y escribiendo notas mientras trabajaba. Y así, la cosa se escribió sola, y luego todo el esfuerzo fue realmente en asegurarme de que estaba haciendo un trabajo decente para hacer que esas cosas no fueran inaccesibles, supongo.

Drew: Sí, me refiero a que la tabla de contenido realmente se lee casi como documentación o como un manual de autoayuda o algo así. Directamente en el capítulo uno, botones de alternancia. Si desea implementar algunos botones de alternar, vaya a este capítulo, léalo y obtendrá todo lo que necesita saber sobre cómo hacerlo, que es un enfoque que realmente me gusta. Veo cosas como secciones contraíbles, interfaz con pestañas, cambios de tema, tablas de datos, un montón de cosas prácticas reales que todos estamos construyendo todos los días y creo que todos, probablemente, podríamos estar construyendo mejor.

Heydon: Sí, esa era totalmente la idea porque no se trataba solo de que yo hiciera mis componentes, era un caso, y lo mencionaste allí, lo cual me alegro de que lo hayas hecho, que era identificar elementos comunes. patrones que todos usamos. Entonces, quiero decir, hay interfaces de pestañas en todas partes y todas están implementadas de manera diferente y todas están implementadas, de diversas formas, muy mal. Quiero decir, he implementado interfaces de pestañas terribles y he aprendido un poco sobre lo malas que eran para las personas, y luego he tratado de hacerlas un poco mejores y un poco mejores y un poco mejores. Probablemente he hecho 15 o 16 versiones diferentes de interfaces de pestañas en mi tiempo, he estado haciendo este tipo de cosas durante años.

Heydon: Y ya sabes, están mejorando un poco, con suerte, cada vez. Pero es sólo una cosa común. Era algo común que usaría con bastante frecuencia entre diferentes sitios web, que uso y todos usan. Entonces, parte de la idea era decir: "Bueno, en realidad, hagamos un sistema de diseño, una especie de sistema de diseño accesible para la web". Ahora, la gente va a diversificarse y van a hacer sus propias versiones de estas cosas, pero para obtener las cosas centrales y la accesibilidad es algo central que debería estar en las cosas. No debería ser un complemento, no debería ser uno u otro, no debería ser una función. Debería ser algo básico. Y si combinas las cosas principales, entonces sí, con suerte, la gente mirará los capítulos y dirá: "Oh, está bien, los hice. He visto esos. Veamos cómo hacerlo de la manera más inclusiva posible”, y luego, con suerte, obtienen algún valor de eso.

Drew: Bueno, lo que me gusta de esto es que ciertamente sé que, en el pasado, tuve algunas funciones de interfaz que necesitaba implementar y sé que será complicado desde el punto de vista de la accesibilidad. , digamos algún tipo de menú desplegable, menú desplegable, algo así. Pienso: “Está bien, aquí hay dragones en términos de accesibilidad. Necesito asegurarme de hacer esto bien”. Entonces, busco en Google cómo hacerlo, encuentro una fuente confiable que dice: "Use este método", uso ese método, lo implemento y sigo adelante, pero en realidad no he aprendido nada. No he aprendido por qué la solución fue esa. Y lo que realmente me gusta de la forma en que abordas el libro es que puedo hacer dos cosas a la vez. Puedo descifrar cómo debo hacerlo y puedo descifrar por qué debo hacerlo así porque todo está muy cuidadosamente explicado. Entonces, creo que es realmente exitoso desde ese punto de vista.

Heydon: Oh, genial. Eso era lo que buscaba. Así que eso es bueno. But yeah, that seems to be my thing. I mean, I've been working with the BBC for some months and we've kind of made a thing a bit like Inclusive Components but for the BBC, so we've done this sort of technical implementation with a through the lens of accessibility version of their design language called GEL. And yeah, it explains the why as well as the how and it's not a pattern, really. The idea is that the individual departments at the BBC, because there's so many of them, because it's such a large organization, so there'll be BBC Sport, BBC Weather, BBC News, they're the ones who would be taking care of the kind of technical stack and making their pattern library. And what we've really provided is just, we've just tried to exemplify the best practices. So it was really much more of a learning resource than a simple plug and play pattern library. Si.

Drew: Was it difficult deciding what patterns to include in the book? Was there anything that you left out?

Heydon: The only ones I really had problems with or second thoughts about were the ones where, the tab interface, for instance, I wasn't going to include, because I really hate tab interfaces, but then I had folks saying, “Could you please do a tab interface? Could you include a chapter of that?” Because I get asked to put them in my interface all the time by clients or whoever. So, I ended up doing one. But it's full of caveats. And the main caveat is, probably don't use a tab interface. Use maybe an accordion, it's a simpler interaction paradigm. It's easier to make responsive, it's easier to make compatible with screen readers, et cetera, et cetera.

Heydon: So I put all those caveats in. But yeah, and some of them were ones where I just thought, “Oh, I haven't written about this before and I could do with having sort of thought about it so that I could actually use it in my design work.” And others were people requesting, saying, “I know this is a gnarly one, I just don't know how to go about it. Could you give it a go?” And so I gave it a go as best as I could. That is going to be the last time I write a book about accessibility because I've done three now.

Heydon: So if anyone wants to know any more and if they think of any other components that they might want doing, just DM me on Twitter or something and I'll try and deal with it in that way rather than writing a whole article, because those articles are quite long and they take up quite a lot of time and I'm kind of doing other things at the moment. But I'm always happy to chat with anyone who has any questions about this stuff. They might be working on something similar to what I've covered and there was just something that they were unsure about or which I, for whatever reason, I hadn't made as clear as they'd liked it. Yeah, then just contact me because I'm always happy to talk about the stuff because it helps me to sort of ruminate over things and try to, it might challenge my assumptions and help me to do a better job as well.

Drew: So, the book, Inclusive Components, is available right now from Smashing Magazine, smashingmagazine.com/books, and I'd recommend everybody check it out.

Heydon: Thank you.

Drew: So I always like to ask people, I mean, Smashing is all about learning, right, with the books, the conferences, the magazine, we're all about learning. What is it that you've been learning lately?

Heydon: So, recently, well, a couple of years ago I made something, I made a drum machine using the web audio API called Beads and it's still available as a PWA, it's a progressive web app. If you Google search Beads GitHub or something like that, you should get the GitHub page which has it on there. But that was a alpha version and I'm now working on doing a much more advanced version of this. And it's a different kind of drum machine because it's polymetric, it has different, you can have different tracks of different lengths. So you can have a track which has seven beats and a track which has nine beats, a track which has four beats. And then, the rhythm evolves over time because of the changing syncopation. You've got these, it's multi-threaded.

Heydon: That was the main reason that I wanted to build it, because, as someone who's interested in kind of experimental music, that's something I wanted to play with. Obviously, I'm trying to make this drum machine as accessible as possible. And that's been interesting from the point of view now that I'm working with, I'm turning it into an Electron app. So, for those of you that know Electron allows you to kind of wrap a sandbox version of Chromium browser and create a desktop application but using web technology, which was really great because it makes things, for this projects anyways, because it gets around a lot of performance problems.

Heydon: But also, although I've been doing cross browser testing for 12 years now, it's really nice to have a break and just to design stuff for one browser. And it's got some, so there's a flag in Chromium. It's a, what's it called, an experimental web platform feature for focus visible. So I've been able to make this drum machine completely keyboard accessible with these really nice, big focus outlines without those appearing for mouse users, because focus visible uses this heuristic where it detects whether or not you're using a keyboard. So that's been nice, to be able to incorporate that.

Heydon: But the thing recently that I've been learning about, just I've, I guess, been learning about some of the more advanced things you can do with the web audio API itself. So I had this problem where I have, you can put multiple sounds on one track so you can load in an array of audio files and it places them one after the other, and by default they overlap, so they'll always play out out, the audio buffer will play until it finishes. So if the next sounds comes before the end of that, it just overlaps, which is fine. It's kind of like a reverb or something. But sometimes if you're doing an arpeggio, like a baseline or something, you don't want them to open up. That's not how a bass guitar works, right? If you're on the same string, you press the next note, the first one has to finish.

Heydon: So, I was stopping a note as the next one started and there was always an audible popping sound and it's not the web audio API having a problem or anything like that. It's just the human ear will hear a kind of a nasty popping sound where you kind of sever away from. You just cut it, stop it dead, it's going to sound nasty. And then, so I found that there's a function as part of the web audio API, which allows you to choose a point where you can taper off the sound. And so I was able to detect where the sounds should end because the other sound is beginning, then taper it off very quickly, but it is a taper, like a fade out, rather than a hard cut off thing.

Heydon: So I solved that problem after it annoying me for ages. So it's basically been web audio API stuff and messing around with sounds because I've always been into, as I say, into experimental music and messing about with that sort of stuff. And I'm trying to write a talk about this. And in the talk, I'm using Billy Jean by Michael Jackson because it's a very straight, fall to the floor rhythm and I'm going to kind of warp it in various different ways. So I've actually had to learn the parts for Billy Jean to kind of sequence that and stuff. So, weirdly enough, that was what I was doing before doing this podcast.

Drew: That sounds like a lot of fun. So if you, dear listener, would like to learn more about Heydon or hire him to consult on your projects, you can follow him on Twitter, where he's @heydonworks, or visit his website at heydonworks.com. Thanks for joining us, Heydon. Do you have any parting words?

Heydon: Goodbye.