Existem alguns exemplos e trabalhos bons e úteis por aí já mostrando como leitores de tela lidam com diversas construções HTML5 e modelos ARIA. Sei que as especificações ainda não estão finalizadas e vendedores de tecnologia assistiva sempre estão trabalhando nisso, mas eu queria brincar um pouco e confirmar por conta própria como alguns dos principais leitores de tela para Windows, como JAWS 11, Window-Eyes 7.11, NVDA 2010.1, e SAToGO 3.0.202 atualmente lidam com a divisão de elementos básicos de HTML5, assim como ARIA landmark e outros modelos. Foi sugerido que até navegadores e leitores de tela suportem elementos de HTML5 e seus modelos ARIA implícitos, deveríamos estar explicitamente suplementando certos elementos HTML5 com seu modelo ARIA associado.

Atualização: Resultados por VoiceOver no MacOS X Snow Leopard com Safari 4.0.3 adicionados. - 7 de Maio de 2010

Os casos teste

O primeiro caso teste usa apenas os elementos HTML5, em particular:

• header
• nav
• section
• article
• aside
• footer

O segundo caso teste também aplica os seguintes modelos ARIA:

• banner
• navigation
• main
• article
• complementary
• contentinfo

Fiz o teste com os quatro leitores de tela usando Internet Explorer 8 e Firefox 3.6.

Nota: Dependendo da combinação de navegador e leitor de tela que você usar, links internos da página nos casos testes, particular aqueles com destinos que são simples cabeçalhos com um atributo id podem ou não conseguir o foco correto e atualizar a posição na ordem TAB. Isso é um problema, bem documentado, com certos navegadores e leitores de tela, e não está relacionado ao uso de HTML5 e modelos ARIA. Este pode ser amenizado ao adicionar tabindex="-1" e/ou usando elementos a de outras maneiras, mas isso fica para outro conjuntos de casos testes.

Os resultados

Brevemente, NVDA funciona muito bem com HTML5 e HTML5 com modelos ARIA nos casos testes, seja no IE8 ou FF3.6. Navegando, lendo, e interagindo com markup HTML5 e referências ARIA é bem direto. Tanto que não há motivo para incluí-lo nos resultados testes: suficiente dizer que NVDA mata a pau.

JAWS funciona bem, ainda que no FF3.6 este não parece gostar do elemento nav aninhado em um header. Por ora, pelo menos, é razoável evitar aninhar elementos nav em elementos header. Atualização (Aug. 27, 2010): Veja o comentário #3 de Terrill Thompson abaixo. Infelizmente, JAWS 11 no Firefox 3.6 não lida bem com elementos header em qualquer implementação.

SAToGO também funciona bem, e agora até permite navegação por referências ARIA, ainda que não anuncie o tipo de referência automaticamente quando a encontra. E só pude navegar pelas referências em uma direção no IE8, enquanto que no FF3.6, pude navegar entre próxima e anterior pressionando ; e Shift+; respectivamente. Atualização: Novos resultados para SAToGO versão 3.1.24, 21 de maio de 2010.

Window-Eyes 7.11, por outro lado, e isso é algo que já sabíamos, simplesmente não reconhece modelos ARIA. Ainda mais, Window-Eyes parece hesitar no IE8 quando HTML5 e modelos ARIA são usados em conjunto: no “Modo Navegação” ele não consegue encontrar nenhum link numa seção de elementos HTML5 que também tem um modelo ARIA. Se você desligar o “Modo Navegação”, ele encontra todos os links, mas isso significa que você teria que continuamente ligar e desligar o “Modo Navegação” para realmente ler e usar a página.

Alguns testes rápidos adicionais que eu fiz mostraram que no IE8, Window-Eyes não tem problemas encontrando links em uma div simples que também tem um modelo ARIA, ou dentro de um elemento HTML5 seccionado sem modelo ARIA, mas combine os dois e Window-Eyes se perde. Isso é confirmado, por exemplo, pelo, Site de Bruce Lawson, que faz bom uso de HTML5 e ARIA. Se você visitar o site com Window-Eyes e IE8, nenhum dos links em header na #sidebar nav são encontrados já que ambos esses elementos HTML5 tem modelos ARIA implementados. Mas não há problema com os links na área de conteúdo central, ainda que tenha role="main" já que este usa uma div nromal. Se você usar um elemento section, a maioria dos links na página iria desaparecer para Window-Eyes no IE8.

Ainda que eu não tenha os números para provar, suponho que a maioria dos usuários de Window-Eyes usam Internet Explorer ao invés de Firefox, então isso pode ser um motivo para evitar o uso de HTML5 e modelos ARIA juntos pelo momento, dependendo de como você se sente apelando para usuários de Window-Eyes com IE8. Será interessante observar como as coisas mudarão uma vez que IE9 e Window-Eyes 8 sejam lançados.

Os resultados mais detalhados dos testes estão abaixo. A não ser que indicado o contrário, o leitor de tela teve a performance esperada para uma experiência normal.

Atualização #1 (30 de Junho de 2010): Parece que mesmo aninhando um elemento com um atributo role em um elemento de divisão HTML5 pai causa problemas para Window-Eyes. Por exemplo, links dentro de um ul com role = "navigation" aninhados dentro de um elemento nav pai não serão encontrados por Window-Eyes.

Atualização # 2 (5 de julho de 2010): Por outro lado, e curiosamente, aninhar um elemento HTML5 dentro de uma div com um role ARIA não parece causar problemas em Window-Eyes. Por exemplo, os links num elemento nav que está aninhado em uma div com role = "navigation" ainda são encontrados por Window-Eyes. Então essa é, por ora, a melhor maneira de usar elementos HTML5 e modelos de referência ARIA juntos sem causar impacto negativo em usuários de Window-Eyes.

