Leitores de Tela e display:none

Introdução

Jim Thatcher descobriu um comportamento interessante com respeito a maneira como um leitor de tela anuncia o conteúdo de um link quando definimos para ele display: none. Normalmente os leitores de tela não anunciam conteúdos escondidos com a declaração display: none com exceção do elemento label usado para associar um rótulo a um controle de formulário.

Aprofundando um pouco mais este comportamento, existem certas situações nas quais os leitores de tela JAWS e Window-Eyes anunciam normalmente os conteúdos escondidos com a declaração display: none. As situções em que isto acontece são explicadas neste artigo, contudo para garantir acessibilidade aos leitores de tela é melhor adotar a técnica de posicionar fora da tela tais conteúdos uma vez que a técnica com display: none pode bloquear o acesso para os leitores de tela.

Índice

Escondendo conteúdo com display: none

Quando escondemos um elemento com a declaração display: none, o navegador não gera um box para ele e em consequência ele não é visto na tela e não interfere com o layout da página. Supostamente um leitor de tela deve ler a tela e assim faz sentido que ele não anuncie um conteúdo escondido com a declaração display: none.

Becky Gibson , há alguns anos atrás, descobriu que rótulos dos controles de formulários que tinham sido escondidos com a declaração display: none são lidos normalmente pelos leitores de tela JAWS and Window-Eyes (NT: link para um artigo, em inglês, sobre este assunto). Eu descobri recentemente que o leitor de tela JAWS anuncia os conteúdos do elemento span contidos no elemento a e escondido com a declaração display: none contudo o Window-Eyes não anuncia. Quando eu comentei sobre minha descoberta com Jim ele enviou para mim vários arquivos que ele estava usando nos quais os conteúdos eram lidos normalmente pelo Window-Eyes; e isto foi um mistério para nós.

Escondendo conteúdo informativo de contexto

Entenda-se como conteúdo informativo de contexto aquele que embora desnecessário para usuários sem necessidades visuais é importante para usuários navegando com um leitor de tela. Nestes caso o desenvolvedor tem necessidade de esconder visualmente o conteúdo e ao mesmo tempo garantir acesso aos leitores de tela. Por exemplo: um link do tipo "Saiba mais" em um contexto visual pode ser evidente e dispensar maiores informações contudo pode não significar absolutamente nada para usuários de leitor de tela se não for seguido de uma explicação adicional. Observe, nos códigos a seguir, uma técnica para resolver tais situações:

CSS
.contexto {display: none;}

Marcação

HTML
<a href="...">Saiba mais <span class="contexto">sobre XYZ</span></a>

O problema é que o uso da declaração display: none esconde o conteúdo tanto visualmente como para os leitores de tela (adiante voltaremos a este assunto). Para evitar isto posicionamos fora da tela o conteúdo a esconder usando a seguinte técnica:

CSS
.contexto {
  position: absolute;
  left: -999em;
  width: 1em;
  overflow: hidden;
}

Aplicando esta regra CSS na marcação mostrada anteriormente a informação contextual não aparece na tela e é acessível aos leitores de tela.

JAWS and display: none

Como já dissemos anteriomente, o JAWS anuncia conteúdos em elementos span quando contidos em um elemento a e declarados com display: none. Isto só acontece com o elemento span; outros elementos inline, tais como, em, strong, abbr, code, etc. quando contidos em um elemento a não são anunciados pelo JAWS .

Steve Faulkner fez alguns testes e descobriu que este comportamento foi introduzido na versão 7.1 do JAWS e somente no Internet Explorer .

Window-Eyes e display: none

O conteúdo mostrado na marcação a seguir é anunciado no JAWS 7.1 mais recentes quando usado o Internet Explorer, mas não é anunciado no Window-Eyes .

CSS
.contexto {display: none;}

Marcação

HTML
<a href="...">Saiba mais <span class="contexto">sobre XYZ</span></a>

