Como incorporar acessibilidade em um produto baseado na tela de trabalho

Assim como um videogame, a tela de trabalho do Figma assume a renderização do navegador para maximizar o desempenho. Isso nos permite oferecer recursos avançados, como zoom infinito e colaboração em tempo real. No entanto, como não usamos HTML e DOM tradicionais para renderizar a tela de trabalho do Figma, não obtemos nenhum dos recursos de acessibilidade integrados ao navegador por padrão.

Para tornar o Figma acessível a mais pessoas, criamos uma estrutura de Mirror DOM que pode se manter sincronizada com qualquer design do Figma. Aqui, vamos explorar os bastidores de como qualquer pessoa pode navegar por um arquivo Figma com um leitor de tela, ouvir as mudanças à medida que são anunciadas e operar o editor com um teclado.

Saiba mais sobre as melhorias de acessibilidade do Figma para teclado e leitor de tela.

Sintetizar o DOM

Os mecanismos de navegador têm um conceito chamado árvore de acessibilidade: uma estrutura de dados extraída do documento que contém as informações não visuais necessárias para o funcionamento das tecnologias assistivas. Quando um usuário de leitor de tela executa o comando “ir para o próximo campo de formulário”, a árvore de acessibilidade informa ao leitor de tela para onde ir. O navegador constrói essa árvore com base no DOM, no HTML semântico, nos atributos ARIA e em alguns estados computados adicionais.

Em um app web comum, cada componente tem seu próprio elemento DOM, como <button>, <p> ou <img>. Mas como o Figma não usa HTML para renderização, a tela de trabalho tem apenas um elemento <input> que mantém o foco, não importa quantas camadas existam no design. Isso significava que a árvore de acessibilidade do navegador ficava praticamente vazia para um arquivo Figma.

Para resolver isso, restauramos elementos do DOM sintéticos na tela de trabalho para que os leitores de tela possam navegar e editar arquivos.

Como o sistema funciona

Por trás da tela de trabalho, invisível para usuários com visão plena, renderizamos elementos DOM que refletem as partes do grafo de cena que são importantes para a tecnologia assistiva. Existem quatro sistemas colaborativos:

• Uma “árvore de acessibilidade” interna do Figma que armazena em cache os detalhes de acessibilidade de cada camada de design. Conforme as edições são feitas, ela realiza atualizações precisas em vez de reconstruir do zero.
• Um componente React chamado “Mirror DOM” é responsável por realmente inserir elementos no DOM, usando a árvore de acessibilidade interna como referência.
• Um sistema de sincronização bidirecional para seleção. Quando você seleciona um nó na tela de trabalho, o elemento correspondente do DOM recebe o foco. Por outro lado, atualizamos a seleção da tela de trabalho quando as ferramentas do leitor de tela são usadas para navegar no Mirror DOM.
• Um sistema de anúncios que alerta o usuário sobre edições e outras alterações não relacionadas à navegação, como deslocamentos, troca de ferramentas e qualquer outra coisa que possa ser óbvia para um usuário com visão plena.

A árvore de acessibilidade interna

Para determinar quais elementos DOM renderizar e como fazer isso, trabalhamos de trás para frente, partindo do que o navegador deveria saber para construir a árvore de acessibilidade. Assim, construímos nossa própria árvore de acessibilidade interna, que captura as informações não visuais que os leitores de tela exigiriam para qualquer documento Figma.

Para cada camada no documento, criamos um “resumo de acessibilidade” que será lido pelos leitores de tela. Esse resumo pode depender do contexto e do tipo de aplicativo que o usuário está utilizando. Por exemplo, em protótipos, podemos omitir a maioria dos recursos de edição e simplesmente emular o conteúdo para o visualizador final: somente o texto dos campos de texto ou uma função de botão para um item com interação de clique. Por outro lado, quadros de layout automático, que são excluídos da árvore de acessibilidade para protótipos, precisam ser incluídos quando o usuário edita um documento.

Após resumir cada uma das camadas, percorremos a árvore de cima para baixo achatando eventuais nós omitidos. Construímos a árvore de acessibilidade interna completa ao carregar um documento pela primeira vez. Em seguida, monitoramos as edições conforme a sessão avança para atualizarmos a árvore com precisão, evitando o alto custo das reconstruções.

O Mirror DOM

Com a árvore de acessibilidade pronta, podemos gerar o DOM. Isso é feito por um componente React que se renderiza recursivamente, com cada instância desse componente assinando mudanças na árvore de acessibilidade para uma camada de design específica.

function ScreenReaderElement({ layerId }: { layerId: string }) {
  const { label, role, children } = useAccessibleSummary(layerId);
  return <div role={role} ariaLabel={label}>
    {children.map((c) => <ScreenReaderElement key={c} layerId={c}>)}
  </div>
}

Conforme fazemos mudanças mínimas e incrementais na árvore de acessibilidade para rastrear edições, usamos o React para reduzir ao mínimo as modificações no DOM.

Um detalhe do Mirror DOM que pode ser surpreendente é que não usamos estilos típicos de conteúdo visualmente oculto para esse conteúdo acessível, mas não exibido. Embora essas técnicas permitam que as tecnologias assistivas interpretem o conteúdo sem afetar o layout da página, na realidade precisamos que os elementos do Mirror DOM sejam dispostos no layout. O motivo é que o layout espacial de um documento do Figma é fundamental para o seu significado. Mesmo sem uma tela, a posição desses elementos influencia as tecnologias assistivas. As lupas de tela podem percorrer a tela para manter o elemento em foco na visualização, os leitores de tela exibem um contorno de alto contraste para usuários com visão parcial e as ferramentas de controle por voz também podem exibir dicas na tela.

