Notícias

Projetos ativos

Última atualização: 31 de outubro de 2026

Em andamento

v3: Um conjunto completo de garantia de qualidade

27 de setembro de 2026

Apresentação na DrupalCon Europe 2026

Principais novidades

• Núcleo de testes unificado com o Sa11y. O novo conjunto de regras, desenvolvido em parceria, acrescenta ao conjunto principal de testes de conteúdo os testes para desenvolvedores, a verificação de contraste e a pontuação de legibilidade.
• Suporte a vários idiomas
• Construtor de testes personalizados
• Ferramentas de manutenção do painel
• Uma ferramenta de rastreamento do site para adicionar novos resultados.
• Permite que determinados testes (este PDF é acessível?) dispensem alertas em todo o site para determinados papéis.
• Configuração separada: testes e visualizações de relatórios por papel, para desenvolvedores ou para conteúdo.

E, talvez o mais importante para o futuro do projeto:

• Obtivemos uma bolsa para lançar esta organização patrocinadora, a fim de dar suporte aos usuários atuais e financiar o trabalho em ideias para projetos futuros.

v2: Dispensas e relatórios

2 de março de 2023

Há dois anos, apresentamos o verificador de acessibilidade Editoria11y, um plugin para Drupal pronto para uso que oferecia aos autores feedback automático e instantâneo, com dicas úteis para melhorar o conteúdo.

Achávamos que isso atenderia a uma necessidade não atendida. Todas as opções existentes exigiam treinamento e uso diligente para ter alguma utilidade, e a experiência já nos mostrara que tentar treinar e monitorar milhares de autores de conteúdo em uma grande organização não era uma forma eficiente de enfrentar o problema. Para dar certo, estávamos convencidos de que um programa precisava de um alto grau de automação, oferecendo aos autores de conteúdo um educado “treinamento na hora certa” ao detectar erros comuns.

E funcionou.

Em Princeton, isso praticamente inverteu o sentido das minhas comunicações. Nas plataformas em que ele estava instalado, deixamos de enviar e-mails repetitivos aos autores de conteúdo pedindo texto alternativo ou melhorias em links e títulos e passamos a receber perguntas dos autores sobre como melhorar a escrita para que ela não fosse sinalizada tantas vezes.

Externamente, a reação foi de euforia:

Escrevendo dicas autossuficientes

Nas dicas da v1, adotamos a abordagem de “resumo e detalhes”: uma breve explicação do problema e um link para mais detalhes.

Isso já era melhor do que as ferramentas escritas para desenvolvedores: as dicas eram curtas e claras. Mas a decisão de para onde apontar o link sempre foi um problema. Vários usuários do governo e do ensino superior sentiram necessidade de modificar as dicas para remover os links para a documentação de Princeton, o que lhes dava trabalho extra. Por isso, reescrevemos as dicas padrão para que fossem autossuficientes, com exemplos inline.

A distinção entre alertas vermelhos (problemas certos) e avisos amarelos (possíveis problemas) mostrou-se confusa e, às vezes, irritante.

Por isso, convertemos os avisos amarelos em “verificações manuais” para deixar claro o que significam e adicionamos botões para que os autores possam dispensar os alertas. Alertas “ignorados” ficam ocultos apenas para quem clicou no botão; alertas “marcados como OK” ficam ocultos para todos os editores do site. Os administradores do site podem escolher quem tem permissão para fazer cada uma dessas ações.

Criando um painel

Uma queixa comum dos responsáveis pelos sites era que a ferramenta fazia um ótimo trabalho ao encontrar problemas por todo o site, mas não havia como ver um relatório geral.

A reescrita adiciona uma opção para sincronizar os resultados com o banco de dados do site. Agora, os responsáveis pelo site podem navegar pelos resultados por página ou por problema, ver quais problemas foram ignorados ou marcados como OK e restaurá-los caso discordem!

Tour pelo código da v2 para desenvolvedores

A v2 foi quase uma reescrita completa. Algumas das novidades:

• A remoção da dependência do jQuery permite instalá-lo em mais plataformas e dobra o desempenho.
• Agora é possível configurar o verificador para analisar várias partes independentes da página (por exemplo, o conteúdo do artigo e o rodapé).
• Agora o verificador consegue testar elementos dentro do shadow DOM, usado por vários Web Components e bibliotecas JavaScript.
• Muitos parâmetros novos facilitam a integração com plataformas, como ignorar automaticamente todos os problemas de determinadas páginas para determinados usuários, caso eles não sejam responsáveis pelo conteúdo dessas páginas, mas ainda queiram ver os resultados quando precisarem.
• Agora o verificador vem com vários temas básicos e parâmetros para personalizar as cores.
• Testes automatizados ajudam a evitar regressões no código.

A11yTalks 2024

11 de junho de 2024

Drupal GovCon 2023

27 de outubro de 2023

