Índice

Abaixo, você encontrará uma lista em ordem alfabética de todos os componentes acessíveis. Pule o índice ou simplesmente role para baixo para explorá-los um por um.

Modais acessíveis

Você pode ter um modal ou sobreposição simples na página, talvez para confirmar a entrada do cliente ou para mostrar algumas fotos em uma galeria, ou apenas para confirmar as preferências do usuário. Em todos esses casos, construir um modal acessível se tornará uma grande aventura, também conhecido como armadilha de foco .

Conforme Eric Bailey explica em detalhes , você precisará identificar os limites do preso conteúdo, incluindo o primeiro e o último item focalizável, em seguida, remova tudo o que não está dentro dele, mova o foco para o conteúdo capturado, ouça eventos que escapam do limite, restaure o estado anterior e mova o foco de volta para o elemento interativo que acionou o conteúdo.

Idealmente, usaríamos algo tão simples como o elemento dialog em HTML, mas infelizmente ele tem problemas massivos de acessibilidade . Com o Shadow DOM, gerenciar o foco também não é fácil . Podemos usar o inerte atributo para remover e, em seguida, restaurar a capacidade dos elementos interativos de serem descobertos e focalizados. Para navegadores mais antigos, podemos usar inert polyfills do Google Chrome e do WICG .

Por enquanto, podemos dar uma olhada no a11y-dialog de Kitty Giraudel, um script leve (1,6 KB) que captura e restaura o foco, alterna os atributos aria– * , fecha a caixa de diálogo no clique de sobreposição e Escape e ainda permite que você aproveite o elemento dialog nativo, se desejado. Uma nova versão 7 está atualmente em beta (mas deve ser lançada em breve), e você também pode usar seus sabores React e Vue.js: react-a11y-dialog e vue-a11y-dialog .

Além disso, você também pode pesquisar Parvus , um simples e acessível , lightbox de imagem de código aberto sem dependências. Em um cenário típico, teríamos uma imagem vinculada a uma versão maior da imagem. Com o Parvus, é suficiente adicionar uma classe .lightbox ao link que envolve uma imagem, e o script faz todo o resto para você automaticamente.

Guias acessíveis

Sua interface pode usar painéis de guias, mas para manter o conteúdo dessas guias acessível aos usuários do teclado e usuários de leitores de tela, precisamos de uma exposição muito cuidadosa e deliberada do design visual e da semântica ARIA. Em Tabbed Interfaces , Heydon Pickering entra em detalhes tentando descobrir a solução certa para respeitar o comportamento do teclado e o gerenciamento de foco. Ele sugere aprimorar seções progressivamente em painéis de guia ( exemplo de código ) (obrigado a Daniela Kubesch pela dica! ).

Como observa Adam Silver, os usuários de leitores de tela menos experientes podem não saber usar as teclas de seta para alternar entre guias. Há um argumento para tornar todas as guias focalizáveis ​​na sequência normal de guias com pouca intervenção dos desenvolvedores para alterar o forma como as guias funcionam por meio do teclado.

Como alternativa, TabPanelWidget é uma solução responsiva e acessível para guias. Ele se baseia em HTML semântico antigo e simples e se transforma em um acordeão sempre que as guias não cabem totalmente (graças ao ResizeObserver , mas há um polyfill para navegadores que ainda não oferecem suporte).

O script não é apenas uma solução semântica e acessível, mas também ágil e versátil para ajudá-lo a criar widgets Tabpanel e sanfona para a web. É amigável ao teclado e disponível como uma biblioteca JS vanilla (ou como um widget para Vue, React e Angular).

Chaves de alternância acessíveis

Sempre que nossos formulários fornecem uma seleção binária para nossos clientes-liga/desliga, modo escuro/claro etc.-podemos usar um botão de alternância. A troca precisa servir a alguns propósitos: precisa explicar claramente a seleção atual (e isso não é tão comum assim!), Precisa explicar que existem duas opções e precisa ser óbvio o suficiente para que os clientes entender como alternar entre eles. Quando Sara Soueidan estava estudando como construir um botão de alternância, ela, claro, passou um bom tempo procurando como construir um botão de alternância acessível .

A solução de Sara usa dois botões de opção, cada um com seu próprio rótulo, anunciados para tecnologias assistivas como um par de opções separadas, acessíveis via teclado, e não tem requisitos ARIA ou JS adicionais para funcionar. O resultado é um exemplo de código de alternância de tema , e você também pode dar uma olhada no exemplo de código .