Esse cálculo de posicionamento tem algumas etapas. Cada camada em um design do Figma tem uma transformação afim: uma estrutura de dados de tamanho fixo que rastreia deslocamento, escala e rotação. As transformações afins são uma ferramenta poderosa para gráficos computacionais porque qualquer sequência de transformações pode ser concatenada em uma única transformação. Usamos esses recursos para posicionar elementos no Mirror DOM com CSS, incluindo eventuais rotações ou inclinações.

Manter a sincronia entre foco e seleção

Com os recursos acima, podemos oferecer a navegação em protótipos e outros conteúdos "publicados" com um leitor de tela. O próximo passo foi oferecer a navegação em aplicativos de "edição" no Figma. Para fazer isso, precisamos reintroduzir outra função que os navegadores geralmente gerenciam por nós: uma semântica de seleção e foco à qual as tecnologias assistivas possam se conectar.

Na navegação pela tela de trabalho do Figma, a tecla tab altera o nó selecionado sem alterar o foco do teclado do sistema. Isso significava que a tela de trabalho parecia ser um grande alvo de navegação para leitores de tela. Era preciso garantir que o foco se moveria para o nó selecionado dentro da tela de trabalho da forma esperada pelos usuários.

Por isso, no nosso sistema de Mirror DOM, construímos uma sincronização bidirecional entre a seleção da tela de trabalho e o foco do teclado do sistema. Quando você clica na tela de trabalho, o item correto é focalizado pelo leitor de tela, e quando uma ação do leitor de tela move o foco, atualizamos os destaques visíveis da seleção. Esse sistema permite que até mesmo controles de leitores de tela, como o rotor de VoiceOver, selecionem nós na tela de trabalho do Figma.

Anunciar ações e mudanças

A árvore de acessibilidade e os sistemas de Mirror DOM internos disponibilizam o conteúdo dos arquivos do Figma para as tecnologias assistivas do Figma. No entanto, essas ferramentas por si só não são suficientes para a edição, em que o aplicativo precisa confirmar para o usuário as ações que ele realiza. Gestos como deslocar, cujos resultados são óbvios para um usuário com visão plena, também precisam fornecer um contexto textual que possa ser anunciado em voz alta. Na verdade, só existe uma maneira de fazer isso: dependemos das regiões em tempo real fornecidas pelos navegadores como parte do padrão ARIA.

Nossa implementação adiciona marcação de região ao vivo a cada anúncio de notificação no produto. Além disso, oferece anúncios invisíveis para eventos que provavelmente seriam percebidos como ruído redundante por usuários com visão plena. Por exemplo, a maioria dos usuários provavelmente não acharia útil ver um popup de notificação confirmando cada deslocamento da tecla de seta, mas essas notificações são importantes para acessibilidade. Também lidamos com o "agrupamento" automático: podemos combinar vários eventos na mesma categoria que ocorrem próximos uns dos outros. Novamente, usando os deslocamentos das teclas de seta como exemplo, se você mover um único pixel cinco vezes seguidas, podemos enviar um anúncio confirmando "Movido cinco pixels" em vez de repetir "Movido um pixel" cinco vezes.

O que está disponível e o que vem a seguir

Nosso trabalho para tornar o Figma mais acessível se desenvolveu ao longo de vários anos, moldado pelo feedback de usuários de tecnologia assistiva por meio de nossa parceria com a Fable. Após os primeiros passos em 2022, com o visualizador de protótipos, oferecemos o FigJam em 2023 e, por fim, avançamos significativamente ao longo de 2024 e 2025: implementamos a configuração Adaptar conteúdo para leitores de tela no Design, Dev Mode e Slides; lançamos a primeira versão dos controles de teclado para a tela de trabalho; adicionamos o modo de contraste aprimorado e acrescentamos mais de 15 melhorias voltadas à acessibilidade.

Estamos integrando acessibilidade na forma como projetamos, construímos e lançamos novos produtos. Revisamos cada novo recurso para conferir sua acessibilidade. Nossa equipe também investe em ferramentas internas, como um agente de IA equipado com contexto específico do Figma e orientações da equipe de design systems para ajudar a levar o contexto de acessibilidade para toda a organização de desenvolvimento de produtos da Figma.

Também queremos facilitar a criação de produtos com acessibilidade no Figma. Hoje, você pode identificar se uma combinação de cores cumpre diretrizes de acessibilidade no seletor de cores e renomear as camadas visíveis para enviar os novos nomes aos leitores de tela. Além disso, lançamos recentemente o recurso conferir designs. Essa nova funcionalidade do Figma Design permite que os designers comparem seus designs com o design system para revelar problemas e corrigi-los com um único clique, incluindo a sinalização de baixo contraste e a sugestão de cores compatíveis com os padrões WCAG 2.0 AA ou AAA, antes de enviar o projeto para a equipe de engenharia.

Na verdade, o trabalho de acessibilidade nunca termina. Cada melhoria ajuda a remover mais uma barreira, possibilitando que mais pessoas participem do processo criativo, compartilhem suas ideias e moldem os produtos que todos usamos. Continuaremos ouvindo, aprendendo e construindo rumo a um futuro mais acessível.