Uma coisa que você pode fazer para melhorar a acessibilidade do seu trabalho é sempre garantir que as coisas tenham nomes acessíveis . Nomes únicos e úteis, idealmente, para que possam ser usados para navegação. Neste post, explicarei como os navegadores decidem os nomes de links, campos de formulário, tabelas e grupos de formulários.
Este post é baseado em parte da minha palestra 6 maneiras de tornar seu site mais acessível , que eu dei no WordCamp Roterdão na semana passada (eu adoraria repeti-lo, sinta-se à vontade para entrar em contato).
Árvore de Acessibilidade
Quando um usuário acessa seu site, o servidor enviará uma marcação para o navegador. Isso se transforma em árvores. Provavelmente todos estamos familiarizados com a árvore DOM, uma representação dinâmica de sua marcação, com todos os nós transformados em objetos nos quais podemos ler propriedades e executar todos os tipos de funções.
O que muitas pessoas não sabem é que existe uma segunda estrutura que o navegador pode gerar: a árvore de acessibilidade. Ele é baseado na árvore DOM e contém toda a relação de meta-informação relacionada à acessibilidade: funções, nomes e propriedades. Outra maneira de dizê-lo: a árvore de acessibilidade é como sua página fica exposta a tecnologias assistivas.
Tecnologia assistiva
A Tecnologia Assistiva (AT) é um termo abrangente para todos os tipos de ferramentas que as pessoas usam para melhorar a maneira como acessam as coisas. Para computadores e a web, eles incluem:
- dispositivos apontadores alternativos, como um mouse que se conecta à cabeça do usuário
- ampliadores de tela, eles aumentam a tela
- barras de braile, eles transformam o que está na tela em braile
- leitores de tela, eles lêem o que está na tela para o usuário
Todas essas ferramentas, para funcionar de forma eficiente, precisam saber o que está acontecendo na tela. Para descobrir, eles acessam as APIs da plataforma, integradas em todas as principais plataformas, incluindo Windows, Mac e Linux. As APIs podem expor tudo no sistema operacional, para que eles saibam sobre coisas como a barra de início, o Dock ou o botão Voltar do navegador. Uma coisa que eles não conhecem são os sites que você acessa. Eles não podem ter a estrutura semântica de cada site embutido em suas APIs, então eles dependem de um intermediário – é onde entra a Árvore de Acessibilidade. Ela expõe a estrutura do seu site. Como eu disse, é baseado no DOM, que é baseado no nosso mark-up.
Um fluxograma útil
A árvore de acessibilidade expõe funções (isto é, um cabeçalho, um rodapé, um botão, uma navegação?), Nomes (eu entrarei em um pouco), propriedades (é o menu de hambúrguer aberto ou fechado, é a caixa de seleção marcada ou não, et cetera) e uma série de outras coisas.
Se você quiser ver como isso fica em um site de sua escolha, dê uma olhada no Painel de acessibilidade do Firefox Developer Tools ou confira as caixas de informações de acessibilidade no Chrome, Safari Tech Preview ou Edge developer tools.
Computação de nome acessível
Os nomes são uma das coisas que a árvore de acessibilidade expõe para seus objetos. O nome de uma coisa é derivado da marcação. Existem muitos aspectos que podem influenciar isso. Se você quiser saber isso em detalhes, confira o Nome Acessível e Descrição da Especificação de Computação .
Nomes exclusivos ajudam a distinguir
Antes de entrar mais em como expor nomes, vamos ver quais nomes queremos. Quais são os nomes é crucial para saber se eles são acessíveis ou não.
E se sua família tiver quatro gatos e cada um deles for chamado de “Alice”? Isso seria incrivelmente impraticável, pois dificultaria a comunicação. “Alice já foi alimentada?”, Você pode se perguntar. “Alice está do lado de fora?”, Você pode perguntar ao seu parceiro. Ambiguidade é impraticável. No entanto, isso é o que fazemos quando nossa página inicial tem quatro itens de notícias, com cada “Leia mais” como o texto do link.
Imagine que todos os seus gatos foram chamados de Alice (foto: stratman2 no Flickr)
Isso é muito comum, infelizmente. No projeto WebAIM Million , no qual o WebAIM analisou mais de um milhão de sites e executou verificações de acessibilidade automatizadas, eles descobriram:
24,4% das páginas tinham links com texto de link ambíguo, como “clique aqui”, “mais”, “continuar”, etc.
Reutilizar “Ler mais” como o texto do link para cada item de notícia torna nosso código e gerenciamento de conteúdo mais simples, mas fornece uma usabilidade ruim para os usuários do leitor de tela. Quando eles usam o atalho de link para navegar pelos links na página, eles não têm ideia de onde cada link os leva. No exemplo acima, quando você pede a um AT para ler todos os links, ele lerá “Link Leia mais, Link Leia mais, Link Leia mais, Link Leia mais”.
Nomeando coisas
Portanto, nomes exclusivos e descritivos são úteis para usuários de AT. Vamos ver qual HTML pode nos ajudar a fornecer nomes. Como eu disse antes, as heurísticas para determinar nomes estão em uma especificação , mas com apenas HTML fornecendo nomes para a maioria das coisas é trivial. A seção a seguir é mais útil para pessoas cujo HTML está enferrujado.
Links
O conteúdo de um <a>elemento geralmente se tornará o nome acessível.
Então em:
<a href="/win-a-prize">Win a prize</a>o nome acessível seria computado como “Ganhe um prêmio”.
Se houver apenas uma imagem, seu texto alternativo também pode ser usado:
<a href="/win-a-prize"><img src="prize.png" alt="Win a prize" /></a>E, para ser claro, se não há nada fornecido, o nome seria nullou string vazia, então algumas pessoas seriam incapazes de ganhar qualquer prêmio.
Campos de formulário
Campos de formulário são rotulados usando o <label>elemento. Na pesquisa acima mencionada, a WebAIM também encontrou:
59% das entradas de formulário não foram devidamente rotuladas.
Vamos ver como poderia ser um erro de rotulagem:
<div>Email</div> <!-- don't do this-->
<input type="email" id="email" />Neste exemplo, a palavra “E-mail” aparece logo antes da entrada, para que uma parte dos usuários possa associá-los visualmente. Mas eles não estão associados , então a entrada não tem nome – ela será computada como nullou ''na árvore de acessibilidade.
A associação pode ser feita agrupando a entrada em um <label>elemento ou usando um foratributo que corresponda ao idatributo da entrada :
<label for="email">Email</label> <!-- do this-->
<input type="email" id="email" />Tabelas
Para dar um nome a uma tabela, você pode usar seu <caption>elemento. Isso é usado como o primeiro elemento em um <table>.
Grupos em um formulário
Nos formulários, às vezes você deseja agrupar um conjunto de entradas de formulário, por exemplo, uma coleção de botões de opção ou caixas de seleção que respondem à mesma pergunta. HTML tem <fieldset>para agrupar elementos de formulário. Para nomear este grupo como um todo, use o <legend>elemento:
<fieldset>
<legend>Don't you love HTML?</legend>
<input type="radio" name="yesno" id="yes"/>
<label for="yes">Yes</label>
<input type="radio" name="yesno" id="no"/>
<label for="no">No</label>
</fieldset>Se você fosse inspecionar este fieldset na árvore de acessibilidade, você notará que o grupo agora é conhecido como “Você não ama HTML?”.
E quanto ao ARIA?
Aqueles que estão familiarizados com as especificações de Computação e Nome Acessível podem se perguntar neste ponto: o ARIA também não nos permite dar elementos a nomes acessíveis? Faz totalmente, por exemplo, através dos aria-label/ aria-labelledbyatributos. Quando adicionados a um elemento, eles sobrescrevem o nome acessível (se houver um).
Boas razões para preferir tags HTML padrão sobre o ARIA incluem:
- melhor suporte ao navegador (muitos navegadores suportam a maioria dos ARIA, mas todos suportam HTML, geralmente falando)
- maior probabilidade de ser entendido por membros atuais ou futuros da equipe que não possuem todas as habilidades do ARIA
- menos provável de ser esquecido quando faz coisas como internacionalização (no seu próprio código, ou por ferramentas externas como o Google Translate, veja o post aria-label de Heydon Pickering é um xenófobo )
Às vezes, o ARIA pode ser útil, por exemplo, se um elemento não funcionar bem com o seu CSS (como se você quiser um Layout de Grade em um fieldset), ou se o CMS (do seu cliente) for muito inflexível.
É a marcação que importa
Nos navegadores modernos, nossa marcação se torna uma árvore de acessibilidade que, por fim, informa qual é a aparência de nossa interface para as tecnologias de assistência. Não importa muito se você escreveu essa marcação:
- em um
.htmlarquivo - no galho, guiador ou Nunjucks
- como o
<template>componente de um único arquivo do Vue - exportado no JSX do seu componente React
- produzido por um legado CMS estranho
É que de marcação que determina se o site é agradável a experiência para os usuários da AT. Resumindo: é a marcação que importa
Existe uma boa chance de o seu site já usar todos os elementos HTML acima mencionados. Eles existem há muitos anos. Mas espero que este post explique por que vale a pena o esforço de sempre garantir o código que seu site serve aos usuários, incluindo nomes úteis para tecnologias assistivas. Marcação-sábio é trivial para atribuir nomes a todas as coisas em nosso site, o verdadeiro desafio é provavelmente duas vezes. É sobre o conteúdo (criamos nomes úteis e distintos) e sobre tecnologia (podemos garantir que a marcação correta entre nos DOMs de nossos usuários).