Um guia completo para componentes front-end acessíveis

Índice

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

• : estilos de foco
• autocompletar
• botões
• cartas
• carrosséis
• botões "fechar"
• controles deslizantes de conteúdo
• caixas de seleção
• sistemas de cores
• paletas de cores
• histórias em quadrinhos
• bibliotecas de componentes
• solicitações de consentimento de cookies
• navegação da página atual
• modo escuro
• gráficos de dados
• visualizações de dados
• selecionadores de data
• botões desativados
• divisores
• estilos de formulário
• notas de rodapé
• escondendo conteúdo
• links de ícones
• entradas
• navegação do teclado
• links
• roladores de mídia
• modais
• menu de navegação
• campos de senha
• prefere-reduzido-*
• botões do rádio
• esqueletos
• links “pular”
• SVGs
• abas
• mesas
• testando
• acessibilidade de componentes de terceiros
• interruptores de alternância
• Ferramentas
• dicas de ferramentas
• players de vídeo/áudio

Acessível :focus

Todo navegador tem estilos de foco padrão, mas prontos para uso, eles não são muito acessíveis. O objetivo do :focus é fornecer orientação ao usuário sobre onde exatamente ele está no documento e ajudá-lo a navegar por ele. Para conseguir isso, precisamos evitar um foco muito sutil ou não 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 estilos de :focus melhores. Em seu artigo Dicas para estilos de foco , Nic Chan destaca algumas dicas úteis sobre como melhorar os estilos de foco com melhor affordance e um pouco de preenchimento, deslocamento e contornos adequados. Precisa de mais diversão com os estilos :focus ? Lari Maza também te protege.

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

É importante considerar as preocupações de acessibilidade em torno :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 teclado tirem uma vantagem para usuários de mouse também, pois o foco também indica que algo é interativo (obrigado a Jason Webb pela dica!) .

Por fim, vale a pena notar que, mais recentemente, o Chrome, Edge e outros navegadores baseados no Chromium pararam de exibir um indicador de foco (anel de foco ) quando o usuário clica ou toca em um botão (graças a Kim Johannesen pela dica!) .

Autocompletar acessível

Toda vez 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 no checkout, o preenchimento automático pode aumentar enormemente a entrada do cliente. Mas, assim como ajuda na entrada, também precisa ajudar a anunciar as opções e a seleção para os usuários do leitor de tela.

Gov.uk, a equipe por trás do Government Digital Service no Reino Unido, tem código aberto de autocompletar acessível (entre muitas outras coisas), um componente JavaScript que segue as melhores práticas 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.

Botões Acessíveis e Links de Ícones

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ê garante que esses tipos de links de ícones sejam totalmente acessíveis? Como se vê, 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 a edição. Eles usam um link de ícone que consiste em um SVG com o icônico pássaro do Twitter para ilustrar o ponto e mostra passo a passo como torná-lo acessível: com um texto descritivo que fica visualmente oculto, 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 enorme diferença para muitos usuários.

Em Criando botões de ícone acessíveis e inclusive ocultos, Sara Soueidan e Scott O'Hara abordam todos os meandros e detalhes dos botões de ícone, explorando uma série de técnicas para fazê-lo 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 será ocultado visualmente, mas acessível aos leitores de tela. Isso pode ser feito com uma classe utilitária .sr-only , ou hidden e aria-labelledby , ou apenas aria-label . Sara não recomendaria usar o próprio ícone SVG para fornecer um rótulo para o botão quando eu puder 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 sobre Links vs. Botões em Aplicativos Modernos. Com um link, o visitante navega para um novo recurso, afastando-o do contexto atual. Mas um botão solicita 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, acionar um pop-up, alternar uma interface ou reproduzir conteúdo de mídia. Você também pode conferir o artigo de Vadim Makeev sobre “Quando um botão não é um botão?”.

Botões desabilitados acessíveis

Tornou-se bastante comum para formulários web longos manter o botão “Continuar” desativado até que o cliente forneça todos os dados corretamente. Esse comportamento atua como um indicador de que algo está errado com o formulário e não pode ser preenchido sem revisar a entrada. Isso funciona se a validação em linha para cada campo de entrada estiver funcionando bem e não funcionar quando estiver com falhas ou bugs.

Em “Botões desativados sugam”, Hampus Sethfors destaca as desvantagens dos botões desativados. Com eles no lugar, comunicamos que algo está errado, mas não explicamos realmente o que está errado ou como corrigi-lo. Portanto, se o cliente ignorou uma mensagem de erro - seja em um formulário longo no computador ou até mesmo em um formulário curto no celular, eles serão perdidos. De muitas maneiras, manter os botões ativos e comunicar erros é mais eficiente.

E se não for possível, pelo menos forneça uma saída com um botão “Não consigo preencher o formulário, por favor me ajude”, para que o suporte ao cliente possa entrar em contato com os clientes caso tenham problemas. Se você precisar de uma atualização mais detalhada em formulários da web, “Form Design From One to Zero” o manterá ocupado.

Em seu artigo sobre CSS-Tricks, Sandrina Pereira explora a questão de que a forma comum de usar <button disabled> impede não apenas o clique, mas também o foco. Embora isso possa parecer inofensivo, causa confusão para os usuários de leitores de tela. Sua sugestão: a troca desabilitada por disabled por aria-disabled torna a experiência mais agradável, pois o botão ainda pode ser acessado pelo foco e também pode acionar uma dica de ferramenta - embora marcado como desabilitado.

Cartões acessíveis

