Acessibilidade na HTML5

Introdução

Em muitos países, prover acessibilidade para pessoas com necessidades especiais é uma disposição legal. Desenvolver com a preocupação de contemplar a acessibilidade é uma das características que diferencia um verdadeiro profissional web de um iniciante. Para muitos, acessibilidade é uma espécie de magia-negra que obriga o desenvolvimento de trabalho extra no código, tal como acréscimos de textos alternativos, de sumários para tabelas, de informações ARIA difíceis de serem testadas por não usuários de tecnologias assistivas.

A HTML5 chegou para por mais lenha na fogueira. Para alguns HTML5 é a salvação do mundo. Para outros – incluindo aí muitos profissionais de acesssibilidade – ela é a própria personificação do demônio.

Na verdade, como você mesmo já deve ter concluido, nenhum destes extremos retrata com precisão a realidade. Mas, a história da acessibilidade na HTML5 é bem interessante.

Uma das providências básicas no sentido de ajudar os usuários de tecnologias assistivas (e também para melhorar o ranqueamento nos dispositivos de busca e incrementar seu karma) é usar marcação semântica — use o elemento certo para cada conteúdo, aquele que descreva seu significado (do conteúdo) e não sua forma de apresentação.

Antigamente para marcar a delimitação de estruturas em uma página - topo, rodapé, blocos de navegação - o único elemento disponível era <div>, que não tem qualquer valor semântico. Leitores de tela, como o JAWS, possuem uma funcionalidade denominada navegação pelo teclado (keyboard navigation) que possibilita ao usuário navegar com facilidade pelos cabeçalhos, listas, blockquotes e tabelas desde que convenientementes marcadas com suas respectivas tags HTML. Contudo, tal facilidade não é possível quando se trata de navegar, por exemplo, entre blocos de navegação (marcados com o elemento div), porque uma vez marcados com um elemento não semântico não há como grupá-los e incluí-los em um esquema diferenciado de navegação.

A HTML5 ampliou consideravelmente o repositório de elementos da HTML4 – agora, para aplicar semântica em áreas estruturais de um página nós temos os elementos <header>, <footer>, <nav>, <article>, <section>, <aside> e <figure> que vieram para socorrer nosso velho <div>.

Uma estrutura baseada em elementos div (que é a única possível com uso de HTML4) é conforme mostrada a seguir:

A mesma estrutura com uso dos novos elementos HTML5 passa a ser marcada assim:

Agora, se um leitor de tela ou outro agente de usuário qualquer quiser oferecer a facilidade de ir direto para <nav> (ou pular) existe uma marcação semântica na página permitindo implementar a funcionalidade. Isto não é vantajoso somente para a acessibilidade. Por exemplo: um navegador poderá disponibilizar uma função para impressão que possibilite ao usuário imprimir somente os conteúdos dos elementos <article> deixando fora da impressão blocos <nav> e outros que não interessam.

Convém ressaltar que tais funcionalidades ainda não existem nos navegadores atuais, mas as condições para implementação delas estão criadas, uma vez que a marcação dos blocos estruturais importantes do site agora estão identificados com elementos semânticos.

Para saber mais sobre os novos elementos estruturais da HTML5 leia o artigo escrito — em inglês — pelo autor desta matéria: Redesigning with HTML 5 and WAI-ARIA e o artigo de Emily Lewis Using HTML5's New Semantic Tags Today.

WAI-ARIA

Os benefícios trazidos pelos elementos estruturais da HTML5 ainda não estão explorados em suas plenas potencialidades. Contudo, tecnologias assistivas já podem tirar proveito de um mecanismo similar, denominada WAI-ARIA, destinado a identificar estruturas importantes em uma página. ARIA não faz parte da HTML5; é uma especificação desenvolvida peloW3C e neste artigo nós não iremos nos aprofundar nas suas funcionalidades (ver um matéria em inglês escrita por Gez Lemon denominda Introduction to WAI ARIA), mas o conceito central da WAI-ARIA é o chamado Document Landmark Roles, que em tradução livre significa: função de um bloco de marcação no documento - conceito este que prevê uma marcação específica para tais blocos. Para cumprir suas finalidades ARIA usa atributos e não elementos uma vez que foi projetada para ser usada com qualquer linguagem de marcação e não apenas com a HTML — pode ser usada, por exemplo, com marcação SVG ou Adobe MXML.

