aulify · Sebenta

UC · Unidade de Competência · UC02636

Acessibilidade e inclusão em multimédia

Design para todos · WCAG · Tecnologias assistivas

25h · 2.25 pontos crédito Curso: T. Multimédia ↗ Referencial oficial SNQ

Índice

Introdução
1. Porque importa
2. WCAG — Web Content Accessibility Guidelines
3. Tecnologias assistivas
4. Como aplicar em cada meio
5. ARIA — quando e como
6. Testar — automático, manual, com pessoas
7. Inclusão para lá da técnica
8. Workflow de equipa
9. Casos práticos
10. Conclusão
Apêndice A · Checklist rápida
Apêndice B · Recursos

Introdução

Acessibilidade é a propriedade de um produto poder ser usado por qualquer pessoa, independentemente das suas capacidades sensoriais, motoras ou cognitivas. Inclusão vai um passo além: pensar nas pessoas desde o início, não como um patch.

Esta UC complementa todas as outras de Multimédia. Não há "site bonito mas inacessível" — há sites bem feitos e sites mal feitos. Boa a11y = boa engenharia.

1. Porque importa

1.1 Números (Portugal e UE)

~1,7 milhões de pessoas com algum tipo de deficiência em Portugal (Censos).
15-20% da população mundial (OMS).
A envelhecer: cada vez mais gente com vista cansada, artrite, perda auditiva.
Utilizadores temporários (braço partido, ruído à volta) e situacionais (mão ocupada, sol no ecrã) → toda a gente, mais cedo ou mais tarde.

1.2 Razões para fazer

Ética/social: ninguém deve ser excluído de serviços essenciais (banca, saúde, educação).
Legal: Diretiva UE 2016/2102 (setor público) e EAA 2019/882 (privado, desde 28 jun 2025) — incumprimento dá coimas e processos.
SEO + UX: sites acessíveis ranqueiam melhor, têm menos bugs.
Mercado: ignorar 15% dos utilizadores potenciais é mau negócio.

1.3 Mitos a desfazer

"Estraga o design" → não, disciplina-o.
"Faz-se no fim" → custo 10× maior; algumas decisões já são irreversíveis.
"Basta alt nas imagens" → é o mínimo dos mínimos.
"Só interessa a cegos" → falsa: motora, auditiva, cognitiva, temporária, situacional…

2. WCAG — Web Content Accessibility Guidelines

WCAG 2.1 (e 2.2) é o standard internacional, mantido pelo W3C. Baseia-se em 4 princípios — POUR.

2.1 Perceptível

A informação tem de chegar pelos sentidos disponíveis.

Texto alternativo (alt) em imagens com informação.
Legendas sincronizadas em vídeo; transcrição em áudio.
Audiodescrição quando há visual essencial não falado.
Contraste texto/fundo ≥ 4.5:1 (texto normal) ou 3:1 (≥ 18pt ou 14pt bold).
Contraste UI ≥ 3:1 para componentes (botões, inputs, focus indicator).
Não depender só de cor para transmitir informação.
Redimensionamento até 200% sem perder função.
Reflow a 320 px sem scroll horizontal.

2.2 Operável

A interface tem de ser usável.

Tudo por teclado (Tab, Shift+Tab, Enter, espaço, setas, Esc).
Foco visível sempre — outline ou alternativa clara.
Sem armadilhas de teclado (poder sair de qualquer widget).
Tempo suficiente — avisar antes de timeouts; oferecer extensão.
Sem flashes > 3 por segundo em área significativa.
Skip link "Saltar para conteúdo".
Headings hierárquicos (h1 → h2 → h3) para navegação por estrutura.
Alvos de toque ≥ 44×44 px.

2.3 Compreensível

O conteúdo e operação têm de ser claros.

Idioma declarado (<html lang="pt-PT">).
Mudanças de idioma marcadas (lang="en" num excerto).
Comportamento previsível — sem ações inesperadas em foco/mudança.
Erros identificados e descritos ("Email inválido — falta @", não só "erro").
Sugestões de correção quando possível.
Linguagem clara (Plain Language) — frases curtas, palavras comuns.

2.4 Robusto

