Smashing Podcast Episódio 4 Com Heydon Pickering: Quais são os componentes inclusivos?

Hoje, falo com Heydon Pickering sobre seu novo livro, Inclusive Components . Heydon é conhecido por seu trabalho e por escrever sobre acessibilidade – então, o que “Design Inclusivo” realmente significa e onde os componentes entram em jogo? Heydon explica tudo isso e muito mais neste episódio. Você pode ouvir abaixo ou assinar onde quer que receba seus podcasts.

Mostrar notas

• O livro Componentes Inclusivos da Smashing Magazine
• Projeto de Heydon Every Layout com Andy Bell
• Site de Heydon Heydonworks
• Heydon no Twitter

Transcrição

Drew McLellan: Ele é consultor freelancer de acessibilidade na web, designer de interface e escritor. Seu trabalho se concentra no design de experiência do usuário acessível, além de escrever e editar para a Smashing Magazine. Ele é o autor do aclamado livro sobre design de aplicativos web acessíveis, Apps For All, e acaba de lançar um novo livro, Inclusive Components, sobre como construir interfaces web acessíveis, novamente, com a Smashing Magazine. Então ele é claramente um especialista no assunto de design acessível, mas você sabia que ele foi o primeiro homem humano a pular a Sydney Harbour Bridge em uma lancha? Meus amigos Smashing, por favor, dêem as boas-vindas a Heydon Pickering. Olá, Heydon. Como você está?

Heydon Pickering: Estou arrasando. Estou na marca.

Drew: Eu queria falar com você hoje sobre o assunto do seu novo livro, Componentes Inclusivos.

Heydon: Sim.

Drew: Obviamente, apenas um título de duas palavras, mas sinto que cada uma dessas palavras faz muito trabalho pesado. Começando pelo final, como é obviamente lógico, componentes, trata-se de um tipo de design baseado em componentes? O que é aquilo?

Heydon: Sim, então suponho que já faz um tempo desde que as pessoas, desenvolvedores front-end, designers e todos que colaboram na criação de interfaces começaram a pensar nas coisas em termos de componentes e dividir as coisas em pedaços digeríveis e reutilizáveis. E suponho que se você não estiver familiarizado com essa maneira de trabalhar por qualquer motivo, é realmente um pouco como componentes eletrônicos. Meu pai é engenheiro eletrônico. Ele trabalha no tipo de mundo analógico de placas de circuito e solda e todo esse tipo de coisa.

Heydon: Na verdade, ele fez alguns componentes, componentes muito pequenos, que foram usados ​​para regular a corrente que entra nos eletroímãs do CERN. E ele tinha muita fé em mim quando criança, porque ele me fez soldar alguns dos bits para eles. Eu acho que esse lote já foi aposentado, então não se preocupe mais com minha pobre solda, minha pobre solda adolescente, estando envolvido no CERN. Mas sim, acho que é análogo a... Ah, há muitos análogos ali.

Heydon: É análogo às placas de circuito analógico, pois a ideia é que você tenha responsabilidades únicas para peças ou componentes individuais e, juntos, eles fazem o circuito e, juntos, aumentam a corrente no caso de um circuito ou, eu acho, a interface ou o resultado de qualquer forma, em um sistema de design ou em uma interface manifestada por meio de um sistema de design. E assim, Componentes Inclusivos, porque eu queria abordar o fato de que, enquanto, quero dizer, a acessibilidade tende a ser deixada para trás geralmente quando avançamos o que estamos fazendo em diferentes arenas, e eu queria trazer acessibilidade e, no mais amplo sentido, design inclusivo para suportar esse tipo de nova maneira de pensar e fazer as coisas usando componentes ou módulos ou como você quiser chamá-los.

Heydon: Então a ideia era trazer acessibilidade aos sistemas de design, mas, ao mesmo tempo, pensar sistemicamente quando se trata de tentar abordar a acessibilidade. Pense em resolver um tipo de problema em um só lugar em termos de acessibilidade e certifique-se de que isso simplesmente se propague ao redor do padrão [inaudível 00:03:16] do sistema de design em geral.

