Pontuação de acessibilidade Lighthouse

O que esta verificação faz

Corre a auditoria de acessibilidade do Lighthouse (um subconjunto curado de regras axe-core) contra a página e reporta a pontuação ponderada. O MetricSpot falha a verificação abaixo de 90.

Porque é importante

A pontuação é um sinal grosseiro, mas honesto. O Lighthouse só apanha problemas que um parser estático consegue verificar — cerca de um terço do WCAG. Qualquer coisa que assinale é quase de certeza real, não um falso positivo.

Utilizadores reais ficam excluídos. Cerca de 1 em cada 5 visitantes usa tecnologia assistiva nalgum momento: leitores de ecrã, navegação só com teclado, modos de alto contraste, controlo por voz. Uma página com pontuação 60 de acessibilidade será inutilizável para a maioria.
Exposição legal. Na UE, o European Accessibility Act aplica-se a sites comerciais públicos desde junho de 2025. Nos EUA, o DOJ afirmou explicitamente que o ADA Título III cobre websites. Sites com pontuação reprovada são alvo frequente de processos abusivos.
SEO e IA. Os sinais de page-experience do Google incluem métricas adjacentes a acessibilidade. Os crawlers de IA fazem o parse com a mesma árvore DOM que os leitores de ecrã usam — semântica partida prejudica a extração.

Como corrigir

Abre o Lighthouse (Chrome DevTools → separador Lighthouse → Accessibility) e corre-o contra o URL falhado. O relatório lista cada auditoria falhada agrupada por severidade, com os nós DOM ofensivos destacados.

Foca-te primeiro nos itens com mais peso — o Lighthouse pondera as auditorias por impacto, não por contagem:

Contraste de cor (color-contrast) — texto ≥ 4.5:1, texto grande ≥ 3:1. Usa uma ferramenta como o Stark ou o indicador de contraste do DevTools.
Texto alternativo de imagens (image-alt) — cada <img> precisa de um atributo alt, ainda que vazio para imagens decorativas. Vê Texto alternativo de imagens.
Etiquetas de formulários (label) — cada input precisa de um <label for="…"> explícito. Vê Etiquetas de formulário.
Idioma do documento (html-has-lang) — <html lang="pt"> na raiz. Vê Declarar idioma da página.
Texto das ligações (link-name) — sem “clica aqui”, sem <a> vazios. Vê Texto descritivo de links.

Corre o axe-core em CI para apanhar regressões:

bun add -d @axe-core/playwright

import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";

test("home page is accessible", async ({ page }) => {
  await page.goto("/");
  const results = await new AxeBuilder({ page }).analyze();
  expect(results.violations).toEqual([]);
});

Verificações manuais que o Lighthouse não consegue. Anda com o Tab pela página de cima a baixo — a ordem do foco é lógica? O contorno de foco é visível? Liga o VoiceOver (Cmd+F5 no macOS) ou o NVDA (Windows) e lê uma página de ponta a ponta. Lighthouse 100 é o chão, não o teto.

Perguntas frequentes

Porque é que a minha pontuação foi tão diferente numa nova execução?

O Lighthouse corre num Chrome headless com CPU limitada. Ruído de rede, scripts de anúncios e o timing do banner de consentimento podem mexer 5–10 pontos na pontuação. Corre três vezes e tira a mediana; trata a tendência, não o valor pontual, como a verdade.

O Lighthouse está em 100 — já está?

Não. O Lighthouse audita cerca de 30% do WCAG. Os outros 70% (ordem lógica de leitura, fluxo de recuperação de erros, gestão de foco, significado de conteúdo transmitido só por cor) requerem revisão manual. Uma pontuação 100 significa que a linha de base automática está limpa; entrega a revisão manual por cima.

De onde vem a pontuação na auditoria?

O MetricSpot chama o motor Lighthouse durante a auditoria e guarda a pontuação. Se a execução falhar (a página está atrás de login, bloqueia browsers headless ou faz timeout) verás um achado separado de Acessibilidade Lighthouse indisponível.