Preenchimento automático acessível

Sempre que você precisa lidar com um conjunto de dados maior, seja um mapa, uma visualização de dados ou apenas um seletor de país na finalização da compra, o preenchimento automático pode aumentar a entrada do cliente de forma massiva. Mas, da mesma forma que ajuda com a entrada, também precisa ajudar a anunciar as opções e a seleção para os usuários de leitores de tela.

Gov.uk, a equipe por trás do Government Digital Service no Reino Unido, abriu o accessible-autocomplete (entre muitas outras coisas ), um componente JavaScript que segue as práticas recomendadas WAI-ARIA. Você pode escolher quando começar a exibir sugestões e permite exibir o menu como uma sobreposição absolutamente posicionada, ou selecionar a primeira sugestão por padrão. A equipe também fornece uma página de demonstração , com uma dúzia de exemplos e implementações de preenchimento automático acessíveis.

Bibliotecas de componentes acessíveis

Embora muitas das bibliotecas de componentes que criamos estejam tentando cobrir todas as suspeitas usuais (os acordeões, as mesas, os carrosséis, os menus suspensos, junto com tipografia, cores e sombras de caixa), No Style Design System de Adam Silver é focado principalmente em acessibilidade e formulários da web.

Como um sistema criado e usado em seu livro sobre Form Design Patterns , a biblioteca de Adam fornece um conjunto de componentes acessíveis para tudo, desde o preenchimento automático, caixas de seleção e senha revelam a rádios, caixas de seleção e steppers. A maioria deles tem um estilo CSS mínimo com marcação limpa e acessível.

E se você precisar de componentes um pouco mais avançados, Componentes inclusivos de Heydon Pickering-mencionamos alguns exemplos acima-está à sua espera: com tutoriais abrangentes sobre cartões acessíveis, tabelas de dados, notificações, controles deslizantes, interfaces com guias, dicas de ferramentas, menus e alternadores.

Visualizações de dados acessíveis

As visualizações de dados geralmente contêm informações importantes sobre as quais os usuários devem agir. Embora às vezes possamos usar números grandes com frases curtas, as visualizações podem ajudar a entender desenvolvimentos e uma grande quantidade de informações mais rapidamente. Mas isso significa que a informação tem que ser de fácil compreensão, e isso se refere principalmente à seleção de cores, forma de apresentação da informação, rótulos, legendas, bem como padrões e formas. Em sua série de artigos sobre acessibilidade em visualizações de dados , Sarah L. Fossheim destaca diretrizes e recursos úteis sobre o tópico, junto com exemplos, o que fazer e o que não fazer para ter em mente ao projetar visualizações de dados acessíveis.

Sarah sugere que você não dependa da cor para explicar os dados e evite cores brilhantes e de baixo contraste em geral. Usar padrões e formas além da cor é útil, e uma linguagem clara, rótulos e legendas podem ajudar a explicar claramente a visualização dos dados. Cada artigo está repleto de exemplos e recursos para leitura adicional. Também vale a pena verificar: a revisão das visualizações de dados das eleições presidenciais dos EUA de Sarah ( graças a Stephanie Eckles pela dica! ).

Sistemas de cores acessíveis

Obter o contraste de cores correto é uma parte essencial para garantir que não apenas as pessoas com deficiência visual possam usar seu produto com facilidade, mas também todas as outras pessoas quando estiverem em ambientes com pouca luz ou usando telas mais antigas. No entanto, se você já tentou criar um sistema de cores acessível, provavelmente sabe que isso pode ser um grande desafio.

A equipe do Stripe recentemente decidiu enfrentar o desafio e redesenhar seu sistema de cores existente. Os benefícios que ele deve fornecer prontos para uso: passar pelas diretrizes de acessibilidade, usar tons claros e vibrantes que os usuários possam distinguir facilmente uns dos outros e ter um peso visual consistente sem que uma cor pareça ter prioridade sobre a outra. Se você está curioso para saber mais sobre a abordagem deles, a postagem do blog deles em sistemas de cores acessíveis fornecerá informações valiosas percepções.

Paletas de cores acessíveis