Observe a seguir uma página HTML4 cuja estrutura foi marcada com uso de atributos ARIA:

Usar ARIA na marcação HTML4 melhora a acessibilidade, mas a página não valida. Por estar a HTML5 ainda em fase de desenvolvimento os atributos ARIA validarão na HTML5. E, não somente isto, existem certas correspondencias entre as duas especificações e determinados elementos da HTML5 têm funções ARIA intríncecas (built-in ARIA roles) que não podem ser sobrescritas por atributos ARIA.

O validador da HTML5 é capaz de identificar tais funções e vai rir da sua cara se você tentar codificar: <header role=navigation> ou <footer role=banner>. Isto é ótimo e uma grande vantagem sobre a HTML4 na qual ARIA não valida. Contudo, seja precavido, pois ARIA e HTML5 ainda estão em fase de discussões e o validador pode ser alterado a qualquer momento.

Acessibilidade à multimídia

Um dos aspectos da HTML5 é o suporte nativo que ela oferece para funcionalidades multimídia. Todos os navegadores oferecem controles nativos para vídeo (play/pause, seek bars, volume controls) da mesma forma que oferecem barras de rolagem e controles de formulários. Oferecer controles multimídia nativos em lugar da necessidade de plugins é uma vantagem para acessibilidade, pois a mídia é parte do navegador. Os navegadores Opera e Firefox oferecem controles nativos capazes de serem acionados por usuários de teclado. Muitas pessoas com restrições motoras ou visuais estão impossibilitadas de usar o mouse.

A HTML5 media elements API (API HTML5 para elementos de mídia) possibilita aos desenvolvedores criar controles de mídia personalizados. Se você pretende se valer desta possibilidade nós o encorajmos vivamente a usar elementos semânticos tais como, <button> para controles play/pause e os mecanismos criados pelos novos elementos input da HTML5 como <input type=range> para um slider de volume, pois são acessíveis pelo teclado por padrão. Para mais informações leia a matéria (em inglês) Patrick H Lauke's fancy video controls e observe que além de transições, opacidade, web font das CSS3 temos também elementos de formulário da HTML4 e um slider cortesia de input type="range" da HTML5 conforme mostrado a seguir:

<div id="controls">
  <button id="playpause">
    <img src="play.png" width="15" height="15" alt="play"/> 
  </button>
  <output id="display">0:01:55</output>
  <img src="audio.png" width="15" height="15" alt="volume" id="volumeicon"/> 
  <input type="range" min="0" max="10" id="volume"/>
</div>

Obviamente os controles de vídeo e áudio somente serão úteis se os usuários puderem perceber o que está se passando durante a reprodução. Os Grupos de Trabalho estão desenvolvendo mecanismos para adicionar legendas, títulos, e textos à maneira karaokê com uso doelemento <track> (<track> element) conforme mostrado a seguir:

<video controls>
  <source src=movie.webm>
  <source src=movie.mp4>
  <track src=english.vtt kind=captions srclang=en>
  <track src=french.vtt kind=captions srclang=fr>
  <p>Texto alternativo aqui com link para download do vídeo</p>
</video>

O exemplo mostra duas trilhas (track) de legendas para o vídeo, uma em inglês e outra em francês. Os navegadores deverão prover um mecanismo nativo capaz de possibilitar ao usuário selecionar uma das trilhas. O elemento <track> não supõe nenhum formato particular, mas é provável que os navegadores comecem a implementar o novo formato WebVTT format baseado no formato .SRT. Este formato está em fase de desenvolvimento pelo WHATWG e vem recebendo uma quantidade incrível de feedback de pessoas que realmente conhecem o assunto, tais como da BBC e do Google, a organização que provalvemente é a mais experiente em fornecimento de vídeo para a web via YouTube.