O código tem de funcionar com tecnologias assistivas.

HTML válido e semântico.
name, role, value acessíveis para componentes customizados (via ARIA quando necessário).
Status messages anunciados (toast com aria-live).

2.5 Níveis de conformidade

A — mínimo (poucos sites ficam só por aqui).
AA — padrão legal UE e referência global.
AAA — excelência, não exigido para todo o site (alguns critérios incompatíveis entre si).

3. Tecnologias assistivas

3.1 Leitor de ecrã

Software que lê o conteúdo em voz alta (ou para braille). Os principais:

NVDA — Windows, grátis, open source.
JAWS — Windows, profissional.
VoiceOver — macOS/iOS, integrado (Cmd+F5).
TalkBack — Android, integrado.

Lê o DOM em ordem, não o ecrã. Por isso o HTML semântico é crítico:

<button type="submit">Enviar</button>
<!-- anunciado: "Enviar, botão" -->

<div onclick="enviar()">Enviar</div>
<!-- anunciado: "Enviar" (texto sem função) -->

3.2 Outras

Lupa — ZoomText, lupa do SO. Precisa de layouts que sobrevivem a zoom grande.
Switches — 1-2 botões para navegar (mobilidade severa). Foco visível e ordem lógica são tudo.
Eye tracking — controlo pelo olhar (ex.: Tobii). Alvos grandes.
Comando por voz — Voice Control (Apple), Dragon. Beneficia de labels claras.
Switch control + scanning — sequencial; um botão chega.
Teclado adaptado — mecânico de teclas grandes, BigKeys.

3.3 Não-tecnológicas

Legendas (CC) e interpretação em LGP em vídeos institucionais.
Fácil leitura (Easy-to-Read) para deficiência intelectual.
Braille para impressos institucionais.

4. Como aplicar em cada meio

4.1 Imagens

<!-- Informativa -->
<img src="grafico.png" alt="Vendas subiram 30% entre 2023 e 2024.">

<!-- Decorativa -->
<img src="ornamento.png" alt="">

<!-- Funcional (logo que é link) -->
<a href="/"><img src="logo.svg" alt="Aulify"></a>

<!-- Complexa: descrição longa -->
<figure>
  <img src="infografico.png" alt="Infográfico das 6 fases.">
  <figcaption>Fases: 1. Briefing...</figcaption>
</figure>

Regras de ouro do alt: - Descreve o propósito, não pixels. - Vazio (alt="") se decorativo. - Não comeces com "Imagem de…" — o leitor já diz "imagem". - Texto sobre a imagem? Replica em texto real (alt ou ao lado).

4.2 Vídeo

Legendas sincronizadas e legíveis (font, contraste, posição).
Closed captions preferíveis a open (utilizador escolhe).
Para vídeos com informação visual: audiodescrição (narrador descreve o que acontece visualmente nas pausas do diálogo).
Transcrição completa descarregável.
Controlo de volume, pausa, velocidade acessíveis por teclado.
Sem autoplay com som.

4.3 Áudio

Transcrição sempre (acessível + boa para SEO).
Capítulos ou timestamps no podcast.
Não dependeres só de áudio para informação crítica.

4.4 Cor

Não comuniques só por cor:
Erros: vermelho + ícone ⚠️ + texto "Erro".
Status: gráfico com padrões/texturas + cor.
Links: cor diferente + sublinhado.
Testa com simuladores de daltonismo (Chrome DevTools → Rendering → Emulate vision deficiencies).
Cuidado com vermelho/verde (deuteranopia/protanopia, ~8% dos homens).

4.5 Formulários

<label for="email">Email</label>
<input
  id="email"
  type="email"
  name="email"
  autocomplete="email"
  required
  aria-describedby="email-hint"
>
<small id="email-hint">Usamos para enviar a confirmação.</small>

<!-- Erro inline -->
<input id="email" aria-invalid="true" aria-describedby="email-erro">
<p id="email-erro" role="alert">Email inválido — falta '@'.</p>

Boas práticas: - Cada input com <label> (não placeholder a fingir de label). - autocomplete correto (name, email, tel, street-address...). - Mensagens de erro específicas e inline. - Não submeter "ao escrever" (utilizador de teclado precisa de tempo). - Indicar campos obrigatórios visualmente e programaticamente.