Os cartões oferecem muitas vantagens. Eles funcionam bem em dispositivos móveis, fornecem grandes áreas de clique e o fato de poderem ser empilhados horizontalmente e verticalmente facilita muitas decisões de layout. No entanto, não há um padrão de acessibilidade a ser seguido, nenhum elemento <card> ou um padrão de design ARIA. Em vez disso, as possíveis barreiras de acessibilidade que você pode encontrar dependem da finalidade e do conteúdo do cartão. Em sua coleção de componentes inclusivos, Heydon Pickering analisa algumas permutações de um componente de cartão simples e como manter o equilíbrio entre a estrutura HTML sólida e a interação ergonômica.

Adrian Roselli também escreveu um ótimo artigo que aborda um aspecto dos cartões que pode facilmente se transformar em sua principal armadilha de acessibilidade: grandes áreas de clique. Eles podem criar controles extremamente detalhados quando um usuário usa um leitor de tela para navegar neles; para usuários de voz, pode ser confuso o que dizer para selecionar a chamada para ação. Adrian demonstra como um pouco de planejamento pode resolver esse problema.

Outro mergulho profundo em componentes de cartões acessíveis vem da equipe da Nomeensa: em sua postagem no blog, eles analisam problemas comuns em torno de cartões e bloqueiam links e compartilham dicas valiosas para tornar seus cartões mais acessíveis - reordenando o conteúdo para melhorar semântica, por exemplo.

Carrosséis acessíveis e controles deslizantes de conteúdo

Um carrossel acessível soa um pouco como oxímoro - embora existam muitos scripts que fornecem a funcionalidade, apenas alguns deles são acessíveis. Agora existem, é claro, controles deslizantes de alcance acessíveis, mas os carrosséis são um componente um pouco diferente. Como Alison Walden observa em seu artigo sobre “Se você deve usar um carrossel, torne-o acessível”, a pessoa que enxerga não é obrigada a usar o carrossel, mas os usuários de teclado são obrigados a navegar pelo carrossel em sua totalidade. No mínimo, um link "pular" oculto pode aparecer no foco do teclado. Além disso, uma vez que a pessoa tenha percorrido todos os conjuntos de painéis, o foco deve passar para o próximo elemento interativo que segue o carrossel.

Heydon Pickering sugere usar a marcação de lista para agrupar os slides, incluir botões anterior e seguinte, pontos de encaixe e usar itens vinculados invisíveis removidos do foco. O artigo também fornece um exemplo de código que usa IntersectionObserver, portanto, você pode precisar de um polyfill para ele.

Botões de Fechar Acessíveis

Os botões "Fechar" estão por toda parte - em modais, anúncios, mensagens de confirmação, avisos de cookies e quaisquer sobreposições que aparecerão em sua interface. Infelizmente, a funcionalidade geralmente é limitada a usuários de mouse, deixando de fora os usuários de leitores de tela e usuários de teclado. Podemos consertá-lo.

Em “Botões de fechamento acessíveis”, Manuel Matuzovic entra em detalhes profundos, destacando 11 exemplos e padrões de botões de fechamento inacessíveis, bem como 5 exemplos de botões de fechamento que funcionam bastante bem. A maneira mais fácil de resolver o problema é fornecer um botão com texto visível e ícone apenas visualmente acessível e garantir que a descrição dos leitores de tela não seja poluída pela descrição do ícone. Manuel também fornece exemplos de código de 5 botões de fechamento que você pode aplicar ao seu trabalho imediatamente.

Caixas de seleção e botões de opção acessíveis

O bom e velho problema: como estilizar caixas de seleção e botões de opção para garantir que eles pareçam, bem, pelo menos semelhantes, na maioria dos navegadores - enquanto garantimos que eles permaneçam acessíveis também? No seu artigo, Sara Soueidan aborda algumas técnicas a ter em conta para alcançar o resultado pretendido.

Sara aborda as diferentes técnicas para ocultar elementos, como cada uma delas afeta a acessibilidade do conteúdo e como ocultá-los visualmente, para que possam ser substituídos por uma alternativa mais estilizada: o SVG.

Ao ocultar um elemento interativo, precisamos ter certeza de escolher uma técnica de ocultação que o mantenha acessível ao leitor de tela, posicioná-lo em cima de qualquer coisa que o esteja substituindo visualmente, para que um usuário navegando pelo toque possa encontrá-lo onde espera, e, em seguida, torná-lo transparente. Sara também fornece demonstrações ao vivo que podemos usar imediatamente, juntamente com referências úteis a artigos para leitura adicional.

Sistemas de cores acessíveis

Obter o contraste de cores correto é uma parte essencial para garantir que não apenas pessoas com deficiência visual possam usar facilmente seu produto, mas também todos os outros 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 da Stripe decidiu recentemente enfrentar o desafio e redesenhar seu sistema de cores existente. Os benefícios que ele deve oferecer imediatamente: passar 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ê estiver curioso para saber mais sobre a abordagem deles, a postagem no blog deles sobre sistemas de cores acessíveis fornecerá informações valiosas.

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 cores, um produto pode, na pior das hipóteses, até se tornar 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 interface do usuário fronteiras). 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 antes do tempo vem de Gianluca Gini: Geenes.

A ferramenta permite mexer com faixas de matiz e saturação e aplicar as paletas de cores a um dos três modelos de interface do usuário selecionáveis. Uma vez aplicado, você pode acionar diferentes tipos de deficiências visuais para ver como as pessoas afetadas veem as cores e, finalmente, tomar uma decisão informada sobre os melhores tons para sua paleta. Para usar as cores imediatamente, basta copiar e colar o código delas ou exportá-las para o Sketch. Você também pode emular deficiências de visão no DevTools.

Entendendo as deficiências visuais

