UC02636

Acessibilidade e inclusão em multimédia

Design para todos · WCAG · Tecnologias assistivas

Técnico de Multimédia · 25h

Plano da unidade

  1. Acessibilidade não é um extra
  2. WCAG: 4 princípios, 13 critérios essenciais
  3. Tecnologias assistivas
  4. Acessibilidade em cada meio
  5. Testar e auditar
  6. Inclusão para lá da técnica

Bloco 1 · Acessibilidade não é um extra

Quem fica de fora?

  • 15-20% da população vive com algum tipo de deficiência (visual, auditiva, motora, cognitiva).
  • Mais utilizadores temporários: braço partido, ruído à volta, ecrã ao sol, idoso com vista cansada.
  • E utilizadores situacionais: comboio sem som, mão ocupada, dados móveis lentos.

Acessibilidade boa = melhor experiência para todos.

Os mitos comuns

  • "Só interessa a poucas pessoas." → Não. (E legalmente obriga em serviços públicos/empresas.)
  • "Estraga o design." → Não. Limita-o (= boa restrição criativa).
  • "Faz-se no fim." → Faz-se desde o início. Adicionar a11y depois custa 10× mais.
  • "Basta alt nas imagens." → É só o começo.
  • Diretiva (UE) 2016/2102 — sites e apps do setor público acessíveis.
  • Diretiva (UE) 2019/882 (EAA) — acessibilidade de produtos e serviços (e-commerce, banca, e-books, comunicações) — em vigor desde 28 jun 2025.
  • Referência técnica: WCAG 2.1 nível AA (EN 301 549).
  • Coimas reais para incumprimento em serviços abrangidos.

Bloco 2 · WCAG: 4 princípios

POUR · os 4 princípios

  1. Perceptível — conteúdo perceptível pelos sentidos disponíveis.
  2. Operável — interface usável por qualquer input.
  3. Understandable / Compreensível — claro, previsível.
  4. Robusto — compatível com tecnologias assistivas.

3 níveis: A (mínimo), AA (padrão legal), AAA (excelência, opcional).

Perceptível — essenciais

  • Texto alternativo em imagens informativas (alt).
  • Legendas em vídeo; transcrição em áudio.
  • Contraste ≥ 4.5:1 (texto normal); ≥ 3:1 (texto grande/UI).
  • Conteúdo não depende só da cor (vermelho ≠ erro, precisa de ícone/texto).
  • Texto redimensionável até 200% sem perda de função.

Operável — essenciais

  • Tudo acessível por teclado (Tab, Enter, Esc).
  • Foco visível em qualquer elemento focável.
  • Sem armadilhas de teclado (poder sempre sair).
  • Tempo suficiente (sem deadlines escondidos).
  • Sem conteúdo que provoque convulsões (≤ 3 flashes/seg).
  • Skip link "Saltar para conteúdo principal".

Compreensível + Robusto

Compreensível:

  • Idioma da página declarado (<html lang="pt">).
  • Erros explicados (não só "erro").
  • Comportamento previsível (não abrir popups sem aviso).

Robusto:

  • HTML semântico válido (a base de tudo).
  • ARIA apenas quando o HTML não basta.
  • Compatibilidade com leitores de ecrã.

Bloco 3 · Tecnologias assistivas

Quem usa o quê

  • Leitor de ecrã (NVDA, JAWS, VoiceOver) — cegueira/baixa visão; lê o HTML em ordem.
  • Lupa (ZoomText, lupa do SO) — baixa visão.
  • Comutadores / switches — mobilidade reduzida; navegação por um botão.
  • Eye tracking — controlo por olhar.
  • Comando por voz (Voice Control, Dragon).
  • Teclado adaptado / sem rato.
  • Legendas + interpretação em LGP.

O que o leitor de ecrã "vê"

Não vê design — vê HTML.

<!-- mau -->
<div onclick="enviar()">Enviar</div>

<!-- bom -->
<button type="submit">Enviar</button>

Um <button> é anunciado como "Enviar, botão". Um <div> clicável é invisível (ou anunciado como texto sem função).

Bloco 4 · Acessibilidade em cada meio

Imagens

  • alt informativo (descreve o propósito, não pixels).
    alt="João sorri com diploma" ✓ · alt="JPG 1200x800" ✗
  • alt="" em imagens decorativas (leitor ignora).
  • Texto em imagens → evita; se necessário, replica em texto real.
  • Infografias → descrição longa em texto a seguir.