WebVTT é muito simples e oferece a possibilidade de criar textos em negrito, itálico, colorido, Ruby annotations, textos na vertical para idiomas asiáticos e até posicionar textos na viewport.

A Dra. Silvia Pfeiffer realizou uma excelente apresentação denominada WebVTT explained que nós recomendamos. Silvia associou WebVTT transcript com um vídeo e usou um código JavaScript open-source denominado Captionator polyfill para prover suporte pelos navegadores, uma vez que ainda não há suporte nativo para esta API.

O W3C também desenvolve uma API denominada Multitrack Media API specification que possibilitará criar informação não textual sincronizada com a mídia provendo assim acessibilidade à trilhas para linguagem de sinais (LIBRA), descrições em áudio, dublagem, ângulos de visão alternativos é demais trilhas similares para vídeo e áudio. Isto é uma novidade excitante.

Canvas

Tal como outros aspectos da acessibilidade na HTML5, (HTML5 accessibility) a acessibilidade a canvas também é um trabalho em andamento. Funcionalidades para prover suporte a acessibilidade a canvas estão ainda em fase de desenvolvimento e algumasn que já foram desenvolvidas (features that are specified), são parcialmente suportada pelos navegadores (limited implementation).

Isto não significa que os desenvolvedores não possam prover acessibilidade quando projetam canvas.

Exemplo de canvas:

<canvas id="example" width="260" height="200" role="img">
 <p><a href="https://en.wikipedia.org/wiki/Rectangle">Retângulo</a> com uma borda
 preta. No fundo há um círculo na cor rosa.Sobrepondo parcialmente o círculo há
 um quadrado na cor verde e um triângulo na cor púrpura e ambos são transparentes 
 de modo que o círculo pode ser visto atrás deles.</p>
</canvas>

Para o exemplo mostrado a especificação para a HTML5 (HTML5 specification) sugere o uso de conteúdo alternativo a ser inserido no elemento canvas:

Ao usar o elemento canvas os autores devem prover conteúdos que, quando expostos ao usuário, transmitam os mesmos propósitos e funções existentes no bitmap de canvas. Tais conteúdos devem ser inseridos na marcação dentro do elemento canvas.

Atualmente essa prática não é recomendada para fins de acessibilidade, pois não é bem suportada pelos agentes de usuário. O método seguro é criar uma apresentação alternativa para canvas, preferencialmente na mesma página:

Exemplo:

<figure>
  <canvas id="example" width="260" height="200"></canvas>
  <figcaption>
    <a href="https://en.wikipedia.org/wiki/Rectangle">
      Retângulo
    </a> com uma borda preta.  No fundo há um círculo na cor rosa. 
    Sobrepondo parcialmente o círculo há um quadrado na cor verde e um 
    triângulo na cor púrpura e ambos são transparentes 
    de modo que o círculo pode ser visto atrás deles.
  </figcaption>
<figure>  

Em alguns casos, como no exemplo anterior, a melhor alternativa é descrever o que está inserido em canvas. Esta alternativa é uma boa solução, por exemplo, para a maioria das demonstrações do uso de canvas existentes em visualwizardry. Em outros casos a melhor alternativa é a criação de uma apresentação usando um formato diferente para ser mostrada em canvas. Um bom exemplo de uso desta alternativa é o plugin jQuery Accessible Charts.

Para conteúdos interativos em canvas deve-se assegurar que todas as ações do usuário com o mouse devem ser possíveis também com uso do teclado. É recomendável que os autores utilizem os controles nativos (HTML5 controls) em lugar de controles personalizados desenhados em canvas uma vez que usuários de tecnologias assistivas não têm condições de acessar e operar controles criados na interface.