Você provavelmente já ouviu falar de protanopia, deuteranopia ou glaucoma antes. Mas como as pessoas com deficiência visual como essas realmente veem suas combinações de cores? A ferramenta Who Can Use de Corey Ginnivan simula isso para você.

Insira um plano de fundo e uma cor de texto e a ferramenta calcula a taxa de contraste, bem como a classificação WCAG para você. Para humanizar esses números bastante abstratos, Who Can Use também mostra uma lista de diferentes tipos de visão, quantas pessoas são afetadas por eles e, claro, a simulação de sua combinação de cores para cada tipo. Um grande ajudante para entender melhor o efeito da cor.

Quadrinhos acessíveis

Quando usamos formas e layouts um pouco mais complexos na Web, às vezes parece muito mais fácil salvá-lo como uma imagem de primeiro plano ou de fundo e exibir imagens diferentes em telas pequenas e grandes. Isso vale para tabelas e gráficos complicados, bem como bons e velhos quadrinhos com balões de fala, mas e se pudéssemos re-imaginar a experiência completamente?

Comica11y é um experimento de Paul Spencer que visa alcançar uma experiência de leitura de quadrinhos online com tudo incluído. E se pudéssemos ter diferentes modos de leitura para os quadrinhos, por exemplo, com legendas ocultas, gerenciamento de foco adequado para navegar entre painéis, modo de alto contraste, filtros de daltonismo SVG, bolhas programáticas, texto selecionável e traduzível, suporte a LTR e RTL e até tamanhos de fonte ajustáveis? Uma iniciativa maravilhosa que mostra até onde podemos levar os desafios da interface do usuário e usar a web para aprimorar muito a experiência.

Bibliotecas de componentes acessíveis

Enquanto muitas das bibliotecas de componentes que criamos estão tentando cobrir todos os suspeitos usuais (os acordeões, as mesas, os carrosséis, os drop-downs, junto com a tipografia, cores e sombras de caixa), o No Style Design System de Adam Silver está focado principalmente em torno de acessibilidade e formulários da web.

Como um sistema criado e usado em seu livro sobre Padrões de Design de Formulários, a biblioteca de Adam fornece um conjunto de componentes acessíveis para tudo, desde preenchimento automático, caixas de seleção e revelação de senha até 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, os Componentes Inclusivos de Heydon Pickering - mencionamos alguns exemplos acima - estão à sua disposição: com tutoriais abrangentes sobre cartões acessíveis, tabelas de dados, notificações, controles deslizantes, interfaces com guias, dicas de ferramentas, menus e alternâncias.

Solicitações de consentimento de cookies acessíveis

Sobreposições e pop-ups são sempre problemáticos. Mas especialmente para usuários de leitores de tela, às vezes esses prompts são incrivelmente difíceis de lidar para definir qualquer configuração ou até mesmo confirmar o uso de cookies no site. Em sua palestra de 15 minutos sobre “Leitores de tela e consentimentos de cookies”, Leonie Watson entra em detalhes explicando as experiências ruins que os pop-ups de conformidade têm para acessibilidade. Em alguns casos, os usuários passam pelos prompts de consentimento sem estar cientes deles, em outros, os prompts são impossíveis de aceitar, resultando na incapacidade de usar o site.

Então, como podemos torná-los melhores? Em banners de cookies e acessibilidade, Sheri Byrne-Haber destaca problemas comuns que os prompts de cookies costumam ter: desde como eles aparecem visualmente até as armadilhas de foco, a aparência na ordem de tabulação, o tipo de aceitação e formatos alternativos de divulgação de consentimento. Quentin Bellanger fornece um exemplo de código básico de um modal de consentimento de cookies e um tutorial junto com ele. Também existem soluções gratuitas de código aberto: Osano Cookie Consent e cookie-consent-box, mas podem exigir algum trabalho de acessibilidade.

Estados de navegação da página atual acessíveis

A cor é uma maneira eficaz de transmitir significado, mas é sempre uma boa ideia ter um segundo indicador visual para pessoas com baixa visão ou deficiências de visão de cores também. Um ícone, por exemplo. Callum Hart conta com uma combinação de cor/ícone para indicar a página em que um usuário está atualmente. Em sua postagem no blog “Um estado de navegação de página atual acessível”, ele compartilha informações valiosas sobre as considerações por trás dessa decisão de design.

Desde inserir o ícone SVG no HTML e usar aria-hidden para escondê-lo de tecnologias assistivas até usar ems em vez de pixels e transmitir contexto adicional para usuários de leitores de tela com o atributo aria-current , a postagem fornece uma visão detalhada de como para um estado de navegação verdadeiramente acessível.

Um guia completo para o modo escuro na web

O modo escuro está rapidamente se tornando uma preferência do usuário com a Apple, Windows e Google implementando-o em seus sistemas operacionais. Mas e o modo escuro na web? Adhuham escreveu um guia abrangente para o modo escuro que investiga diferentes opções e abordagens para implementar um design de modo escuro na web.

Para começar, o guia analisa as considerações técnicas que a implementação de um modo escuro envolve, abrangendo diferentes abordagens para alternar os temas e como armazenar as preferências de um usuário para que sejam aplicadas de forma consistente em todo o site e nas visitas subsequentes. Dicas para lidar com estilos de agente de usuário com a metatag color-scheme ajudam a evitar possíveis situações de FOIT.

As considerações de design também são abordadas, é claro, com dicas valiosas para obter imagens, sombras, tipografia, ícones e cores prontas para o modo escuro. Enquanto estiver nele: para garantir que não quebramos involuntariamente o alto contraste no modo, dê uma olhada em Styling for Windows High Contrast mode ( obrigado pela dica, Courtney Heitman! ).

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 uniu à SuperFriendly para criar um microsite 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 o 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 aborda por que você deve evitar tentar tornar um gráfico SVG acessível usando funções ARIA e por que Sara não escolheu <figure> 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 também os aborda em um artigo separado.

