Marc Benioff declarou 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. Companheiros 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 ter imaginado.
Embora essa mudança constante na indústria de tecnologia tenha levado à inovação e aos avanços que vemos hoje, ela também introduziu o conceito de escolha. Embora a escolha-superficialmente-possa parecer algo inerentemente positivo, nem sempre é igual a arco-íris e rosas. O influxo da mudança tecnológica também traz a fragmentação das linguagens de codificação e os sabores intermináveis de”gostosura”de programação. Às vezes, essa abundância de escolha se transforma em overchoice -uma deficiência cognitiva bem estudada em que as pessoas têm dificuldade de tomar uma decisão por terem muitas 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 restrições potenciais e, por último, faremos 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
A Overchoice se infiltrou em todos os aspectos da tecnologia, incluindo os padrões e bibliotecas que usamos para construir nossas criações digitais-da caixa de seleção simples ao modal dinâmico complexo e tudo mais. Mas como sabemos qual padrão ou biblioteca é o certo 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 do 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 para trá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 difícil o suficiente, este pode ser o ponto onde você começou a ficar preocupado. Mas não precisa se preocupar-escolher um padrão/biblioteca acessível não é ciência do foguete. Como tudo o mais na tecnologia, esta jornada começa com um pouco de conhecimento, um grande acúmulo de tentativa e erro e uma compreensão de que não existe apenas um padrão/biblioteca perfeito que se adapta a cada usuário, situação ou estrutura.
Como eu sei disso? Bem, passei os últimos cinco anos pesquisando, criando e testando diferentes tipos de padrões acessíveis enquanto trabalho no Guia de estilo A11y , Biblioteca de padrões ARIA de Deque e avaliando a popular Padrões SVG . Mas também revisei muitos padrões de cliente e bibliotecas em todas as estruturas/plataformas imagináveis. Neste momento, posso dizer sem escrúpulos que existe uma hierarquia inata para acessibilidade de padrão que começa a se desenvolver quando você olha por tempo suficiente. E embora haja ocasionalmente padrões a evitar a todo custo, nem sempre é tão claro. Quando se trata de acessibilidade, eu diria que a maioria dos padrões cai em gradientes de bom, melhor, ótimo. A parte difícil é saber qual padrão pertence a qual categoria.
Pensando criticamente sobre os 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, então, 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?
- Para quais navegadores e dispositivos de tecnologia assistiva (AT) oferecemos suporte?
- Há alguma limitação de estrutura ou outras integrações/fatores a serem considerados?
Claro, suas perguntas específicas podem ser diferentes das minhas, mas a questão é que você precisa começar a usar suas habilidades de pensamento crítico ao avaliar padrões. Você pode fazer isso observando, analisando e classificando cada padrão de acessibilidade antes de tomar uma decisão final. Mas antes de chegarmos a isso, vamos primeiro nos aprofundar um pouco mais nas perguntas iniciais.
Já existe um padrão de acessibilidade estabelecido?
Por que parece que, com cada nova estrutura, obtemos um novo conjunto de padrões? Essa reinvenção constante da roda com novas opções de padrão pode confundir e frustrar os desenvolvedores, especialmente porque geralmente não é necessário fazer isso.
Não acredita em mim? Bem, pense desta forma: se assinarmos 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 olharmos mais profundamente em todos os padrões disponíveis nas várias estruturas que existem, a estrutura subatômica central é essencialmente a mesma, independentemente da linguagem de codificação real usada. É por isso que agradeço bibliotecas de codificação simplificadas com padrões acessíveis que podemos construir com base nas necessidades tecnológicas e de design.
Observação : Algumas ótimas fontes confiáveis incluem Componentes inclusivos , Componentes acessíveis e o Gov.UK Design Sistema , além da lista de padrões acessíveis Smashing Revista publicada 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 navegador e suporte de dispositivo 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ível, apenas muito mais tempo, esforço e processo de pensamento envolvidos para descobrir tudo.
Mas não são todas más notícias. Existem alguns recursos fabulosos como HTML5 Accessibility e Accessibility Support que nos ajudam a compreender melhor o navegador atual + o suporte ao dispositivo 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ão-para navegadores de desktop e móveis/dispositivos AT.
Há alguma limitação da estrutura ou outras integrações/fatores a serem considerados?
Depois de escolher alguns padrões de base acessíveis e fatorar no suporte do navegador/dispositivo AT, podemos prosseguir 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ão podem ser rapidamente reduzidas a uma ou duas. Por outro lado, alguns frameworks são mais tolerantes e abertos para aceitar qualquer padrão, então podemos nos preocupar menos com as restrições de framework e nos concentrar mais em fazer a escolha de padrão mais acessível que pudermos.
Além de tudo o que discutimos até agora, há muitas considerações adicionais a pesar ao escolher um padrão, como desempenho, segurança, otimização de mecanismo de pesquisa, tradução de idioma, 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 estão criando o conteúdo. O padrão acessível que você escolher deve ser construído de uma 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.
Avaliação de padrões de acessibilidade
O código geralmente fala mais alto do 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 é considerado o “melhor” no grupo o melhor opção em todo o mundo de padrões acessíveis.
Para as demonstrações de padrão abaixo, devemos imaginar uma situação hipotética em que estamos comparando cada grupo de padrões com eles próprios. Embora esta 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 terceiro padrões de botão usam o HTML elemento . O terceiro padrão também adiciona aria-describeby e CSS para ocultar coisas visualmente .
Veja a Caneta Padrões de botões acessíveis por Carie Fisher .
Bom: role="button"
Inscreva-se
Melhor:
Melhor: visualmente oculto + aria-describedby
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 ARIA role="button" sendo usado no padrão “bom” em vez de um elemento HTML . Pensando em termos de acessibilidade, já que sabemos que o elemento HTML foi introduzido no HTML4, podemos especular que ele é totalmente compatível com as 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”, vemos uma ligeira vantagem de um assistente perspectiva da tecnologia, enquanto o elemento HTML está faltando algumas áreas de cobertura do navegador + AT , especialmente quando consideramos o suporte ao controle de voz.
Então, por que o padrão ARIA não está na categoria “melhor”? ARIA não o torna mais acessível? Não. Na verdade, em casos como esse, os profissionais de acessibilidade costumam recitar a primeira regra do ARIA- não use ARIA . Esta é uma forma 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. Na verdade, o relatório WebAIM Million afirma que “as 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 ponto contra o uso de ARIA nesta situação é que a funcionalidade do botão de que precisamos precisa ser construída para o padrão role="button", enquanto essa funcionalidade já está pré-incorporada ao
O terceiro padrão de botão mostra o elemento HTML acoplado a aria-describeby 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, criando uma relação entre o botão e a finalidade. Em caso de dúvida, a qualquer momento podemos adicionar mais contexto à situação, melhor, para que possamos presumir que, se codificado corretamente, é o melhor padrão ao comparar apenas esses padrões de botão específicos.
Padrões de link contextual acessíveis
O segundo grupo de padrões que revisaremos são os links contextuais. Esses padrões ajudam a fornecer mais informações aos usuários de 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 o terceiro padrões de link adicionam atributos ARIA à mistura: aria-label , respectivamente.
Veja a Caneta Padrões de link acessíveis por Carie Fisher .
Bom: visualmente oculto
“Minha mãe sempre dizia: quanto mais você envelhece, melhor você fica, a menos que você seja uma banana.”-Rose (Betty White) Leia mais Citações da Golden Girl
Melhor: visualmente oculto + aria-labelledby
“Ou vou pegar um sorvete ou cometer um crime... Decidirei no carro.”-Blanche (Rue McClanahan) Leia mais Leia mais citações da Golden Girl
Melhor: aria-label
“As pessoas perdem tempo pensando se um copo está meio cheio ou meio vazio. Eu só bebo o que quer que esteja no copo."-Sophia (Estelle Getty) Leia mais
Embora todos os três padrões de link contextual pareçam iguais, quando inspecionamos o código ou os testamos com dispositivos AT, existem 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 de 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 escolha OK, 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 difíceis de avaliar. De acordo com as especificações ARIA do W3C “O propósito de aria-label é o mesmo que aria-labelledby . Ele fornece ao usuário um nome reconhecível do objeto. ” Portanto, em teoria, os dois atributos devem ter a mesma funcionalidade básica.
No entanto, as especificações também indicam 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 de tradução automática e atributos de rótulo de ária . Isso significa que devemos usar aria-labelledby , certo?
Bem, não tão rápido. As mesmas especificações ARIA dizem “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 deveriam use aria-label e não deve usar aria-labelledby . ” Isso é confuso-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 o contexto completo exibido (por exemplo, “ Leia mais sobre essa coisa incrível ”) ou decidir para 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 uma forma razoável/acessível e não quiséssemos mudar o visual-e então?
Com base nas recomendações atuais do ARIA 1.1 (com a promessa de tradução de aria-label no ARIA 1.2 ) além do fato de que aria-label é um pouco mais fácil para os desenvolvedores implementarem do que aria-labelledby , poderíamos decidir ponderar 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.
acessíveis
Por último, mas não menos importante, vamos investigar um grupo de padrões de imagem SVG para acessibilidade. SVGs são uma representação visual do código, mas código, mesmo assim. Isso significa que um dispositivo AT pode pular uma imagem SVG não decorativa, a menos que role="img" seja adicionado ao padrão.
Assumindo que os seguintes padrões SVG são informativos por natureza, um role="img" foi incluído em cada um. O primeiro padrão SVG usa