Jim Thatcher notou que em alguns sites que ele examinara, conteúdos escondidos com a declaração display: none eram anunciados normalmente pelo Window-Eyes 5.5. Um inspeção cuidadosa nas CSS daqueles sites demonstrou que os conteúdos eram anunciados no Window-Eyes porque para um elemento ancestral do conteúdo havia sido declarada uma URL apontando para uma imagem de fundo com a propriedade background-image. Observe no exemplo a seguir a combinação de regras CSS que fazem display: none ser anunciado no Window-Eyes .

CSS
a {background: url(hidden.gif);}
.contexto {display: none;}

Eu suspeito que a razão para o leitor de tela anunciar o conteúdo quando uma imagem de fundo e declarada para o ancestral com uso da propriedade background-image é que o leitor procura por alternativa a uma imagem inacessível como se ali tivesse sido empregada a técnica de substituição de um texto por uma imagem tal como a técnica descrita em Fahrner Image Replacement technique explicada (mas não recomendada) por Doug Bowman.

Existem alguns pontos interessantes a considerar.

  1. Não importa se o elemento ancestral é o elemento-pai ou um elemento ancestral mais distante na hierarquia do documento — se um container do conteúdo escondido tem a propriedade background-image então display: none não impede que o Window-Eyes o anuncie.
  2. Se a propriedade background-image for declarada para o elemento body então display: none não será anunciado exceto se hover outro ancestral após o elemento body com a propriedade background-image declarada.
  3. Ao contrário do leitor de tela JAWS, o conteúdo escondido com display: none não precisa ser um elemento span contido em um elemento a; não precisa nem mesmo estar contido em um elemento a. Elementos div ou qualquer outra coisa escondida com display: none será anunciada no leitor de tela Window-Eyes desde que tenham background-image declarada para um ancestral.
  4. Se um elemento a for escondido com display: none, e tiver um ancestral com a propriedade background-image declarada, será visível para o Window-Eyes, mesmo que não esteja na ordem natural de tabulação do navegador.

Este é um comportamento bastante estranho e segundo os itens 3 e 4 pode trazer sérios problemas para os usuários do leitor de tela Window-Eyes. Se um conteúdo houver sido escondido deliberadamente de todos inclusive de leitores de tela, ainda assim aos usuários do leitor de tela Window-Eyes será anunciado o conteúdo se a propriedade background-image tiver sido declarada para um ancestral. Eu entendo o comportamento do leitor de tela JAWS que anuncia um conteúdo que não deva ser anunciado quando o elemento span é usado dentro de um link, pois neste caso o leitor esta se comportando heuristicamente com a finalidade de socorrer o usuário. O comportamento do leitor de tela Window-Eyes me parece menos cuidadoso embora, provavelmente, bem intencionado. A propriedade background-image é largamente empregada e muito mais popular que as técnicas de substituição de imagens. Páginas que escondem conteúdos de todos com uso de display: none quebram no leitor de tela Window-Eyes se hover declaração da propriedade background-image.

Atualização - apontando a solução

Jared Smith perguntou nos comentários desta matéria quais os resultados se usarmos display: none e visibility: hidden ao mesmo tempo.

Para visibility: hidden o leitor de tela JAWS se comporta exatamente como no caso do elemento span dentro de um elemento a escondido com display: none.

O leitor de tela Window-Eyes não apresenta o mesmo comportamento quendo usamos visibility: hidden. conteúdo escondido com visibility: hidden não é anunciado mesmo que para o elemento ancestral tenha sido declarada a propriedade background-image. A declaração visibility: hidden em si pode ser inconveniente e não desejada, pois ela gera um box que poderá afetar o layout. Felizmente a declaração visibility: hidden pode ser usada em conjunto com display: none e neste caso não haverá geração de box e consequente interferéncia com o layout. Assim, o comportamento estranho do leitor de tela Window-Eyes pode ser evitado quando usamos aquelas dus propriedades em conjunto como mostrado a seguir::

CSS
.hide {
  display: none;
  visibility: hidden;
}

Obrigado ao Jared por ter apontado uma solução para o problema.

Compartilhe essa matéria com seus amigos

logo twitter logo facebook logo linkedin logo reddit

Conheça os livros do Maujor®

Ir para a página de entrada nos sites dos livros.