Visualizações de dados acessíveis

As visualizações de dados geralmente contêm informações importantes sobre as quais os usuários precisam agir. Embora às vezes possamos usar grandes números com frases curtas, as visualizações podem ajudar a entender os desenvolvimentos e a grande quantidade de informações mais rapidamente. Mas isso significa que a informação tem que ser fácil de entender, e isso se refere especialmente à seleção de cores, a forma como a informação é apresentada, 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, juntamente com exemplos, o que fazer e o que não fazer ao projetar visualizações de dados acessíveis.

Sarah sugere não confiar na cor para explicar os dados e evitar cores brilhantes e de baixo contraste em geral. Usar padrões e formas além da cor é útil, e linguagem clara, rótulos e legendas podem ajudar a explicar claramente a visualização de dados. Cada artigo é embalado com muitos exemplos e recursos para leitura adicional. Também vale a pena conferir: a revisão de Sarah das visualizações de dados da eleição presidencial dos EUA ( obrigada a Stephanie Eckles pela dica! ).

Selecionadores de data acessíveis

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

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

Se você precisar de uma alternativa, confira o React Dates, uma biblioteca lançada pelo Airbnb que é otimizada para internacionalização, além de ser acessível e compatível com dispositivos móveis.

Estilizando divisores horizontais

Os elementos <hr> geralmente são bem chatos. Linhas simples e horizontais que fornecem uma quebra visual e dividem o conteúdo. Mas você sabia que eles podem ser estilizados usando CSS e SVG para dar um toque pessoal ao seu conteúdo e design?

Sara Soueidan fez exatamente isso: Os <hr> s em seu site pessoal não são exibidos como linhas chatas, em vez disso, você verá pássaros sentados em um fio. Para ajudá-lo a tornar seus <hr> s mais agradáveis ​​também, Sara resumiu como ela estilizou linhas horizontais com a ajuda de alguma magia CSS e SVG. Ela também procura maneiras de melhorá-los ainda mais para que se adaptem a vários contextos, mantendo-se semânticos e acessíveis. Um pequeno detalhe legal.

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

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? Nós tendemos a construir e reconstruir os mesmos componentes o tempo todo, então vamos acertá-los de uma vez por todas.

“<select> your poison” de Sarah Higley é um mergulho profundo em duas partes abrangente em todos os desafios e complexidades de estilizar o elemento <select> , com variantes editáveis ​​e multisseleção, sua usabilidade comparativa (com dados!) e recomendações práticas de como acertar.

Stephanie Eckles' Modern CSS Solutions for Old CSS Problems destaca 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 estilizados, estilos selecionados, entradas e áreas de texto.

Em seu blog, Sara Soueidan explica detalhadamente como ocultar e estilizar caixas de seleção e botões de opção. Bônus: os exemplos de código de Adrian Roselli fornecem informações adicionais sobre alternâncias com pouca engenharia. Recursos fantásticos para usar imediatamente e estilizar formulários de forma acessível.

Ocultar conteúdo com responsabilidade

Como você oculta conteúdo de forma responsável para torná-lo invisível, mas ainda acessível para leitores de tela? Kitty Giraudel resumiu diferentes maneiras de esconder algo, seja com HTML ou CSS, e quando usar cada uma.

Como Kitty sugere, convém evitar muitas discrepâncias entre o conteúdo visual e o conteúdo subjacente exposto à camada de acessibilidade. Quanto mais sincronizados, melhor. Kitty define três cenários diferentes para ajudá-lo a avaliar quando usar qual técnica: Se você precisar ocultar algo visualmente e da árvore de acessibilidade (mostrar/ocultar widgets, navegação fora da tela ou uma caixa de diálogo fechada, por exemplo), use display: none ou o atributo HTML hidden . Se você precisar ocultar algo da árvore de acessibilidade, mas mantê-lo visível, use aria-hidden="true" (casos válidos são conteúdo visual sem significado, ícones). E, por último, mas não menos importante, se você quiser ocultar algo, mas mantê-lo acessível, use o grupo de declaração CSS visualmente oculto (por exemplo, para conteúdo complementar que fornece mais contexto, como botões de ícone ou links). Uma ótima visão geral.

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 em linha, um pequeno acordeão. No entanto, como as notas de rodapé são links de salto, precisamos garantir que os usuários do leitor de tela entendam quando os links são referências a notas de rodapé — e podemos fazer isso com o atributo aria-describedby . O contador para cada link seria implementado por meio de um contador CSS. Com :target , destacamos a linha para a qual o leitor pulou e fornecemos um link de retorno 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 verificar como construir notas de rodapé acessíveis com React e usar react-a11y-footnotes para construí-las em React with Eleventy (graças a Kitty Giraudel pela dica!) .

Entradas Acessíveis

Em 2019, o WebAIM analisou a acessibilidade dos principais sites de um milhão, com uma conclusão chocante: a porcentagem de páginas sem erros foi estimada em menos de um por cento. Para tornar nossos sites inclusivos e utilizáveis ​​para pessoas que dependem de tecnologia assistiva, precisamos ter o básico do HTML semântico correto. Com seu credo de começar pequeno, compartilhar e trabalhar em conjunto, o artigo de Oscar Braunert sobre insumos inclusivos é um ótimo ponto de partida para isso.

Começando com o básico de WAI, ARIA e WCAG, o artigo explora como tornar as entradas mais acessíveis. As dicas podem ser implementadas sem alterar a interface do usuário e, como diz Oscar: “Na dúvida, é só fazer. Ninguém vai notar. Exceto alguns de seus usuários. E eles vão agradecer por isso.”