Encontrar a tonalidade ou tonalidade perfeita de uma cor não é apenas uma questão de gosto, mas também de acessibilidade. Afinal, se faltar contraste de cor, um produto pode, na pior das hipóteses, até tornar-se inutilizável para pessoas com deficiência visual. WCAG 2.0 nível AA requer uma taxa de contraste de pelo menos 4.5: 1 para texto normal .) E 3: 1 para texto grande, e WCAG 2.1 requer uma taxa de contraste de pelo menos 3: 1 para gráficos e componentes de IU (como bordas de entrada de formulário). AAA requer uma taxa de contraste de pelo menos 7: 1 para texto normal e 4,5: 1 para texto grande. Um verificador de contraste muito detalhado para ajudá-lo a detectar possíveis armadilhas com antecedência vem de Gianluca Gini: Geenes .

A ferramenta permite que você mexa nos intervalos de matiz e saturação e aplique as paletas de cores a uma das três maquetes de IU selecionáveis. Uma vez aplicado, você pode desencadear diferentes tipos de deficiência visual para ver como as pessoas afetadas veem as cores e, por fim, tomar uma decisão informada sobre os melhores tons para sua paleta. Para usar as cores imediatamente, basta copiar e colar o código ou exportá-las para o Sketch. Você também pode emular deficiências de visão no DevTools .

Selecionadores de data acessíveis

Existem dezenas de bibliotecas de seleção de data por aí, mas é sempre bom ter ferramentas confiáveis ​​que funcionem em todos os navegadores, não tenham dependências pesadas, sejam escritas razoavelmente bem e atendam a todos os principais requisitos de acessibilidade.

Duet Date Picker é exatamente assim. É um selecionador de data compatível com WCAG 2.1 acessível que pode ser implementado e usado em qualquer estrutura JavaScript ou em nenhuma estrutura. Ele vem com uma funcionalidade integrada que permite definir uma data mínima e máxima permitida e pesa cerca de 10kb com formato reduzido e Gzip (isso inclui todos os estilos e ícones).

Se precisar de uma alternativa, verifique React Dates , uma biblioteca lançada pela Airbnb otimizada para internacionalização, ao mesmo tempo ser acessível e compatível com dispositivos móveis.

Gráficos de dados acessíveis

As visualizações de dados são uma ótima maneira de destacar as informações. No entanto, eles também vêm com seus próprios desafios de acessibilidade. Quando Sara Soueidan se juntou à SuperFriendly para criar um microssite acessível para o relatório anual da Khan Academy, ela queria ter certeza de que a forma como os dados são apresentados e implementados é o mais acessível possível, independentemente de como o visitante explora o site. A solução dela: SVG.

Em um estudo de caso sobre gráficos de dados acessíveis , Sara resumiu tudo que você precisa considerar quando quiser tornar seus gráficos e visualizações SVG acessíveis-começando com a etapa mais importante de escolher uma técnica de incorporação apropriada. Também cobre por que você deve evitar tentar tornar um gráfico SVG acessível usando funções ARIA e por que Sara não escolheu

para incorporá-los. Um guia de referência fantástico. Mais: especialmente em gráficos, também poderíamos usar rótulos de texto mais acessíveis , e Sara os cobre separadamente artigo também.

Links e botões de ícones acessíveis

Não é incomum ter um link ou botão que visualmente não tem texto, mas consiste apenas em um ícone-uma barra de navegação compacta, por exemplo, ou ícones sociais. Mas como você tem certeza de que esses tipos de links de ícone são totalmente acessíveis? Acontece que não é tão simples como se poderia pensar.

Para mostrar como podemos fazer melhor, Kitty Giraudel dedicou um artigo” Links de ícones acessíveis “para o problema. Eles usam um link de ícone que consiste em um SVG com o icônico pássaro do Twitter para ilustrar o ponto e mostram passo a passo como torná-lo acessível: com um texto descritivo que está visualmente oculto e, em seguida, removendo a marcação SVG da árvore de acessibilidade com aria-hidden e, finalmente, corrigindo o fato de que os elementos svg podem ser focados no Internet Explorer adicionando o atributo focusable . No final do artigo, Kitty também mostra como transformar tudo isso em um pequeno componente React .

Um pequeno detalhe que fará uma grande diferença para muitos usuários.