Atualização # 3 (7 de julho de 2010): Com a última atualização para Window-Eyes 7.2, links dentro de elementos HTML5 que tem uma referência ARIA role podem ser encontrados e utilizados. Infelizmente, aninhar pelo menos alguns elementos semânticos HTML 4 com um atributo role em uma divisão de elementos pai HTML5 ainda causa problemas para Window-Eyes 7.2. Ou seja, links em uma ul com role = "navigation" aninhada dentro de um elemento nav pai, por exemplo, ainda não são encontrados e acionáveis usando essa última versão de Window-Eyes.

Atualização # 4 (21 de julho de 2010): Acho que deixei as coisas um pouco confusas a esse ponto, então vamos recapitular: no Internet Explorer 8, versões de Window-Eyes 7.2 e inferiores, quando em modo de navegação normal, tem problema encontrando e usando links em conteúdo onde role foram usados em conjunto com elementos de divisão HTML5 em certos arranjos. Usar links em um elemento HTML5 com um atributo role ARIA é um problema com Window-Eyes 7.11 e inferior. Isso não é um problema com Window-Eyes 7.2, mas na versão 7.2 persiste um problema pelo menos com listas ordenados e desordenadas, e possivelmente com alguns outros elementos também, que tenham um role ARIA aplicado. Tanto Window-Eyes 7.11 quanto 7.2 não conseguem usar links em um elemento ul com role = "navigation" , independente de estar aninhado em um elemento nav. O mesmo vale, por exemplo, para links dentro de um elemento ol com role = "contentinfo" . (Esse bug do Window-Eyes também se manifesta um pouco no Firefox 3.6). Entretanto, aninhar um elemento HTML5 em uma div genérica com um role ARIA, ou vice-versa, aninhar uma dia com div com ARIA role ARIA dentro de um elemento HTML5, não parece causar problemas com Window-Eyes. Então, por exemplo, você poderia envolver o elemento nav com <div role="navigation"> ou, alternativamente, envolver o conteúdo interno da nav em uma div com um role ARIA. Exemplos desses diferentes arranjos podem ser encontrados neste página teste especial para Window-Eyes.

Caso teste somente com HTML5

JAWS 11

IE8

• nenhum problema ou complicação óbvia

FF3.6

• não gosta da nav entre o elemento header : ao carregar a página, JAWS pula para algum lugar abaixo da header e começa a ler, frequentemente a h1 ou a “Primeira Seção” interna da página; e os links nav dentro do header não aparecem na lista de links de JAWS
• Pode pressionar TAB para chegar em cada link, mas, no modo VirtualPC Cursor, os links dentro do header , quando selecionados com o teclado, registram e agem como qualquer link fora do header que estava focado anteriormente (exemplo, com frequência o link interno da “Primeira Seção” da página dentro da section “principal”)
• com o modo VirtualPC Cursor desligado, os links no header funcionam normalmente via teclado
• Os links no header parecem funcionar normalmente quando selecionados com o mouse, estando VirtualPC Cursor ligado ou não
• Links fora do header são todos reconhecidos e funcionam bem

Window-Eyes 7.11

IE8 e FF3.6

• nenhum problema ou complicação óbvia

SAToGo 3.0.202

IE8 e FF3.6

• nenhum problema ou complicação óbvia

VoiceOver

Safari 4.0.3

• nenhum problema ou complicação óbvia

Caso de teste HTML5 + Modelos ARIA

JAWS 11

IE8

• o mesmo que a versão somente HTML5, exceto que,
• todas as referências ARIA são encontradas e navegáveis
• também considera role="article" uma referência

FF3.6

• mesmos problemas com o nav e header que com o caso somente HTML5
• todas as referências ARIA são encontradas e navegáveis, exceto pela navigation entre referências ARIA aninhadas no header
• Também considera role = "article" uma referência

Window-Eyes 7.11

IE8

• nenhuma referência ARIA encontradas
• nenhum link encontrado porque as três seções principais da página usam elementos HTML5 com modelos ARIA
• O header com role = "banner" , a section com o role = "main" > Footer com role = "contentinfo" são reconhecidos como controles (exemplo, eles podem ser acessados ao pressionarC) e estão na ordem TAB

FF3.6

• nenhuma referência ARIA encontrada
• todos os links encontrados, ao contrário de IE8
• O header , a section com role = "main" e o footer NÃO são reconhecidos como controles assim como são no IE8

SAToGo 3.0.202

IE8

• todas as referências ARIA são encontradas e navegáveis, mas somente em uma direção (pressionando ; para a próxima referência), e o tipo de papel da referência não é anunciado

FF3.6

• todas as referências ARIA são encontradas e navegáveis em ambas direções (pressionando ; e Shift+;), mas o tipo de referência não é anunciada

SAToGo 3.1.24 (21 de maio de 2010)

IE8

• Ainda que essa versão de SAToGo agora permita navegação por referência ARIA em ambas as direções no IE8 (pressionando ; e Shift+;), esta não mais encontra o modelo de referência complementary
• o tipo do modelo de referência continua não anunciado

FF3.6

• SAToGO ainda encontra referência, permite navegação em ambas as direções, e o tipo de modelo de referência permanece não anunciado

VoiceOver

Safari 4.0.3

• nenhuma referência ARIA encontrada

O conteúdo neste sítio de página é autorizado de acordo com uma Licença de Povo criativa Attribution-NonCommercial-ShareAlike 3.0