Este artigo vai explorar como os leitores de tela identificam os principais tipos de campos de formulários e dar algumas dicas de como melhorar sua acessibilidade.
Ontem tive uma conversa com o Gustavo Torniero e ele levantou uma dúvida interessante: Como certos campos semânticos de formulário se comportam com leitores de tela sem rótulos? Eu já tinha uma resposta parcial baseada em documentação, então decidi testar cada um dos tipos de campos de entrada do HTML5 com leitores de tela sem rótulos.
Sempre defendi a importância da semântica para a acessibilidade. Tecnologia assistiva consegue reconhecer certos elementos e permitem o acesso fácil por usuários com deficiência. A semântica é fundamental para manter sua aplicação mais robusta e não deixar a responsabilidade de ajustar a interface a cargo do agente de usuário.
IMPORTANTE: Os rótulos são fundamentais para que o usuário saiba quais informações preencher. O teste a seguir foi feito apenas para verificar como os leitores de tela detectam cada campo individualmente.
O teste é bem simples: Passar todos os campos de formulário do HTML5 em leitores de tela. Os campos utilizados foram os seguintes:
<input type="hidden"> <input type="password"> <input type="checkbox"> <input type="radio"> <input type="file"> <input type="submit"> <input type="image"> <input type="reset"> <input type="button"> <input type="search"> <input type="tel"> <input type="email"> <input type="url"> <input type="date"> <input type="month"> <input type="week"> <input type="time"> <input type="datetime-local"> <input type="number"> <input type="range"> <input type="color">
Em seguida, salvei o documento em HTML e passei pelos seguintes leitores de tela:
- Computador com Windows no navegador Brave: NVDA
- Celular com Android no navegador Brave: Leitor de tela da Samsung
- Celular com Android no navegador Brave: Talkback
O leitor de tela do celular acrescenta informações após o campo como “toque duas vezes para editar”. Essa informação foi retirada pois todos os resultados envolvem essa ação. Apesar do Talkback e o Leitor nativo da Samsung terem praticamente os mesmos resultados, algumas diferenças são importantes.
Passei por cada um dos campos de formulário registrando o que o leitor de tela dizia. O resultado de exibição de alguns campos me surpreendeu. A seguir apresento os resultados e alguns comentários sobre eles.
type=”text”
<input type="text">
- NVDA: Edição em branco
- Leitor de tela Samsung: Caixa de edição
Muito comum para a maioria dos campos genéricos. Sem a informação de rótulos ou descrição fica impossível saber o que o campo exige.
type=”hidden”
<input type="hidden">
- NVDA: Não é lido pelo leitor de tela
- Leitor de tela Samsung: Não é lido pelo leitor de tela
- Talkback: Não é lido pelo leitor de tela
Foi ignorado por todos os leitores de tela.
type=”password”
<input type="password">
- NVDA: Edição protegido em branco
- Leitor de tela Samsung: Caixa de edição
- Talkback: Senha. Caixa de edição
Somente o talkback informa que é uma caixa de edição de senha.
type=”checkbox”
<input type="checkbox">
- NVDA: Caixa de seleção não marcado
- Leitor de tela Samsung: Não optado caixa de seleção
- Talkback: Não selecionado caixa de edição
type=”radio”
<input type="radio">
- NVDA: Botão de opção não marcado 1 de 1
- Leitor de tela Samsung: Não selecionado botão de opção
- Talkback: Não selecionado botão de opção
type=”file”
<input type="file">
- NVDA: Nenhum arquivo selecionado. Escolher arquivo botão
- Leitor de tela Samsung: Nenhum arquivo selecionado. Escolher arquivo botão
- Talkback: Nenhum arquivo selecionado. Escolher arquivo botão
Esse campo sofre interferência do atributo lang. Se o idioma não estiver declarado adequadamente esse campo pode ser lido com o sintetizador incorreto.
type=”submit”
<input type="submit">
- NVDA: Enviar botão
- Leitor de tela Samsung: Enviar botão
- Leitor de tela Samsung: Enviar botão
- Talkback: Enviar botão
Também sofre interferência do atributo “lang.
type=”image”
<input type="image">
- NVDA: Enviar botão
- Leitor de tela Samsung: Enviar botão
- Leitor de tela Samsung: Enviar botão
- Talkback: Enviar botão
Também sofre interferência do atributo lang.
type=”reset”
<input type="reset">
- NVDA: Redefinir botão
- Leitor de tela Samsung: Redefinir botão
- Talkback: Redefinir botão
Também sofre interferência do atributo lang.
type=”button”
<input type="button">
- NVDA: Botão
- Leitor de tela Samsung: Botão
- Talkback: Botão
type=”search”
<input type="search">
- NVDA: Edição em branco
- Leitor de tela Samsung: Campo de texto da pesquisa
- Talkback: Pesquisar
Apenas o leitor de tela do celular apontou o campo como caixa de pesquisa. Nesse caso, adicionar role="search" a esse elemento pode ser uma boa sugestão.
type=”tel”
<input type="tel">
- NVDA: Edição em branco
- Leitor de tela Samsung: Caixa de edição
- Talkback: Caixa de edição
Não há informação para o leitor de tela de que ele aceita somente números. Neste caso pode ser uma boa sugestão utilizar um aria-label="inserir somente números".
type=”email”
<input type="email">
- NVDA: Edição em branco
- Leitor de tela Samsung: Caixa de edição
- Talkback: Caixa de edição
Também não há informação sobre o campo.
type=”url”
<input type="url">
- NVDA: Edição em branco
- Leitor de tela Samsung: Caixa de edição
- Talkback: Caixa de edição
type=”date”
<input type="date">
- NVDA: Edição de data.
- Dia botão de rotação zero.
- Mês botão de rotação zero.
- Ano botão de rotação zero.
- Mostrar seletor de data botão de menu submenu
- Leitor de tela Samsung: Seletor de data
- Talkback: Seletor de data
Os campos de formulário de data e hora são interessantes no NVDA. Quando navegamos por teclado ele passa por cada seletor (dia, mês, ano, hora, etc) antes de dar a opção de abrir um modal de data. Já no celular essa opção depende de interação do usuário (dois toques na tela) para selecionar a data. Pouco intuitivo.
type=”month”
<input type="month">
- NVDA: Edição de data.
- Mês botão de rotação zero.
- Ano botão de rotação zero.
- Mostrar seletor de mês botão de menu submenu
- Leitor de tela Samsung: Seletor de data e hora
- Talkback: Seletor de data e hora
type=”week”
<input type="week">
- NVDA: Edição de data.
- Mês semana de rotação zero.
- Ano botão de rotação zero.
- Mostrar seletor de semana botão de menu submenu
- Leitor de tela Samsung: Seletor de data e hora
- Talkback: Seletor de data e hora
type=”time”
<input type="time">
- NVDA: Horas botão de rotação zero.
- Minutos botão de rotação zero.
- Mostrar seletor de horário botão de menu submenu
- Leitor de tela Samsung: Seletor de hora
- Talkback: Seletor de hora
type=”datetime-local”
<input type="datetime-local">
- NVDA: Edição de data.
- Dia botão de rotação zero.
- Mês botão de rotação zero.
- Ano botão de rotação zero.
- Mostrar seletor de data botão de menu submenu.
- Horas botão de rotação zero.
- Minutos botão de rotação zero.
- Mostrar seletor de horário e data local botão de menu submenu
- Leitor de tela Samsung: Seletor de data e hora
- Talkback: Seletor de data e hora
type=”number”
<input type="number">
- NVDA: Botão de rotação editável em branco
- Leitor de tela Samsung: Botão de rotação
- Talkback: Botão de rotação
Este campo também não dá qualquer informação que ele exige somente números.
type=”range”
<input type="range">
- NVDA: Deslizante 50
- Leitor de tela Samsung: 50% 50 controle deslizante
- Talkback: 50% 50 controle deslizante
Talvez um dos mais interessantes, pois exibe a posição atual e a cada movimento informa o usuário de uma mudança de valor.
type=”color”
<input type="color">
- NVDA: Clicável 0%red, 0% green, 0%blue,
- Leitor de tela Samsung: Número zero. Seletor de cores.
- Talkback: Número zero. Seletor de cores.
No NVDA a identificação de cor é mais simples, pois ele insere o percentual e informa ao usuário. No celular isso não é tão claro, pois ele fala uma sequência numérica que não consegui compreender.
Conclusão:
Apesar de serem amplamente suportados por leitores de tela e navegadores, alguns dos tipos de formulário não transmitem toda informação semântica para o usuário. Isso não significa que eles não são importantes (por exemplo, os campos "tel" e "number" exibem somente o teclado numérico quando selecionado em um celular). Não esqueça dos rótulos e de utilizar o elemento "label" para relaciona-lo aos seus respectivos campos.
Há também um site que mostra como anda a implementação de acessibilidade pelos navegadores, o que inclui os input type. É o https://www.html5accessibility.com/
Se você quiser fazer o teste com uma combinação de dispositivo, navegador e leitor de tela diferente, o arquivo com todos os campos está disponível neste link.
Créditos da imagem: Design vector created by freepik – www.freepik.com