Em Criando botões de ícone acessíveis e Inclusively Hidden , Sara Soueidan e Scott O’Hara analisam todas as complexidades e detalhes dos botões de ícone, explorando uma série de técnicas para faça funcionar. Sara e Scott exploram várias técnicas, sugerindo o uso de uma técnica apropriada para texto visualmente oculto acessível-o texto que estará visualmente oculto, mas acessível para leitores de tela. Isso pode ser feito com uma classe de utilitário .sr-only , ou hidden e aria-labelledby , ou aria-label sozinho. Sara não recomendaria usar o ícone SVG em si para fornecer um rótulo para o botão, quando posso fornecer um no próprio botão diretamente.

Em geral, porém, ainda há um pouco de confusão sobre qual elemento usar para a interação do usuário: quando usamos links e quando usamos botões? Marcy Sutton escreveu um artigo detalhado em Links vs. botões em aplicativos modernos . Com um link, o visitante navega para um novo recurso, retirando-o do contexto atual. Mas um botão indica uma mudança na interface.

Marcy descreve casos de uso para links e botões em aplicativos de página única, mostrando que um botão é um elemento perfeito para abrir uma janela modal, disparar um pop-up, alternar uma interface ou reproduzir conteúdo de mídia. Você também pode verificar o artigo de Vadim Makeev em “ Quando um botão não é um botão? ”.

Dicas e alternâncias acessíveis

Um componente intimamente relacionado aos botões de ícone é uma dica de ferramenta. Literalmente"dicas para ferramentas", são pequenos pedaços de informação que explicam a finalidade de um controle, ou um visual, que de outra forma poderia ser mal interpretado. Toda vez que queremos explicar por que precisamos de uma determinada informação pessoal em um checkout, é aí que provavelmente usaremos uma boa e velha dica. Então, como os acertamos?

As Dicas de ferramentas e alternâncias de Heydon Pickering fornecem uma visão geral completa de praticamente tudo o que é necessário para construir uma dica de ferramenta acessível. Isso significa decidir se o conteúdo da dica deve ser fornecido como rótulo ou descrição e escolher as propriedades ARIA de acordo, sem depender dos atributos title e evitando colocar conteúdo interativo, como fechar e confirmar botões ou links em dicas de ferramentas.

Notas de rodapé e notas laterais acessíveis

Em sua essência, as notas de rodapé não são muito mais do que links de salto-links para a descrição de uma fonte, colocados na parte inferior do documento, ou na barra lateral, ou aparecendo inline, um little acordeão . No entanto, como notas de rodapé são links de salto, precisamos garantir que os usuários de leitores de tela entendam quando os links são referências a notas de rodapé-e podemos fazer isso com o atributo aria-describeby . O contador para cada link seria implementado por meio de um contador CSS. Com : target , destacamos a linha para a qual o leitor saltou e fornecemos um link de volta para o local real da nota de rodapé no conteúdo.

Kitty Giraudel entra em detalhes explicando como construir notas de rodapé acessíveis, e você também pode
verifique como construir notas de rodapé acessíveis com React e usar react-a11y-footnotes para construí-las no React with Eleventy (obrigado a Kitty Giraudel pela dica!) .

SVGs acessíveis

Falando sobre SVGs: o que podemos fazer com SVGs hoje vai muito além das formas básicas de antigamente. Não apenas podemos descrever ícones SVG, mas também estilizá-los e animá-los. Se a verdadeira inclusão está além dos padrões-que outros fatores devemos considerar ao projetar e desenvolver SVGs acessíveis?

Essa é exatamente a pergunta que Carie Fisher está respondendo em seu artigo sobre SVGs acessíveis: Inclusão além dos padrões . No artigo, Carie dá uma olhada mais de perto na cor e contraste SVG, modos claro e escuro, animação SVG, movimento reduzido e muitas ferramentas focadas em acessibilidade. Você também encontrará demonstrações e exemplos de código nos artigos, junto com explicações detalhadas e dicas para leitura adicional.

E se você quiser se aprofundar no mundo complexo dos componentes acessíveis-não apenas relacionados a SVGs- acabamos de publicar o artigo de Carie em padrões de código acessíveis .

Estilos : focus melhores

Cada navegador tem estilos de foco padrão, mas fora da caixa, eles não são muito acessível . O objetivo de : focus é fornecer orientação ao usuário sobre onde exatamente eles estão no documento e os ajudam a navegar por ele. Para conseguir isso, precisamos evitar um foco que é muito sutil ou nem um pouco visível. Na verdade, remover o contorno é uma má ideia , pois remove qualquer indicação visível de foco para usuários de teclado. Quanto mais óbvio for o foco, melhor.

