O Chrome DevTools está lançando uma árvore de acessibilidade completa para facilitar a visualização geral da árvore inteira. Nesta postagem, saiba como essa árvore é criada e como usá-la no seu trabalho.
O que é a árvore de acessibilidade?
A tecnologia adaptativa, como leitores de tela, usa a API de acessibilidade do Chromium para interagir com o conteúdo da Web. O modelo dessa API é a árvore de acessibilidade: uma árvore de objetos de acessibilidade que a tecnologia adaptativa pode consultar para buscar atributos e propriedades e realizar ações. Os desenvolvedores da Web moldam e manipulam a árvore de acessibilidade principalmente por 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 deles é exposto à tecnologia assistiva. Especificamente, quando um nó é selecionado no visualizador de árvore do DOM, as propriedades do nó de acessibilidade correspondente são mostradas no painel junto com uma visualização dos ancestrais do nó e dos filhos imediatos.
Como a árvore é criada?
Antes de chegarmos à aparência dessa nova visualização de árvore completa no DevTools, vamos falar brevemente sobre o que é a árvore de acessibilidade em termos mais tangíveis. A árvore de acessibilidade é derivada da árvore do DOM. A estrutura é mais ou menos a mesma, mas simplificada para remover nós sem conteúdo semântico, como um elemento <div> usado apenas para estilização. Cada nó na árvore tem uma função, como Button ou Heading, e geralmente um nome que pode ser derivado dos atributos ARIA ou do conteúdo do nó. Se olharmos para 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, gera uma árvore de acessibilidade interna mais ou menos assim:
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'
Observe que essa representação contém vários nós desnecessários com o papel genericContainer, o que parece contradizer a declaração acima de que a árvore de acessibilidade é um derivado simplificado da árvore do DOM. No entanto, a maioria desses nós só ocorre na árvore interna e não é exposta à tecnologia adaptativa. Como o DevTools coleta as 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 sincronizada com a árvore do DOM para que os desenvolvedores possam alternar entre as duas árvores. Esperamos que a nova árvore seja mais fácil de explorar, útil e fácil de usar.
Agora que você sabe como a árvore de acessibilidade funciona, use as Ferramentas do desenvolvedor para conferir a nova visualização em árvore. O documento HTML a seguir com um título, um título 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ó permitia que você explorasse um único nó e seus ancestrais.
Agora, quando você alternar a nova árvore, ela vai substituir a visualização da árvore DOM e permitir que você veja a árvore de acessibilidade completa da página:
Construção de árvore lenta
Para melhorar o desempenho da árvore, mesmo para sites maiores, ela é construída de forma lenta no front-end à medida que é explorada. Quando um nó é expandido na árvore, os filhos dos nós são buscados pelo protocolo do Chrome DevTools (CDP) e a árvore é recriada.
Ao vivo
A nova visualização de árvore é ativada e atualizada dinamicamente se a árvore de acessibilidade mudar no renderizador. Ele se conecta às mesmas mecânicas que notificariam a tecnologia adaptativa sobre as mudanças na árvore e as usa para emitir eventos para a interface do DevTools com nós atualizados. Na prática, o back-end do CDP detecta atualizações na árvore, rastreia quais nós foram solicitados antes e envia eventos para o front-end do DevTools se algum 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 sobre qual parte dos recursos internos de acessibilidade do Chromium queríamos mostrar.
Plataformas
Cada plataforma tem uma API de acessibilidade diferente. 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. As Ferramentas do desenvolvedor mostram a árvore interna do Chromium, em que as funções e os 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 processos de renderizador diferentes, mas também isola documentos entre sites em processos de renderizador diferentes, precisamos nos conectar a cada documento filho fora do processo separadamente pelo CDP e buscar a árvore de acessibilidade. Em seguida, unimos esses subárvores no front-end para criar a ilusão de uma árvore coerente, embora elas estejam em diferentes processos de renderizador no Chromium.
Nós ignorados e sem interesse
Alguns nós são ocultos por padrão: nós ignorados e nós com a função "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 adaptativa. Ocultamos esses nós para evitar a poluição visual da visualização em árvore. Caso contrário, a árvore de acessibilidade da maioria das páginas da Web ficaria assim:
A ressalva aqui é que isso significa essencialmente que precisamos criar outra árvore do que está disponível no back-end. Digamos, por exemplo, que temos os nós A, B, C e X, em que A tem X e B como filhos, e X tem C como filho. Se X for um nó ignorado, vamos remover X da árvore e criar uma árvore em que C é filho de A.
No front-end, construímos a árvore completa, incluindo nós ignorados, e apenas as podamos antes de renderizar os nós. Isso acontece por dois motivos:
- Isso facilita muito o processamento de atualizações de nós no back-end, já que temos a mesma estrutura de árvore nos dois endpoints. Por exemplo, se o nó B for removido no exemplo, receberemos uma atualização para o nó X (já que os filhos dele mudaram), mas se tivéssemos podado esse nó, seria difícil descobrir o que atualizar.
- Ele garante que todos os nós do DOM tenham um nó de acessibilidade correspondente. Quando a árvore é alternada, selecionamos o nó correspondente ao selecionado na árvore DOM. No exemplo anterior, se o usuário alternar a árvore enquanto o nó DOM correspondente a X estiver selecionado, vamos injetar X entre os nós A e B e selecionar X na árvore. Isso permite que o usuário inspecione o nó de acessibilidade para todos os nós do DOM e ajude 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 poderíamos criar com base na nova visualização, mas também queremos seu feedback.
Filtragens alternativas
Como explicado acima, atualmente filtramos os nós que são considerados sem interesse. Poderíamos oferecer uma maneira de desativar esse comportamento e mostrar todos os nós ou oferecer filtros alternativos, como Mostrar nós de referência ou Mostrar títulos.
Destacar problemas de a11y
Poderíamos incorporar uma análise de "práticas recomendadas de acessibilidade" à árvore e destacar os problemas de acessibilidade diretamente nos nós com problemas.
Mostrar ações de acessibilidade no DevTools
A árvore que mostramos atualmente é unidirecional: ela nos permite ter uma ideia de quais informações seriam enviadas à tecnologia adaptativa ao navegar em uma página da Web específica. As ações de acessibilidade representam a comunicação na outra direção: elas permitem que a tecnologia adaptativa atue 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 adaptativa.