5 etapas para criar aplicativos com a acessibilidade do teclado em mente

Quando pensamos no usuário “médio”, tendemos a imaginá-lo usando um mouse ou trackpad quando está no computador. Mas, e se a opção preferida ou única fosse usar um teclado? Você já pensou em projetar seus aplicativos tendo em mente a acessibilidade do teclado?

Há muitos motivos pelos quais alguém pode não querer ou não ser capaz de operar um mouse ou trackpad para usar o computador. Eles podem ter condições permanentes, crônicas ou temporárias que limitam sua destreza ou controle muscular, causando sensibilidade em seus pulsos ou mãos ou dificultando o acompanhamento do cursor do mouse em uma tela. Eles também podem ser “usuários avançados” procurando mais atalhos para otimizar seus fluxos de trabalho. Em qualquer um desses casos, os teclados podem ser os meios preferidos ou necessários de um indivíduo para interagir com a tecnologia.

Neste artigo, você aprenderá sobre as diretrizes de acessibilidade do teclado, bem como cinco etapas a serem lembradas ao criar aplicativos para garantir que sejam acessíveis pelo teclado.

Como funciona a acessibilidade do teclado?

Se um aplicativo for acessível por teclado, isso significa que as pessoas têm a opção de usar apenas um teclado para operar os elementos de controle . Elementos de controle são quaisquer componentes interativos na página, como botões, links, entradas de formulário, vídeos e outros conteúdos interativos.

Noções básicas de navegação do teclado

Aqui estão algumas teclas básicas usadas para navegação no teclado:

• Navegando para o próximo elemento de controle: Tab (ou a tecla de seta para a direita ou para baixo para botões de opção relacionados e opções selecionadas)
• Navegando para o elemento de controle anterior: Shift + Tab (ou a tecla de seta para a esquerda ou para cima para botões de rádio relacionados e opções selecionadas)
• Clicar em um elemento de controle: Enter e/ou barra de espaço
• Navegando entre botões de rádio relacionados ou opções selecionadas: Teclas de seta

ordem de foco

A seqüência na qual os elementos de controle podem responder aos eventos do teclado é conhecida como ordem de foco . Quando um elemento está em foco, você pode interagir com ele usando determinados controles do teclado. Quando um elemento perde o foco, ele fica borrado. Os navegadores renderizam estados de foco padrão para ajudar os usuários a acompanhar qual elemento está em foco no momento.

Você também pode gostar de: Design universal: 11 dicas práticas para tornar seus sites e aplicativos mais acessíveis.

Acessibilidade de teclado e Diretrizes de acessibilidade de conteúdo da Web (WCAG)

As Diretrizes de Acessibilidade de Conteúdo da Web (WCAG) descrevem três níveis de conformidade — Nível A, Nível AA e Nível AAA — que foram adotados como padrões para leis regionais ou nacionais de acessibilidade na Web em todo o mundo.

A acessibilidade do teclado é um dos critérios de sucesso para conformidade com o Nível A. Os critérios de nível A descrevem recursos obrigatórios para todo o conteúdo da web. Eles também são considerados os mais fáceis de implementar.

“A acessibilidade do teclado também é fácil de errar se não formos cuidadosos.”

Dito isso, a acessibilidade do teclado também é fácil de errar se não formos cuidadosos. Aqui estão alguns exemplos de problemas comuns de acessibilidade de teclado encontrados na web:

• Estados de foco imperceptíveis
• Ordem de foco incorreta
• Elementos interativos que não podem receber foco
• Componentes complexos que não captam interações do teclado

Felizmente, existem muitas técnicas que podemos usar para manter os usuários de teclado em mente e evitar cometer esses erros em nossos próprios aplicativos.

5 etapas para criar aplicativos acessíveis por teclado

1. Crie interações intuitivas

Quando renderizamos elementos de controle simples sem comportamentos personalizados, geralmente podemos aproveitar seus recursos integrados de acessibilidade de teclado. Mas, se não conhecermos os comportamentos padrão do teclado associados a botões, links ou entradas, podemos criar inadvertidamente experiências confusas para usuários de teclado.

“Se não conhecermos os comportamentos padrão do teclado associados a botões, links ou entradas, podemos inadvertidamente criar experiências confusas para usuários de teclado.”

Por exemplo, os desenvolvedores às vezes usam CSS para ocultar botões de opção HTML nativos em favor de visuais mais estilizados. Não é óbvio que as entradas são botões de opção nos bastidores, portanto, os usuários de teclado podem não perceber que devem usar as teclas de seta — não a tecla Tab — para mudar o foco entre as opções relacionadas.

