Bom, melhor, melhor: desvendando o mundo complexo dos padrões acessíveis

Marc Benioff afirmou de forma memorável que a única constante na indústria de tecnologia é a mudança. Tendo trabalhado em tecnologia por mais de 15 anos, posso confirmar isso. Os dinossauros da tecnologia podem atestar que a forma como a web funcionava nos primeiros dias é drasticamente diferente do que muitos de nós poderíamos imaginar.

Embora essa mudança constante no setor de tecnologia tenha levado à inovação e aos avanços que vemos hoje, também introduziu o conceito de escolha. Embora a escolha – na superfície – possa parecer uma coisa inerentemente positiva, nem sempre é igual a arco-íris e rosas. O influxo de mudanças tecnológicas também traz a fragmentação das linguagens de codificação e os sabores intermináveis ​​da programação “quente”. Às vezes, essa abundância de escolha se transforma em excesso de escolha – um comprometimento cognitivo bem estudado em que as pessoas têm dificuldade em tomar uma decisão devido ao excesso de opções.

Neste artigo, tentaremos desvendar o complexo mundo dos padrões acessíveis – um passo de cada vez. Começaremos revisando os padrões e bibliotecas acessíveis atuais, depois consideraremos nossas necessidades gerais de padrões e possíveis restrições e, por último, passaremos por uma série de exercícios de pensamento crítico para aprender como avaliar melhor os padrões de acessibilidade.

Que teia emaranhada nós tecemos

Overchoice penetrou em todos os aspectos da tecnologia, incluindo os padrões e bibliotecas que usamos para construir nossas criações digitais - da simples caixa de seleção ao complexo modal dinâmico e tudo mais. Mas como sabemos qual padrão ou biblioteca é a correta quando há tantas opções? É melhor usar padrões/bibliotecas estabelecidos que os usuários encontram todos os dias? Ou é melhor criar novos padrões para uma experiência de usuário mais agradável?

Com a miríade de opções disponíveis, podemos rapidamente ficar paralisados ​​pela superabundância de opções. Mas se dermos um passo atrás e considerarmos por que construímos nossos produtos digitais em primeiro lugar (ou seja, o usuário final), não faz sentido escolher o padrão ou biblioteca que pode agregar mais valor para o maior número de pessoas? ?

Se você pensou que escolher um padrão ou biblioteca já era um processo bastante assustador, esse pode ser o ponto em que você começa a ficar preocupado. Mas não precisa se preocupar - escolher um padrão/biblioteca acessível não é ciência do foguete. Como tudo na tecnologia, essa jornada começa com um pouco de conhecimento, uma enorme quantidade de tentativa e erro e um entendimento de que não existe apenas um padrão/biblioteca perfeito que se adapte a cada usuário, situação ou estrutura.

Como eu sei disso? Bem, passei os últimos cinco anos pesquisando, construindo e testando diferentes tipos de padrões acessíveis enquanto trabalhava no Guia de Estilo A11y, na Biblioteca de Padrões ARIA da Deque e avaliava padrões SVG populares. Mas também revisei muitos padrões e bibliotecas de clientes em todos os frameworks/plataformas imagináveis. Neste momento, posso dizer sem escrúpulos que existe uma hierarquia inata para acessibilidade de padrões que começa a se desenvolver quando você olha o suficiente. E, embora ocasionalmente existam padrões a serem evitados a todo custo, nem sempre é tão claro. Quando se trata de acessibilidade, eu diria que a maioria dos padrões se enquadra em gradientes de bom, melhor, melhor. A parte difícil é saber qual padrão pertence a qual categoria.

Pensando criticamente sobre padrões

Então, como sabemos quais padrões são bons, melhores e melhores quando se trata de acessibilidade? Depende. Essa frase frequentemente invocada da comunidade de acessibilidade digital não é uma desculpa, mas é uma abreviação de “precisamos de mais contexto para poder dar a melhor resposta”. No entanto, o contexto nem sempre é claro, portanto, ao construir e avaliar a acessibilidade de um padrão, algumas perguntas fundamentais que faço incluem:

• Já existe um padrão acessível estabelecido que podemos usar?
• Quais navegadores e dispositivos de tecnologia assistiva (AT) são compatíveis?
• Existem limitações de estrutura ou outras integrações/fatores a serem considerados?

