Destinatários

Designers, developers front-end, testers de QA, UX researchers e responsáveis de conteúdo que já correm validadores automáticos mas precisam de ir além do score.
É também dirigida a equipas que necessitam de transformar descobertas de acessibilidade em tickets acionáveis e num processo de remediação recorrente, e que reconhecem que a validação com utilizadores reais é insubstituível pela auditoria técnica.

Objectivos

Esta formação tem como objetivo capacitar os participantes a distinguir o que as ferramentas automáticas detectam do que exige inspeção humana.
No final da formação terá as informações necessárias para validar produtos digitais com leitores de ecrã e em dispositivos móveis, conduzir sessões de validação com utilizadores reais de tecnologias de apoio, e converter todos estes achados num plano de remediação priorizado, com tickets prontos para o ciclo de desenvolvimento.

Programa

A formação “Temos um Bom Score de Acessibilidade. E Agora?” tem o formato online live-training e a duração de 6 horas, distribuídas em 2 módulos de 3 horas cada, no formato teórico-prático e com exercícios aplicados diretamente à realidade organizacional dos formandos.

Conteúdos

• 1. Avaliação Técnica

• 1.1. Ferramentas Automáticas:

  1. O que os Validadores Medem
     Distinção entre o que scanners como o Axe, o Lighthouse e o WAVE detectam de forma fiável (contraste, alt, labels, ARIA, headings) e o que continua a exigir inspeção humana (ordem de leitura, foco preso, textos de link genéricos, drag & drop…).
  2. Três Ferramentas Essenciais
     Quando usar o Axe DevTools (precisão, integração em CI/CD), o Lighthouse (auditoria e relatórios de gestão) e o WAVE (visualização inline, ideal para formação e sensibilização).
  3. Exercício “Score 100. Acessível?”
     Auditoria comparativa numa página real do produto dos formandos com Axe e Lighthouse, seguida da deteção manual de 3 erros que nenhum dos dois scanners identificou.

• 1.2. Inspeção Semântica:

  1. Estrutura de Headings e Landmarks
     Leitura do documento apenas pelos títulos (Document Outline) e verificação de header, main, nav, aside e footer através dos ARIA Roles.
  2. Listas, Tabelas e Ordem de Leitura
     Uso correto de thead, th e scope em tabelas de dados, ul/ol em listas, e validação da ordem de leitura com o CSS desativado.
  3. Exercício “Estrutura sem Estilo”
     Leitura de uma página de conteúdo com o CSS desligado, comparando a história contada pela estrutura semântica com a contada pelo layout visual.

• 2. Experiência Real e Processo

• 2.1. Leitores de Ecrã e Mobile:

  1. Leitores de Ecrã na Prática
     NVDA e Narrator, VoiceOver e TalkBack — onde cada um domina, e como simular a experiência sem depender de hardware dedicado.
  2. Exercício “Navegar sem Olhar”
     Em pares, um formando navega às cegas com o leitor de ecrã enquanto o outro observa e cronometra os pontos onde o utilizador fica preso.
  3. Acessibilidade Mobile
     Touch targets mínimos, uso de teclado externo, zoom e reflow a 200%, e comportamento do foco ao rodar o ecrã.

• 2.2. Validação com Utilizadores:

  1. Porque Testar com Utilizadores Reais
     A diferença entre um formador a simular um leitor de ecrã e um utilizador real de tecnologia de apoio: vieses do avaliador, atalhos e estratégias de contorno que só quem usa a tecnologia diariamente revela.
  2. Recrutar e Preparar Sessões de Teste
     Onde encontrar participantes com necessidades de acessibilidade diversas (visual, motora, cognitiva, auditiva), consentimento informado, e como adaptar o guião de teste a cada perfil.

• 2.3. Formulários e Remediação:

  1. Formulários e Interações Dinâmicas
     Labels associados a cada campo, mensagens de erro anunciadas ao leitor de ecrã, gestão de foco em modais e uso de live regions em conteúdo que muda em reload.
  2. Exercício “Preencher às Cegas”
     Preenchimento de um formulário real apenas com teclado e leitor de ecrã, incluindo uma submissão propositadamente incompleta para testar o anúncio do erro.
  3. Da Auditoria ao Ticket
     Critérios de severidade, impacto e esforço para priorizar achados, incluindo os que só emergiram na sessão com utilizadores, e como escrever um ticket de acessibilidade que um developer consegue fechar sem ambiguidade.
  4. Exercício “Plano de Remediação”
     Consolidação dos achados de todos os exercícios anteriores, incluindo a sessão de validação com utilizadores, em tickets prontos para o backlog, cada um com o critério de aceitação que confirma a correção.