Facilitar o preenchimento de formulários é fundamental para aplicações em dispositivos móveis. Existem atributos que nos ajudam nessa tarefa, mas com relação a acessibilidade, o que é melhor usar? inputmode ou o input type específico?
Sempre defendi que devemos deixar nossos campos de formulário mais amigáveis, afinal, é onde obtemos de forma voluntária informações e dados dos nossos usuários. Considerando que a navegação nos campos deve ser feita nos mais diversos dispositivos e situações decidi pesquisar as diferenças dos atributos “inputmode” e os “<input type>” para o usuário final.
Para quem não sabe, inputmodeé um atributo global que permite que o dispositivo móvel ofereça ao usuário o teclado adequado para sua digitação, por exemplo, em um campo de telefone oferecer somente o teclado numérico. Esse atributo pode ser usado nos elementos <input> ou em outro qualquer outro elemento com o atributo contenteditable.
Já o uso do “<input type>” está relacionado ao tipo de dado exigido no campo e vem desde a primeira versão do HTML5. Esse atributo carrega carga semântica quando usamos um “type=tel” por exemplo, além de também mudar o teclado para numérico.
A diferença entre eles é que o inputmode não muda a forma como o navegador interpreta o campo de entrada. Apenas muda o teclado em dispositivos móveis. Para adicionar significado ao campo o ideal é usar um “<input type>” apropriado.
A partir disso, criei alguns campos de formulário para testar a diferença entre eles com relação a acessibilidade. Foram criados os seguintes campos:
<input type="text" inputmode="numeric">
<input type="number">
<input type="text" inputmode="tel">
<input type="tel">
<input type="text" inputmode="search">
<input type="search">
<input type="text" inputmode="email">
<input type="email">
<input type="text" inputmode="url">
<input type="url">
Os campos foram criados sem rótulos relacionados. O objetivo é entender como funciona o acesso de um leitor de tela somente nos campos.
Os testes foram conduzidos com software leitor de tela pelo computador (Windows com NVDA e JAWS) e smartphone (Android com talkback no Chrome/Firefox/Brave). O resultado foi o seguinte:
Resultados no computador
- No computador somente o
<input type="number">aponta diferença para usuário de leitor de tela. Ele informa ao usuário que há “botão de rotação editável em branco”. Os demais campos testados são lidos como campos de entrada de texto comum em ambas as modalidades (inputmodeeinput type).
Resultados no smartphone
- numeric/number: Em ambos o teclado numérico é exibido da mesma forma. A única diferença é que no
inputmodeum dos botões dá opção de uso de ponto ou hífen. No<input type="number">o botão só permite o uso do ponto. Para o leitor de tela (talkback) ele trata o campo doinputmodecomo texto enquanto que no<input type="number">ele lê como “botão de rodação”. - tel: Não há diferenças entre os campos na exibição do teclado e na leitura do leitor de tela.
- search: No
inputmodeo teclado exibe o símbolo da tecla “enter” e o talkback lê como um campo texto. No<input type="search">ele muda para uma lupa e quando usamos o talkback ele lê “campo de texto da pesquisa”. No firefox não há mudança no áudio do leitor de tela. - email e url: Existem poucas diferenças na exibição dos navegadores. No Chrome os campos com
inputmodehabilitam as letras maiúsculas para a primeira digitação. No Firefox ambos começam com minúscula. Não há diferença entre eles no uso com leitores de tela.
Validação de markup
Passei o código na ferramenta de verificação de marcação do W3C para registrar o resultado. Obtive apenas o seguinte aviso:
Warning: The inputmode attribute is not supported in all browsers. Please be sure to test, and consider using a polyfill.
Conclusão:
Há pouca diferença entre o uso dos atributos inputmode e <input type> para a acessibilidade e usabilidade. Para transmitir informação semântica do tipo de campo é recomendado o uso do "input type" adequado. Porém em alguns casos o "input type" específico pode impor algumas limitações, como campos numéricos que podem exigir alguns caracteres específicos como o hífen. Se o uso é apenas para a exibição de um teclado mais apropriado o inputmode pode ser uma solução, principalmente em campos além do <input> como os que fazem uso de atributos contenteditable.
A escolha também deve acompanhar o suporte dos dispositivos. O CanIUse mostra como está o suporte dos navegadores para o atributo inputmode e o input type. Importante também acompanhar o suporte a acessibilidade desses recursos nos navegadores pelo site html5accessibility.com.
Esse teste serviu para mostrar que campos de formulário sem descrição são ruins para a acessibilidade. Para tecnologias assistivas eles são apenas campos sem orientação. O mais importante para a acessibilidade é a relação entre os campos e seus rótulos. Nunca esqueça de relacionar o campo com seu rótulo pelo elemento <label> e atributo "for".
Crédito das imagens: Freepik.com