Vídeo

  • Legendas (CC) sincronizadas e bem cronometradas.
  • Audiodescrição quando há informação visual essencial não falada.
  • Transcrição descarregável.
  • Pausa, parar, controlo de volume acessíveis por teclado.
  • Sem autoplay com som.

Áudio (podcasts, música, narração)

  • Transcrição completa.
  • Capítulos/marcadores para navegar.
  • Para áudio informativo: nunca dependas só dele.

Cor

  • Não comuniques só por cor (gráficos, semáforos, erros).
    Junta ícone, texto ou padrão.
  • Verifica em modo daltonismo (Protanopia/Deuteranopia/Tritanopia) — plugins Figma, DevTools.
  • Contraste com WebAIM, Stark, Contrast (macOS).

Formulários

  • Cada input com <label> associada.
  • Erros inline + descritivos: "Email inválido — falta '@'", não só "erro".
  • autocomplete preenchido (name, email, etc.).
  • Foco visível em cada campo.
  • Validação acessível (aria-invalid, aria-describedby).

Animação e motion

  • prefers-reduced-motion respeitado (versão simplificada).
  • Sem flashes > 3/seg numa área grande (risco de epilepsia).
  • Pausável quando longa (carousels).
  • Não esconde informação atrás de animação obrigatória.

Mobile + toque

  • Alvos ≥ 44 × 44 px (Apple) / ≥ 48 × 48 dp (Google).
  • Gestos têm alternativa (botão equivalente).
  • Suporta rotação (não forçar landscape).
  • Funciona com TalkBack (Android) / VoiceOver (iOS).

Bloco 5 · Testar e auditar

Ferramentas automáticas

  • axe DevTools (browser) — apanha 30-40% dos problemas reais.
  • Lighthouse Accessibility — quick check (em DevTools).
  • WAVE (WebAIM) — overlay visual.
  • Stark / Contrast — contraste e daltonismo.

Atenção: automático não chega. Apanha o básico; teste manual descobre o resto.

Testes manuais essenciais

  1. Navegar só com teclado — Tab por todo o site. Consegues fazer tudo? Foco visível?
  2. Leitor de ecrã — VoiceOver (macOS/iOS) Cmd+F5; NVDA (Windows, grátis); TalkBack (Android).
  3. Zoom 200% — ainda funciona? Texto cortado?
  4. Sem cor — DevTools → Rendering → Emulate vision deficiencies.
  5. Sem som / com som — vídeo continua a fazer sentido?

Teste com utilizadores reais

  • O melhor teste é com pessoas com deficiência — associações locais, plataformas como User Interviews.
  • Mesmo 1-2 sessões revelam problemas que ferramentas nunca apanham.
  • Pagar os participantes; tratar como peritos do próprio uso.

Bloco 6 · Inclusão para lá da técnica

Linguagem inclusiva

  • Linguagem clara (plain language) — frases curtas, palavras comuns.
  • Evitar jargão sem explicação.
  • Pronomes/género — quando relevante, neutro ou plural.
  • Imagens diversas (idade, cor de pele, capacidades, contextos).
  • Não assumir que todos têm casa, smartphone caro, internet rápida.

Inclusão cognitiva e neurodivergência

  • Layouts previsíveis (não muda a posição entre páginas).
  • Conteúdo chunked (parágrafos curtos, listas, títulos).
  • Tempo suficiente; sem distrações desnecessárias.
  • Opção de modo simplificado quando útil.
  • Considerar dislexia: tipografia legível, sem itálico longo, contraste suave.

Checklist final (10 mínimos)

  1. Contraste ≥ 4.5:1
  2. Navegação por teclado completa
  3. Foco visível
  4. alt correto em imagens
  5. Legendas em vídeo
  6. HTML semântico (<button>, <nav>, ...)
  7. Labels em todos os inputs
  8. prefers-reduced-motion respeitado
  9. Lang declarado (<html lang="pt">)
  10. Testado com leitor de ecrã

UC02636 · resumo

  • 15-20% utilizam algum apoio; muitos mais beneficiam de boa a11y.
  • WCAG POUR com nível AA legal na UE.
  • Tecnologias assistivas "veem" HTML — escrever bem importa.
  • Cada meio (imagem/vídeo/áudio/cor/formulário/animação) tem regras próprias.
  • Testar automático + manual + com pessoas reais.
  • Inclusão é técnica + linguagem + imagem + atitude.