Tão logo as funcionalidades para acessibilidade tenham sido totalmente desenvolvidas e implementadas métodos robustos estarão disponíveis para prover acessibilidade a canvas. Fique atento e confira com frequência as novidades relacionads ao desenvolvimento desta área.

As duas principais funcionalidades para acessibilidade a canvas são o sub-DOM para navegação em canvas e o mecanismo que aponta o foco em uma área de canvas.

A existência de um sub-DOM para canvas implica em que leitores de tela terão acesso aos elementos de marcação para canvas. Isto significa que mesmo usando um navegador que suporte canvas o conteúdo alternativo inserido em canvas será acessível. Significa também, que conteúdo interativo poderá ser acessado via teclado.

Usando o mecanismo para dar o foco os desenvolvedores poderão habilitar elementos em determinadas áreas de canvas para uma ação, como por exemplo seguir um link ou preencher um controle de formulário. Quando um elemento no sub-DOM recebe o foco via navegação pelo teclado ou com uso do método focus() da JavaScript a área de canvas correspondente será iluminada por um círculo sobre ela desenhado. As coordenadas do círculo que define o foco estarão disponíveis na API de acessibilidade facilitando os leitores de tela na tarefa de fornecer informações precisas sobre a área em foco.

Esta funcionalidade e comportamento será útil para o desenvolvimento de scripts de interação com links e controles desenhados em canvas com HTML real inserido no sub-DOM, tornando a interação acessível

Assim, tão logo as funcionalidades para acessibilidade tenham sido totalmente desenvolvidas e implementadas métodos robustos estarão disponíveis para prover acessibilidade a canvas

Áreas de divergências

Tem havido muita discussão em torno da remoção das especificações de alguns atributos que foram projetados para acessibilidade. É o caso, por exemplo, dos atributos longdesc para o elemento img e summary para o elemento table.

Está proposta a remoção do atributo longdesc (longdesc is proposed for removal) porque poucos sites o utilizam e a maioria dos agentes de usuários (navegadores e tecnologias assistivas) não os suporta de maneira adequada. Aqueles que defendem a permanência de longdesc argumentam que ele é suportado de maneira decente por tecnologias assistivas e usuários de leitores de tela os consideram útil (screen reader users find it useful) (muito embora a menos de dois anos atrás (two years ago) uma enquete considerou longdesc "muito impopular "). A argumentação final é que ele é usado atualmente, ainda que por poucos sites, e seria errado quebrar a retro-compatibilidade para quem já os usa.

O atributo summary é um metadado invisível destinado apenas às tecnologias assistivas. Destina-se a explicar a estrutura de uma tabela complexa para usários cegos, podendo beneficiar também usuários com necessidades cognitivas que não usam leitores de tela. Um dado que não é exposto visualmente tende a não estar sincronizado com o restante da página. Usar ARIA e/ou o elemento detail (HTML5 details element) é uma alternativa melhor.

Conclusão

HTML5 não é um desastre em termos de acessibilidade como alguns querem fazer você acreditar. Ela está tentando criar um projeto de acessibilidade novo em lugar de se apegar ao passado, e isto, sem dúvida, é uma boa iniciativa; deixar por conta do desenvolvedor o provimento de acessibilidade, não funciona. Tome como exemplo a quantidade de imagens que não têm um atributo alt com o respectivo texto alternativo ou mesmo com um texto alternativo completamente inútil.

Com o refinamento das especificações mais mudanças acontecerão. Sem dúvida, não é a especificação que implemanta acessibiliade pelo teclado, ou passa informações para leitores de tela, para ampliadores de tela, narradores e dispositivos braille usados por portadores de necessidades especiais - isto é função dos navegadores. Steve Faulkner (um dos autores desta matéria) mantém tabelas sobre o andamento de várias implementações de acessibilidade que podem ser consultadas em HTML5accessibility.com. Considerando a rapidez com que as implementações acontecem na HTML5 e a velocidade com que os navegadores as acompanham, nós temos razões para esperar com otimismo um futuro brilhante.

Compartilhe essa matéria com seus amigos