O Chrome DevTools está lançando uma árvore de acessibilidade completa para que os desenvolvedores tenham uma visão geral de toda a árvore com mais facilidade. Nesta postagem, descubra como essa árvore é criada e como usá-la no seu trabalho.
O que é a árvore de acessibilidade?
A tecnologia assistiva, como leitores de tela, usa a API de acessibilidade do Chromium para interagir com o conteúdo da Web. O modelo subjacente dessa API é a árvore de acessibilidade, uma árvore de objetos de acessibilidade em que a tecnologia adaptativa pode consultar atributos e propriedades e realizar ações. Os desenvolvedores da Web moldam e manipulam a árvore de acessibilidade principalmente por meio de propriedades DOM, como atributos ARIA para HTML.
No Chrome DevTools, oferecemos o painel de acessibilidade para ajudar os desenvolvedores a entender como o conteúdo é exposto à tecnologia adaptativa. Concretamente, quando um nó é selecionado no visualizador de árvore DOM, as propriedades do nó de acessibilidade correspondente são exibidas no painel com uma visualização dos ancestrais do nó e de seus filhos imediatos.
Como a árvore é criada?
Antes de vermos como é essa nova visualização em árvore completa no DevTools, vamos ver rapidamente o que é a árvore de acessibilidade em termos mais tangíveis. A árvore de acessibilidade é uma derivada da árvore do DOM. A estrutura é aproximadamente a mesma, mas simplificada para remover nós sem conteúdo semântico, como um elemento <div> usado exclusivamente para estilo. Cada nó da árvore tem um papel, como Button ou Heading, e, muitas vezes, um nome que pode ser dos atributos ARIA ou derivado do conteúdo do nó. Se observarmos um documento HTML:
<html>
<head>
<title>How old are you?</title>
</head>
<body>
<label for="age">Age</label>
<input id="age" type="number" name="age" value="42">
<div>
<button>Back</button>
<button>Next</button>
</div>
</body>
</html>
O renderizador no Chromium, chamado Blink, deriva uma árvore de acessibilidade interna da seguinte maneira:
role='rootWebArea' focusable name='How old are you?'
role='genericContainer' ignored
role='genericContainer' ignored
role='labelText'
role='staticText' name='Age'
role='spinButton' editable focusable name='Age' value='42'
role='genericContainer' editable
role='staticText' editable name='42'
role='genericContainer'
role='button' focusable name='Back'
role='staticText' name='Back'
role='button' focusable name='Next'
role='staticText' name='Next'
Essa representação contém vários nós supérfluos com o papel genericContainer, o que parece contradizer a afirmação acima de que a árvore de acessibilidade é uma derivada simplificada da árvore DOM. Ainda assim, a maioria desses nós só ocorre na árvore interna e não seria exposta à tecnologia assistiva. Como o DevTools coleta informações de acessibilidade diretamente do processo do renderizador, essa é a representação em árvore que ele processa.
Árvore de acessibilidade completa no DevTools
A nova árvore de acessibilidade completa e a nova árvore de acessibilidade sincronizada com a árvore do DOM para que os desenvolvedores possam alternar entre as duas árvores. Esperamos que a nova árvore se mostre mais explorável, útil e fácil de usar.
Agora que você sabe como a árvore de acessibilidade funciona, use o DevTools para conferir a nova visualização em árvore. O seguinte documento HTML com um título, cabeçalho e dois botões é usado para mostrar a árvore.
<!DOCTYPE html>
<title>Test</title>
<h1>Heading for example page</h1>
<div>
<button>Back</button>
<button>Next</button>
</div>
A visualização em árvore anterior só permitiria a análise de um único nó e dos ancestrais dele.
Agora, quando você alternar a nova árvore, ela substituirá a visualização em árvore do DOM e permitirá que você veja a árvore de acessibilidade completa da página:
Construção lenta de árvore
Para que a árvore tenha um bom desempenho mesmo em locais maiores, a árvore é construída lentamente no front-end à medida que é explorada. Assim que um nó é expandido na árvore, os filhos deles são buscados pelo protocolo do Chrome DevTools (CDP) e a árvore é recriada.
Transmissões ao vivo
A nova visualização em árvore é ativada e atualizada dinamicamente se a árvore de acessibilidade mudar no renderizador. Ele se conecta à mesma mecânica que notificaria a tecnologia assistiva sobre as mudanças na árvore e a usa para emitir eventos para o front-end do DevTools com nós atualizados. Na prática, o back-end do CDP detecta atualizações na árvore, monitora quais nós foram solicitados antes e envia eventos para o front-end do DevTools se qualquer um desses nós mudar.
A história de muitas árvores
Na descrição de o que é a árvore de acessibilidade, você aprendeu como o Blink constrói uma árvore de acessibilidade para o DOM que está renderizando e como o DevTools busca essa árvore pelo CDP. Embora isso seja verdade, deixamos de fora algumas complicações nesta descrição. Na verdade, há muitas maneiras diferentes de usar a árvore de acessibilidade no Chromium. Ao projetar a nova visualização em árvore para o DevTools, fizemos algumas escolhas ao longo do caminho sobre qual parte dos componentes internos de acessibilidade do Chromium queríamos mostrar.
Plataformas
Cada plataforma tem uma API de acessibilidade diferente e, embora a forma da árvore seja a mesma em todas as plataformas, a API para interagir com a árvore é diferente, e os nomes dos atributos podem variar. O DevTools mostra a árvore interna do Chromium onde as funções e atributos tendem a corresponder aos definidos na especificação ARIA.
Vários frames e isolamento de sites
Como o Chromium não apenas coloca o conteúdo de cada guia em diferentes processos de renderizador, mas também isola documentos entre sites em diferentes processos de renderizador, é necessário conectar-se a cada documento filho fora do processo separadamente no CDP e buscar a árvore de acessibilidade. Em seguida, juntamos essas subárvores no front-end para dar a ilusão de uma árvore coerente, embora elas existam em diferentes processos de renderização no Chromium.
Nós ignorados e desinteressantes
Ocultamos alguns nós por padrão: nós ignorados e nós com o papel "genérico" sem nome. Esses nós não têm significado semântico e, no caso de nós ignorados, não são expostos à tecnologia assistiva. Ocultamos esses nós para evitar sobrecarregar a visualização em árvore. Se não fizéssemos isso, a árvore de acessibilidade para a maioria das páginas da Web ficaria assim:
A ressalva aqui é que isso basicamente significa que precisamos construir mais uma árvore do que está disponível no back-end. Digamos, por exemplo, que temos os nós A, B, C e X, onde A tem os filhos X e B e X tem os filhos C. Se X for um nó ignorado, nós removemos X da árvore e, em vez disso, criamos uma árvore em que C é um filho de A.
No front-end, construímos a árvore completa, incluindo os nós ignorados, e os removemos logo antes de renderizar os nós. Fazemos isso por dois motivos:
- É muito mais simples lidar com atualizações de nós do back-end, já que temos a mesma estrutura de árvore nos dois endpoints. Por exemplo, se o nó B fosse removido no exemplo, receberíamos uma atualização para o nó X (já que seus filhos foram alterados), mas se tivéssemos removido esse nó, teríamos dificuldade em descobrir o que atualizar.
- Ele garante que todos os nós DOM tenham um nó de acessibilidade correspondente. Quando a árvore é alternada, selecionamos o nó correspondente ao nó atualmente selecionado na árvore do DOM. No exemplo anterior, se o usuário alternar a árvore enquanto o nó DOM correspondente a X estiver selecionado, injetaremos X entre os nós A e B e selecionaremos X na árvore. Isso permite que o usuário inspecione o nó de acessibilidade em todos os nós DOM e ajuda a determinar por que o nó é ignorado.
Ideias futuras
O lançamento da nova árvore de acessibilidade é apenas o começo. Temos algumas ideias para projetos futuros que podemos desenvolver com base nessa nova visualização, mas também estamos ansiosos para receber seu feedback.
Filtros alternativos
Conforme explicado acima, atualmente filtramos os nós considerados desinteressantes. Podemos fornecer uma forma de desativar esse comportamento e mostrar todos os nós ou fornecer filtros alternativos, como Mostrar nós de ponto de referência ou Mostrar cabeçalhos.
Destacar problemas de acessibilidade
Poderíamos incorporar uma análise de “práticas recomendadas de acessibilidade” na árvore e destacar os problemas de acessibilidade diretamente nos nós problemáticos.
Mostrar ações de acessibilidade no DevTools
Atualmente, a árvore que mostramos é unidirecional: ela nos permite ter uma ideia de quais informações seriam alimentadas para a tecnologia assistiva ao navegar em uma página da web específica. As ações de acessibilidade representam a comunicação na outra direção: permitem que a tecnologia assistiva aja na IU apresentada. Podemos mostrar essas ações no DevTools para permitir ações como “clicar”, rolar ou mudar valores na página usando a API disponível para tecnologia assistiva.