Drew: Em um sentido prático, como é realmente trabalhar de uma maneira baseada em componentes? O que poderia ser um exemplo de um componente?

Heydon: Então, existem diferentes maneiras de conceber e codificar componentes. Eu costumo ir direto ao âmago da questão, além das coisas conceituais e pensar em como eu poderia organizar o código. Na verdade, me concentrei muito em elementos personalizados ou, se não em elementos personalizados, em elementos normais, mas com um tipo de comportamento JavaScript anexado a eles de uma maneira isolada e com componentes. Eu realmente gosto da ideia de componentes que são interoperáveis. E com isso quero dizer que eles podem ser usados ​​em diferentes estruturas, sistemas, abordagens e pilhas técnicas. E os elementos personalizados são bons nisso porque são nativos. Você pode defini-los em um lugar e então eles podem ser usados, digamos, em um aplicativo react ou eles podem ser usados ​​em um aplicativo de visualização ou eles podem ser usados ​​em um aplicativo angular, ou qualquer tipo de tecnologia de gerenciamento de estado maior que você esteja usando.

Heydon: Então, para mim, geralmente um componente provavelmente será um elemento personalizado. Trabalhei recentemente em um projeto que não é muito focado em acessibilidade, embora tenha tentado torná-lo o mais acessível possível, chamado Every Layout, e trata-se de tentar isolar tipos muito específicos de algoritmos para Disposição CSS. E eles são definidos como elementos personalizados e meio que se implantam e executam seu próprio CSS e funcionam como primitivos dentro do sistema maior.

Drew: Quer dizer, em termos práticos, estamos falando que um componente pode ser algo como um campo de formulário?

Heydon: Sim, então pode ser algo tão simples quanto uma entrada. Digamos, como uma entrada de texto ou pode ser algo complexo como uma interface de guia. E assim, a ideia com os Componentes Inclusivos era pegar o conceito de um componente com seu propósito único, como uma entrada de texto, e então pensar em todas as coisas diferentes que poderiam atrapalhar diferentes tipos de pessoas e tentar evitar eles. Não evite as pessoas, evite os problemas. Não se trata tanto de incluir pessoas, trata-se de tentar não excluir pessoas arbitrariamente.

Heydon: Essa parece ser a maneira mais fácil de abordar um processo de design inclusivo para mim, é identificar os potenciais elementos excludentes de algo e tentar contorná-los. Assim, com uma entrada de texto, com um rótulo, você tem várias coisas diferentes com as quais pode se preocupar. Então, você teria se ou não está realmente rotulado corretamente para começar. Então, você está usando um elemento de rótulo e esse elemento de rótulo está apontando para o campo de texto usando um atributo for para que as duas coisas sejam associadas programaticamente para que, quando um usuário de leitor de tela foca a entrada, ele realmente ouça o rótulo sendo anunciado? Então isso é uma coisa para acertar.

Heydon: Então, em um nível mais visual, garantir que o rótulo esteja claramente associado a esse campo e não a campos diferentes, e isso é uma questão de espaço em branco e esse tipo de coisa. Além disso, certificando-se de que o rótulo não é, você não está fazendo algo extravagante, como colocar o rótulo abaixo da entrada do formulário, porque quando você, por exemplo, quando um teclado virtual aparece, isso pode ficar obscurecido. Então, está levando em consideração esse tipo de coisa.

Heydon: Certificando-se de que a entrada em si tenha um estilo de foco, então, quando você a focaliza com um teclado, seja você um usuário de teclado habitual que usa teclados para navegar ou não, certificando-se de que fique claro no estilo de foco que esse é o entrada em que você está focado. Certificando-se de que, quero dizer, coisas como preenchimento automático, se preocupar com isso, se o preenchimento automático é apropriado e útil no contexto ou não. E muitas dessas coisas abordam diretamente a deficiência, mas muitas delas são mais amplas em termos de usabilidade e apenas tornam as coisas o mais compreensíveis possível.