É claro que suas perguntas específicas podem variar das minhas, mas o ponto é que você precisa começar a usar suas habilidades de pensamento crítico ao avaliar padrões. Você pode fazer isso primeiro observando, analisando e classificando cada padrão para acessibilidade antes de tomar uma decisão final. Mas antes de chegarmos a isso, vamos nos aprofundar um pouco mais nas questões iniciais.

Já existe um padrão acessível estabelecido?

Por que parece que a cada nova estrutura, obtemos um novo conjunto de padrões? Essa reinvenção constante da roda com novas escolhas de padrões pode confundir e frustrar os desenvolvedores, principalmente porque geralmente não é necessário fazê-lo.

Não acredite em mim? Bem, pense desta forma: se subscrevermos o sistema de design atômico, entendemos que vários pequenos “átomos” de código se unem para criar um produto digital maior. Mas no mundo científico, os átomos não são o menor componente da vida. Cada átomo é feito de muitas partículas subatômicas como prótons, nêutrons e elétrons.

Essa mesma lógica pode ser aplicada aos nossos padrões. Se examinarmos mais profundamente todos os padrões disponíveis nas várias estruturas existentes, a estrutura subatômica central é essencialmente a mesma, independentemente da linguagem de codificação real usada. É por isso que aprecio bibliotecas de codificação simplificadas com padrões acessíveis que podemos construir com base nas necessidades tecnológicas e de design.

Nota : Algumas ótimas fontes respeitáveis ​​incluem Componentes Inclusivos, Componentes Acessíveis e o Sistema de Design Gov.UK, além da lista de padrões acessíveis que a Smashing Magazine publicou recentemente (além de uma lista mais detalhada de padrões e bibliotecas no final do artigo) .

Quais navegadores e dispositivos de tecnologia assistiva (AT) oferecemos suporte?

Depois de pesquisar alguns padrões básicos que podem funcionar, podemos passar para a questão do suporte a navegadores e dispositivos de tecnologia assistiva (AT). Por si só, o suporte ao navegador não é brincadeira. Quando você adiciona dispositivos AT e especificações ARIA à mistura, as coisas começam a ficar complicadas... não impossíveis, apenas muito mais tempo, esforço e processo de pensamento envolvido para descobrir tudo.

Mas nem tudo são más notícias. Existem alguns recursos fabulosos como Acessibilidade HTML5 e Suporte de Acessibilidade que nos ajudam a construir uma maior compreensão do navegador atual + suporte a dispositivos AT. Esses sites descrevem os diferentes subelementos de padrão HTML e ARIA disponíveis, incluem testes de comunidade de código aberto e fornecem alguns exemplos de padrões — para navegadores/dispositivos AT de desktop e móveis.

Existem limitações de estrutura ou outras integrações/fatores a serem considerados?

Assim que tivermos escolhido alguns padrões básicos acessíveis e levado em consideração o suporte do navegador/dispositivo AT, podemos passar para questões contextuais mais refinadas sobre o padrão e seu ambiente. Por exemplo, se estivermos usando um padrão em um sistema de gerenciamento de conteúdo (CMS) ou tivermos considerações de código legado, haverá certas limitações de padrão. Nesse caso, um punhado de opções de padrões pode ser rapidamente reduzido a um ou dois. Por outro lado, alguns frameworks são mais tolerantes e abertos a aceitar qualquer padrão, então podemos nos preocupar menos com restrições de framework e focar mais em fazer a escolha de padrão mais acessível que pudermos fazer.

Além de tudo o que discutimos até agora, há muitas considerações adicionais a serem consideradas ao escolher um padrão, como desempenho, segurança, otimização de mecanismos de pesquisa, tradução de idiomas, integração de terceiros e muito mais. Esses fatores, sem dúvida, influenciarão sua escolha de padrão acessível, mas você também deve pensar nas pessoas que criam o conteúdo. O padrão acessível que você escolher deve ser construído de forma robusta o suficiente para lidar com quaisquer limitações potenciais em torno do conteúdo gerado pelo editor e/ou gerado pelo usuário.

Avaliando Padrões de Acessibilidade

O código geralmente fala mais alto que as palavras, mas antes de entrarmos em tudo isso, uma observação rápida de que os exemplos de padrões a seguir não são os únicos padrões disponíveis para cada situação, nem aquele considerado “melhor” no grupo a melhor opção no mundo inteiro de padrões acessíveis.