DrupalCamp NJ 2023

28 de março de 2023

v1: Ajuda inline

11 de março de 2021

Criar conteúdo Web altamente acessível é complicado e costuma começar com muito treinamento.

É preciso desestimular práticas conhecidas:

• Tabelas não devem ser usadas para criar colunas falsas
• Texto corrido não deve ser centralizado nem justificado
• Não se deve depender de formatação apenas visual (peso e tamanho da fonte) para transmitir significado aos usuários, que podem estar ouvindo o conteúdo ou visualizando-o no “modo de leitura”

É preciso estimular novas práticas:

• Imagens precisam de texto alternativo significativo no contexto
• Páginas precisam de uma estrutura real
• Links devem ter textos significativos

Sem dúvida, alguns dos nossos treinamentos existem porque estamos ensinando conceitos novos, mas em algum momento é preciso perguntar: quanto da necessidade de novas habilidades vem de os conceitos serem novos, e quanto vem de impormos novas expectativas sem atualizar nossas ferramentas? Só porque algo é novo não significa que não possa ser intuitivo.

Lições da história da ortografia

Fase 1: A culpa é do autor

Desde os primórdios da história registrada até o início dos anos 1980, a culpa por uma palavra escrita errado era do autor. Cabia a ele aprender a escrever corretamente.

Como alguém melhorava a própria ortografia? Isto vai soar familiar:

1. Fazia treinamentos, com professores particulares ou em sala de aula
2. Recebia listas, diretrizes e dicionários para estudar, uma tradição que remonta aos antigos léxicos cuneiformes gravados em argila.

Fase 2: A culpa é do dicionário

Mas algo mudou nos anos 1980: vamos chamar isso de “fase 2 da ortografia”. Os processadores de texto mais populares passaram a incluir o corretor ortográfico.

E o que aconteceu com o jogo de empurra? Quase da noite para o dia, a culpa passou para a ferramenta:

• Não sabe escrever uma palavra? Dê um palpite e torça para encontrar uma correspondência. Se não encontrar, a culpa é do dicionário.
• Usou uma palavra real que o dicionário marca porque não a conhece? Resmungue e decida se vai ignorar o sublinhado ou clicar com o botão direito e adicionar a palavra ao dicionário.

O corretor ortográfico resolveu todos os nossos erros de ortografia? Claro que não. Mas ajudou. E transferiu grande parte do peso e da responsabilidade do autor para a máquina.

Mas isso não foi o fim…

Fase 3: A culpa é da ferramenta de autoria

Os últimos anos trouxeram mais um avanço: os computadores começaram a escrever por nós:

• Algoritmos preditivos tentam adivinhar a próxima palavra, a próxima frase, talvez até uma resposta inteira de mensagem de texto.
• Ferramentas de formatação automática tentam converter asteriscos, números e letras em listas, atalhos em caracteres especiais e emojis etc.
• Ferramentas de ditado tentam reconhecer conceitos para escolher entre homônimos.

E quem leva a culpa quando isso dá errado? A ferramenta!

Os agregadores de redes sociais adoram aquela captura de tela constrangedora de “Não foi isso que eu quis dizer!”.

O Editoria11y é um passo rumo à fase 2

Em nossos treinamentos, falamos muito sobre testes e apresentamos várias ferramentas de teste muito boas. Nenhuma delas consegue detectar tudo: conceitos como “evitar explicar conceitos por meio de referências cromáticas ou espaciais” precisam ser verificados por um ser humano; em geral, as ferramentas detectam pouco menos da metade dos problemas reais que um site pode ter. Mas elas fazem um ótimo trabalho ao detectar muitos erros comuns em conteúdo editorial.

Só que há três problemas:

1. A maioria é de ferramentas manuais. O criador de conteúdo precisa ter aprendido a usá-las, precisa se lembrar de que elas existem ao escrever o conteúdo e precisa se lembrar de executá-las ao terminar. Esses três pontos de falha conspiram para deixar boa parte (a maior parte?) do conteúdo sem verificação.
2. Elas sinalizam coisas demais. Não marcam apenas os erros que o autor acabou de cometer: marcam problemas de cor causados pelo designer, problemas técnicos causados pelo desenvolvedor, elementos estruturais para fins informativos etc. Isso aumenta a exigência dos treinamentos: os autores não precisam apenas entender a ferramenta, precisam aprender a ignorar uma lista de falsos positivos ou de problemas bem reais que não cabe a eles corrigir hoje, enquanto escrevem este artigo específico.
3. As ferramentas automatizadas tendem a seguir o paradigma de rastrear o site e consultar o painel. Mais uma vez, isso pressupõe que o autor foi treinado para consultar o painel e que vai se lembrar de fazer isso.

Por isso, Princeton decidiu criar algo novo: um verificador automático integrado ao site, que analisaria apenas os erros editoriais comuns.