Heydon: Muitas vezes, há uma linha muito tênue ou talvez uma linha tênue entre o que aborda a usabilidade para todos e o que aborda a deficiência. E então, para tornar ainda mais difícil de definir, deficiências cognitivas. Então, se algo não for muito útil para alguém que não tem deficiências cognitivas, será ainda mais difícil trabalhar e ser capaz de usar para alguém que tenha esses tipos de desafios.

Heydon: Então é só tentar pensar em todas essas coisas em um só lugar. E realmente, o livro é apenas meu, é o meu processo de pensamento à medida que me aproximo de cada um deles. Então eu fiz isso como um blog para começar. E cada padrão ou cada componente é uma postagem de blog e o texto é apenas eu dizendo: “Então, vamos agora abordar esse problema em potencial. Como vamos fazer isso? Ok, nós verificamos isso. Acho que estamos bem lá.” E, de forma alguma estou tentando dizer que estes são perfeitos e que eu pensei em tudo, porque isso não é possível.

Drew: O mesmo acontece com uma abordagem baseada em componentes para como você trabalha em partes individuais de uma interface, eu acho, isso permite que você se aprofunde nesse item em particular e tenha certeza de que você o otimizou da melhor maneira possível. pode para que seja acessível a todos. Existe algum perigo em fazer isso e fazer isso em muitos componentes diferentes e depois colocá-los todos juntos em uma página? Existe o perigo de você criar problemas dos quais não estava ciente porque os está testando individualmente e não em conjunto?

Heydon: Esse é um ponto muito bom, e eu ia falar sobre isso mais cedo, na verdade. Estou feliz que você tenha dito isso. Então, de várias maneiras, acho que, filosoficamente, decidimos que precisamos separar as coisas nesses componentes individuais. E há virtude em fazer isso, porque se for isolado, é mais fácil testar e tratar como uma única coisa. E você pode meio que, em termos da maneira como trabalhamos, torna as coisas mais fáceis de gerenciar. Temos que considerar, também, o fato de que essas coisas, em última análise, precisam compartilhar o mesmo espaço e se unir em um sistema maior.

Heydon: E eu não acho, na verdade, que o nosso esforço e pensamento sejam suficientes para isso, curiosamente. Acho que dividimos mais as coisas para facilitar nossas vidas como engenheiros, para que saibamos no que estamos trabalhando e em que momento. E, mas então, muitas vezes negligenciamos o fato de que essas coisas estarão vivendo em sistemas dinâmicos e precisam ser …

Heydon: Quero dizer, o projeto Every Layout, embora seja mais sobre design visual e sobre layout, trata-se de tentar fazer esses pequenos primitivos de CSS, esses pequenos primitivos de layout, de tal forma que eles possam se autogerenciar algoritmicamente. É para que você possa tirá-los de uma coluna estreita e colocá-los em uma coluna larga e então será, o próprio código determinará quantos itens lado a lado deve haver ou se deve se reconfigurar de alguma outra maneira. Porque não podemos nos dar ao luxo de estar constantemente intervindo, e tem que ser um sistema que seja auto-conhecido e inteligente, eu acho.

Heydon: Há sempre coisas que você pode esquecer. Então talvez você faça uma interface de abas, você tem uma linha de abas, você escolhe entre a aba e a aba corresponde a um painel de abas, que abre algo. E então, alguém virá e dirá: “Bem, e se eu quiser colocar uma interface de guia dentro de uma interface de guia ou algum outro componente dentro de uma interface de toque?”

Heydon: E claro, quero dizer, é parcialmente uma preocupação técnica se isso seria possível, mas sim, você tem que escolher se vai tornar as coisas tão flexíveis quanto possível para que seja possível imbricar as coisas de uma maneira complexa, ou simplesmente escrever regras rígidas que digam: “Você não pode colocar algo aqui porque o nível de complexidade em termos de código provavelmente seria muito alto, mas também possivelmente em termos de como o usuário pode perceber e usar a coisa”. Eu sou a favor de escrever regras que digam: “Não aninhe um monte de funcionalidades complexas dentro de si mesmo”, porque não é provável que as pessoas sejam capazes de entender isso, realmente.