A ligação perfeita

Um link é um link é um link, certo? Bem, há mais em um link do que apenas uma palavra ou imagem clicável. Com seu artigo “The perfect link”, Rian Rietveld examina como escrever, projetar e codificar um link que funcione para todos em todos os dispositivos.

Rian aborda a questão se um link deve ser aberto em uma nova janela ou em uma nova guia, como tornar os textos dos links compreensíveis, como lidar com links para um endereço de e-mail, número de telefone ou arquivo, o que você precisa considerar ao incorporar uma imagem em um link, quando sublinhá-lo e como lidar com estilos de foco e foco, bem como questões semânticas e links internos. Um olhar de 360 ​​graus sobre o tema.

Navegação de teclado acessível em todo o aplicativo

Um conceito bem pensado para a navegação pelo teclado beneficia a todos: permite que pessoas que não podem usar confortavelmente um mouse, auxilia os usuários de leitores de tela na interação com um aplicativo e fornece aos usuários avançados mais atalhos para trabalhar da maneira mais eficiente possível. Normalmente, o suporte ao teclado é limitado a atalhos específicos, mas a equipe do Discord decidiu dar um passo adiante com seu aplicativo e expandir o suporte ao teclado para tudo.

O estudo de caso “Como o Discord implementou a navegação do teclado em todo o aplicativo” compartilha informações valiosas sobre como eles abordaram a tarefa – e os desafios que enfrentaram ao longo do caminho, é claro. Um acabou sendo particularmente difícil: como indicar consistentemente onde o foco está na página? Como as soluções existentes para o Focus Rings não deram certo, a equipe teve que construir sua própria solução do zero e tornou o código de código aberto. Se você está enfrentando um desafio semelhante, este é para você.

Menu de toque/clique acessível

Ainda é uma boa ideia projetar mega-drop-downs abrindo ao passar o mouse? Provavelmente não. Os menus suspensos têm muitos problemas de usabilidade e acessibilidade, pois são inconsistentes, confusos e, claro, precisam de uma solução alternativa para dispositivos móveis. Na verdade, Mark Root-Wiley sugere que é hora de deixar os menus flutuantes em favor de menus de clique inequívocos e acessíveis.

Em seu artigo, Mark entra em detalhes de como construir um menu de cliques acessível, juntamente com dicas úteis e referências de sua pesquisa. A ideia é começar a construir o menu como um menu flutuante somente CSS que usa li:hover > ul e li:focus-within > ul para mostrar os submenus. Em seguida, usamos JavaScript para criar os elementos <button> , definir os atributos de aria e adicionar os manipuladores de eventos. O resultado final está disponível como exemplo de código no CodePen e como repositório do GitHub. Este deve ser um bom ponto de partida para o seu menu também.

Componentes do Scroller de Mídia Acessível

Como você criaria um componente de rolagem de mídia responsivo que funcionasse em TVs, telefones e desktops? Adam Argyle leva você pelo processo passo a passo.

Projetado para hospedar miniaturas de mídia ou produtos, o componente scroller é construído sobre um <ul> com marcação acessível. O CSS transforma a lista humilde em uma experiência de rolagem suave que mostra as imagens e as encaixa em uma grade. Para adicionar um pouco de sutileza, o JavaScript facilita as interações itinerantes de índice, ajudando os usuários de teclado a pular a travessia de um grande número de itens e, por último, mas não menos importante, a consulta de mídia experimental prefers-reduced-data transforma o scroller de mídia em uma experiência leve, se necessário . Esperto!

Modais Acessíveis

Você pode ter um modal simples ou sobreposição 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 aventura e tanto, também conhecida como armadilha de foco .

Como Eric Bailey explica em detalhes, você precisará identificar os limites do conteúdo preso, incluindo o primeiro e o último item focalizável, remover tudo o que não estiver dentro dele, mover o foco para o conteúdo preso, ouvir eventos que escapam o limite, restaurar o estado anterior e mover o foco de volta para o elemento interativo que acionou o conteúdo capturado.

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

• A janela modal acessível de Scott O'Hara é um script totalmente acessível e confiável para usar.
• Kitty Giraudel lançará em breve o a11y-dialog Next, um script leve (1,6 KB) que captura e restaura o foco, alterna os atributos aria–* e fecha a caixa de diálogo ao clicar sobreposição e Escape. É importante não confundir esta versão com a versão anterior (6.1.0), pois ela depende do <dialog> que ainda carece de suporte à implementação e tem problemas de acessibilidade persistentes.
• Você pode olhar para Parvus, uma lightbox de imagem simples, acessível e 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 Parvus, basta adicionar uma classe .lightbox ao link que envolve uma imagem, e o script faz todo o resto automaticamente.

Campos de senha acessíveis

“Mostrar senha” e dicas de senha tornam os campos de formulário mais úteis. Eles ajudam os usuários a descobrir se digitaram incorretamente sua senha, bem como qual padrão é aceitável quando criam uma nova. No entanto, como se vê, muitas vezes falta acessibilidade quando se trata dessas coisas.

Para ajudá-lo a melhorar a situação, Nicolas Steenhout analisa mais de perto a acessibilidade da senha para mostrar/ocultar e como garantir que as dicas de senha sejam úteis para todos. Desde o aprimoramento dos botões mostrar/ocultar com uma função de switch e aria-live e aria-pressed até o suporte ao preenchimento automático, Nicolas resumiu tudo o que você precisa saber para tornar a web um pouco mais acessível a esse respeito.

Suporte às preferências do usuário com prefers-reduced-*