4.6 Tabelas

<th> com scope="col" / scope="row".
<caption> com título da tabela.
Não usar tabela para layout.

4.7 Animação e motion

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

prefers-reduced-motion sempre respeitado.
Sem flashes > 3/seg numa área grande (risco de epilepsia).
Carousels e auto-rotação pausáveis.
Conteúdo não pode estar só atrás de animação.

4.8 Mobile

Alvos ≥ 44×44 px (iOS) / 48×48 dp (Android).
Suporta rotação (portrait/landscape).
Pinch-zoom não bloqueado (viewport não force user-scalable=no).
TalkBack/VoiceOver — testar realmente.

4.9 PDF e documentos

PDF "image-only" é inacessível — usa PDF taggado com texto extraível.
Headings, alts, tabelas estruturadas no Word/Google Docs → propagam ao PDF.
Preferir HTML a PDF sempre que possível (mais acessível por defeito).

5. ARIA — quando e como

ARIA = Accessible Rich Internet Applications. Atributos HTML que adicionam semântica quando o HTML não chega.

5.1 Regras de ouro

No ARIA é melhor que mau ARIA. Usar <button> é sempre melhor que <div role="button" tabindex="0"> com handlers à mão.
ARIA não muda comportamento, só anuncia. Um role="button" num <div> não passa a responder a Enter — tens de implementar.
Não inventar — só usar atributos válidos.

5.2 Atributos comuns

aria-label="Fechar" — quando o ícone não tem texto visível.
aria-labelledby="id" — quando o label é outro elemento.
aria-describedby="id" — descrição adicional (hint, erro).
aria-expanded="true|false" — em accordions, dropdowns.
aria-hidden="true" — esconder do leitor (ícones decorativos).
aria-live="polite|assertive" — anunciar mudanças (toast, status).
role="alert" — equivalente a aria-live="assertive" + relevância.

5.3 Padrões prontos

Em vez de implementar do zero, segue o ARIA Authoring Practices Guide (APG) do W3C: receitas testadas para combobox, modal, tabs, menu, etc.

6. Testar — automático, manual, com pessoas

6.1 Ferramentas automáticas

Ferramenta	Onde	Apanha
axe DevTools	Chrome/Firefox	30-40% dos problemas reais
Lighthouse	Chrome DevTools	Quick check, conta para auditorias
WAVE	webaim.org/wave	Overlay visual amigável
Pa11y	CLI	CI/CD, batch de páginas
Stark / Contrast	Figma/macOS	Design-time

⚠️ Automático só apanha o básico. Um relatório verde não significa "site acessível".

6.2 Testes manuais — checklist

Só com teclado — Tab por todo o ecrã. Consegues:
Ver onde está o foco em cada passo? (sem outline = falha)
Abrir e fechar modais/menus?
Submeter formulários?
Sair de carousels/widgets (sem armadilhas)?
Zoom a 200% (Cmd/Ctrl +) — texto cortado? Layout parte? Scroll horizontal?
Sem cor — DevTools → Rendering → Emulate vision deficiencies → "Achromatopsia". Tudo ainda faz sentido?
Leitor de ecrã (VoiceOver é gratuito):
Cmd+F5 para ligar.
Setas para navegar; VO+H headings; VO+L links; VO+G graphics.
O fluxo de leitura faz sentido?
Sem som — vídeo continua compreensível?

6.3 Teste com utilizadores reais

Nada substitui pessoas com deficiência a usar o produto. 1-2 sessões revelam problemas que ferramentas nunca apanham.

Recrutar: associações (ACAPO para visão, APD para deficiência, APS para surdez); User Interviews; redes.
Pagar os participantes — são peritos do próprio uso.
Observar, não guiar — pedir que descrevam o que estão a tentar fazer.

7. Inclusão para lá da técnica

7.1 Linguagem

Plain language — frases curtas (~15 palavras), palavras comuns, ativos.
Evita jargão; explica acrónimos no 1º uso.
Inclusivo de género quando relevante (neutros, plural, "a pessoa").

7.2 Imagens e representação