Drew: É possível adotar uma abordagem totalmente algorítmica ou automatizada para projetar para acessibilidade?

Heydon: Não acredito. Não. Portanto, temos ferramentas automatizadas e não quero menosprezar as ferramentas automatizadas de forma alguma. Eu acho que eles são muito úteis, mas eu os uso como um sistema de alerta antecipado para tentar obter uma impressão de onde estão as áreas problemáticas. Então, se eu estivesse fazendo uma auditoria para uma organização que queria alguns conselhos sobre como tornar seus produtos mais acessíveis. Portanto, é uma boa forma de financiamento onde estão as áreas problemáticas, mas quero dizer, você pode ter uma interface que seja tecnicamente 100% acessível, talvez, de acordo com alguma ferramenta, até mesmo uma boa ferramenta para julgá-la, digamos, contra as WCAG , as diretrizes de acessibilidade de conteúdo da Web ou alguma outra especificação de aceitação. E, mesmo que seja 100% de todas as caixas marcadas, ainda pode ser totalmente inutilizável por vários motivos.

Heydon: Por exemplo, voltando ao que estávamos dizendo antes, pode ser muito complexo. Você pode simplesmente sobrecarregar alguém com links e não há como eles conseguirem passar por isso e então isso se torna, é uma coisa muito tácita e difícil de definir, mas é obrigado a apenas alienar as pessoas. Mas há também, você pode obter, é muito fácil obter falsos positivos e coisas assim. Eu tive uma coisa no outro dia, eu disse no outro dia, foi no outro mês, eu estava trabalhando para uma organização e é claro que eles queriam ter uma escola farol de acessibilidade 100% e havia um iframe que foi colocado lá dinamicamente por um script analítico ou algo assim. Você sabe o tipo de coisa em que é algum tipo de código um pouco grosseiro, que é meio que jogado na página para fazer alguma tarefa como essa.

Heydon: Agora, eu recomendaria não usar análises, e recomendei a eles que pelo menos suportassem o protocolo de não rastrear para que as pessoas pudessem optar por não participar. Infelizmente, esse protocolo meio que não funciona mais porque nunca foi realmente suportado adequadamente. Mas este iframe, estava dizendo que não tem um título nele. Portanto, a ideia é que, se você tiver um iframe, ele deve ter um atributo title, porque essa é a melhor forma de identificar para que serve o iframe para um usuário de leitor de tela. Mas este era um iframe que também estava configurado para não exibir nenhum, então nem era perceptível para um leitor de tela em primeiro lugar porque exibir nenhum, assim como oculta as coisas visualmente em um leitor de tela, ele essencialmente o removerá do interface, para que não seja encontrado ou anunciado de forma alguma.

Heydon: Então foi um falso positivo. Quero dizer, ele estava me pedindo para identificar um iframe que não estava lá para ser percebido em primeiro lugar. Portanto, sempre haverá esses tipos de erros e problemas nos testes automatizados. Mas, em última análise, trata-se de saber, embora seja apenas uma coisa que os programadores, eu acho, não gostam de pensar que estão envolvidos e acham um pouco nojento, mas é sobre o comportamento humano e sobre como as pessoas entendem as coisas e isso é uma coisa muito difícil de ter apenas um conjunto de regras binárias ou booleanas.

Heydon: Então, quero dizer, eu falei com um desenvolvedor quando estava prestando consultoria há algum tempo atrás sobre isso e eles ficavam dizendo: “Bem, desde que tenhamos testes automatizados, estamos bem, não estamos? É só, então podemos seguir em frente.” E eu disse: “Você ainda tem que testar manualmente. Não há nenhum teste automatizado que possa realmente dizer se usar a interface pelo teclado é impossível de uma forma ou de outra.” Existem coisas discretas que você pode procurar, mas a experiência geral ainda é algo que precisa ser julgado pelo ser humano. Sim.

