Notícias

Projetos ativos

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

Em curso

v3: Um conjunto completo de garantia de qualidade

27 de setembro de 2026

Apresentação pública na DrupalCon Europe 2026

Principais novas funcionalidades

• Fusão do núcleo de testes com o Sa11y. O novo conjunto de regras, desenvolvido em parceria, acrescenta testes para programadores, verificação de contraste e pontuação de legibilidade ao conjunto principal de regras para testes de conteúdo.
• Suporte para várias línguas
• Construtor de verificações personalizadas
• Ferramentas de manutenção do painel
• Uma ferramenta de rastreio do sítio para adicionar novos resultados.
• Permite que determinados testes (este PDF é acessível?) dispensem alertas em todo o sítio para determinadas funções.
• Configuração dividida: testes e vistas de relatório baseados em funções, separando programadores e responsáveis de conteúdo.

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

• Obtenção de um subsídio para lançar esta organização patrocinadora, de modo a apoiar os utilizadores atuais e financiar o trabalho em futuras ideias para o projeto.

v2: Dispensas e relatórios

2 de março de 2023

Há dois anos, apresentámos o verificador de acessibilidade Editoria11y como um plugin chave na mão para Drupal, que oferecia aos autores feedback automático e instantâneo, com dicas úteis para melhorarem os seus conteúdos.

Pensámos que isto iria responder a uma necessidade por satisfazer. As opções existentes exigiam todas formação e uma utilização diligente para serem úteis, e a experiência tinha-nos mostrado que tentar formar e acompanhar milhares de autores de conteúdo numa grande organização não era uma forma eficiente de enfrentar o problema. Para um programa ter êxito, estávamos convictos de que precisava de um elevado grau de automatização, proporcionando aos autores de conteúdo uma cortês «formação no momento certo» sempre que detetasse erros comuns.

Funcionou.

Em Princeton, inverteu em grande medida o sentido das minhas comunicações. Nas plataformas onde estava instalado, passámos de enviar e-mails repetitivos a autores de conteúdo a pedir melhorias no texto alternativo, nas ligações ou nos cabeçalhos a receber perguntas de autores de conteúdo sobre como melhorar a sua escrita para que não fosse tão assinalada.

Externamente, a reação foi de euforia:

Escrever dicas autónomas

Nas dicas da v1, adotámos uma abordagem de «resumo e pormenores»: uma breve explicação do problema e uma ligação para mais pormenores.

Isto representava uma melhoria face às ferramentas escritas para programadores: as dicas eram curtas e claras. Mas a decisão sobre para onde apontar a ligação foi sempre um problema. Vários utilizadores da administração pública e do ensino superior sentiram necessidade de alterar as dicas para retirar as ligações à documentação de Princeton, o que lhes dava trabalho extra. Por isso, reescrevemos as dicas predefinidas para serem autónomas, com exemplos incorporados.

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

Por isso, convertemos os avisos amarelos em «verificações manuais» para clarificar o seu significado e acrescentámos botões que permitem aos autores dispensar alertas. Os alertas «ignorados» ficam ocultos apenas para a pessoa que clica; os alertas «marcados como OK» ficam ocultos para todos os editores do sítio. Os administradores do sítio podem escolher quem tem permissão para fazer cada uma destas ações.

Criar um painel

Uma queixa frequente dos proprietários de sítios era que a ferramenta fazia um excelente trabalho a encontrar problemas por todo o sítio, mas não havia forma de ver um relatório global.

A reescrita acrescenta a opção de sincronizar os resultados com a base de dados do sítio. Os proprietários de sítios podem agora consultar os resultados por página ou por problema e rever quais os problemas que foram ignorados ou marcados como OK – e repô-los, se discordarem!

Visita guiada ao código da v2 para programadores

A v2 foi uma reescrita quase completa. Algumas das novas funcionalidades:

• A remoção da dependência de jQuery permite instalá-lo em mais plataformas e duplica o desempenho.
• O verificador pode agora ser configurado para analisar várias partes independentes da página (por exemplo, o conteúdo do artigo e o rodapé da página).
• O verificador pode agora testar elementos dentro do shadow DOM, utilizado por vários componentes Web e bibliotecas JavaScript.
• Muitos parâmetros novos facilitam as integrações com plataformas, como ignorar automaticamente todos os problemas em determinadas páginas para determinados utilizadores, caso não sejam responsáveis pelo conteúdo dessa página, mas possam ainda assim querer ver os resultados a pedido.
• O verificador inclui agora vários temas base e parâmetros para personalizar as cores.
• Os testes automatizados ajudam a prevenir 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 incorporada

11 de março de 2021

Criar conteúdos Web altamente acessíveis é complicado e tende a começar com muita formação.

É preciso desencorajar práticas familiares:

• As tabelas não devem ser utilizadas para criar colunas falsas
• O texto corrido não deve ser centrado nem justificado
• Não se deve depender de formatação meramente visual (peso e tamanho da letra) para transmitir significado aos utilizadores, que podem estar a ouvir o conteúdo ou a vê-lo em «modo de leitura»

É preciso incentivar novas práticas:

• As imagens precisam de texto alternativo com significado no contexto
• As páginas precisam de uma estrutura real
• As ligações devem ter títulos com significado

É certo que algumas das nossas formações existem porque estamos a ensinar conceitos novos, mas, a dada altura, há que perguntar: que parte da necessidade de novas competências vem do facto de os conceitos serem novos, e que parte vem de estarmos a impor novas expectativas sem atualizarmos as nossas ferramentas? Só porque algo é novo não significa que não possa ser intuitivo.

Lições da história da ortografia

Fase 1: culpar o autor

Desde os primórdios da história registada até ao início da década de 1980, culpávamos o autor quando escrevia mal uma palavra. A responsabilidade de aprender a escrever corretamente recaía sobre o autor.

Como é que alguém melhorava a sua ortografia? Isto vai soar familiar:

1. Frequentava formações, com tutores ou numa sala de aula
2. Recebia listas, orientações e dicionários para estudar, numa tradição que remonta aos antigos léxicos cuneiformes gravados em argila.

Fase 2: culpar o dicionário

Mas algo mudou na década de 1980: chamemos-lhe «fase 2 da ortografia». Os programas de processamento de texto mais populares implementaram a verificação ortográfica.

E o que aconteceu ao jogo das culpas? Quase de um dia para o outro, a culpa passou para a ferramenta:

• Não sabe como se escreve uma palavra? Arrisca um palpite e espera que seja encontrada uma correspondência. Se não for, a culpa é do dicionário.
• Usa uma palavra real que o dicionário assinala por não a conhecer? Resmunga e decide se ignora o sublinhado ou se clica com o botão direito e adiciona a palavra ao dicionário.

A verificação ortográfica resolveu todos os nossos erros? Claro que não. Mas ajudou. E transferiu grande parte do fardo e da responsabilidade do autor para a máquina.

Mas a história não acabou aqui…

Fase 3: culpar a ferramenta de autoria

Os últimos anos trouxeram mais um passo em frente: os computadores começaram a escrever por nós:

• Os algoritmos preditivos tentam adivinhar a palavra seguinte, a expressão seguinte, talvez até uma resposta inteira a uma mensagem de texto.
• As ferramentas de formatação automática tentam converter asteriscos, números e letras em listas, tentam converter códigos abreviados em caracteres especiais e emoji, etc.
• As ferramentas de ditado tentam reconhecer conceitos para escolher entre homónimos.

E quem fica com as culpas quando isto corre mal? A ferramenta!

Os agregadores de redes sociais adoram a embaraçosa captura de ecrã «Não era isso que eu queria dizer!».

O Editoria11y é um passo rumo à fase 2

Nas nossas formações, falamos muito sobre testes e apresentamos várias ferramentas de teste bastante boas. Nenhuma delas consegue detetar tudo: conceitos como «evitar explicar conceitos através de referências cromáticas ou espaciais» têm de ser verificados por um ser humano; as ferramentas detetam, em geral, pouco menos de metade dos problemas reais que um sítio pode ter. Mas fazem um trabalho muito bom a detetar muitos erros comuns em conteúdos editoriais.

Mas há três problemas:

1. A maioria são ferramentas manuais. O criador de conteúdo tem de ter aprendido a usá-las, tem de se lembrar de que existem quando escreve os seus conteúdos e tem de se lembrar de as executar quando termina. Estes três pontos de falha conspiram para deixar muito (a maior parte?) do conteúdo por verificar.
2. Assinalam demasiadas coisas. Não marcam apenas os erros que o autor acabou de cometer: marcam problemas de cor criados pelo designer, problemas técnicos criados pelo programador, elementos estruturais para fins informativos, etc. Isto eleva a fasquia das formações: os autores não só precisam de compreender a ferramenta, como têm de aprender a ignorar uma lista de falsos positivos ou de problemas bem reais que não lhes cabe corrigir hoje, enquanto escrevem este artigo em particular.
3. As ferramentas automatizadas tendem a seguir um paradigma de rastrear o sítio e visitar o painel. Mais uma vez: isto pressupõe que o autor recebeu formação para visitar o painel e que se vai lembrar de o fazer.

Por isso, Princeton decidiu criar algo novo: um verificador automático, integrado no sítio web, que analisasse apenas os erros editoriais comuns.

Automático é… difícil.

