Í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.
- : estilos de foco
- preenchimento automático
- botões
- carrosséis
- botões”fechar”
- controles deslizantes de conteúdo
- caixas de seleção
- sistemas de cores
- paletas de cores
- quadrinhos
- bibliotecas de componentes
- solicitações de consentimento de cookies
- modo escuro
- gráficos de dados
- visualizações de dados
- selecionadores de data
- estilos de formulário
- notas de rodapé
- links de ícone
- entradas
- navegação por teclado
- menu de navegação
- modais
- prefere-reduzido-*
- botões de opção
- “ pular ”links
- SVGs
- guias
- tabelas
- interruptores
- ferramentas
- dicas de ferramentas
- vídeo/reprodutores de áudio
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
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.
- Sara Soueidan, é claro, também analisa os detalhes da construção de uma dica de ajuda totalmente acessível e conclui que o JavaScript é fundamental para tornar os componentes interativos totalmente acessíveis.
- Sarah Higley também explica a complexidade das dicas 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 em dicas de ferramentas ,
- Adrian Roselli fornece muitos exemplos de código para alternar também, incluindo demonstrações com dicas de ferramentas desativadas e direção RTL.
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
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 “ de Sarah Higley é um mergulho profundo abrangente em duas partes todos os desafios e complexidades de estilizar o elemento , 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 elements, set the aria attributes, and add the event handlers. The final result is available as a code example on CodePen and as a GitHub repo. This should be a good starting point for your menu as well.
Accessible “Skip” Links
Especially on pages with a large amount of navigation, moving between sections or around the page can be frustrating and annoying. That’s where “Skip” links can be very helpful. Unfortunately, it’s not uncommon to see “Skip” links being implemented but hidden away with display: none, and as such, unavailable to anybody (including screen reader users and keyboard users).
In How To Create a “Skip content” Link, Paul Ryan provides a step-by-step tutorial on how to implement an accessible skip content link. Basically we use CSS transform to push the skip link off the screen, but bring it back on screen on :focus. In the comments to the article, Eric Bailey also noticed that we could provide skip-links before sections of content that contain lots of interactive items, or items that can be tough to navigate through (such as table of contents and iframes).
Accessible Tables
There are plenty of accessibility issues related to tables, but the biggest challenges is to turn a visual representation into a linear series that will be read aloud meaningfully by a screen reader, without omitting any important information. Fortunately, Adrian Roselli has been spending a lot of time exploring the challenges and solutions of accessible tables.
In his post on accessible tables, Adrian suggests to wrap the table in a
role="region", aria-labelledby and tabindex="0" to ensure that a keyboard-only user can tab to the container, that the table receives focus and
within table to ensure that it’s properly announced to screen readers. Adrian also provides a code example for a responsive table, as well as tables with expandable rows, sortable table and fixed table headers.
How Screen Readers Navigate Data Tables
Have you ever tried to navigate a table with a screen reader? If not, you should check out Leonie Watson’s article on how screen readers navigate data tables. It shares precious insights and shows what matters to create frustration-free tables that can be used by anyone.
In the post, Leonie uses NVDA to move to a table, navigate its content, and find specific information. The appropriate HTML elements (or ARIA roles) inform her about the characteristics of the table and give her access to keyboard commands specifically for navigating the table’s content.
An interesting takeaway: Keyboard focus and screen reader focus are not the same thing. Contrary to what you might have heard, you do not need to make each cell of a table focusable with a keyboard to aid navigation. If the content inside the cell is non-interactive, you’ll likely make keyboard users work much harder to navigate the table than you intended. You can also watch a Smashing TV video with Léonie on How A Screen Reader User Accesses The Web (73 mins).
Website Features That Annoy Screen Reader Users
A missing alt caption, an auto-playing video, unlabelled buttons, poor use of headings, inaccessible web forms — what might seem like a small issue for sighted users can make the difference between being able to use a website independently or not for blind and visually impaired people. Holly Tuke knows this from her own experience.
To raise awareness for common accessibility issues, Holly summarized five annoying website features she faces as a screen reader user every single day, and, of course, how to fix them. Chris Ashton also published a piece explaining common issues that screen reader users have, which are often neglected in conversations focus on semantics and keyboard-accessibility alone. Little details that make a huge difference (thanks to Alex Chudesnov for the tip!).
Accessible Video/Audio Players
It’s not uncommon to see viewers frequently using captions when watching a short clip or a lengthy movie these days. We might be consuming the video in a noisy environment, or perhaps we can better understand written language, or perhaps we are currently busy with something else and need to look up something quickly without having to resort to headphones. Beyond that, how often do we use keyboard’s
Accessible HTML5 Media Players provides an overview of accessible audio and video players. There are plenty of great open-source options, e.g. AblePlayer seems to be one of the reliable ones. It includes a full set of player controls that are keyboard-accessible, properly labelled for screen reader users, and controllable by speech recognition users, features high contrast, supports closed captions and subtitles, chapters, text-based audio description, an interactive transcript feature and automatic text highlighting. It supports YouTube and Vimeo videos. Hower, it depends on jQuery.
Alternatively, you could look into Vime.js as well: fully open-source, lightweight, fully customizable and without third-party dependencies. Other great options like Plyr and Accessible HTML5 Video Player by PayPal are similar. The latter is fully accessible to keyboard-only users and screen reader users, written in vanilla JavaScript, is additionally provided as a React component, and falls back to browser’s native controls if JavaScript is unavailable (thanks for the tip, @jamsandwich!).
Accessible Cookie Consent Prompts
Overlays and pop-ups are always problematic. But especially for screen reader users, sometimes those prompts are incredibly difficult to deal with to set any settings or even confirm the usage of cookies on the site. In her 15-mins talk on”Screen readers and cookie consents“, Leonie Watson goes into detail explaining the poor experiences that compliance pop-ups have for accessibility. In some cases, users glide past consent prompts without being aware of them, in the others, the prompt are impossible to accept, resulting in an inability to use the site at all.
So how can we make them better? In Cookie banners and accessibility, Sheri Byrne-Haber highlights common issues that cookie prompts usually have: from how they visually appear to focus traps, the appearance in the tab order, the type of acceptance and alternate formats of consent disclosure. Quentin Bellanger provides a basic code example of a cookie consent modal and a tutorial along with it. There are also free open-source solutions: Osano Cookie Consent and cookie-consent-box, but they might require some accessibility work.
Accessible Close Buttons
“Close” buttons are everywhere — in modals, ads, confirmation messages, cookie prompts and any overlays that will appear in your interface. Unfortunately, the functionality is often limited to mouse users, leaving screen reader users and keyboard-users out. We can fix it.
In “Accessible Close Buttons” Manuel Matuzovic goes into deep details highlighting 11 examples and patterns of inaccessible close buttons as well as 5 examples of close buttons that work fairly well. The easiest way to solve the problem is to provide a button with visible text and only visually accessible icon and ensure that the description by screen readers isn’t polluted by the icon’s description. Manuel also provides code examples of 5 close buttons that you can apply to your work right away.
Accessible Inputs
In 2019, WebAIM analyzed the accessibility of the top one million websites, with a shocking conclusion: the percentage of error-free pages was estimated to be under one percent. To make our sites inclusive and usable for people who rely on assistive technology, we need to get the basics of semantic HTML right. With its credo of starting small, sharing, and working together, Oscar Braunert’s article on inclusive inputs is a great starting point to do so.
Starting off with the basics of WAI, ARIA, and WCAG, the article explores how to make inputs more accessible. The tips can be implemented without changing the user interface, and, as Oscar puts it: “If in doubt, just do it. Nobody will notice. Except some of your users. And they will thank you for it.”
Support User Preferences With prefers-reduced-*
Not every user is the same, and while some users love animations, others may have medical issues concerning motion. The prefers-reduced-motion media query lets you toggle animations on and off, but there are even more solutions to manage animations depending on a user’s preference. In his blog post, Elijah Manor addresses different techniques such as @media, matchMedia, and a custom React hook to address CSS, SVG SMIL, and JavaScript animations.
When it comes to making your content accessible to everyone, there’s another prefers-reduced-* media query that is worth knowing about — even though it isn’t supported by browsers yet (but you can emulate it in Polypane and Chromium browsers): prefers-reduced-data. It indicates when a user wants to use as little data as possible — if their connection is slow, for example, or if data is limited. The Polypane team summarized what you need to know about the media query to future-proof your site already today.
A Complete Guide To Dark Mode On The Web
Dark mode is quickly becoming a user preference with Apple, Windows, and Google having it implemented into their operating systems. But what about dark mode on the web? Adhuham wrote a comprehensive guide to dark mode that delves into different options and approaches to implementing a dark mode design on the web.
To start off, the guide looks at the technical considerations that implementing a dark mode entails, covering different approaches to toggling the themes and how to store a user’s preferences so that they will be applied consistently throughout the site and on subsequent visits. Tips for handling user agent styles with the color-scheme meta tag help avoid potential FOIT situations.
Design considerations are also tackled, of course, with valuable tips to get images, shadows, typography, icons, and colors ready for dark mode. While on it: to ensure we don’t unintentionally break the high contrast in mode, take a look at Styling for Windows High Contrast mode (thanks for the tip, Courtney Heitman!).
Accessible App-Wide Keyboard Navigation
A well-thought-out concept for keyboard navigation benefits everyone: It enables people who can’t comfortably use a mouse, assists screen reader users in interacting with an application, and it provides power users with more shortcuts to work as efficiently as possible. Usually, keyboard support is limited to specific shortcuts, but the team at Discord decided to go a step further with their application and expand keyboard support to, well, everything.
The case study “How Discord Implemented App-Wide Keyboard Navigation” shares valuable insights into how they tackled the task — and the challenges they faced along the way, of course. One turned out to be particularly difficult: How to consistently indicate where focus is on the page? As existing solutions for Focus Rings didn’t work out, the team had to build their own solution from scratch and made the code open source. If you’re facing a similar challenge, this one’s for you.
Accessible Comics
When we use slightly more complex shapes and layouts on the web, sometimes it appears to be so much easier to just save it as a foreground or background image and serve different images to small and large screens. This holds true for complicated charts and graphs as well as good old comics with speaking bubbles, but what if we could re-imagine the experience altogether?
Comica11y is an experiment by Paul Spencer that aims to achieve an all-inclusive online comic reading experience. What if we could have different reading modes for the comic, e.g. with closed captions, proper focus management to navigate between panels, high-contrast mode, SVG color blindness filters, programatic bubbles, selectable and translatable text, LTR and RTL support, and even adjustable font sizes? A wonderful initiative that shows just how far we can take UI challenges and use the web to enhance the experience greatly.
Inaccessible Disabled Buttons
It has become quite common for lengthy web forms to keep the “Continue” button disabled until the customer has provided all data correctly. This behavior acts as an indicator that something is wrong with the form, and it can’t be completed without reviewing the input. This works if the inline validation for every input field is working well, and it doesn’t work at all when it’s glitchy or buggy.
In “Disabled Buttons Suck”, Hampus Sethfors highlights the downsides of disabled buttons. With them in place, we do communicate that something is wrong, but we don’t really explain what is wrong, or how to fix it. So if the customer has overlooked an error message — be it in a lengthy form on desktop, or even in a short form on mobile, they’ll be lost. In many ways, keeping buttons active and communicating errors is more efficient.
And if it’s not possible, at least provide a way out with a button “I can’t complete the form, please help”, so customer support can get back to customers in case they get into trouble. If you need a more detailed refresher on web forms,”Form Design From One to Zero” will keep you busy.
But First, Accessibility Support
There are many different ways that assistive technologies interact with browsers and code. Since it’s still not possible to fully automate screen readers and voice control softwares, we are left with having to do manual tests. And that’s where a11ysupport.io comes into play.
Originally created by Michael Fairchild, this community-driven website aims to help inform developers about what is accessibility supported. It’s a project that is active and contributions are always welcome, so start testing away. Also, it’s always worth checking the WAI-ARIA authoring practices which describe essential semantics, roles, and ARIA necessary for common components and patterns (thanks to Stephanie Eckles for the tip!).
Accessibility Resources And Checklists
Accessibility is incredibly important, but, unfortunately, often overlooked. The community-driven A11Y Project attempts to make digital accessibility easier, providing designers and developers with the know-how they need to build beautiful, accessible, and inclusive experiences.
From the basic principles behind accessible design to conducting an accessibility audit, and cultivating community, The A11Y Project takes a 360 degree look at the topic. You’ll find articles just like quick tips, tips on books to read, newsletters to follow, as well as handy tools, groups committed to accessibility, and much more.
Repository Of Accessibility Tools
Do you ever get that itching feeling of forgetting something before shipping a project? Well, checklists are known to be the key to keeping an overview of things that need to be done and taken care of before the final showdown. When it comes to accessibility, there’s a growing list of tools and resources that are bound to help you keep an eye on things: A11y Resources.
Curated by Hannah Milan, this list was initially created to keep track of more than 200+ hand-curated accessibility plugins, tools, articles, case studies, design patterns, design resources, accessibility standards, and even checklists. Of course, you can always submit a tool if you see anything missing.
Wrapping Up
We probably have missed some important and valuable techniques and resources! So please leave a comment and refer to them — we’d love to update this post and keep it up-to-date for us all to be able to get back to it and build reliable, accessible components faster.
We sincerely hope that these tools and techniques will prove to be useful in your day-to-day work — and most importantly help you avoid some time-consuming, routine tasks.
Stay accessible!
Thank you! ❤️
A huge thanks to @jamsandwich, Courtney Heitman, Stephanie Eckles, Adam Silver, Daniela Kubesch, Tanisha Sabherwal, Manuel Matuzović, Vadim Makeev, Kitty Giraudel, Ian James, Juha Lehtonen, Shivani Gupta, Sara Soueidan, Jason Webb, Alex Kallinikos, Sasha Chudesnov, Adam Liptrot, Holger Bartel, Kim Johannesen and everybody else who has been passionately working all around accessibility for the contributions to this article. Community matters.
More On Accessibility
- CSS Auditing Tools
- CSS Generators
- Untangling The Complex World Of Accessible Patterns
- Designing With Reduced Motion For Motion Sensitivities
- I Used The Web For A Day Using A Screen Reader
- Accessibility In Chrome DevTools
- Things You Can Do With CSS Today
- Also, subscribe to our newsletter to not miss the next ones.