Drew: Às vezes, o perigo das ferramentas automatizadas é que elas analisam os itens isoladamente ou uma interface isoladamente e não veem o contexto mais amplo.

Heydon: Sim.

Drew: Certamente com o uso do lighthouse para auditorias de desempenho, às vezes eu posso tomar uma decisão como desenvolvedor para incluir, pode haver muito mais CSS do que é usado nessa página e, estritamente falando, estou baixando muito CSS, mas na verdade , eu sei que uma vez que o arquivo é carregado, no momento em que o usuário navega para a próxima página, ele já tem o CSS. Portanto, é uma otimização que está sendo feita em várias páginas que a ferramenta, olhando para uma página isoladamente, vê como um erro.

Heydon: Sim, absolutamente. Você está pensando no futuro e está fazendo um julgamento, e até chegarmos à IA avançada para antecipar isso, então sim, você realmente precisa de seres humanos olhando para isso e passando por isso e indo ... quero dizer, então testes automatizados deveriam estar em vigor, como eu disse, uma espécie de sistema de alerta precoce, sistema de diagnóstico, mas também deve haver, se você estiver interessado em que sua organização realmente se importe e torne as coisas mais inclusivas e acessíveis, também deve haver treinamento . Tem que haver perguntas e respostas.

Heydon: Então eu escreveria scripts para “É assim que deve funcionar quando você interage com este componente com um teclado” ou “É assim que deve funcionar quando você interage com ele com um leitor de tela e não percorre isto. Então, quando você faz isso, isso deve acontecer. Quando você fizer isso, isso deve acontecer. Quando você faz isso, isso deve aparecer”, ou esse tipo de coisa. Então, e o tipo de coisa de jornada, como você diz, as ferramentas automatizadas não estão cientes disso. Eles apenas veem: “Ah, isso não tem texto alternativo aqui”. E, na verdade, em muitos casos, talvez não devesse ter texto alternativo. E também, não pode julgar se você escreveu o texto alternativo bem ou não. Então, acho que uma imagem sem todo o texto alternativo provavelmente é melhor do que uma imagem com texto alternativo enganoso ou apenas ruim. E isso é um julgamento novamente, não é?

Drew: Uma das coisas com as quais tenho lutado, historicamente, ao construir coisas de uma maneira acessível é manter meu conhecimento das melhores práticas atualizado porque, cada vez que me refiro a qualquer documentação ou qualquer tipo de recomendação, é parece que eu estava fazendo e pensei que estava fazendo a coisa certa, as recomendações mudaram e agora eu deveria estar fazendo outra coisa. E essa é uma história familiar com todas as áreas de trabalho na web. Mas acho que o perigo é, claro, com problemas de acessibilidade, é que, se você não estiver seguindo as melhores práticas, se você deixar algo em sua interface que agora não é uma boa prática, isso pode afetar seus usuários de forma negativa caminho. Uma abordagem baseada em componentes para construir uma interface ou um site ajuda de alguma forma?

Heydon: Acho que puramente no sentido de que, porque você tem um componente que, então, a ideia é claro em todos os casos e não apenas em termos de acessibilidade, é que você tenha esse componente definido em um lugar que será usado em diferentes lugares, pelo menos quando aspectos ou suporte do navegador ou o que quer que seja muda e você deseja atualizar o componente, você só precisa fazê-lo em um lugar e então onde quer que seja usado, essa melhoria ou essa mudança será sentida. Então, nesse sentido, acho que é certamente mais útil ter as coisas divididas em componentes.

Heydon: Mas então, sim, como eu disse, isso não afeta apenas a acessibilidade, isso pode afetar qualquer coisa que mude. Mas então, eu realmente não tenho certeza de quantas mudanças em sua... quer dizer, haverá poucas mudanças em termos de acessibilidade HTML, que é, obviamente, uma área muito restrita. Mas em termos de qualidade do código ou como o código funciona, as coisas são introduzidas na especificação HTML, obviamente, muito lentamente e não tão lentamente, mas muito lentamente na especificação ARIA também. E então, muito do ARIA apenas espelha o que está no HTML básico subjacente de qualquer maneira.