Para evitar esse problema, devemos exibir algo que, pelo menos, se assemelhe ao elemento HTML nativo para fornecer dicas visuais para quem quiser ou precisar interagir com ele usando um teclado.

2. Crie seu aplicativo para que um teclado possa fazer tudo o que um mouse pode

Esteja ciente dos elementos que não vêm com recursos de acessibilidade de teclado integrados. Elementos de layout, listas, tabelas, cabeçalhos, parágrafos e tags HTML não semânticas não suportam atalhos de teclado por padrão. Ainda assim, eles são frequentemente usados ​​para construir componentes mais complexos, como guias, listas de arrastar e soltar ou modais.

O JavaScript nos permite adicionar ouvintes de eventos que fazem com que elementos não controlados respondam a cliques ou gestos do mouse. No React, por exemplo, podemos usar a propriedade onClick para adicionar interatividade a um elemento de item de lista.

Sempre que adicionamos interatividade a elementos que não são de controle, precisamos definir seu atributo tabIndex como 0 . Isso permitirá que o elemento receba o foco na ordem de foco correta quando a tecla Tab for pressionada. Também precisamos implementar os manipuladores de evento keypress ou keydown para registrar “cliques” por meio da tecla Enter e/ou da barra de espaço (os links podem ser clicados usando ambos, enquanto os botões suportam apenas a tecla Enter).

Podemos evitar parte desse trabalho extra usando controles como tags de âncora ou elementos de botão. Sempre podemos usar CSS para substituir os estilos padrão de link e botão e fazer com que o elemento interativo ocupe toda a largura de seu pai não interativo para maximizar a área de destino.

Quer usemos ou não elementos de controle para recursos não nativos, ainda podemos precisar adicionar ouvintes de evento para as teclas de seta (para navegar entre as guias em um componente de guia) ou a tecla Escape (para fechar uma sobreposição) para tornar nosso componente 100 teclado percentual acessível.

Se implementarmos comportamentos de teclado não padrão para um componente mais complexo, é útil fornecer instruções visíveis que descrevam os controles de teclado que as pessoas podem usar para interagir com o componente.

3. Faça o trabalho extra ao substituir a ordem de foco padrão

A ordem do foco é outro requisito WCAG que está intimamente relacionado à acessibilidade do teclado. Para atender aos critérios do Nível A, a ordem de foco deve ser consistente com a sequência visual dos elementos interativos na página. Os usuários de teclado devem poder navegar pelos elementos de controle na tela de cima para baixo e na mesma direção horizontal do conteúdo do texto (da esquerda para a direita ou da direita para a esquerda).

A maneira mais fácil de atender a esse critério é deixar a ordem de foco padrão, que é determinada pela sequência na qual os elementos são organizados na marcação , como está. Corremos o risco de não atender a esse critério quando introduzimos discrepâncias entre a ordem visual dos elementos de controle e a maneira como eles são dispostos no código-fonte.

Você também pode gostar de: Construindo uma Navegação Breadcrumb Acessível com Liquid e Shopify.

Se usarmos a captura de tela acima como exemplo, digamos que queremos que o cartão “Atualizar tags” troque de posição com o cartão “Atualizar descrição” quando empilhados para viewports mais estreitos. Se os cartões forem renderizados como itens flexíveis, podemos considerar o uso da propriedade CSS order para alterar sua sequência em um ponto de interrupção específico.

Embora a propriedade order afete a sequência visual dos itens flexíveis, ela não atualiza sua organização no código-fonte. Como resultado, quando um usuário pressiona a tecla Tab para navegar entre cada botão, o botão “Atualizar tags” ainda receberá o foco antes de “Atualizar descrição”, mesmo que sejam exibidos na ordem inversa na tela. Isso faz com que o foco mude inesperadamente para cima e para baixo na página, criando uma experiência desorientadora para o usuário.

Uma maneira de evitar esse problema é renderizar duas versões dos cartões na marcação: uma na ordem esperada para larguras de janela de visualização mais largas e outra na ordem desejada para larguras de janela de visualização mais estreitas. Podemos usar a propriedade display para alternar entre eles em determinados pontos de interrupção.

Se não quisermos manter duas versões na marcação, precisaremos usar JavaScript para atualizar os atributos tabIndex dos cartões à medida que eles empilham na página. Dependendo do número de elementos de controle que estamos renderizando, essa abordagem pode ser mais difícil de acertar do que manter diferentes versões dos cartões na marcação.

4. Ao personalizar os estados de foco, projete para os usuários que mais precisam deles