Para as demonstrações de padrões abaixo, devemos imaginar uma situação hipotética na qual estamos comparando cada grupo de padrões contra si mesmos. Embora essa não seja uma situação realista, executar esses exercícios de pensamento crítico e avaliar os padrões de acessibilidade deve ajudá-lo a estar mais preparado quando encontrar a escolha de padrões no mundo real.

Padrões de botões acessíveis

O primeiro grupo de padrões que analisaremos para acessibilidade é onipresente em quase todos os sites ou aplicativos: botões. O primeiro padrão de botão usa a função de botão ARIA para imitar um botão, enquanto o segundo e o terceiro padrão de botão usam o elemento HTML <button> . O terceiro padrão também adiciona aria-describedby e CSS para ocultar as coisas visualmente.

Bom: role="button"

 <a role="button" href="[link]">Sign up</a>

Melhor: <button>

 <button type="button">Sign up</button>

Melhor: <button> + visually hidden + aria-describedby

 <button type="button">Sign up</button> <span class="visually-hidden"> for our monthly newsletter</span>

Embora os primeiros padrões pareçam simples à primeira vista, eles evocam algumas questões de acessibilidade. Por exemplo, no primeiro padrão de botão, vemos que ARIA role="button" é usado no padrão "bom" em vez de um elemento HTML <button> . Pensando em termos de acessibilidade, já que sabemos que o elemento HTML <button> foi introduzido no HTML4, podemos razoavelmente especular que ele é totalmente suportado pelas versões mais recentes de todos os principais navegadores e funcionará bem com a maioria dos dispositivos AT. Mas se nos aprofundarmos e olharmos para o suporte de acessibilidade para ARIA role=“button” veremos uma pequena vantagem do ponto de vista de tecnologia assistiva, enquanto o elemento HTML <button> está faltando algumas áreas de cobertura de navegador + AT, especialmente quando consideramos suporte de controle de voz.

Então, por que o padrão ARIA não está na categoria “melhor”? O ARIA não o torna mais acessível? Não. Na verdade, em casos como esse, os profissionais de acessibilidade geralmente recitam a primeira regra do ARIA — não use o ARIA. Esta é uma maneira irônica de dizer use elementos HTML sempre que possível. ARIA é realmente poderoso, mas nas mãos erradas, pode fazer mais mal do que bem. De fato, o relatório do WebAIM Million afirma que “páginas com ARIA apresentam em média 60% mais erros do que aquelas sem”. Como tal, você deve saber o que está fazendo ao usar o ARIA.

Outro contra o uso de ARIA nesta situação é que a funcionalidade do botão que precisamos precisaria ser construída para o padrão role="button" , enquanto essa funcionalidade já está pré-preparada no elemento <button> . Considerando que o elemento <button> também tem 100% de suporte ao navegador e é um padrão fácil de implementar, ele fica um pouco à frente na hierarquia ao avaliar os dois primeiros padrões. Felizmente, essa comparação ajuda a acabar com o mito de que adicionar ARIA torna um padrão mais acessível - muitas vezes o oposto é verdadeiro.

O terceiro padrão de botão mostra o elemento HTML <button> acoplado com aria-describedby vinculado a um elemento de ID que está visualmente oculto com CSS. Embora esse padrão seja um pouco mais complexo, ele adiciona muito em termos de contexto ao criar uma relação entre o botão e a finalidade. Em caso de dúvida, sempre que pudermos adicionar mais contexto à situação, melhor, para que possamos assumir que, se codificado corretamente, é o melhor padrão ao comparar apenas esses padrões de botões específicos.

Padrões de links contextuais acessíveis

O segundo grupo de padrões que analisaremos são os links contextuais. Esses padrões ajudam a fornecer mais informações aos usuários do AT do que o que é visível na tela. O primeiro padrão de link utiliza CSS para ocultar visualmente as informações contextuais adicionais. Enquanto o segundo e terceiro padrões de link adicionam atributos ARIA à mistura: aria-labelledby e aria-label , respectivamente.

Bom: visually-hidden

 <p>“My mother always used to say: The older you get, the better you get, unless you're a banana.” — Rose (Betty White)<a href="[link]">Read More<span class="visually-hidden"> Golden Girl quotes</span></a></p>

Melhor: visually-hidden + aria-labelledby

 <p>“I'm either going to get ice cream or commit a felony...I'll decide in the car.” — Blanche (Rue McClanahan)<a href="[link]" aria-labelledby="quote">Read More</a><span class="visually-hidden">Read more Golden Girl quotes</span></p>