Heydon: Acho que, mais do que a tecnologia, a percepção e a compreensão dessas coisas tendem a mudar com o tempo. Quer dizer, houve recentemente, na pesquisa WebAIM recentemente, eles identificaram que os sites que estavam usando ARIA eram mais inacessíveis do que os sites que não o usavam. Então, essa tecnologia concebida especificamente para ajudar as pessoas a tornar os sites mais acessíveis, estava piorando. Então, na verdade, é apenas uma lacuna de conhecimento, não uma lacuna tecnológica ou uma deficiência tecnológica. São pessoas apenas pegando a tecnologia e usando-a mal porque não entenderam realmente como ela deveria funcionar, infelizmente. Espero que alguns dos meus escritos possam ajudar com isso. Em algumas áreas, de qualquer maneira.

Drew: Mas um tipo de sistema baseado em componentes bem estruturado permitiria que você, uma vez que você percebesse que algo está desatualizado ou tomou uma decisão ruim e agora sabe melhor, permitiria que você entrasse e consertasse mais facilmente em todo o seu aplicativo.

Heydon: Sim, exatamente. Sim, sim, absolutamente. Quero dizer, é tudo uma questão de eficiência, não é mesmo? E esse princípio seco ou o que você tem, e veja, é por isso que eu estava originalmente muito empolgado com essa oportunidade, porque as pessoas sempre reclamam que tornar as coisas acessíveis é um trabalho extra e é difícil e perturbador e tudo isso. E então, foi uma espécie de oportunidade de dizer: “Bem, você sabe como você está fazendo essas coisas de forma realmente eficiente, construindo esses sistemas de componentes? Obtenha sua acessibilidade para aquele componente que você está criando e, em seguida, você não precisa mais se preocupar com a acessibilidade, além da alteração ou atualização ocasional de especificações ou o que você tiver.”

Heydon: Ou apenas, quero dizer, provavelmente na maioria das vezes, a iteração será simplesmente baseada no feedback do usuário e na pesquisa em andamento, o que, obviamente, você deve, tanto quanto possível, conduzir com um grupo diversificado de pessoas. Então, você deve receber pessoas que usam dispositivos diferentes e têm hábitos de navegação diferentes e usam tecnologias assistivas diferentes e esse tipo de coisa. E você sabe, as coisas estão fadadas a surgir o tempo todo. Eu acho que realmente fixei um componente, acho que é realmente sólido, e então eu faço um pouco de pesquisa e descobri que fiz algumas suposições muito ruins. Mas sim, com um sistema de componentes, você só precisa consertá-lo em um lugar.

Drew: Um componente pode ser totalmente inclusivo ou é um espectro em que você está apenas trabalhando cada vez mais para a inclusão?

Heydon: Sim, seria possível para um componente ser, digamos, livre de erros do WCAC, ele atende a todos os critérios do WCAC, mas como eu disse, isso só leva você até certo ponto e ainda pode ser totalmente inutilizável ou impossível de entender mesmo com esses critérios técnicos atendidos. Então, sim, isso é algo que eu falo muito. Eu tento convencer as pessoas de que a acessibilidade é como qualquer outra área do design, é apenas uma parte do processo de design e nada pode ser perfeitamente projetado como nada pode ser perfeitamente acessível. Acho que, infelizmente, muitas pessoas pensam nisso apenas em termos de garantir que seja compatível com leitores de tela, o que obviamente é um escopo muito estreito em termos de acessibilidade e inclusão em geral.

Heydon: Então, haverá pessoas que, algumas boas pessoas com quem trabalhei, como no Paciello Group, que diriam: “Bem, na verdade, eu quero ser conhecido como uma pessoa de UX acessível”. Portanto, não se trata apenas deste exercício de marcação de caixa, trata-se mais de tentar tornar a experiência melhor e mais valiosa para o maior número de pessoas e avançar mais para princípios mais amplos e coisas menos binárias. Mas, em última análise, é tudo isso, e o WCAC e outros critérios semelhantes só podem realmente identificar as coisas realmente duras e rápidas do tipo “Isso está errado”, suponho.

