Ocultar conteúdo contra tecnologia assistiva
aria-hidden
Outra técnica importante no ajuste fino da experiência para usuários de tecnologia assistiva envolve garantir que apenas partes relevantes da página sejam expostas à tecnologia assistiva. Existem várias maneiras de garantir que uma seção do DOM não seja exposta às APIs de acessibilidade.
Primeiro, tudo o que estiver explicitamente oculto do DOM também não será incluído
na árvore de acessibilidade. Portanto, qualquer coisa que tenha um estilo CSS de visibility:
hidden
ou display: none
ou use o atributo hidden
do HTML5 também será
oculto para usuários de tecnologia assistiva.
No entanto, um elemento que não seja renderizado visualmente, mas não é explicitamente oculto, ainda é incluído na árvore de acessibilidade. Uma técnica comum é incluir "texto somente para leitor de tela" em um elemento que é absoluto posicionado fora da tela.
.sr-only {
position: absolute;
left: -10000px;
width: 1px;
height: 1px;
overflow: hidden;
}
Além disso, como vimos, é possível fornecer texto somente para leitor de tela por meio de um
atributo aria-label
, aria-labelledby
ou aria-describedby
que referencia um
elemento oculto.
Consulte este artigo do WebAIM sobre Técnicas para ocultar texto para mais informações sobre a criação de texto "somente para leitor de tela".
Por fim, ARIA fornece um mecanismo para excluir conteúdo de tecnologia
adaptativa que não seja visualmente oculto, usando o atributo aria-hidden
.
Aplicar esse atributo a um elemento o remove e todos os
descendentes da árvore de acessibilidade. As únicas exceções são elementos
referidos por um atributo aria-labelledby
ou aria-describedby
.
<div class="deck">
<div class="slide" aria-hidden="true">
Sales Targets
</div>
<div class="slide">
Quarterly Sales
</div>
<div class="slide" aria-hidden="true">
Action Items
</div>
</div>
Por exemplo, você pode usar aria-hidden
se estiver criando uma IU modal que
bloqueia o acesso à página principal. Nesse caso, um usuário que enxerga pode ver algum tipo
de sobreposição semitransparente, que indica que a maior parte da página não
pode ser usada atualmente, mas um usuário de leitor de tela ainda pode
conseguir acessar as outras partes
da página. Nesse caso, além de criar a armadilha de teclado explicada
anteriormente,
é necessário garantir que as partes da página que estão atualmente fora do escopo
também sejam aria-hidden
.
Agora que você entende os conceitos básicos de ARIA, como ele joga com semântica de HTML nativa, e como pode ser utilizado para realizar cirurgias bastante importantes na árvore de acessibilidade, além de alterar a semântica de um único elemento, vejamos como podemos usá-lo para transmitir informações que dependem do tempo.
aria-live
aria-live
permite que os desenvolvedores marquem uma parte da página como "ativa" no sentido de que
as atualizações precisam ser comunicadas aos usuários imediatamente, independentemente da posição
da página, em vez de fazê-lo apenas se elas exploram essa parte da página. Quando
um elemento tem um atributo aria-live
, a parte da página que o contém e
seus descendentes é chamada de região ativa.
Por exemplo, uma região ativa pode ser uma mensagem de status que aparece como resultado de
uma ação do usuário. Se a mensagem for importante o suficiente para chamar a atenção
de um usuário que não enxerga, é importante definir o atributo aria-live
para direcionar a atenção de um usuário de tecnologia adaptativa. Compare este div
<div class="status">Your message has been sent.</div>
com sua contraparte "ativa".
<div class="status" aria-live="polite">Your message has been sent.</div>
aria-live
tem três valores permitidos: polite
, assertive
e off
.
aria-live="polite"
informa à tecnologia assistiva para alertar o usuário sobre esta mudança assim que tiver terminado o que quer que esteja fazendo atualmente. É ótimo para ser usado se algo é importante, mas não urgente, e é responsável pela maioria do uso dearia-live
.aria-live="assertive"
informa à tecnologia assistiva para interromper o que quer que esteja fazendo e alertar o usuário sobre essa mudança imediatamente. Isso é válido apenas para atualizações importantes e urgentes, como uma mensagem de status como "Ocorreu um erro no servidor e suas alterações não foram salvas. Atualize a página" ou atualizações em um campo de entrada como resultado direto de uma ação do usuário, como botões em um widget de acompanhamento.aria-live="off"
informa à tecnologia assistiva para suspender temporariamente as interrupções dearia-live
.
Há alguns truques para garantir que suas regiões ativas funcionem corretamente.
Em primeiro lugar, a região aria-live
provavelmente precisa ser definida no carregamento inicial da página.
Esta não é uma regra rígida, mas se você tiver dificuldade com uma
região aria-live
, este pode ser o problema.
Em segundo lugar, leitores de tela diferentes reagem de forma diferente a diferentes tipos
de mudanças. Por exemplo, é possível acionar um alerta em alguns leitores de tela
alternando o estilo hidden
de um elemento descendente de verdadeiro para falso.
Outros atributos que funcionam com aria-live
ajudam a ajustar o que
é comunicado ao usuário quando a região ativa muda.
aria-atomic
indica se a região inteira precisa ser considerada como um todo ao comunicar atualizações. Por exemplo, se um widget de data que consiste em um
dia, mês e ano tiver aria-live=true
e aria-atomic=true
, e o usuário
usar um controle de passo para mudar o valor apenas do mês, o conteúdo completo
do widget de data será lido novamente. O valor de aria-atomic
pode ser true
ou false
(padrão).
aria-relevant
indica que tipos de mudanças devem ser apresentadas ao usuário.
Existem algumas opções que podem ser usadas separadamente ou como uma lista de tokens.
- adições, o que significa que qualquer elemento adicionado à região ativa é
significativo. Por exemplo, adicionar um span a um registro de mensagens
de status significaria que o span seria anunciado para o usuário (supondo
que
aria-atomic
fossefalse
). - text, o que significa que o conteúdo de texto adicionado a qualquer nó descendente é
relevante. Por exemplo, modificar a propriedade
textContent
de um campo de texto personalizado leria o texto modificado para o usuário. - remoções, o que significa que a remoção de qualquer texto ou nós descendentes precisa ser transmitida ao usuário.
- todos, o que significa que todas as mudanças são relevantes. No entanto, o valor padrão para
aria-relevant
éadditions text
, o que significa que, se você não especificararia-relevant
, ele vai atualizar o usuário sobre qualquer adição ao elemento, que é o que você provavelmente quer.
Por fim, aria-busy
permite notificar a tecnologia assistiva que ela deve
ignorar temporariamente mudanças em um elemento, como quando as coisas estão carregando. Quando
tudo estiver no lugar, aria-busy
precisa ser definido como falso para normalizar a
operação do leitor.