Existem maneiras de projetar melhores estilos : focus . Em seu artigo Dicas para estilos de foco , Nic Chan destaca um algumas dicas úteis sobre como melhorar os estilos de foco com melhor acessibilidade e um pouco de preenchimento, deslocamento e contornos adequados. Precisa de mais diversão com os estilos : focus ? Lari Maza também protege .

Também podemos usar : focus-within para estilize o elemento pai de um elemento em foco e : focus-visible para não mostrar estilos de foco ao interagir com um mouse/ponteiro se causar algum problema em seu design.

É importante considerar as questões de acessibilidade em torno do : focus-visible : como Hidde de Vries observou , nem todas as pessoas que dependem de estilos de foco usam um teclado, e fazer com que os estilos de foco apenas para teclado também diminua a capacidade dos usuários de mouse, pois o foco também indica que algo é interativo (graças a Jason Webb pelo dica!) .

Finalmente, é importante notar que, mais recentemente, Chrome, Edge e outros navegadores baseados em Chromium parou de exibir um indicador de foco ( anel de foco ) quando o usuário clica ou toca em um botão (obrigado a Kim Johannesen pela dica!) .

Estilos de formulário acessíveis em vários navegadores

Você já teve dificuldade em ocultar e estilizar caixas de seleção e botões de opção personalizados? E quanto aos estilos de seleção personalizados? Ou talvez um menu de navegação suspenso acessível? Temos a tendência de construir e reconstruir os mesmos componentes o tempo todo, então vamos corrigi-los de uma vez por todas.

O , com variantes editáveis ​​e multisseleção, sua usabilidade comparativa (com dados!) e recomendações práticas de como acertar.

Destaques do

Soluções CSS modernas para problemas CSS antigos de Stephanie Eckles muitas técnicas modernas úteis para resolver muitos desafios, mas alguns artigos de sua série são dedicados a formulários: Caixas de seleção CSS personalizadas , botões de opção com estilo, seleção de estilos, entradas e áreas de texto.

Além disso, Stephanie mostra como construir um (quase) acessível apenas por CSS dropdown, and on her blog, Sara Soueidan goes into detail explaining how to inclusively hide and style checkboxes and radio buttons. Bonus: Adrian Roselli’s code examples provides additional insights into under-engineered toggles. Fantastic resources to use right away and style forms accessibly.

Accessible Checkboxes And Radio Buttons

The good ol’ issue: how do we style checkboxes and radio-buttons to ensure that they look, well, at least similar, in most browsers — while ensuring that they stay accessible as well? In her article, Sara Soueidan covers a few techniques to keep in mind to achieve the desired result.

Sara covers the different techniques for hiding elements, how each of them affects the accessibility of the content, and how to visually hide them, so they can be replaced with a more styleable alternative: the SVG.

When hiding an interactive element, we need to make sure we choose a hiding technique that keeps it screen reader-accessible, position it on top of whatever is visually replacing it, so that a user navigating by touch can find it where they expect to, and then make it transparent. Sara also provides live demos that we can use right away, along with useful references to articles for further reading.

Accessible Carousels and Content Sliders

An accessible carousel sounds a bit like oxymoron — while there are plenty of scripts that provide the functionality, only few of them are accessible. Now there are, of course, accessible range sliders, but carousels are a slightly different component. As Alison Walden notices in her article on “If you must use a carousel, make it accessible”, the sighted person is not forced to use the carousel at all, but keyboard users are forced to navigate through the carousel in its entirety. At the very least, a hidden “skip” link could appear on keyboard focus. Also, once the person has tabbed through all the panel sets, focus should move to the next interactive element that follows the carousel.

Heydon Pickering suggests to use list markup to group the slides together, include previous and next buttons, snap points, and use invisible linked items removed from focus. The article also provides a code sample which uses IntersectionObserver, so you might need a polyfill for it.

Accessible Tap/Click Menu

Is it still a good idea to design mega-drop-downs opening on hover? Probably not. Hover menus have plenty of usability and accessibility issues, as they are inconsistent, confusing and of course need an alternative solution for mobile devices. In fact, Mark Root-Wiley suggests that it’s about time to drop hover menus in favor of unambiguous and accessible click menus.

In his article, Mark goes into fine details of how to build an accessible click menu, along with useful pointers and references from his research. The idea is to start building the menu as a CSS-only hover menu that uses li:hover > ul and li:focus-within > ul to show the submenus. Then, we use JavaScript to create the