Drew: Então, se eu sou um desenvolvedor, o que devo fazer diferente ao abordar como projeto, planejo e construo um componente? Existe alguma coisa que eu deveria considerar no meu trabalho para garantir que esse componente acabe sendo o mais inclusivo possível?

Heydon: Então, quero dizer, dependendo do que você está construindo, haverá critérios diferentes que precisam ser atendidos. Assim, por exemplo, nem todos os componentes terão imagens acessíveis com texto alternativo, porque podem não usar imagens. Pode ser apenas baseado em texto ou o que você tem. Alguns podem não ser interativos. Então, em termos de requisitos específicos, isso mudaria entre os componentes, mas espero que alguns dos meus escritos e o que o livro de Componentes Inclusivos o ajudem a fazer é cair ou adotar uma disciplina de apenas pensar de forma inclusiva.

Heydon: Então, quando você está abordando essas coisas, não apenas pensando, bem, basicamente apenas saindo da mentalidade de “Se funciona para mim, provavelmente funcionará para todos os outros”, porque simplesmente não é o caso de o maneira que você ou eu navegamos nas coisas, quer dizer, provavelmente faremos as coisas de forma completamente diferente, só nós dois, certo?

Drew: Certo.

Heydon: E nós somos ocidentais, brancos, ingleses como primeira língua. E então, sim, a quantidade de diversidade em termos de pessoas que consomem isso, quero dizer, pessoas de desempenho sempre falam sobre isso também, pessoas interessadas em defender um melhor desempenho. Você está acostumado a usar uma configuração de alta especificação em uma boa rede e muitos de seus usuários ou muitos de seus usuários em potencial certamente não estarão, e o mesmo com acessibilidade. É apenas uma questão de, basicamente, deixar de pensar em si mesmo, na verdade. Literalmente apenas isso. E tentando, obviamente, ir além de seus colegas imediatos e pessoas do mesmo grupo social também.

Heydon: Espero que seja realmente apenas “Aqui está o que eu resolvi para essas coisas”, e o que eu estava pensando na época. Você pode reutilizar algumas dessas ideias e aplicar exatamente o que eu apliquei, se isso for útil ou relevante para você. Felizmente, o livro é mais sobre apenas “Aqui está um estudo de caso de uma pessoa que tenta pensar de forma inclusiva. Veja, o tipo de coisa que eles estavam pensando, quando você está projetando algo completamente diferente, talvez apenas empregue o mesmo tipo de pensamento e tente abrir sua mente para a diversidade de usuários e como eles fazem as coisas.”

Drew: Então o livro em si, como você decidiu como estruturá-lo? Parece muito prático, o que eu gosto em um livro, mas como você o estruturou?

Heydon: Muito parecido com o livro anterior, na verdade era Inclusive Design Patterns e eu tive muitos problemas nesse livro, para começar, porque tentei organizá-lo em termos de critérios abstratos. Então eu comecei fazendo um capítulo que era sobre acessibilidade de teclado, mas isso foi muito difícil porque então eu meio que, toda vez que eu falava sobre um tipo diferente de acessibilidade de teclado ou a coisa que você tem que pensar, então eu tinha que conjurar algum tipo de componente e depois abandonar esse componente e depois passar para outra coisa.

Heydon: Então, fez mais sentido para mim organizar as coisas em termos de componentes em si. Então, o Inclusive Design Patterns faz isso e agora o Inclusive Components é realmente apenas uma continuação, que cobre apenas componentes diferentes. É diferente porque, em termos de recursos, é um pouco diferente porque também inclui exemplos de código ao vivo e outras coisas, o que não fiz muito nos livros anteriores. Mas sim, é literalmente apenas "Vamos fazer este componente", seja uma interface de toque ou uma seção dobrável ou um alternador de temas ou um cartão flash de notificação ou torradeira ou o que quer que eles sejam chamados, e então tudo é então organizado em torno desse componente.