Nem todos os usuários são iguais e, embora alguns usuários amem animações, outros podem ter problemas médicos relacionados ao movimento. A consulta de mídia prefers-reduced-motion permite ativar e desativar animações, mas há ainda mais soluções para gerenciar animações dependendo da preferência do usuário. Em sua postagem no blog, Elijah Manor aborda diferentes técnicas, como @media, matchMedia e um gancho React personalizado para abordar animações CSS, SVG SMIL e JavaScript.

Quando se trata de tornar seu conteúdo acessível a todos, há outra consulta de mídia prefers-reduced-* que vale a pena conhecer - mesmo que ainda não seja suportada por navegadores (mas você pode emulá-la nos navegadores Polypane e Chromium): prefers-reduced-data . Indica quando um usuário deseja usar o mínimo de dados possível — se a conexão estiver lenta, por exemplo, ou se os dados forem limitados.

• Tatiana Mac escreveu um artigo muito completo sobre Como adotar uma abordagem sem movimento para animações, sugerindo colocar todos os estilos específicos de animação em uma folha de estilo específica de animação e servi-la apenas se o visitante não tiver indicado “Reduzir movimento”.
• Kitty Giraudel fornece diretrizes sobre a implementação de um modo de movimento reduzido em um exemplo de interface de usuário bancária e também em um exemplo de código.
• A equipe do Polypane resumiu o que você precisa saber sobre a consulta de mídia para preparar seu site para o futuro já hoje.

Esqueletos Acessíveis

Os padrões de esqueleto tendem a não ter uma maneira significativa de se apresentar aos leitores de tela. Eles costumam usar aria-busy="true" quando um widget está carregando, mas apenas alguns leitores de tela realmente honram o atributo. Então, como fazer melhor?

Como Adrian Roselli sugere, você pode usar CSS para encontrar qualquer nó com aria-busy="true" e configurá-lo para display: none para obter o mesmo efeito para usuários de leitores de tela e não leitores de tela. Em seu artigo “Mais Acessíveis Esqueletos”, ele mostra o processo passo a passo. A demonstração funciona em navegadores com versões atuais do JAWS, NVDA, VoiceOver e TalkBack.

Links “Pular” Acessíveis

Especialmente em páginas com uma grande quantidade de navegação, mover-se entre as seções ou ao redor da página pode ser frustrante e irritante. É aí que os links “Pular” podem ser muito úteis. Infelizmente, não é incomum ver links “Skip” sendo implementados, mas escondidos com display: none e, como tal, indisponíveis para qualquer pessoa (incluindo usuários de leitores de tela e usuários de teclado).

Em Como criar um link “Pular conteúdo”, Paul Ryan fornece um tutorial passo a passo sobre como implementar um link acessível para pular conteúdo. Basicamente, usamos a transformação CSS para empurrar o link de pular para fora da tela, mas trazê-lo de volta à tela em :focus . Nos comentários ao artigo, Eric Bailey também notou que poderíamos fornecer links para pular antes de seções de conteúdo que contêm muitos itens interativos ou itens que podem ser difíceis de navegar (como sumário e iframe s).

SVGs acessíveis

Falando em 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 Accessible SVGs: Inclusiveness Beyond Patterns. No artigo, Carie analisa mais de perto a cor e o contraste do SVG, os modos claro e escuro, a animação SVG, o movimento reduzido e muitas ferramentas focadas em acessibilidade. Você também encontrará demonstrações e exemplos de código nos artigos, juntamente 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 sobre padrões de código acessíveis.

Guias acessíveis