Os navegadores usam a propriedade CSS do outline para renderizar algum tipo de indicação visual de que um elemento está em foco. Os estados de foco destinam-se a ajudar os usuários a identificar qual elemento registrará eventos de teclado enquanto eles navegam na página com um teclado.

É muito comum que designers e desenvolvedores substituam os estados de foco padrão renderizados pelos navegadores. Isso pode envolver atualizar o outline padrão ou removê-lo completamente e substituí-lo por outra propriedade CSS, como background , border , box-shadow , color ou transform .

Você também pode gostar de: Criando uma Paginação Acessível com Liquid.

No entanto, decidimos renderizar estados de foco personalizados em nossos aplicativos, devemos garantir que eles atendam aos seguintes requisitos de acessibilidade:

• Contraste de cor suficiente: deve haver contraste suficiente entre nosso estado de foco e as cores ao seu redor para que os usuários com deficiência visual possam acompanhar facilmente qual elemento está em foco no momento.
• As alterações na cor são combinadas com outros indicadores visuais: alterar a cor da borda, fonte ou plano de fundo de um elemento pode não ser perceptível para usuários com daltonismo. Ele deve ser combinado com outras mudanças visuais que não exijam que os usuários possam distinguir cores. Isso também se aplica a estados de foco e erro que envolvem alterações na cor.
• Visível em temas de alto contraste: algumas propriedades CSS, incluindo background e box-shadow , são ignoradas quando o modo de alto contraste está ativado em dispositivos Windows. Mudanças na cor também podem não ser registradas, e é por isso que é duplamente importante contar com indicadores adicionais perceptíveis para pessoas que precisam de mais contraste entre as cores de fundo e de primeiro plano.

Embora seja aceitável substituir a propriedade de outline padrão, nunca remova os estados de foco padrão sem fornecer uma substituição.

5. Forneça atalhos para usuários de teclado

Se alguém usar um mouse para navegar em uma página da Web, poderá rolar pelo conteúdo estranho do cabeçalho quando a página carregar para acessar as informações que está procurando. O processo não é tão simplificado para usuários de teclado, que podem precisar navegar por vários links de navegação ou quaisquer outros elementos de controle que vêm antes do conteúdo principal da página.

Como desenvolvedores, podemos fornecer um “link para pular” na parte superior de cada página em nosso aplicativo para permitir que os usuários de teclado ignorem os elementos de controle que precedem o conteúdo principal da página. O link de pular normalmente fica oculto até receber o foco. Ele não fica visível para as pessoas que usam o mouse para interagir com seu aplicativo, mas será o primeiro elemento a receber o foco para quem usa o teclado.

Quando o link é clicado, o foco muda para o contêiner de conteúdo principal e os usuários do teclado podem começar a navegar imediatamente pelos principais elementos de controle em uma página.

Skip links são mais do que atalhos convenientes. Eles são um exemplo de blocos de desvio, que são necessários para atender aos padrões WCAG de nível A.

Teste seu aplicativo com frequência tornando-se um usuário de teclado

Testar a acessibilidade do teclado tem uma curva de aprendizado relativamente menor para pessoas que não estão acostumadas a usar tecnologias ou dispositivos assistivos. Tudo o que você precisa é acesso a um teclado, familiaridade com os comportamentos padrão do teclado e acesso ao modo de alto contraste do Windows (adquirindo um dispositivo Windows ou instalando uma máquina virtual).

Aqui estão algumas perguntas a serem lembradas enquanto testamos nosso aplicativo para acessibilidade do teclado:

• Posso usar meu teclado para interagir com qualquer coisa que responda a cliques e gestos do mouse?
• Alguém saberá como interagir com este elemento quando ele receber o foco?
• A ordem do foco corresponde à sequência visual dos elementos interativos na página?
• Posso acompanhar qual elemento está em foco no momento, mesmo se eu precisar de um contraste maior entre as cores?
• Posso chegar facilmente ao conteúdo principal da página?

Responder “sim” a todas essas perguntas não exige muito esforço e pode ter efeitos positivos para os usuários em qualquer circunstância: sejam eles portadores de uma deficiência física, procurando maneiras de economizar tempo ou precisando usar seu computador com uma mão.

O teste de acessibilidade é um componente crucial do desenvolvimento de aplicativos. Especificamente, a acessibilidade do teclado é tão importante quanto fornecer texto alternativo para pessoas que usam leitores de tela ou legendas para pessoas que não conseguem ouvir o conteúdo de áudio. No final do dia, a capacidade de usar um mouse não deve ser necessária para usar um aplicativo se você deseja que seu aplicativo seja totalmente acessível.