Heydon: Então é: “É isso que estamos fazendo e essas são as coisas que devemos considerar enquanto fazemos isso para ser mais inclusivo”, porque é assim que eu trabalho e é assim que outras pessoas trabalham. E assim que comecei a fazer assim, era apenas eu trabalhando e escrevendo notas enquanto trabalhava. E então, a coisa meio que se escreveu sozinha, e então todo o esforço foi realmente apenas para ter certeza de que eu estava fazendo um trabalho decente para tornar essas coisas não inacessíveis, eu acho.

Drew: Sim, quero dizer que o índice realmente parece quase como uma documentação ou como um manual de auto-ajuda ou algo assim. Direto com o capítulo um, botões de alternância. Se você quiser implementar alguns botões de alternância, vá para este capítulo, leia-o e você terá tudo o que precisa saber sobre como fazer isso, que é uma abordagem que eu realmente gosto. Eu vejo coisas como seções recolhíveis, interface com guias, opções de temas, tabelas de dados, um monte de coisas práticas reais que estamos construindo todos os dias e acho que todos nós, provavelmente, poderíamos estar construindo melhor.

Heydon: Sim, essa foi totalmente a ideia porque não era apenas sobre eu fazer meus componentes, era um caso, e você tocou nisso lá, o que estou feliz que você fez, que era identificar padrões que todos nós usamos. Então, quero dizer, há interfaces de guias em todos os lugares e todas são implementadas de maneira diferente e todas são implementadas, de forma variada, muito mal. Quer dizer, eu implementei interfaces de abas terríveis e aprendi um pouco sobre como elas eram ruins para as pessoas, e então tentei torná-las um pouco melhores e um pouco melhores e um pouco melhores. Eu provavelmente fiz 15 ou 16 versões diferentes de interfaces de guias no meu tempo, fazendo esse tipo de coisa há anos.

Heydon: E você sabe, eles estão ficando um pouco melhores, espero, a cada vez. Mas é apenas uma coisa comum. Era uma coisa comum que eu usava com bastante frequência entre sites diferentes, eu uso e todo mundo usa. Então, parte da ideia era dizer: “Bem, na verdade, vamos fazer um sistema de design, uma espécie de sistema de design acessível para a web”. Agora, as pessoas vão se ramificar e vão fazer suas próprias versões dessas coisas, mas meio que colocar as coisas principais e a acessibilidade é uma coisa essencial que deveria estar nas coisas. Não deve ser um complemento, não deve ser um ou/ou, não deve ser um recurso. Deve ser uma coisa central. E se você juntar essas coisas principais, então sim, espero que as pessoas vejam os capítulos e digam: “Ah, ok, eu fiz isso. Eu vi aqueles. Vamos ver como fazê-lo da forma mais inclusiva possível”, e esperamos que eles obtenham algum valor com isso.

Drew: Bem, o que eu gosto é que certamente sei que, no passado, tive alguns recursos de interface que precisei implementar e sei que será complicado do ponto de vista da acessibilidade , digamos algum tipo de menu suspenso, menu suspenso, algo assim. Eu penso: “Ok, aqui estão os dragões em termos de acessibilidade. Eu preciso ter certeza de fazer isso direito.” E então, procuro no Google como fazer isso, encontro uma fonte respeitável dizendo: “Use este método”, eu uso esse método, implemento e sigo em frente, mas na verdade não aprendi nada. Eu não aprendi porque a solução foi essa. E o que eu realmente gosto na maneira como você aborda isso no livro é que posso fazer duas coisas ao mesmo tempo. Eu posso descobrir como eu deveria estar fazendo isso e eu posso descobrir por que eu deveria estar fazendo assim, porque tudo é explicado com muito cuidado. Então, eu acho que é realmente bem sucedido desse ponto de vista.

Heydon: Ah, ótimo. Era para isso que eu estava indo. Então isso é bom. 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. Sim.

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.