Sua interface pode estar usando painéis de guias, mas para manter o conteúdo dessas guias acessível aos usuários de teclado e leitores de tela, precisamos de uma exposição muito cuidadosa e deliberada do design visual e da semântica ARIA. Em Interfaces com abas, 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 progressivamente as seções em painéis de guias (exemplo de código) (graças 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 as guias. Há um argumento para tornar todas as guias focáveis ​​na sequência de guias normal com pouca intervenção dos desenvolvedores para alterar a maneira como as guias funcionam via teclado.

Alternativamente, TabPanelWidget é uma solução responsiva e acessível para guias. Ele se baseia em HTML semântico simples e se transforma em um acordeão sempre que as guias não podem caber inteiramente (graças ao ResizeObserver , mas há um polyfill para navegadores que ainda não o suportam).

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

Tabelas acessíveis

Existem muitos problemas de acessibilidade relacionados às tabelas, mas o maior desafio é transformar uma representação visual em uma série linear que será lida em voz alta de forma significativa por um leitor de tela, sem omitir nenhuma informação importante. Felizmente, Adrian Roselli tem passado muito tempo explorando os desafios e soluções das mesas acessíveis.

Em sua postagem sobre tabelas acessíveis, Adrian sugere envolver a tabela em um <div> com role="region" , aria-labelledby e tabindex="0" para garantir que um usuário apenas de teclado possa tabular para o contêiner, que o table recebe foco e <caption> dentro da tabela para garantir que seja anunciado corretamente aos leitores de tela. Adrian também fornece um exemplo de código para uma tabela responsiva, bem como tabelas com linhas expansíveis, tabela classificável e cabeçalhos de tabela fixos.

Como os leitores de tela navegam nas tabelas de dados

Você já tentou navegar em uma tabela com um leitor de tela? Caso contrário, você deve conferir o artigo de Leonie Watson sobre como os leitores de tela navegam nas tabelas de dados. Ele compartilha insights preciosos e mostra o que importa para criar tabelas sem frustrações que podem ser usadas por qualquer pessoa.

No post, Leonie usa o NVDA para se mover para uma tabela, navegar em seu conteúdo e encontrar informações específicas. Os elementos HTML apropriados (ou papéis ARIA) informam sobre as características da tabela e dão acesso a comandos de teclado específicos para navegar pelo conteúdo da tabela.

Uma conclusão interessante: o foco do teclado e o foco do leitor de tela não são a mesma coisa. Ao contrário do que você pode ter ouvido, você não precisa tornar cada célula de uma tabela focalizável com um teclado para auxiliar a navegação. Se o conteúdo dentro da célula não for interativo, você provavelmente fará com que os usuários de teclado trabalhem muito mais para navegar na tabela do que você pretendia. Você também pode assistir a um vídeo Smashing TV com Leonie sobre Como um usuário de leitor de tela acessa a Web (73 minutos).

Interruptores 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 mudança precisa servir a alguns propósitos: ela precisa explicar claramente a seleção atual (e isso não é tão frequente!), ela precisa explicar que existem duas opções e precisa ser óbvia o suficiente para que os clientes entender como alternar entre eles. Quando Sara Soueidan estava procurando como construir um interruptor de alternância, é claro que ela passou um bom tempo procurando como construir um interruptor de alternância acessível.

A solução da Sara usa dois botões de opção, cada um com seu próprio rótulo, anunciado para tecnologias assistivas como duas opções separadas, acessíveis via teclado, e não possui requisitos adicionais de ARIA ou JS 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 de Scott O'Hara.

É importante observar que a chave de alternância do botão de opção de Sara é acessível por causa de seus dois rótulos. Portanto, se uma chave de alternância não tiver dois rótulos, esse não seria um padrão a ser usado. Você pode encontrar padrões de marcação para alternâncias no repositório de Scott. ( obrigado a Scott O'Hara pela dica! ).

Kitty Giraudel também compartilha um tutorial para uma pequena implementação somente HTML e CSS de uma alternância acessível que você pode ajustar conforme sua conveniência. A base para a alternância acessível é uma caixa de seleção devidamente rotulada. Ele transmite seu status com iconografia e cor e não deixa nenhum artefato se o CSS não estiver ativado. A alternância vem com estilos de foco nativos que podem ser personalizados, um estado desabilitado e também suporta orientação da direita para a esquerda, se necessário.

Dicas de ferramentas e dicas de alternância acessíveis

Um componente que está intimamente relacionado aos botões de ícone é uma dica de ferramenta. Literalmente “dicas para ferramentas”, são pequenas informações que explicam o propósito de um controle, ou 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 de ferramenta. Então, como vamos acertar eles?

As dicas de ferramentas e dicas de alternância inclusivas do Heydon Pickering fornecem uma visão geral muito completa de praticamente tudo o que é necessário para criar 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 adequadamente, não confiando nos atributos do title e evitando colocar conteúdo interativo, como botões ou links para fechar e confirmar, nas dicas de ferramentas.

• Sara Soueidan, é claro, também entra nos meandros da construção de uma dica de ferramenta de ajuda totalmente acessível e conclui que o JavaScript é imperativo para criar componentes interativos totalmente acessíveis.
• Sarah Higley também explica a complexidade das dicas de ferramentas e lançou um exemplo de código que mostra um padrão confiável em ação.
• Scott O'Hara tem um repositório GitHub sobre dicas de ferramentas,
• Adrian Roselli também fornece muitos exemplos de código para alternâncias, incluindo demos com dicas de ferramentas desabilitadas e direção RTL.

Players de vídeo/áudio acessíveis

Atualmente, não é incomum ver os espectadores usando legendas ao assistir a um clipe curto ou a um filme longo. Podemos estar consumindo o vídeo em um ambiente barulhento, ou talvez possamos entender melhor a linguagem escrita, ou talvez estejamos ocupados com outra coisa e precisemos procurar algo rapidamente sem precisar recorrer a fones de ouvido. Além disso, com que frequência usamos o <space> do teclado para solicitar uma pausa ou as setas das teclas para retroceder e avançar? Ainda assim, muitos players de vídeo e soluções personalizadas não oferecem essa funcionalidade pronta para uso.

Os players de mídia HTML5 acessíveis fornecem uma visão geral dos players de áudio e vídeo acessíveis. Existem muitas ótimas opções de código aberto, por exemplo, o AblePlayer parece ser um dos confiáveis. Ele inclui um conjunto completo de controles do player que são acessíveis pelo teclado, devidamente rotulados para usuários de leitores de tela e controláveis ​​por usuários de reconhecimento de fala, apresenta alto contraste, suporta legendas e legendas ocultas, capítulos, descrição de áudio baseada em texto, um recurso de transcrição interativa e realce automático de texto. Ele suporta vídeos do YouTube e Vimeo. No entanto, depende do jQuery.

Como alternativa, você também pode pesquisar no Vime.js: totalmente de código aberto, leve, totalmente personalizável e sem dependências de terceiros . Outras ótimas opções como Plyr e Accessible HTML5 Video Player do PayPal são semelhantes. O último é totalmente acessível para usuários apenas de teclado e usuários de leitores de tela, escritos em JavaScript vanilla, é fornecido adicionalmente como um componente React e retorna aos controles nativos do navegador se o JavaScript não estiver disponível ( obrigado pela dica, @jamsandwich ! ).

Recursos do site que incomodam os usuários do leitor de tela

Uma legenda alt ausente, um vídeo de reprodução automática, botões sem rótulo, mau uso de títulos, formulários da web inacessíveis - o que pode parecer um pequeno problema para usuários com visão pode fazer a diferença entre poder usar um site de forma independente ou não para cegos e pessoas com deficiência visual. Holly Tuke sabe disso por experiência própria.

Para aumentar a conscientização sobre problemas comuns de acessibilidade, Holly resumiu cinco recursos irritantes do site que ela enfrenta como usuário de leitor de tela todos os dias e, é claro, como corrigi-los. Chris Ashton também publicou um artigo explicando problemas comuns que os usuários de leitores de tela têm, que muitas vezes são negligenciados em conversas focadas apenas na semântica e na acessibilidade do teclado. Pequenos detalhes que fazem uma enorme diferença ( obrigado a Alex Chudesnov pela dica! ).

Mas primeiro, suporte de acessibilidade

Há muitas maneiras diferentes pelas quais as tecnologias assistivas interagem com navegadores e códigos. Como ainda não é possível automatizar totalmente os leitores de tela e os softwares de controle de voz, ficamos com a necessidade de fazer testes manuais. E é aí que o a11ysupport.io entra em ação.

Originalmente criado por Michael Fairchild, este site voltado para a comunidade visa ajudar a informar os desenvolvedores sobre o que é compatível com acessibilidade. É um projeto ativo e contribuições são sempre bem-vindas, então comece a testar. Além disso, sempre vale a pena verificar as práticas de autoria WAI-ARIA que descrevem a semântica, funções e ARIA essenciais necessários para componentes e padrões comuns (graças a Stephanie Eckles pela dica!) .

Recursos e listas de verificação de acessibilidade

A acessibilidade é incrivelmente importante, mas, infelizmente, muitas vezes esquecida. O Projeto A11Y, voltado para a comunidade, tenta facilitar a acessibilidade digital, fornecendo aos designers e desenvolvedores o conhecimento necessário para criar experiências bonitas, acessíveis e inclusivas.

Dos princípios básicos por trás do design acessível à realização de uma auditoria de acessibilidade e ao cultivo da comunidade, o Projeto A11Y analisa o tópico em 360 graus. Você encontrará artigos como dicas rápidas, dicas de livros para ler, boletins informativos a seguir, além de ferramentas úteis, grupos comprometidos com a acessibilidade e muito mais.

Repositório de Ferramentas de Acessibilidade

Você já teve aquela sensação de coceira de esquecer algo antes de enviar um projeto? Bem, as listas de verificação são conhecidas por serem a chave para manter uma visão geral das coisas que precisam ser feitas e cuidadas antes do confronto final. Quando se trata de acessibilidade, há uma lista crescente de ferramentas e recursos que certamente ajudarão você a ficar de olho nas coisas: Recursos A11y.

Com curadoria de Hannah Milan, esta lista foi inicialmente criada para acompanhar mais de 200 plugins de acessibilidade, ferramentas, artigos, estudos de caso, padrões de design, recursos de design, padrões de acessibilidade e até listas de verificação. Claro, você sempre pode enviar uma ferramenta se vir alguma coisa faltando.

Acessibilidade de componentes de terceiros

Componentes reutilizáveis, como seleções personalizadas, preenchimentos automáticos ou seletores de data, são auxiliares poderosos. No entanto, muitos componentes de terceiros que afirmam ser acessíveis acabam sendo apenas parcialmente acessíveis quando você se aprofunda um pouco. Como aponta Hidde de Vries, mesmo os componentes que implementaram o ARIA Authoring Practices Guide 1:1 podem ser críticos porque o guia não faz afirmações sobre acessibilidade do leitor de tela ou experiência do usuário. Então, como você encontra esses componentes que são realmente acessíveis?

Hide publicou uma lista de perguntas que você pode fazer para ter um pouco mais de certeza sobre a acessibilidade de um componente: Como eles testaram? Com quem eles testaram? Eles são abertos sobre os prós e contras de sua abordagem? E quem criou o componente? Ele também compartilha algumas dicas valiosas da comunidade que ajudam você a avaliar se um componente que afirma ser acessível cumprirá sua promessa.

Empacotando

Definitivamente, existem dezenas e centenas de diretrizes importantes de pessoas incríveis na comunidade de acessibilidade, como Steve Faulkner com uma enorme série de artigos sobre semântica e acessibilidade e Leonie Watson com uma enorme série de artigos sobre acessibilidade em geral. É impossível listar todos, mas somos sinceramente gratos a cada contribuição.

Provavelmente perdemos algumas técnicas e recursos importantes e valiosos! Então, por favor, deixe um comentário e consulte-os - adoraríamos atualizar esta postagem e mantê-la atualizada para que todos possamos voltar a ela e criar componentes confiáveis ​​e acessíveis mais rapidamente.

Esperamos sinceramente que essas ferramentas e técnicas sejam úteis em seu trabalho diário e, o mais importante, ajudem você a evitar algumas tarefas rotineiras e demoradas.

Fique acessível!

Obrigado! ️

Um grande obrigado a @jamsandwich, Courtney Heitman, Stephanie Eckles, Adam Silver, Daniela Kubesch, Tanisha Sabherwal, Manuel Matuzovic, Vadim Makeev, Kitty Giraudel, Ian James, Juha Lehtonen, Heydon Pickering, Shivani Gupta, Jason Webb, Alex Kallinikos, Scott O'Hara, Sara Soueidan, Sasha Chudesnov, Adam Liptrot, Holger Bartel, Kim Johannesen e todos os outros que têm trabalhado apaixonadamente em torno da acessibilidade pelas contribuições para este artigo. Assuntos da comunidade.

Mais sobre acessibilidade

• Ferramentas de auditoria CSS
• Geradores CSS
• Desvendando o mundo complexo dos padrões acessíveis
• Projetando com movimento reduzido para sensibilidades de movimento
• Usei a Web por um dia usando um leitor de tela
• Acessibilidade no Chrome DevTools
• Coisas que você pode fazer com CSS hoje
• Além disso, assine nossa newsletter para não perder as próximas.