Ser automático é… difícil.

1. Verificadores automáticos precisam ser sutis: se forem insistentes demais, interrompem e frustram o autor. Se forem educados demais, podem virar um ruído de fundo fácil de ignorar.
2. Verificadores automáticos precisam ter alto desempenho: se a página travar ou hesitar durante a execução, os autores vão se ressentir da presença deles e desativá-los.
3. Verificadores automáticos precisam de dicas amigáveis para iniciantes. Para muitos autores, esta será a primeira vez que ouvirão falar das marcações, da estrutura e da linguagem que tornarão seu conteúdo mais acessível. Os alertas precisam estar em linguagem simples e não técnica, com conselhos práticos para melhorar o conteúdo.

Por isso, começamos pela ferramenta mais próxima desses objetivos que conseguimos encontrar: o Sa11y, da Toronto Metropolitan University. Aproveitamos sua arquitetura de testes e sua abordagem amigável de painel de informações com tooltips, e passamos meio ano adaptando a ferramenta para que os testes sempre rodassem automaticamente, otimizando o desempenho, ajustando os tooltips e criando uma longa lista de opções de configuração que um desenvolvedor poderia usar para adaptá-la rapidamente a qualquer plataforma.

Veja como ele está hoje:

Quando o autor está conectado ao site, o botão de alternância do Editoria11y indica o número e o tipo de problemas (aprovado, verificações manuais necessárias, prováveis problemas encontrados) em cada página. Ele pode clicar para exibir os destaques e as dicas inline. Se o erro for novo, porque ele está vendo uma página que acabou de editar, o painel se abre automaticamente.

Em março de 2021, isso significa que mais de 400 sites de Princeton verificam automaticamente:

• Uma boa estrutura de títulos do documento
  • Níveis de título pulados
  • Títulos vazios
  • Títulos muito longos
  • Blocos de citação suspeitosamente curtos que podem, na verdade, ser títulos.
• Alternativas em texto
  • Imagens sem texto alternativo
  • Imagens com um nome de arquivo como texto alternativo
  • Imagens com texto alternativo muito longo
  • Texto alternativo com palavras redundantes, como “imagem de” ou “foto de”
  • Imagens em links com texto alternativo que parece descrever a imagem, e não o destino do link
  • Visualizações incorporadas que geralmente exigem uma alternativa em texto
• Links significativos
  • Links sem texto
  • Links cujo texto é um nome de arquivo
  • Links cujo texto é apenas genérico: “clique aqui”, “saiba mais”, “baixar” etc.
  • Links que abrem em uma nova janela sem um ícone de link externo
• Garantia de qualidade em geral
  • Garantir que seja usada a formatação de lista, e não asteriscos, números e letras
  • GRANDES QUANTIDADES DE TEXTO EM CAIXA ALTA
  • Tabelas sem cabeçalhos e tabelas com títulos de documento (“Título 3”) em vez de cabeçalhos de tabela (<th>)
  • Links para PDFs e outros documentos, lembrando o usuário de testar a acessibilidade do arquivo ou de oferecer um formato alternativo acessível
  • Vídeos incorporados, lembrando o usuário de adicionar legendas ocultas
  • Áudios incorporados, lembrando o usuário de fornecer uma transcrição
  • Conteúdo incorporado de redes sociais, lembrando o usuário de fornecer elementos alt

Disponibilizamos a biblioteca JavaScript para a comunidade, criamos uma integração com o Drupal pronta para uso e começamos a trabalhar em uma integração com o WordPress também pronta para uso.

Rumo à fase 3: Acessível por padrão

Em muitos aspectos, o Editoria11y é uma solução paliativa. A maioria dos erros que ele detecta foi cometida porque impusemos novas expectativas aos autores de conteúdo (“marque seu conteúdo com uma boa estrutura”), mas lhes demos ferramentas que incentivavam o contrário.

O caminho a seguir é tornar a criação de conteúdo acessível mais fácil e o mais automática possível. Como isso será ainda não está claro, mas provavelmente inclui coisas como:

• Repensar quais opções estão disponíveis. Por exemplo: se continuamos dizendo aos usuários que não justifiquem texto na Web, não estaria na hora de aposentar aquele botão “justificar texto”?
• Repensar as opções padrão. Por exemplo: a tabela padrão da maioria dos sistemas de gerenciamento de conteúdo não tem cabeçalhos. Cabe ao usuário saber que precisa clicar em “propriedades” e adicionar os recursos de acessibilidade; talvez esteja na hora de inverter isso?
• Refletir sobre formatação preditiva e “dicas enquanto você trabalha”. Se um usuário deixa uma linha inteira em negrito, podemos sugerir que a transforme em título? Se um usuário vai selecionar um título, podemos adivinhar quais níveis ele pode querer em vez de lhe dar seis opções? Podemos oferecer treinamento na hora certa para conceitos difíceis?