Acessibilidade ≠ Overlay: quando um overlay interfere com o leitor de ecrã

Os leitores de ecrã apresentam por voz ou braille a informação que uma interface expõe programaticamente. Quem os utiliza aprende os seus comandos, configura preferências e cria estratégias para navegar por títulos, ligações, regiões, formulários e controlos. O W3C inclui os leitores de ecrã entre as tecnologias de apoio usadas para interagir com a Web. O ponto de partida deve ser, portanto, um site corretamente construído, e não uma tentativa da página de substituir a tecnologia do utilizador.

A interoperabilidade depende do código: HTML semântico, títulos reais, ligações e botões reconhecíveis, etiquetas associadas aos campos, nomes acessíveis, funções, estados e valores corretos, além de uma gestão coerente do foco. O W3C explica que os leitores de ecrã podem usar a estrutura de títulos para navegar e que os controlos HTML padrão favorecem a interoperabilidade. Se esta base falha, o problema está na implementação do site.

Alguns overlays injetam JavaScript de terceiros que analisa a página e tenta reparar problemas no front-end. A tecnologia de apoio pode assim receber uma versão modificada da interface. A Overlay Fact Sheet alerta que estas reparações podem tornar o carregamento mais lento ou provocar alterações inesperadas para utilizadores de tecnologias de apoio. Isso não significa que todos os overlays causem sempre a mesma falha, mas acrescenta uma variável entre o site e o leitor de ecrã.

Para quem navega sem visão, o foco determina onde está e qual elemento irá operar. Mudanças inesperadas de foco, teclas intercetadas ou semântica alterada podem causar desorientação. O mesmo acontece com títulos artificiais, nomes pouco fiáveis ou estados mal anunciados. A Overlay Fact Sheet reúne experiências de utilizadores de leitores de ecrã que descrevem saltos de foco, navegação alterada e sites mais difíceis de utilizar com o overlay ativo.

A questão não deve ser se o utilizador ativou um perfil especial, mas se o site funciona desde o início com a sua tecnologia de apoio habitual. O W3C salienta que as pessoas usam configurações e ferramentas diferentes segundo as suas necessidades e preferências. Ter de descobrir um widget, abri-lo e selecionar um modo adicional acrescenta passos sem garantir a correção das barreiras originais.

NVDA, JAWS, VoiceOver, TalkBack e outras soluções têm comandos e modos diferentes. Cada pessoa também configura voz, velocidade, pontuação, braille e preferências de navegação. É arriscado desenhar uma experiência universal de «utilizador de leitor de ecrã». A acessibilidade robusta expõe informação padrão e previsível para permitir a interoperabilidade.

Um bom título não é apenas texto grande. Um campo não é acessível apenas porque existe uma palavra visualmente próxima. Com HTML apropriado e, quando necessário, ARIA correto, o leitor de ecrã pode comunicar a estrutura e o utilizador pode navegar com os seus próprios comandos. O W3C recomenda elementos nativos sempre que possível e define ARIA para comunicar funções, estados e propriedades.

Ouvir texto não demonstra que uma página seja utilizável. É necessário testar tarefas completas: chegar ao conteúdo principal, compreender a hierarquia, utilizar menus e formulários, identificar erros, trabalhar com diálogos e componentes dinâmicos e recuperar a orientação. Também importa testar com teclado e, sempre que possível, envolver pessoas que utilizam habitualmente estas tecnologias.

Primeiro devem identificar-se as barreiras reais e corrigi-las no componente, modelo, tema ou aplicação que as gera. HTML semântico, padrões acessíveis, gestão correta do foco e testes com combinações representativas de navegador e tecnologia de apoio. A automatização pode detetar alguns problemas, mas a experiência com leitor de ecrã exige testes funcionais e humanos.

A entrega 06 centra-se numa ideia simples: o leitor de ecrã pertence ao utilizador, não ao site. O site deve oferecer uma interface sólida e previsível com a qual essa tecnologia possa interoperar. Se uma camada altera estrutura, foco ou semântica, pode transformar uma barreira conhecida noutra mais difícil de diagnosticar. A solução sustentável continua a ser corrigir a acessibilidade na origem e testar com tecnologias de apoio reais.

W3C Web Accessibility Initiative (WAI)
Tools and Techniques — How People with Disabilities Use the Web
Page Structure Tutorial
WAI-ARIA Overview

Overlay Fact Sheet
Overlay Fact Sheet — assistive technology experiences and limitations

Entrega 06 — Overlays y lectores de pantalla.