1. Os verificadores automáticos têm de ser subtis: se forem demasiado assertivos, interrompem e frustram o autor. Se forem demasiado delicados, podem tornar-se ruído de fundo fácil de ignorar.
2. Os verificadores automáticos têm de ter um desempenho muito elevado: se a página estremecer ou hesitar enquanto são executados, os autores ganham-lhes aversão e desativam-nos.
3. Os verificadores automáticos precisam de dicas acessíveis a principiantes. Para muitos autores, será a primeira vez que ouvem falar das etiquetas, da estrutura e da linguagem que tornarão os seus conteúdos mais acessíveis. Os alertas têm de usar linguagem simples e não técnica, com conselhos práticos para melhorar o conteúdo.

Por isso, começámos pela ferramenta mais próxima destes objetivos que conseguimos encontrar: o Sa11y, da Toronto Metropolitan University. Adotámos a sua arquitetura de testes e a sua abordagem intuitiva de painel de informação com dicas, e passámos meio ano a adaptar a ferramenta para que os testes corressem sempre automaticamente, a otimizar o seu desempenho, a afinar as dicas e a criar uma longa lista de opções de configuração que um programador pudesse usar para a adaptar rapidamente a qualquer plataforma.

Eis o seu aspeto atual:

Quando um autor tem sessão iniciada no seu sítio, o botão de alternância do Editoria11y indica o número e o tipo de problemas (aprovado, verificações manuais necessárias, problemas prováveis encontrados) em cada página. O autor pode clicar para revelar o realce incorporado e as dicas. Se o erro for novo, por estar a ver uma página que acabou de editar, o painel abre-se automaticamente.

Em março de 2021, isto significa que mais de 400 sítios web de Princeton verificam automaticamente:

• Uma boa estrutura de documento
  • Níveis de cabeçalho saltados
  • Cabeçalhos vazios
  • Cabeçalhos muito longos
  • Citações em bloco suspeitamente curtas que podem ser, na verdade, cabeçalhos.
• Alternativas textuais
  • Imagens sem texto alternativo
  • Imagens com um nome de ficheiro como texto alternativo
  • Imagens com texto alternativo muito longo
  • Texto alternativo com texto redundante como «imagem de» ou «fotografia de»
  • Imagens em ligações cujo texto alternativo parece descrever a imagem em vez do destino da ligação
  • Visualizações incorporadas que normalmente requerem uma alternativa textual
• Ligações com significado
  • Ligações sem texto
  • Ligações cujo título é um nome de ficheiro
  • Ligações cujo título é apenas texto genérico: «clique aqui», «saber mais», «transferir», etc.
  • Ligações que abrem numa nova janela sem um ícone de ligação externa
• Garantia de qualidade geral
  • Garantir que se usa formatação de lista em vez de asteriscos, números e letras
  • GRANDES QUANTIDADES DE TEXTO EM MAIÚSCULAS
  • Tabelas sem cabeçalhos e tabelas com cabeçalhos de documento («Cabeçalho 3») em vez de cabeçalhos de tabela (<th>)
  • Ligações para PDF e outros documentos, lembrando o utilizador de testar a acessibilidade do ficheiro transferido ou de disponibilizar um formato alternativo acessível
  • Vídeos incorporados, lembrando o utilizador de adicionar legendas
  • Áudios incorporados, lembrando o utilizador de disponibilizar uma transcrição
  • Conteúdos incorporados de redes sociais, lembrando o utilizador de fornecer elementos alt

Disponibilizámos a biblioteca JavaScript à comunidade, criámos uma integração chave na mão para Drupal e começámos a trabalhar numa integração chave na mão para WordPress.

Rumo à fase 3: acessível por predefinição

Em muitos aspetos, o Editoria11y é uma solução provisória. A maior parte dos erros que deteta foi cometida porque impusemos novas expectativas aos autores de conteúdo («marque o seu conteúdo com uma boa estrutura»), mas lhes demos ferramentas que incentivavam o contrário.

O caminho a seguir passa por tornar a criação de conteúdos acessíveis mais fácil e tão automática quanto possível. Como será isso ainda não é óbvio, mas provavelmente inclui coisas como:

• Repensar as opções disponíveis. Por exemplo: se continuamos a dizer aos utilizadores para não justificarem texto na Web, não estará na hora de reformar o botão «justificar texto»?
• Repensar as opções predefinidas. Por exemplo: a tabela predefinida na maioria dos sistemas de gestão de conteúdos não tem cabeçalhos. Cabe ao utilizador saber que tem de clicar em «propriedades» e adicionar as funcionalidades de acessibilidade; talvez esteja na hora de inverter isto?
• Ponderar a formatação preditiva e as «sugestões durante o trabalho». Se um utilizador puser uma linha inteira a negrito, podemos sugerir que a transforme num cabeçalho? Se um utilizador for selecionar um cabeçalho, podemos adivinhar que níveis de cabeçalho poderá querer, em vez de lhe dar seis opções? Podemos oferecer formação no momento certo para conceitos difíceis?