Deixando o botão acessível para leitores de tela
É muito comum no nosso dia a dia criarmos componentes de interfaces de forma customizada, com um estilo diferente daquele padrão que já vem nativo com os elementos HTML.
Nesta postagem, iremos abordar a acessibilidade apenas no botão, em como deixá-lo acessível, principalmente para usuários de leitores de tela.
Mas qual é a função de um botão?
Segundo o Guia da WCAG, um botão é:
[…]um widget que permite aos usuários acionar uma ação ou evento, como enviar um formulário, abrir uma caixa de diálogo, cancelar uma ação ou executar uma operação de exclusão.
O botão é diferente do link! O link tem a finalidade de redirecionar o usuário para uma nova página ou localmente, e deixar esta informação clara é muito importante para usuários de leitores de tela.
1 - Utilizar o elemento <button>
O elemento <button> além de ser semanticamente apropriado, já contém diversas funcionalidades prontas que os leitores de tela já compreendem. Por exemplo:
- você não precisa colocar o tabindex nele, isso já é nativo.
- o leitor de tela lê como título do botão o texto que se encontra dentro dele.
- o leitor de tela já o identifica com um botão para o usuário.
Este elemento já vem com um estilo pronto que pode ser modificado facilmente via CSS.
2 - Colocar rótulos em botões sem nomes
Existem situações em que colocamos um texto ou um ícone que visualmente é intuitivo, como por exemplo o clássico “x” nos componentes de diálogo.
Para deixar este componente mais descritivo para os leitores de tela, podemos utilizar o atributo aria-label, da seguinte forma:
3 - Botão desabilitado
Existem duas maneiras de desabilitar um botão, que refletem em comportamentos diferentes:
1- Utilizando a propriedade disabled:
Ao utilizá-lo, o botão não entrará no fluxo de tabulação. Então, ao utilizar a tecla tab, ele não estará disponível para o usuário.
2 - Utilizando a propriedade aria-disabled:
Neste caso, o botão continua no fluxo de tabulação e, ao encontrá-lo, o leitor de tela dirá ao usuário algo parecido com: “Botão cancelar não disponível”.
Desta forma, você traz um feedback ao usuário de que existe um botão. No entanto, ele está desabilitado por algum motivo, que pode ser um formulário incompleto. Para saber mais, veja o exemplo de aria-disabled do A11Y-101.
4 - Adicionar uma descrição extra/complementar
Imagine que você precisa adicionar uma descrição complementar ou uma observação importante para o usuário que irá utilizar aquele botão. Você pode fazer isso utilizando o atributo aria-describedby. E você pode utilizá-lo da seguinte forma:
5 - Deixar uma <div> com função de botão
Se por alguma razão você não puder utilizar o elemento <button>, você pode dar esta funcionalidade para outro elemento através do atributo role=”button”.
No entanto, este atributo não trará consigo todas as vantagens de se utilizar o <button>, como a tabulação automática, por exemplo.
6 - Fazer um botão do tipo on/off
Existem alguns botões que têm a função de habilitar ou desabilitar algo, por exemplo um botão play/stop para ouvir uma música. Para isso, pode ser utilizado o atributo aria-pressed dentro do <button>.
Este atributo irá dizer ao usuário se o botão está “ligado” (pressionado) ou desligado (não pressionado).
7 - Interação com o teclado
A ativação do botão também deve estar disponível via teclado. Afinal, nem todos os usuários utilizam o mouse, não é mesmo?
Segundo a WCAG, a interação com o teclado deve ser da seguinte forma:
- Space: ativa o botão.
- Enter: ativa o botão.
- Deve ser um elemento que receba foco(tab).
Após a ativação do botão, o foco é novamente definido para:
- Se a ativação do botão abrir uma caixa de diálogo, o foco deverá ser movido para dentro da caixa de diálogo.
- Se a ativação do botão fechar uma caixa de diálogo, o foco normalmente retorna ao botão que abriu a caixa de diálogo, a menos que a função executada no contexto da caixa de diálogo conduza logicamente a um elemento diferente.
- Se a ação do botão indicar uma alteração de contexto, como mover para a próxima etapa em um assistente ou adicionar outro critério de pesquisa, geralmente é apropriado mover o foco para o ponto inicial desta ação.
8 - Faça testes em um leitor de tela
É sempre muito importante testar as funcionalidades em um leitor de tela. Já aconteceu algumas vezes onde eu coloquei um atributo para torná-lo acessível e quando fui testar no leitor de tela o resultado não era bem o que eu esperava. Tanto no sentido de não estar funcionando, porque alguma outra funcionalidade estava interferindo, quanto a ordem dos textos que eu tinha colocado poderia dificultar ainda mais aos usuários.
Então, duas regras de ouro na acessibilidade:
- Utilize os seus componentes de interface em um leitor de tela.
- É necessário realizar testes manuais com os usuários.
Para concluir…
Sempre que possível, podemos utilizar os elementos nativos do HTML para poder deixar os nossos sistemas acessíveis.
Tem bastante conteúdo e dicas na internet que podem te auxiliar nesta etapa de desenvolvimento!
Fique ligado no guia de boas práticas do próprio WCAG. Neste material há exemplos e dicas valiosas para deixar os seus componentes ainda mais acessíveis.