Diversidade em idade, cor de pele, capacidades, contextos socioeconómicos.
Não assumir contextos privilegiados (casa grande, último smartphone, internet fibra).

7.3 Cognição e neurodivergência

Layouts previsíveis entre páginas.
Chunks (parágrafos curtos, listas).
Tempo sem pressão.
Modo simplificado quando útil.
Cuidado com dislexia: tipografia legível (sans-serif moderadas, espaçamento generoso), evitar itálico longo, alinhamento à esquerda.

7.4 Acesso e dispositivo

Performance = acessibilidade (3G real, telemóveis antigos).
Offline-friendly quando possível.
Dados móveis — vídeos pesados não autoplay.

8. Workflow de equipa

8.1 Quem é responsável?

Toda a gente. Designer, copywriter, dev, PM, QA, conteúdo.

Designer: contraste, foco, hierarquia, alvos, estados.
Copy: clareza, alts, mensagens de erro, labels.
Dev: HTML semântico, ARIA quando necessário, testes.
PM: prioriza, exige a11y no Definition of Done.
QA: inclui testes de a11y na checklist.

8.2 Acessibilidade no fluxo

Design: anotar estados de foco, contrastes verificados, alts no design.
Implementação: HTML semântico, axe a cada PR.
QA: checklist + auditoria periódica.
Pós-lançamento: monitorizar com Pa11y CI; feedback channel acessível.

Statement of Accessibility público (exigido na UE para setor público).
O que é AA conforme, o que ainda não está, como contactar.

9. Casos práticos

9.1 Card clicável

Mau:

<div onclick="window.location='/post/1'">
  <h3>Título</h3>
  <p>Excerto</p>
</div>

Bom:

<article>
  <h3><a href="/post/1">Título</a></h3>
  <p>Excerto</p>
</article>

Toda a área pode ser clicável com CSS (a::after { content: ""; position: absolute; inset: 0; }), mantendo o link real.

9.2 Botão hamburger

<button
  type="button"
  aria-label="Abrir menu"
  aria-expanded="false"
  aria-controls="menu-principal"
>
  <svg aria-hidden="true">...</svg>
</button>
<nav id="menu-principal" hidden>...</nav>

JS troca aria-expanded e hidden.

9.3 Toast acessível

<div role="status" aria-live="polite">
  Encomenda guardada.
</div>

polite para confirmação; assertive para erros críticos (interrompe o leitor).

dialog nativo (<dialog>) ou ARIA role="dialog" aria-modal="true".
Focus trap dentro do modal enquanto aberto.
Foco volta ao botão que abriu, ao fechar.
Esc fecha.

10. Conclusão

Acessibilidade é uma prática, não um certificado. Pequenas decisões — usar <button> em vez de <div>, contraste 4.5:1, foco visível — compõem-se em algo que funciona para todos. E "todos" inclui o teu eu futuro: vais querer um site que ainda funcione quando tiveres 70 anos, óculos novos e uma mão dorida.

Apêndice A · Checklist rápida

[ ] Contraste ≥ 4.5:1 (texto), ≥ 3:1 (UI)
[ ] Navegação completa por teclado
[ ] Foco visível em todo o elemento focável
[ ] alt em todas as imagens (vazio se decorativas)
[ ] Legendas em todos os vídeos
[ ] HTML semântico (<button>, <nav>, <main>, headings hierárquicos)
[ ] <label> em todos os inputs
[ ] prefers-reduced-motion respeitado
[ ] <html lang="pt-PT">
[ ] Sem flashes > 3/seg
[ ] Alvos toque ≥ 44 px
[ ] Erros descritivos
[ ] Testado com leitor de ecrã

Apêndice B · Recursos

W3C WCAG 2.1/2.2 — w3.org/WAI/standards-guidelines/wcag/
ARIA Authoring Practices Guide — w3.org/WAI/ARIA/apg/
WebAIM — webaim.org (contraste, recursos, formação)
A11y Project — a11yproject.com (checklist e padrões)
Inclusive Components — inclusive-components.design (Heydon Pickering)
Microsoft Inclusive Design — microsoft.com/design/inclusive/
Acessibilidade.gov.pt — recursos PT