Melhor: aria-label

 <p>“People waste their time pondering whether a glass is half empty or half full. Me, I just drink whatever's in the glass.” — Sophia (Estelle Getty)<a href="[link]" aria-label="Read more Golden Girls quotes">Read More</a></p>

Embora todos os três padrões de links contextuais pareçam iguais, quando inspecionamos o código ou os testamos com dispositivos AT, há algumas diferenças óbvias. O primeiro padrão usa uma técnica CSS para ocultar o conteúdo visualmente para usuários com visão, mas ainda renderiza o conteúdo oculto para usuários AT sem visão. E embora essa técnica deva funcionar na maioria dos casos, não há uma relação real formada entre o link e as informações adicionais, portanto, a conexão é, na melhor das hipóteses, provisória. Como tal, o primeiro padrão de link é uma boa escolha, mas não o padrão de link mais robusto dos três.

Os próximos dois padrões de link são um pouco mais complicados de avaliar. De acordo com as especificações ARIA do W3C “O propósito do aria-label é o mesmo do aria-labelledby . Ele fornece ao usuário um nome reconhecível do objeto.” Então, em teoria, ambos os atributos devem ter a mesma funcionalidade básica.

No entanto, as especificações também apontam que os agentes do usuário dão precedência a aria-labelledby sobre aria-label ao decidir qual nome acessível transmitir ao usuário. A pesquisa também mostrou problemas em torno da tradução automática e atributos de rótulo de ária. Então isso significa que devemos usar aria-labelledby , certo?

Bem, não tão rápido. As mesmas especificações do ARIA continuam dizendo: “Se a interface for tal que não seja possível ter um rótulo visível na tela (ou se um rótulo visível não for a experiência do usuário desejada), os autores devem usar aria-label e não devem use aria-labelledby .” Fale sobre confusão – então, qual padrão devemos escolher?

Se tivéssemos necessidades de tradução em grande escala, poderíamos decidir mudar o aspecto visual e escrever os links com todo o contexto exibido (por exemplo, “ Leia mais sobre essa coisa incrível ”) ou decidir usar aria-labelledby . No entanto, vamos supor que não tivéssemos necessidades de tradução em grande escala ou pudéssemos atender a essas necessidades de maneira razoável/acessível, e não queríamos alterar o visual — e então?

Com base nas recomendações atuais do ARIA 1.1 (com a promessa de tradução de aria-label em ARIA 1.2) mais o fato de que aria-label é um pouco mais fácil para os desenvolvedores implementarem versus aria-labelledby , poderíamos decidir aria-label sobre aria-labelledby em nossa avaliação de padrão. Este é um exemplo claro de quando o contexto pesa muito em nossa escolha de padrão acessível.

Padrões <svg> acessíveis

Por último, mas certamente não menos importante, vamos investigar um grupo de padrões de imagem SVG para acessibilidade. SVGs são uma representação visual de código, mas ainda assim código. Isso significa que um dispositivo AT pode pular uma imagem SVG não decorativa, a menos que role="img" seja adicionado ao padrão.

Supondo que os padrões SVG a seguir sejam de natureza informativa, um role="img" foi incluído em cada um. O primeiro padrão SVG usa <title> e <text> em conjunto com CSS para ocultar visualmente o conteúdo de usuários com visão. Os próximos dois padrões SVG envolvem os elementos <title> e <desc> , mas com um atributo aria-labelledby adicionado ao último padrão.

Bom: role="img" + <title> + <text>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The first little pig built a house out of straw.</title> <text class="visually-hidden">Sadly, he was eaten by the wolf.</text>... </svg>

Melhor: role="img" + <title> + <desc>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The second little pig built a house out of sticks.</title> <desc>Sadly, he too was eaten by the big, bad wolf.</desc>... </svg>

Melhor: role="img" + <title> + <desc> + aria-labelledby="[id]"

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" aria-labelledby="pig3house pig3wolf" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The third little pig built a house out of bricks.</title> <desc>Thankfully he wasn't eaten by the wolf.</desc>... </svg>

