Apostila completa de Acessibilidade Digital & WCAG
Cerca de 1 em cada 6 pessoas no mundo vive com alguma deficiência — e todo mundo, em algum momento, usa a web com uma mão ocupada, sob sol forte, ou com uma lesão temporária. Acessibilidade é construir para essa realidade. Esta apostila vai dos princípios POUR do WCAG ao HTML semântico, foco por teclado, ARIA sem estragar, testes com leitor de tela, e o cenário legal — incluindo o European Accessibility Act, em aplicação desde junho de 2025 para produtos e serviços privados.
Por que acessibilidade e quem é afetado
Objetivo: entender a diversidade de pessoas e situações que a acessibilidade atende, os quatro argumentos a favor, e desmontar os mitos comuns.
1.1 A gama de deficiências — e de situações
| Domínio | Exemplos | Barreiras comuns na web |
|---|---|---|
| Visão | Cegueira, baixa visão, daltonismo | Imagem sem alternativa textual, contraste baixo, informação só por cor, texto que não amplia |
| Auditiva | Surdez, perda auditiva | Vídeo sem legenda, áudio sem transcrição |
| Motora | Tremor, amputação, paralisia, RSI | Alvos pequenos, ações só por mouse, tempo limitado, arrastar obrigatório |
| Cognitiva / neurodivergência | Dislexia, TDAH, autismo, deficiência intelectual, memória | Linguagem complexa, layout caótico, sem feedback claro, movimento distrativo, fluxos longos |
| Fala | Dificuldade de fala | Interfaces só por comando de voz sem alternativa |
| Fotossensibilidade | Epilepsia fotossensível | Flashes > 3×/s |
A Microsoft popularizou este enquadramento: a barreira de "usar com uma mão só" atinge quem tem uma amputação (permanente), quem quebrou o braço (temporário) e quem está segurando um bebê (situacional). Acessibilidade não é um recurso para "eles" — é design para a variação humana real, e o benefício vaza para todo mundo (o "curb-cut effect": a rampa na calçada, feita para cadeiras de rodas, serve carrinhos de bebê, malas, entregadores).
1.2 Os quatro argumentos
- Ético / direitos: acesso à informação e a serviços é um direito; excluir pessoas de bancos, compras, saúde e educação online é discriminação.
- Legal: WCAG virou referência em leis no mundo todo — EU Web Accessibility Directive, European Accessibility Act, ADA/Section 508 (EUA, com forte litígio), lei brasileira (LBI/Decreto 5.296, eMAG no governo). Módulo 9.
- Negócio: o "mercado da deficiência" e suas famílias movimenta trilhões; sites inacessíveis perdem clientes, e um processo custa mais que a correção.
- Qualidade: código acessível é HTML semântico, testável, com bom SEO, performático, e mais fácil de manter. Acessibilidade e qualidade técnica andam juntas.
1.3 Mitos
| Mito | Realidade |
|---|---|
| "É só para cegos" | A maioria dos usuários de acessibilidade tem baixa visão, deficiência motora ou cognitiva — não usa leitor de tela |
| "Deixa o site feio" | Acessibilidade é sobre estrutura e comportamento, não sobre aparência; sites premiados são acessíveis |
| "É caro e lento" | Feito desde o início ("shift-left"), o custo marginal é baixo; corrigir depois é que é caro |
| "Um overlay/plugin resolve" | A comunidade de deficiência rejeita overlays — eles não corrigem os problemas de fundo e frequentemente atrapalham a tecnologia assistiva (Módulo 9) |
| "Nosso público não tem deficiência" | Você não sabe — e não deveria precisar saber para não excluir |
Com o EAA em vigor, "Accessibility Specialist/Engineer", "Inclusive Design" e "a11y" viraram linha de vaga em produto, jurídico e QA. Pergunta de abertura: "Por que acessibilidade importa e quem é afetado?" — a resposta forte cita a gama de deficiências (não só visão), o enquadramento permanente/temporário/situacional, e os quatro argumentos (ético, legal, negócio, qualidade).
✏️ Exercício 1 — Encontre as barreiras
Uma tela de checkout tem: um botão "Comprar" que só funciona no clique do mouse; campos de erro em vermelho sem texto; um contador "conclua em 5:00" que expira o carrinho; e um vídeo explicativo autoplay sem legenda. Para cada, diga quem é afetado e a correção.
Gabarito: (1) Botão só-mouse → exclui quem navega por teclado, switch, ou voz; correção: usar <button> real que responde a Enter/Espaço. (2) Erro só por cor vermelha → daltônicos e leitores de tela não percebem; correção: mensagem de texto associada ao campo (aria-describedby), ícone + texto, e não depender só de cor. (3) Tempo limitado → prejudica quem tem deficiência motora/cognitiva ou usa leitor de tela (mais lento); correção: WCAG pede permitir estender/desligar o limite, ou avisar e dar mais tempo. (4) Vídeo autoplay sem legenda → exclui surdos, incomoda todos, e leitores de tela; correção: legendas, sem autoplay (ou com controle e sem som), transcrição.
WCAG: POUR, níveis e versões
Objetivo: a estrutura das Web Content Accessibility Guidelines — os quatro princípios, os critérios de sucesso, os níveis A/AA/AAA — e o que muda entre 2.0, 2.1, 2.2 e o rumo do 3.0.
2.1 A estrutura
As WCAG (do W3C) são organizadas em quatro camadas:
- 4 princípios (POUR): o conteúdo deve ser Perceptível, Operável, Uompreensível (Understandable), Robusto.
- 13 diretrizes (guidelines): objetivos gerais sob cada princípio (ex.: "1.1 Alternativas em texto").
- Critérios de sucesso (success criteria): as regras testáveis, cada uma com um nível (ex.: "1.1.1 Conteúdo não textual — Nível A"). É o que se audita.
- Técnicas e documentos de apoio: "sufficient techniques", "understanding", "how to meet" — não normativos, mas essenciais na prática.
| Princípio | Pergunta | Exemplos de critério |
|---|---|---|
| Perceptível | A informação e a UI podem ser percebidas pelos sentidos disponíveis? | Texto alternativo, legendas, contraste, não usar só cor, reflow, redimensionar texto |
| Operável | A interface pode ser operada por qualquer forma de entrada? | Tudo por teclado, sem armadilha de foco, tempo suficiente, sem flashes, foco visível, alvos grandes (2.2) |
| Compreensível | A informação e a operação são claras e previsíveis? | Idioma da página, comportamento previsível, ajuda em erros, labels e instruções, navegação consistente |
| Robusto | Funciona com tecnologias assistivas atuais e futuras? | HTML válido, nome/role/value corretos, mensagens de status anunciadas |
2.2 Os níveis A, AA, AAA
- A — o mínimo essencial; sem isso há barreiras graves.
- AA — o alvo prático de conformidade na maioria das leis e contratos (EU, EAA/EN 301 549, Section 508). "Conformidade WCAG" quase sempre significa "2.1 AA" ou "2.2 AA".
- AAA — nível elevado; alguns critérios não são atingíveis para todo tipo de conteúdo, então não se exige AAA para o site inteiro — aplica-se onde faz sentido.
- 1.4.3 Contraste (mínimo): texto normal ≥ 4,5:1; texto grande (≥ 24px ou 19px bold) ≥ 3:1.
- 1.4.11 Contraste não textual: componentes de UI e gráficos ≥ 3:1.
- 1.4.10 Reflow: conteúdo utilizável a 320px de largura sem scroll em dois eixos (equivale a zoom 400%).
- 1.4.4 Redimensionar texto: até 200% sem perda de conteúdo/função.
- 2.4.7 Foco visível; 2.4.11 Foco não obscurecido (2.2).
- 2.5.8 Tamanho do alvo (mínimo): 24×24px (2.2).
- 3.3.7 Entrada redundante e 3.3.8 Autenticação acessível (2.2) — não obrigar a redigitar/decorar.
2.3 Versões
| Versão | O que trouxe |
|---|---|
| WCAG 2.0 (2008) | A base POUR; ainda referenciada em leis antigas |
| WCAG 2.1 (2018) | +17 critérios: mobile, baixa visão (reflow, contraste não textual), cognitivo (timeouts, orientação), motor (target size AAA, pointer gestures) |
| WCAG 2.2 (2023) | +9 critérios: foco não obscurecido, tamanho de alvo mínimo (AA), arrastar tem alternativa, ajuda consistente, entrada redundante, autenticação acessível. (Removeu o 4.1.1 "Parsing", agora obsoleto) |
| WCAG 3.0 (rascunho, "Silver") | Reestruturação profunda: novo modelo de conformidade (pontuação/graus em vez de "passou/falhou" por critério), escopo além de "conteúdo web", processos e não só páginas. Anos de distância; não usar como base de conformidade ainda |
Recomendação prática: mire WCAG 2.2 AA (é retrocompatível com 2.1 e 2.0). Leis podem citar uma versão específica; a EN 301 549 (a norma técnica europeia) incorpora WCAG e é o que o EAA referencia.
2.4 Declarar conformidade
- Uma declaração de conformidade formal exige: a versão/nível, o escopo (URLs), a data, e que todas as páginas do escopo satisfaçam todos os critérios daquele nível (conformidade é binária por critério).
- Mais comum e honesto: uma página "Acessibilidade" (accessibility statement) que diz o alvo (2.2 AA), o estado atual, os problemas conhecidos, e um canal de contato/feedback — exigido pela legislação europeia para setor público e boa prática para todos.
- VPAT / ACR (Voluntary Product Accessibility Template / Accessibility Conformance Report): o documento padrão em procurement, sobretudo para vender ao setor público dos EUA.
Perguntas: "O que significa POUR?", "Diferença entre A, AA e AAA — qual o alvo prático?" (AA), "Cite três critérios de nível AA" (contraste 4,5:1, reflow a 320px, foco visível…), "O que a WCAG 2.2 adicionou?" (foco não obscurecido, target size mínimo, autenticação acessível…), "O que é uma accessibility statement e um VPAT?".
✏️ Exercício 2 — Classifique por princípio
Para cada problema, diga qual princípio POUR ele viola: (a) um ícone de "salvar" sem rótulo acessível; (b) um carrossel que só avança com swipe; (c) um <div onclick> como botão; (d) um erro de formulário que só diz "erro" sem explicar o quê; (e) contraste de 2,8:1 no texto do corpo.
Gabarito: (a) Robusto (nome acessível ausente) — e também Perceptível. (b) Operável (não funciona por teclado / gesto único sem alternativa — 2.5.1/2.5.7). (c) Robusto (role/estado errados; não é focável nem anunciado como botão) + Operável. (d) Compreensível (3.3.1/3.3.3 — identificar e sugerir correção do erro). (e) Perceptível (1.4.3 contraste mínimo).
HTML semântico e a árvore de acessibilidade
Objetivo: entender por que o elemento HTML certo faz metade do trabalho, o que é a "accessibility tree", e o trio nome / role / value.
3.1 O elemento nativo já vem acessível
Um <button> é: focável por teclado, ativável por Enter e Espaço, anunciado como "botão" pelo leitor de tela, e estilizável. Um <div> transformado em botão não tem nada disso — você teria que adicionar tabindex="0", role="button", handlers de teclado, e ainda assim faltariam detalhes. A primeira regra de acessibilidade é usar o elemento HTML certo.
| Você quer… | Use | Não use |
|---|---|---|
| Uma ação | <button> | <div>/<span> com onclick |
| Navegar para outra página/âncora | <a href> | <button> que faz location=, ou div clicável |
| Entrada de dados | <input>/<select>/<textarea> com <label> | divs com contenteditable e listeners |
| Estrutura da página | <header>, <nav>, <main>, <aside>, <footer>, <h1>–<h6> | divs com classes "header", "sidebar"… |
| Lista | <ul>/<ol>/<li> | divs (o leitor de tela anuncia "lista de 5 itens") |
| Tabela de dados | <table> com <th scope>, <caption> | grid de divs (perde navegação por célula/cabeçalho) |
| Divulgar/esconder conteúdo | <details>/<summary> (para casos simples) | div + JS sem aria-expanded |
3.2 Landmarks e headings — a "sumário" da página
- Landmarks (
banner/header,navigation/nav,main,complementary/aside,contentinfo/footer,search): usuários de leitor de tela pulam entre regiões. Tenha um<main>, rotule<nav>s múltiplas (aria-label). - Headings: um
<h1>por página (o título do conteúdo), hierarquia sem pular níveis (não vá deh2parah4). Usuários de leitor de tela navegam a página pelos headings — uma hierarquia quebrada é como um índice bagunçado. - Skip link ("Pular para o conteúdo") como primeiro elemento focável.
3.3 A accessibility tree
O navegador constrói, a partir do DOM + CSS + ARIA, uma árvore de acessibilidade — uma versão simplificada da página que ele expõe às APIs de acessibilidade do sistema operacional (UIA no Windows, AX no macOS, etc.), que os leitores de tela e outras tecnologias assistivas consomem. Cada nó relevante tem:
- Nome (accessible name): o rótulo que será falado ("Enviar formulário"). Vem, em ordem:
aria-labelledby→aria-label→ conteúdo (texto do botão,altda imagem) →<label>associado →title(último recurso). A ordem de precedência importa e é fonte de bug. - Role (papel): o que o elemento é ("button", "link", "checkbox", "heading level 2"). Vem do elemento nativo ou de
role=. - Value / state / properties: o valor atual e os estados ("checked", "expanded", "disabled", "invalid", "20% preenchido", "3 de 5").
Para todo componente interativo, um usuário de leitor de tela precisa saber: o que é (role), como se chama (name), em que estado está (value/state). Se você constrói um componente custom e falha em qualquer um dos três, ele é inutilizável para quem depende de tecnologia assistiva. É o critério 4.1.2 do WCAG e a checagem mais frequente numa auditoria.
Ferramentas: o painel "Accessibility" do DevTools (Chrome/Firefox) mostra a árvore e o nome computado de qualquer elemento — use-o para depurar.
Perguntas: "Por que <div onclick> como botão é um problema?" (sem foco, sem teclado, sem role — falha nome/papel/valor), "O que é a accessibility tree?", "Como o nome acessível de um elemento é computado?" (aria-labelledby > aria-label > conteúdo > label > title), "Por que a hierarquia de headings importa?" (navegação por leitor de tela), "O que são landmarks?".
✏️ Exercício 3 — Conserte o "botão"
Um componente de card tem: <div class="card" onclick="abrir()">...<div class="fav" onclick="favoritar()">♥</div></div>. Liste os problemas de acessibilidade e a versão correta.
Gabarito: Problemas: (1) o card inteiro clicável não é focável nem operável por teclado, não tem role, e "clique aninhado" (favoritar dentro de abrir) é ambíguo. (2) O "♥" não tem nome acessível (leitor de tela fala "♥" ou nada), não é botão, não comunica estado (favoritado ou não). Correção: o card não deve ser um "botão gigante" — dentro dele, um <a href> real no título (a navegação principal) e um <button> separado para favoritar: <button aria-pressed="false" aria-label="Favoritar Café Especial"><span aria-hidden="true">♥</span></button>. O aria-pressed alterna e comunica o estado; o ícone é decorativo (aria-hidden); o nome vem do aria-label. Se quiser a "área clicável grande" visualmente, use CSS (pseudo-elemento estendendo o link), não um div-botão.
Teclado e gestão de foco
Objetivo: garantir que tudo seja operável por teclado, com ordem de foco lógica, foco visível, e gestão correta de foco em SPAs, modais e widgets.
4.1 O teste de teclado (o mais rápido e revelador)
Guarde o mouse. Navegue a página inteira com Tab (avançar), Shift+Tab (voltar), Enter/Espaço (ativar), setas (dentro de componentes), Esc (fechar). Você deve conseguir fazer tudo e ver sempre onde está o foco. É o teste que pega mais bugs em menos tempo.
4.2 Os requisitos
- Tudo operável por teclado (WCAG 2.1.1). Se dá para clicar, tem que dar para tabular e acionar.
- Sem armadilha de foco (2.1.2): o foco nunca fica preso num componente sem saída (exceto o focus trap intencional de um modal, do qual se sai com Esc ou fechando).
- Ordem de foco lógica (2.4.3): segue a ordem visual/de leitura. A ordem do DOM manda; evite
tabindexpositivo (quebra a ordem para todos). - Foco visível (2.4.7): nunca
outline: nonesem um substituto claro. Use:focus-visiblepara um anel de foco bonito e com contraste ≥ 3:1. - Foco não obscurecido (2.4.11, WCAG 2.2): um header sticky ou um cookie banner não pode cobrir o elemento focado.
- Alvos de tamanho adequado (2.5.8): mínimo 24×24px (com exceções); ideal 44px.
4.3 tabindex
| Valor | Efeito | Uso |
|---|---|---|
tabindex="0" | Torna focável, na ordem natural do DOM | Um componente custom que precisa receber foco (com role apropriado) |
tabindex="-1" | Focável por script (.focus()), mas não por Tab | Mover o foco programaticamente (destino de skip link, título de página em SPA, primeiro erro) |
tabindex="1" (positivo) | Força uma ordem de tabulação antes de tudo — quase sempre errado | Praticamente nunca; quebra a ordem para o resto da página |
4.4 Gestão de foco em SPA e componentes
- Navegação de rota (SPA): ao mudar de "página", o foco fica onde estava (num link do menu antigo) e o leitor de tela não anuncia nada. Padrão: mover o foco para o
<h1>da nova view (comtabindex="-1") ou para uma região, e atualizar o<title>. Bibliotecas de router modernas têm helpers, mas você precisa ligar. - Modal / dialog: ao abrir, mover o foco para dentro (o modal ou seu primeiro campo); focus trap (Tab cicla dentro do modal); Esc fecha; ao fechar, devolver o foco ao elemento que o abriu; o resto da página com
inert/aria-hidden. Use<dialog>nativo quando possível. - Widgets compostos (menu, tabs, grid, listbox): um tab stop para o widget inteiro, e as setas movem entre os itens internos (roving tabindex ou
aria-activedescendant). Não faça cada item ser um tab stop. - Após uma ação: deletou um item de uma lista? Mova o foco para o próximo item (ou um resumo), não deixe o foco "cair" no
<body>.
outline: none é o pecado nº 1Resets de CSS e designers que "acham o anel feio" removem o foco visível — e a página fica inutilizável por teclado (você não sabe onde está). Se vai remover o outline padrão, substitua por um estilo de :focus-visible claramente visível, com contraste suficiente, em todos os elementos interativos. Nunca "some" com o foco.
Perguntas: "Como você testa acessibilidade rapidamente?" (teste de teclado), "Diferença entre tabindex 0, -1 e positivo", "O que fazer com o foco ao abrir e fechar um modal?" (mover para dentro, trap, Esc, devolver ao gatilho), "O que acontece com o foco numa SPA ao trocar de rota e como resolver?" (fica perdido; mover para o h1 e atualizar o title), "Por que outline: none é problema?".
✏️ Exercício 4 — Especifique o comportamento do modal
Descreva o comportamento de foco e teclado completo de um modal de confirmação ("Tem certeza que deseja excluir?" com botões Cancelar e Excluir), acionado por um botão "Excluir" numa linha de tabela.
Gabarito: (1) Ao abrir: mover o foco para dentro do modal — para o botão "Cancelar" (opção mais segura como default) ou para o título do modal. (2) O resto da página fica inert (não focável, não lido). (3) Focus trap: Tab e Shift+Tab ciclam apenas entre os elementos do modal (título/close, Cancelar, Excluir). (4) Esc fecha o modal (equivale a Cancelar). (5) O modal tem role="dialog" (ou <dialog>), aria-modal="true", e um nome acessível (aria-labelledby apontando para o título). (6) Ao fechar (por qualquer via): devolver o foco ao botão "Excluir" da linha que o abriu — se essa linha foi removida, mover para um ponto lógico (a linha seguinte, ou o cabeçalho da tabela) e, idealmente, anunciar "item excluído" numa live region.
ARIA: as regras e os padrões
Objetivo: usar ARIA para o que HTML nativo não cobre — sem estragar. As cinco regras, roles/states/properties, live regions, e os padrões do ARIA Authoring Practices.
5.1 O que ARIA é (e não é)
WAI-ARIA é um conjunto de atributos (role, aria-*) que modificam a accessibility tree — mudam o que a tecnologia assistiva "vê". ARIA não muda comportamento: role="button" num <div> faz o leitor de tela dizer "botão", mas não o torna focável nem faz Enter funcionar — você ainda tem que adicionar tabindex="0" e handlers de teclado. ARIA é uma promessa que você tem que cumprir com JS e CSS.
5.2 As cinco regras do ARIA
- Não use ARIA se um elemento HTML nativo serve.
<button>><div role="button" tabindex="0">. - Não mude a semântica nativa sem necessidade.
<h2 role="tab">some com o heading para a tecnologia assistiva. - Todo controle ARIA interativo tem que ser operável por teclado.
- Não use
role="presentation"nemaria-hidden="true"num elemento focável — você o esconde do leitor de tela mas ele ainda recebe Tab (foco "fantasma"). - Todo elemento interativo precisa de um nome acessível.
Dados do WebAIM (análise anual do "Million") mostram que páginas com mais ARIA têm, em média, mais erros detectáveis — porque ARIA mal aplicado (role errado, estado que não atualiza, aria-label sobrescrevendo texto útil, referência a um id que não existe) cria barreiras novas, muitas vezes piores que a ausência. Aprenda os padrões corretos, teste com leitor de tela, e na dúvida, não use.
5.3 As categorias de ARIA
- Roles: o que o elemento é.
tab,tablist,tabpanel,dialog,alert,menu,listbox,combobox,tooltip,status,progressbar… e os landmarks. - States (mudam com a interação):
aria-expanded,aria-checked,aria-selected,aria-disabled,aria-pressed,aria-invalid,aria-current,aria-hidden. Você tem que atualizá-los no JS quando o estado muda. - Properties (mais estáticas):
aria-label,aria-labelledby,aria-describedby,aria-controls,aria-haspopup,aria-required,aria-live.
5.4 Live regions
Para anunciar mudanças dinâmicas que não recebem foco (um toast "Salvo com sucesso", "3 resultados encontrados", um erro que aparece):
<div aria-live="polite" aria-atomic="true"></div> // depois, via JS, insira o texto DENTRO da região já existente no DOM: regiao.textContent = "3 resultados encontrados"; // aria-live="polite": espera o leitor de tela terminar o que está lendo // aria-live="assertive" (ou role="alert"): interrompe — só para erros críticos // role="status" ≈ polite; role="alert" ≈ assertive
- A região precisa já existir no DOM quando a página carrega; você insere o texto nela, não cria a região com o texto junto.
- Use
politequase sempre.assertive/alertsó para o que exige interrupção imediata. - Não abuse — várias live regions gritando ao mesmo tempo é ruído.
5.5 Os padrões prontos: ARIA Authoring Practices Guide (APG)
O APG do W3C documenta a implementação correta (roles, estados, e interação de teclado esperada) dos widgets comuns: accordion, alert, breadcrumb, button, carousel, checkbox, combobox, dialog (modal), disclosure, feed, grid, listbox, menu/menubar, radio group, slider, spinbutton, switch, table, tabs, toolbar, tooltip, tree. Não invente o padrão de teclado de um combobox — siga o APG (ou use um componente headless que já o implementa — Módulo 8).
Perguntas: "ARIA muda comportamento?" (não — só a árvore de acessibilidade; você cumpre o resto com JS/CSS/teclado), "As regras do ARIA" (nativo primeiro; não quebre semântica; teclado; nada de aria-hidden em focável; nome acessível), "O que é uma live region e quando polite vs assertive?", "Onde você acha o padrão de teclado de um accordion/combobox?" (ARIA APG). "No ARIA is better than bad ARIA" é uma frase que sinaliza que você entende o assunto.
✏️ Exercício 5 — Especifique um accordion
Descreva o markup ARIA e a interação de teclado de um accordion (vários painéis, cada um com um cabeçalho-botão que expande/colapsa o conteúdo).
Gabarito (conforme o APG): Cada cabeçalho é um <button> dentro de um <h3> (ou heading apropriado). O botão tem aria-expanded="true|false" (atualizado no clique) e aria-controls apontando para o id do painel. O painel é uma <div> (ou region) com id, opcionalmente aria-labelledby apontando para o botão. Teclado: Enter/Espaço no botão alterna o painel; Tab move para o próximo elemento focável (o próximo cabeçalho ou conteúdo do painel aberto) — não se usa setas entre cabeçalhos de accordion (isso é para tabs/menu). Opcional (APG): Home/End para o primeiro/último cabeçalho. O ícone de seta é decorativo (aria-hidden) e gira por CSS baseado em [aria-expanded].
Conteúdo, cor, mídia e formulários
Objetivo: as decisões de conteúdo — texto alternativo, cor e contraste, tipografia e zoom, legendas, movimento, linguagem clara — e como fazer um formulário acessível.
6.1 Texto alternativo: uma decisão, não um reflexo
| A imagem… | alt |
|---|---|
| transmite informação (gráfico, foto de produto, diagrama) | Descreva a informação que ela transmite, no contexto (alt="Vendas cresceram 30% de jan a jun", não alt="gráfico") |
| é um link ou botão (ícone) | Descreva o destino/ação (alt="Página inicial", não alt="logo") |
| é decorativa (ornamento, fundo, ícone ao lado de texto que já diz o mesmo) | alt="" (vazio, mas presente) — o leitor de tela a ignora. Nunca omita o atributo (aí ele lê o nome do arquivo) |
| é complexa (infográfico, mapa) | alt curto + descrição longa adjacente (texto, tabela) referenciada |
| contém texto | Reproduza o texto no alt (ou, melhor, use texto real com CSS) |
6.2 Cor
- Contraste (1.4.3 AA): texto ≥ 4,5:1; texto grande ≥ 3:1; componentes de UI e limites de foco ≥ 3:1 (1.4.11). Verifique com um checker (WebAIM Contrast Checker, o do DevTools, TPGi CCA).
- Não use só a cor (1.4.1): um erro em vermelho precisa também de texto/ícone; um item "selecionado" precisa de mais que uma cor; um gráfico precisa de rótulos/padrões além da cor de série (ver apostila de dataviz).
- Modo escuro: re-verificar o contraste — inverter cores não garante conformidade.
6.3 Tipografia, zoom e reflow
- Redimensionar texto até 200% (1.4.4) sem perder conteúdo — use unidades relativas (
rem), não trave o layout em pixels. - Reflow (1.4.10): a 320px de largura (≈ zoom 400% num monitor comum), o conteúdo deve fluir numa coluna, sem scroll horizontal — nada de conteúdo cortado ou sobreposto.
- Espaçamento de texto (1.4.12): o usuário pode aumentar entrelinha, espaço entre palavras/letras/parágrafos via extensão — não quebre.
- Boas práticas cognitivas: linha de ~65–75 caracteres, contraste confortável (não máximo — preto puro em branco puro cansa alguns), evitar texto justificado, respeitar a preferência de fonte do usuário.
6.4 Mídia e movimento
- Vídeo: legendas sincronizadas (1.2.2, AA) — para surdos e para quem assiste sem som; transcrição; audiodescrição (1.2.5, AA) quando há informação visual essencial não dita.
- Áudio: transcrição.
- Sem autoplay de áudio; se algo toca > 3s, dar controle de pausa/parar (1.4.2).
- Movimento e animação: respeitar
@media (prefers-reduced-motion: reduce)— desligar parallax, auto-carrossel, transições grandes; nada que pisque > 3×/s (2.3.1 — risco de convulsão); permitir pausar conteúdo em movimento (2.2.2).
6.5 Formulários acessíveis
<label for="email">E-mail</label> <input id="email" type="email" name="email" autocomplete="email" aria-describedby="email-hint email-err" aria-invalid="true" aria-required="true"> <p id="email-hint">Usaremos para enviar a confirmação.</p> <p id="email-err" role="alert">Formato de e-mail inválido.</p>
- Todo campo tem um
<label>visível e associado (porfor/id). Placeholder não é label (some ao digitar, contraste ruim, não é lido de forma confiável). - Instruções e dicas associadas com
aria-describedby. - Erros: identificados em texto (3.3.1), com sugestão de correção (3.3.3), associados ao campo (
aria-describedby+aria-invalid), e um resumo no topo com links para os campos; mover o foco para o primeiro erro (ou para o resumo). autocompletecom os tokens padrão (1.3.5) — ajuda quem tem dificuldade de digitação e memória.- Agrupar campos relacionados com
<fieldset>/<legend>(endereço, opções de rádio). - Não obrigar a redigitar informação já dada no mesmo fluxo (3.3.7, WCAG 2.2); autenticação sem depender de memorizar/transcrever (3.3.8).
Perguntas: "Quando alt="" e quando descrever?", "Qual o contraste mínimo para texto normal em AA?" (4,5:1), "Por que placeholder não substitui label?", "Como você faz mensagens de erro de formulário acessíveis?" (texto + sugestão + aria-describedby/aria-invalid + resumo + foco), "O que é prefers-reduced-motion?", "O que é reflow a 320px?".
✏️ Exercício 6 — Audite o formulário
Um formulário de cadastro tem: campos só com placeholder ("Nome", "E-mail"); um asterisco vermelho para obrigatório; erros que aparecem em vermelho abaixo do campo sem associação; e um botão "Enviar" que, se houver erro, não faz nada visível. Liste os problemas e as correções.
Gabarito: (1) Placeholder como label → adicionar <label> visível e associado por for/id; o placeholder, se ficar, só como exemplo de formato. (2) Obrigatório só por cor/asterisco → adicionar aria-required="true" (ou required) e a palavra "(obrigatório)" no label, ou explicar "campos marcados com * são obrigatórios" no topo. (3) Erros não associados → aria-describedby ligando o campo à mensagem, aria-invalid="true", e a mensagem com texto claro + sugestão. (4) Envio sem feedback → ao falhar a validação, exibir um resumo de erros no topo (com links para cada campo), mover o foco para ele (ou role="alert"), e não deixar o usuário adivinhar. Bônus: autocomplete nos campos, <fieldset> onde fizer sentido.
Testar acessibilidade
Objetivo: o que a automação pega, o que exige teste manual (teclado, leitor de tela, zoom), como fazer teste com usuários com deficiência, e como integrar tudo no fluxo de trabalho.
7.1 O que a automação pega — e o que não
Ferramentas automáticas (axe-core — base do axe DevTools, do Lighthouse e de integrações; pa11y, WAVE, ARC, Accessibility Insights) detectam de forma confiável ~30–50% das barreiras: alt ausente, contraste insuficiente, labels de formulário faltando, ARIA inválido, ordem de headings quebrada, lang ausente, id duplicado.
A automação não verifica: se o alt é bom (só se existe), se a ordem de foco é lógica, se um componente custom funciona com leitor de tela, se o conteúdo faz sentido, se as legendas estão corretas, se o movimento respeita a preferência, se o fluxo é utilizável. Passar no scanner é o piso, não o teto. A maior parte da acessibilidade real só se verifica manualmente.
7.2 Teste manual
| Verificação | Como |
|---|---|
| Teclado | Guarde o mouse; Tab/Shift+Tab/Enter/setas/Esc por toda a página. Tudo operável, foco sempre visível, ordem lógica, sem armadilha (Módulo 4) |
| Leitor de tela | Ao menos um: NVDA (Windows, grátis) + Firefox/Chrome; VoiceOver (macOS/iOS, embutido); TalkBack (Android); JAWS (padrão corporativo, pago). Testar: navegar por headings/landmarks, ler formulários e erros, operar componentes custom, ouvir os anúncios de live region |
| Zoom / reflow | Zoom do navegador a 200% e a 400% (ou viewport 320px); zoom do SO; espaçamento de texto aumentado |
| Cor | Contrast checker nos pares de cor; simular daltonismo; testar se a informação sobrevive sem cor |
| Sem CSS / conteúdo linear | Desligar o CSS: a ordem de leitura e a estrutura ainda fazem sentido? |
| Reduced motion | Ligar a preferência no SO e verificar que animações param |
7.3 Teste com usuários com deficiência
A verificação definitiva. Nenhuma checklist substitui observar uma pessoa que usa leitor de tela / navegação por switch / ampliação todos os dias tentar completar uma tarefa real no seu produto. Faça (com compensação justa) em pesquisa de usabilidade regular, não só numa "auditoria de a11y" isolada.
7.4 Integrar no fluxo (shift-left)
- Design: anotações de acessibilidade no Figma (ordem de foco, nomes, contraste, comportamento de estados), componentes do design system já acessíveis.
- Desenvolvimento:
eslint-plugin-jsx-a11yna IDE; axe rodando em dev (extensão, ou@axe-core/react). - CI:
@axe-core/playwright(ou jest-axe / cypress-axe / pa11y-ci) em cada página/estado — gate em violações críticas/sérias. Regressão visual + verificação de foco. - QA: checklist de teclado + leitor de tela nos fluxos críticos de cada release; a11y no "definition of done".
- Auditoria periódica (interna ou por especialista externo) contra WCAG 2.2 AA, com relatório priorizado.
Perguntas: "Quanto da acessibilidade dá para automatizar e por quê?" (~30–50%; automação vê presença, não qualidade nem usabilidade), "Como você testaria um dropdown custom?" (teclado + NVDA/VoiceOver + verificar nome/role/state), "Que ferramentas você usa?" (axe, Lighthouse, NVDA/VoiceOver, contrast checker, eslint-plugin-jsx-a11y, axe-playwright no CI), "Como integrar a11y no CI?".
✏️ Exercício 7 — Plano de teste de uma página de produto
Você recebe uma página de produto nova para validar acessibilidade antes do lançamento. Liste os passos, do automático ao manual.
Gabarito: (1) Automático: axe (DevTools + no CI) em todos os estados da página (galeria, variações selecionadas, erro de "adicionar ao carrinho"); Lighthouse; eslint-plugin-jsx-a11y no código. (2) Teclado: percorrer tudo — selecionar variação, abrir a galeria/zoom, adicionar ao carrinho, abrir avaliações — só com teclado; foco visível e ordem lógica; galeria/modal com trap e Esc. (3) Leitor de tela (NVDA+Firefox e VoiceOver+Safari): navegar por headings/landmarks; a imagem principal tem alt informativo; o seletor de variação anuncia nome/opção/estado; o preço e a disponibilidade são lidos; ao adicionar ao carrinho, uma live region anuncia o resultado. (4) Zoom 400% / 320px: reflow sem scroll horizontal, nada cortado. (5) Cor: contraste do preço, dos selos ("Em promoção" não só por cor), do foco. (6) Reduced motion: a animação da galeria para. (7) Registrar as violações priorizadas (crítico/sério/moderado) e bloquear o lançamento nos críticos.
A11y em stacks modernas
Objetivo: os pontos de atenção específicos de SPAs e design systems, componentes headless acessíveis, mobile, documentos, e visualização de dados.
8.1 SPAs
- Título da página (
document.title) atualizado a cada rota — é o primeiro anúncio de "onde estou". - Gestão de foco na navegação (Módulo 4): mover para o
h1da nova view. - Anúncio de mudança de rota numa live region ("Página Carrinho carregada").
- Loading states: um spinner precisa de
role="status"/aria-livee um texto ("Carregando resultados"); skeleton screens devem seraria-hiddencom um anúncio à parte. - Conteúdo que aparece (infinite scroll, "carregar mais", filtros que atualizam a lista): anunciar quantos itens, e não roubar o foco do usuário.
- SSR/hidratação: garantir que o HTML inicial já é semântico e navegável.
8.2 Design systems e componentes headless
A alavanca mais eficiente: se os componentes do design system são acessíveis, cada produto que os usa herda isso. Componentes headless (comportamento + acessibilidade, sem estilo) resolvem os widgets difíceis conforme o ARIA APG:
- React: React Aria / React Spectrum (Adobe) — o mais completo; Radix UI; Headless UI (Tailwind); Ark UI; Reach UI (legado).
- Vue: Headless UI, Radix Vue, Ark UI.
- Bibliotecas com estilo mas boa base a11y: MUI, Mantine, Chakra (verificar sempre — "acessível" varia).
- Ainda assim, teste: um componente headless correto ainda pode ser mal usado (label ausente, estilo que quebra o foco visível, conteúdo mal estruturado dentro).
8.3 Mobile
- APIs nativas: iOS (UIAccessibility,
accessibilityLabel/Traits) + VoiceOver; Android (contentDescription, accessibility services) + TalkBack. - Alvos de toque ≥ 44×44pt (iOS) / 48×48dp (Android); ordem de foco; suportar tamanho de fonte dinâmico do sistema; não depender de gestos complexos sem alternativa.
- React Native / Flutter têm props/widgets de acessibilidade — usá-los explicitamente (o mapeamento automático é parcial).
8.4 Documentos e outros formatos
- PDF: precisa ser "tagged" (estrutura, ordem de leitura, alt, tabelas, idioma) — PDF/UA; a maioria dos PDFs exportados sem cuidado é inacessível. Prefira HTML quando possível.
- E-mail: HTML semântico, alt nas imagens, contraste, não depender de imagem para a mensagem,
lang, ordem de leitura em tabelas de layout. - E-books (EPUB): o EAA cobre e-books e leitores — EPUB acessível (EPUB Accessibility 1.1).
- Data viz: alternativa textual que dá a conclusão + os dados numa tabela associada; não só cor para séries (padrões/rótulos diretos); interações do gráfico operáveis por teclado; ver apostila de dataviz.
8.5 Dark mode
Não assuma conformidade por inversão. Reverificar todos os contrastes (texto, UI, foco) no tema escuro; evitar branco puro sobre preto puro (halação/"blooming" incomoda astigmatismo e alguns usuários de baixa visão); respeitar prefers-color-scheme e permitir override.
Perguntas: "Quais os problemas de acessibilidade típicos de uma SPA e como resolver?" (título, foco na rota, anúncio, loading states), "Como um design system melhora a acessibilidade da organização inteira?", "Por que usar um componente headless para um combobox?" (implementa o ARIA APG e o teclado corretamente), "PDF é acessível por padrão?" (não — precisa ser tagged).
✏️ Exercício 8 — SPA com filtros
Uma página de listagem em React tem filtros (checkboxes) que, ao mudar, atualizam a lista de resultados via fetch, sem recarregar. Descreva o que precisa acontecer para ser acessível.
Gabarito: (1) Cada checkbox é um <input type="checkbox"> real com <label>; agrupados em <fieldset><legend>Filtros</legend>. (2) Ao mudar um filtro: enquanto carrega, um role="status" anuncia "Atualizando resultados"; ao terminar, a mesma (ou outra) live region polite anuncia "42 resultados encontrados". (3) O foco não é roubado — permanece no checkbox que o usuário acabou de mudar. (4) A região de resultados não deve "sumir e voltar" de forma que quebre a navegação; se a contagem/estado importa, refletir num heading ou texto visível também. (5) Se há "carregar mais", o botão anuncia o novo total e o foco vai para o primeiro item novo (ou fica no botão, com anúncio). (6) URL reflete os filtros (para compartilhar/voltar) — bom para todos.
Legal, organizacional e o European Accessibility Act
Objetivo: o panorama regulatório — Web Accessibility Directive, o EAA, EN 301 549, ADA/Section 508 — e como uma organização vai de "reativa" a "born accessible".
9.1 União Europeia
| Instrumento | Escopo | Exigência |
|---|---|---|
| Web Accessibility Directive (2016/2102) | Sites e apps do setor público da UE | Conformidade com a EN 301 549 (que incorpora WCAG, hoje ~2.1 AA), + accessibility statement + mecanismo de feedback + monitorização pelos Estados |
| European Accessibility Act — EAA (Diretiva 2019/882) | Produtos e serviços privados específicos: e-commerce, serviços bancários ao consumidor, e-books e software de leitura, transporte de passageiros (sites/apps/bilhética), comunicações eletrónicas, computadores e SOs, terminais de autoatendimento (ATMs, quiosques), TV e serviços audiovisuais, chamadas de emergência (112) | Requisitos de acessibilidade harmonizados; na prática, para o digital, alinhados a WCAG (via EN 301 549). Aplicação a partir de 28 de junho de 2025 (com períodos transitórios para alguns terminais/serviços) |
- Isenções: microempresas prestadoras de serviços (< 10 pessoas e < €2M) têm alívio; "ónus desproporcionado" pode ser invocado com justificação documentada e reavaliação periódica — não é uma saída fácil.
- Enforcement: por autoridades nacionais, com sanções definidas por cada Estado-membro; consumidores e associações podem acionar.
- Alcance prático: qualquer empresa que venda produtos/serviços cobertos a consumidores na UE — inclusive de fora — precisa cumprir.
9.2 Estados Unidos
- ADA (Americans with Disabilities Act): tribunais têm aplicado a sites de "lugares de acomodação pública"; milhares de processos por ano, WCAG 2.1 AA como padrão de fato nos acordos. Em 2024, o DOJ publicou regra tornando WCAG 2.1 AA explícito para sites e apps de governos estaduais/locais (Title II).
- Section 508: exige acessibilidade (via EN 301 549 / WCAG 2.0 AA, atualizando) para tecnologia adquirida pelo governo federal — daí a importância do VPAT/ACR em procurement.
9.3 A norma e a base comum
A EN 301 549 é a norma técnica europeia de acessibilidade de TIC; ela referencia o WCAG para conteúdo web e adiciona requisitos para hardware, software não web, documentos e suporte. É o denominador comum entre a Web Accessibility Directive, o EAA e o 508. Na prática, "cumprir WCAG 2.2 AA" atende à maior parte das obrigações digitais — mas verifique a versão exata que a lei aplicável cita e os requisitos não-WCAG da EN 301 549.
9.4 Overlays — por que a comunidade rejeita
Widgets de terceiros ("clique aqui para ativar o modo acessível") que prometem conformidade automática via JavaScript. Problemas: não corrigem os defeitos de fundo do código (só maquiam), frequentemente interferem com leitores de tela e configurações do próprio usuário, coletam dados, e dão falsa sensação de segurança jurídica (empresas que usam overlays continuam sendo processadas, agora com o overlay como agravante). Centenas de especialistas assinaram o "Overlay Fact Sheet" contra eles. A solução é corrigir o produto.
9.5 Maturidade organizacional
| Estágio | Como é |
|---|---|
| Reativo | Age só após reclamação/processo; correções pontuais; sem processo |
| Consciente | Tem uma política e um alvo (2.2 AA), faz auditorias esporádicas, treina alguns times |
| Sistemático | A11y no design system, no CI, no "definition of done", no QA; accessibility statement mantida; auditoria regular; a11y em procurement (só compra ferramentas acessíveis) |
| "Born accessible" | Acessibilidade é requisito default; rede de "champions" nos times; testes com usuários com deficiência na pesquisa regular; métricas de programa; parte da cultura |
- Papéis: um dono do programa de acessibilidade; champions por time; especialistas para auditoria e consultoria; envolvimento de jurídico e procurement.
- Procurement: exigir VPAT/ACR e testar antes de comprar — herdar a inacessibilidade de um fornecedor é comum e caro.
9.6 IA e acessibilidade
- Ajuda: geração de rascunho de
alttext, legendas e transcrições automáticas, descrição de imagens, simplificação de linguagem, testes assistidos. - Riscos: alt/legendas geradas erradas ou genéricas publicadas sem revisão (pior que ausência, porque enganam); "acessibilidade por IA em runtime" (parente do overlay) que não corrige o código; e novas interfaces de IA (voz, chat) que precisam ser elas mesmas acessíveis. A IA é assistente de produção, com revisão humana — não substituto do trabalho estrutural.
Com o EAA, perguntas legais entraram nas entrevistas: "O que é o European Accessibility Act e a quem se aplica?" (produtos/serviços privados — e-commerce, banca, e-books, transporte…; desde jun/2025; alcança quem vende a consumidores na UE), "Qual o padrão técnico?" (EN 301 549, que incorpora WCAG — mire 2.2 AA), "Por que não usar um overlay?" (não corrige o fundo, atrapalha AT, não protege juridicamente), "O que é um VPAT?".
✏️ Exercício 9 — Roadmap de conformidade EAA
Uma empresa de e-commerce que vende para toda a UE precisa estar em conformidade com o EAA. Não tem programa de acessibilidade. Esboce um roadmap.
Gabarito (esboço): (1) Escopo e gap: auditoria WCAG 2.2 AA (+ requisitos EN 301 549) das jornadas críticas — home, busca, produto, carrinho, checkout, conta, ajuda; por especialista externo; relatório priorizado (crítico/sério/moderado). (2) Correção priorizada: primeiro os bloqueadores de tarefa (checkout inoperável por teclado, formulários sem label, contraste, foco) — meta de "todas as jornadas críticas completáveis por teclado + leitor de tela". (3) Prevenção: acessibilizar o design system, ligar axe no CI, a11y no "definition of done", treinar dev/design/QA/conteúdo, exigir VPAT dos fornecedores (gateway de pagamento, chat, reviews). (4) Governança: nomear um dono do programa, champions, e publicar uma accessibility statement com estado, problemas conhecidos e canal de feedback. (5) Contínuo: auditoria periódica, teste com usuários com deficiência, e monitorização de regressões. Documentar tudo — é a evidência de conformidade e de "esforço" se houver questionamento.
Mercado de trabalho: roadmap, entrevistas e portfólio
Objetivo: converter o conteúdo dos módulos anteriores em aprovação — perfis, certificações, roadmap, banco de perguntas com respostas e projetos que geram entrevista.
10.1 Os perfis que contratam
| Perfil | Foco |
|---|---|
| Accessibility Engineer / a11y Specialist | Implementar e revisar a11y no código; consultoria interna; design system |
| Accessibility Auditor / Tester | Auditar contra WCAG/EN 301 549; relatórios; teste com tecnologia assistiva |
| Inclusive / Accessible Design | UX/UI com acessibilidade desde o design; anotações; pesquisa com usuários com deficiência |
| Accessibility Program Manager | Estratégia, maturidade, procurement, treinamento, compliance (EAA/ADA) |
| Todo front-end / QA / conteúdo | a11y é competência esperada, não nicho — cai em entrevista de front |
10.2 Certificações e leituras
- IAAP (International Association of Accessibility Professionals): CPACC (Certified Professional in Accessibility Core Competencies — conceitos, deficiências, leis, design) e WAS (Web Accessibility Specialist — técnico, WCAG, ARIA, teste). A combinação (CPWA) é a credencial da área.
- Leitura / referência: as próprias WCAG 2.2 + "Understanding" + "Techniques"; o ARIA Authoring Practices Guide; a MDN Accessibility; o WebAIM (artigos, o "Million" report, contrast checker); "Inclusive Components" (Heydon Pickering); "Form Design Patterns" (Adam Silver); o "A11y Project" (checklist).
- Acompanhar: WebAIM, TPGi, Deque, Smashing Magazine (a11y), a comunidade no Mastodon/blogs.
10.3 Roadmap de estudo (7–9 semanas)
| Semanas | Foco | Prática |
|---|---|---|
| 1 | Por que a11y, quem é afetado, panorama (Módulo 1); instalar NVDA/usar VoiceOver | Navegar 3 sites conhecidos só com teclado; depois com leitor de tela |
| 2 | WCAG: POUR, níveis, 2.2, critérios de AA (Módulo 2) | Mapear 10 critérios de AA a exemplos reais numa página |
| 3 | HTML semântico, accessibility tree, nome/role/valor (Módulo 3) | Refatorar uma página de "divs" para HTML semântico; inspecionar a árvore no DevTools |
| 4 | Teclado e foco: SPA, modal, widgets, roving tabindex (Módulo 4) | Construir um modal e um accordion acessíveis do zero (APG) |
| 5 | ARIA: as regras, states, live regions, os padrões do APG (Módulo 5) | Construir tabs e um combobox seguindo o APG; testar com leitor de tela |
| 6 | Conteúdo, cor, mídia, formulários (Módulo 6) | Auditar e corrigir um formulário real (labels, erros, autocomplete) |
| 7 | Testar: axe, Lighthouse, NVDA/VoiceOver, zoom, CI (Módulo 7) | Auditar uma página inteira (automático + manual) e escrever o relatório priorizado |
| 8 | Stacks modernas + legal/EAA (Módulos 8–9); preparo para CPACC/WAS | Ligar axe-playwright no CI de um projeto; escrever uma accessibility statement |
| 9 | Consolidação e portfólio | Publicar as auditorias e os componentes acessíveis |
10.4 Banco de perguntas de entrevista (com a resposta que aprova)
Júnior/pleno — "O que significa POUR?"
Os quatro princípios do WCAG: Perceptível (a informação pode ser percebida — alt, legendas, contraste), Operável (a interface pode ser usada por qualquer entrada — teclado, tempo suficiente, sem flashes), Compreensível (claro e previsível — idioma, ajuda em erros, consistência) e Robusto (funciona com tecnologia assistiva — HTML válido, nome/role/valor). O alvo prático de conformidade é o nível AA.
Pleno — "Por que não usar <div onclick> como botão?"
Um <div> não é focável por teclado, não responde a Enter/Espaço, não é anunciado como "botão" pelo leitor de tela, e não comunica estado — falha "nome, papel, valor" (WCAG 4.1.2) e a operabilidade por teclado (2.1.1). Recriar tudo isso com tabindex, role, handlers e ARIA é frágil e incompleto. Use <button>, que já vem com tudo.
Pleno — "ARIA muda o comportamento de um elemento?"
Não. ARIA só altera a accessibility tree — o que a tecnologia assistiva percebe. role="button" num div faz o leitor dizer "botão", mas não o torna focável nem faz o teclado funcionar; isso você implementa com JS/CSS. Daí as regras: usar HTML nativo primeiro, garantir operação por teclado, atualizar os estados no código, e "no ARIA is better than bad ARIA".
Pleno/sénior — "Quanto da acessibilidade dá para automatizar?"
Cerca de 30–50% das barreiras (alt ausente, contraste, labels faltando, ARIA inválido, headings, lang). A automação vê presença, não qualidade: não sabe se o alt é bom, se a ordem de foco é lógica, se um componente funciona com leitor de tela, se o conteúdo faz sentido. "0 erros no axe" é o piso. O resto exige teste manual (teclado, leitor de tela, zoom) e, idealmente, teste com usuários com deficiência.
Sénior — "Como você gerencia o foco numa SPA?"
Ao trocar de rota: atualizar document.title; mover o foco para o <h1> da nova view (com tabindex="-1") ou para uma região; opcionalmente anunciar "Página X carregada" numa live region. Em modais: mover o foco para dentro, focus trap, Esc fecha, devolver o foco ao gatilho ao fechar, resto da página inert. Após ações destrutivas: mover o foco para um ponto lógico, não deixar cair no body.
Sénior — "O que é o European Accessibility Act e por que importa mesmo fora da UE?"
Diretiva 2019/882, em aplicação desde 28/06/2025, que estende requisitos de acessibilidade a produtos e serviços privados de setores como e-commerce, banca ao consumidor, e-books, transporte de passageiros e comunicações. O padrão técnico é a EN 301 549, que incorpora o WCAG (mire 2.2 AA). Importa fora da UE porque alcança qualquer empresa que venda os serviços cobertos a consumidores na UE — como o GDPR, tem efeito prático global.
Armadilha — "Instalamos um plugin de acessibilidade, então estamos cobertos"
Overlays não corrigem os defeitos de fundo do código — só aplicam ajustes por cima, frequentemente atrapalhando leitores de tela e as configurações do próprio usuário. Empresas que usam overlays continuam sendo processadas, agora com o overlay como agravante. Centenas de especialistas assinaram um manifesto contra. A única solução real é consertar o produto: HTML semântico, teclado, contraste, componentes acessíveis, testados.
10.5 Projetos de portfólio que geram entrevista
- Auditoria completa (âncora): escolher um site real, auditá-lo contra WCAG 2.2 AA (automático + teclado + leitor de tela + zoom), e produzir um relatório profissional: cada achado com o critério violado, o impacto no usuário, a severidade, evidência (screenshot/gravação) e a recomendação de correção.
- Biblioteca de componentes acessíveis: construir do zero (seguindo o ARIA APG) um modal, um accordion, tabs, um combobox e um menu — com testes de teclado e de leitor de tela documentados.
- "Antes/depois": pegar uma página inacessível (de "divs", sem foco, sem labels) e refatorá-la, documentando cada mudança e o critério que ela resolve.
- a11y no CI: um projeto com
@axe-core/playwright+eslint-plugin-jsx-a11yintegrados, com gate configurado e um exemplo de regressão sendo pega. - Accessibility statement + VPAT de exemplo, bem escritos, para um produto fictício.
Quatro ideias sustentam acessibilidade: (1) é design para a variação humana real — permanente, temporária, situacional — e o benefício vaza para todos; (2) o HTML certo faz metade do trabalho — semântica primeiro, ARIA só para o que falta e sem estragar; (3) teclado e "nome, papel, valor" são o coração do que se testa, e a automação só vê ~metade; (4) com o EAA e a maré de litígio, acessibilidade passou de "bom ter" a requisito legal — e a solução é sempre consertar o produto, nunca um overlay. Feito desde o início, custa pouco; feito depois, custa caro.