Vamos primeiro olhar para o primeiro padrão usando <title> e <text> e CSS visualmente oculto. Ao contrário do texto anterior visivelmente oculto em padrões, há uma relação inerente entre os elementos <title> e <text> , pois eles são agrupados sob o mesmo guarda-chuva de elementos SVG. No entanto, essa relação não é muito forte. Na verdade, se você olhar para trás em minha pesquisa sobre padrões SVG, veremos que apenas 3 de 8 combinações de navegador/AT ouviram a mensagem completa. (Nota: o padrão de porco nº 1 é equivalente ao padrão de lâmpada nº 7.)

Isso é verdade, embora as especificações SVG do W3C definam o elemento <text> como “um elemento gráfico que consiste em texto… os caracteres a serem desenhados são expressos como dados de caracteres. Como resultado, os dados de texto no conteúdo SVG são facilmente acessíveis aos deficientes visuais.” Este primeiro padrão está OK, mas podemos fazer melhor.

O segundo padrão remove o elemento <text> e o substitui por um elemento <desc> . As especificações do W3C SVG indicam:

“O elemento filho <title> representa uma alternativa de texto curto para o elemento... e o elemento <desc> representa informações textuais mais detalhadas para o elemento, como uma descrição.”

Ou seja, os elementos <title> e <desc> em SVGs podem ser usados ​​de forma semelhante ao texto alternativo da imagem e às opções de descrição longa encontradas tradicionalmente nos elementos <img> . Depois de adicionar o elemento <desc> ao segundo SVG, vemos suporte semelhante ao navegador/AT com 3 de 8 combinações ouvindo a mensagem completa. (Observação: o padrão Pig nº 2 é equivalente ao padrão de lâmpada nº 10.) Embora esses resultados de teste pareçam espelhar o primeiro padrão, a razão pela qual esse padrão chega à categoria “melhor” é que é um pouco mais fácil implementar o código. inteligente e impacta mais usuários AT, pois funcionou no JAWS, VoiceOver desktop e VoiceOver mobile, enquanto o primeiro padrão suportava combinações menos populares de navegador/AT.

O terceiro padrão novamente usa os elementos <title> e <desc> , mas agora tem um aria-labelledby plus ID adicionado à mistura. De acordo com os mesmos testes de SVG, adicionar esse código adicional significa que podemos oferecer suporte total a 7 de 8 combinações de navegador/AT. (Observação: o padrão Pig nº 3 é equivalente ao padrão de lâmpada nº 11.) Dos três padrões SVG, este terceiro é o “melhor”, pois suporta a maioria dos dispositivos AT. Mas esse padrão tem uma desvantagem no uso de algumas combinações de navegador/AT; você ouvirá o conteúdo duplicado do título/descrição da imagem para este padrão. Embora potencialmente irritante para os usuários, eu diria que geralmente é melhor ouvir conteúdo duplicado do que nenhum.

Considerações finais

Embora todos nós certamente valorizemos a escolha em tecnologia, eu me pergunto se chegamos a um ponto no tempo em que a superabundância de opções nos deixou paralisados ​​e confusos sobre o que fazer a seguir. Em termos de escolha de padrões acessíveis, podemos fazer perguntas diretas sobre opções de padrão/biblioteca, suporte a navegador/dispositivo AT, limitações de estrutura e muito mais.

Com os dados certos em mãos, essas perguntas são fáceis de responder. No entanto, torna-se um pouco mais complicado quando vamos além dos padrões e realmente consideramos as pessoas que os usam. É então que percebemos o impacto que nossas escolhas têm na capacidade de sucesso de nossos usuários. Como o Prof. George Dei afirma eloquentemente:

“A inclusão não é trazer as pessoas para o que já existe – é criar um novo espaço, um espaço melhor para todos.”

Ao dedicar um pouco mais de tempo para pensar criticamente sobre os padrões e escolher os mais acessíveis, sem dúvida criaremos um espaço mais inclusivo para alcançar mais usuários – em seus termos.

Recursos Relacionados

Ferramentas

• Suporte de acessibilidade, Michael Fairchild, a11ysupport.io
• Acessibilidade HTML5, Steve Faulkner

Bibliotecas de padrões

• Projeto de Acessibilidade
• Guia de estilo de acessibilidade
• Componentes Acessíveis, Scott O'Hara
• Plugin de Reordenação de Listas drag-and-drop acessível, Harris Schneiderman
• Biblioteca de padrões ARIA do Deque
• Biblioteca React Acessível do Deque
• Sistema de Design GOV.UK
• Componentes Inclusivos, Heydon Pickering
• Sistema de Web Design dos EUA (USWDS)
• Tutoriais de Acessibilidade na Web