Tema: accessibility
-
Acessibilidade de cor em sinais de jogo: comunicar o estado com mais do que o matiz
Combine a cor com símbolos, padrões e rótulos estáveis e teste o sinal completo na escala real do jogo, em vez de confiar apenas em uma paleta predefinida.
-
Interfaces sensíveis à localidade: regras de plural do Intl, datas e layout da direita para a esquerda
Formate números, datas e tempos relativos com os objetos Intl do navegador em vez de manipular strings, escolha as formas de plural pelas categorias de Intl.PluralRules e não por n == 1, monte o layout com propriedades lógicas de CSS para que um documento com dir=rtl se espelhe sozinho e reserve espaço para textos que crescem na tradução.
-
Texto corrido legível: comprimento da linha, espaçamento entre linhas e contraste
Três propriedades determinam se um texto longo é confortável de ler: o comprimento da linha (o critério AAA das WCAG limita-o a 80 caracteres), o espaçamento entre linhas (deve ser possível chegar a pelo menos 1,5 vez o tamanho da fonte sem quebrar o layout) e o contraste (4,5:1 para texto normal, 3:1 para texto grande). Defina-os em unidades relativas, para que os usuários possam ampliar o texto e alterar seus espaçamentos.
-
Ícones SVG: marcação inline, sprite com use ou elemento img
O SVG inline pode ser estilizado com currentColor e CSS, mas repete bytes a cada ocorrência; um sprite de mesma origem referenciado com use é guardado em cache uma só vez e continua seguindo a cor do texto; um img é cacheável, mas opaco para o CSS. Escolha conforme o papel de cada ícone, mantenha os decorativos ocultos para tecnologias assistivas e defina o tamanho de todos para que nada se desloque enquanto o sprite carrega.
-
Texto corrido legível: medida, altura de linha e contraste
Três propriedades decidem se um texto longo pode ser lido com conforto: o comprimento da linha (o critério AAA da WCAG limita a 80 caracteres), o espaçamento entre linhas (deve ser possível chegar a pelo menos 1,5 vez o tamanho da fonte sem quebrar o layout) e o contraste (4,5:1 para texto normal, 3:1 para texto grande). Defina-as em unidades relativas, para que o usuário possa redimensionar e reespaçar o texto.
-
Modo escuro com prefers-color-scheme, color-scheme e light-dark()
O modo escuro tem três partes: a media query prefers-color-scheme detecta a escolha do usuário; a propriedade color-scheme (e a meta tag) informa ao navegador quais esquemas a página suporta, para que controles de formulário, barras de rolagem e o canvas os acompanhem; e light-dark() ou custom properties trocam os valores da paleta sem duplicar regras.
-
Seletores estáveis e espera automática em testes end-to-end de navegador
Duas causas dominam os testes de navegador instáveis: seletores que quebram ou apontam para o elemento errado, e pausas fixas que pressupõem um tempo de resposta. Localize os elementos por papel (role), rótulo ou test id, garanta que cada localizador corresponda a um único elemento e sincronize com asserções que repetem a verificação e com checagens de acionabilidade, não com o tempo.
-
Formulários acessíveis: rótulos, mensagens de erro e autocomplete
Associe cada controle a um rótulo por meio de for e id, indique os campos obrigatórios no texto e com o atributo, use tokens autocomplete para que navegadores e tecnologias assistivas conheçam a finalidade do campo e informe os erros num resumo e em mensagens por campo ligadas com aria-describedby.
-
dialog versus popover: comportamento modal, top layer e light dismiss
dialog com showModal() é modal: top layer, página inerte, ::backdrop, Escape, closedby e form method=dialog; o atributo popover transforma qualquer elemento numa sobreposição não modal na top layer, alternada por um botão sem script e fechada por light dismiss no estado auto. Use dialog para avisos bloqueantes e formulários, popover para menus, tooltips e toasts.
-
Legendas em jogos e cues de legenda descritiva: preservar sentido, sincronização e legibilidade
Represente diálogos e eventos sonoros relevantes com cues temporizados, trate sobreposições de forma deliberada e ofereça uma apresentação legível antes da primeira cena falada.
-
O que quem ativa o movimento reduzido espera que seja removido: toda animação, movimentos amplos ou apenas a reprodução automática?
Pergunta em aberto: a configuração de movimento reduzido pede reduzir, não eliminar, e as recomendações sugerem manter pequenas transições com significado e remover parallax, zoom e reprodução automática; existem evidências sobre o que os usuários que ativam a opção realmente querem e se as expectativas variam conforme o motivo (distúrbio vestibular, distração, bateria, preferência)?
-
Papéis ARIA: por que um elemento HTML nativo é melhor que uma div com role
A primeira regra de uso de ARIA do W3C é preferir um elemento ou atributo HTML nativo que já tenha a semântica e o comportamento necessários; ARIA só muda o que é informado às tecnologias assistivas, nunca o que o elemento faz. Uma div com role=button ainda precisa de foco, tratamento de teclado e estados implementados manualmente, e qualquer erro passa despercebido em testes visuais.
-
Navegação por teclado em widgets compostos: roving tabindex, setas e Escape
Tab e Shift+Tab movem o foco entre componentes; as setas movem-no dentro de um componente como lista de abas, barra de ferramentas, menu ou grupo de rádio. Implemente isso com roving tabindex (um item com tabindex=0 e os demais com -1) ou aria-activedescendant, feche superfícies transitórias com Escape e nunca prenda o foco sem oferecer uma saída documentada.
-
Gerenciamento de foco em interações de página única: diálogos, mudanças de rota e elementos removidos
Quando a página muda sem um carregamento completo, o foco do teclado precisa ser movido de propósito: para dentro do diálogo ao abri-lo e de volta ao seu acionador ao fechá-lo, para o título da nova visualização após uma mudança de rota no cliente e para um elemento vizinho adequado quando o elemento focado é excluído. Caso contrário, o foco cai no body do documento e os usuários de leitores de tela voltam ao topo da página.
-
prefers-reduced-motion: qual animação reduzir e como
A media feature prefers-reduced-motion indica se o usuário pediu ao sistema operacional menos movimento; seus valores são no-preference e reduce. Para respeitá-la, substitua movimentos amplos (parallax, zoom, deslizamentos, movimento com reprodução automática) por fades ou mudanças instantâneas, mantenha as pequenas transições de estado que carregam significado e aplique a mesma regra às animações feitas via script.
-
Action maps de entrada no Unity: contextos, control schemes e rebinding persistente
Organize actions semânticas por contexto de jogo, diferencie esquemas de dispositivo da ativação de mapas e dê ao rebinding um ciclo de vida completo.
-
Acessibilidade: os quatro princípios das WCAG aplicados na prática
As WCAG 2.2 organizam todos os critérios de sucesso em quatro princípios: perceptível, operável, compreensível e robusto. Conhecendo as violações mais comuns de cada princípio (falta de alternativas em texto, armadilhas de teclado, contraste insuficiente, campos sem rótulo, alvos pequenos demais), é possível encontrar muitas barreiras sem ferramentas especiais; o nível AA é o objetivo habitual.
-
Que parcela dos defeitos de acessibilidade encontrados em auditorias manuais ou por usuários já tinha passado nas verificações automáticas do CI, e que tipos escaparam?
Pergunta em aberto: a orientação do W3C WAI sobre ferramentas de avaliação afirma que algumas verificações de acessibilidade não podem ser automatizadas e exigem intervenção manual; em sites que executam um verificador automático a cada build, que parcela dos defeitos encontrados depois numa auditoria manual ou reportados por usuários tinha passado nesse verificador, e que tipos de defeito explicam a diferença?
-
Alvos de toque e tipos de ponteiro: dimensionar controles para dedos e mouse
O WCAG 2.2 exige alvos de ponteiro de pelo menos 24 por 24 pixels CSS no nível AA, com exceções para espaçamento, links em linha e controles equivalentes, e 44 por 44 no nível AAA. As media features pointer e hover indicam se a entrada principal é grosseira ou precisa e se consegue fazer hover, de modo que o design possa ampliar controles e abandonar interações só de hover quando o ponteiro é um dedo.
-
Fundamentos de acessibilidade: perceptível, operável, compreensível e robusto
As WCAG organizam seus requisitos em quatro princípios; as falhas mais comuns em sites de conteúdo são falta de alternativas em texto, sinalização apenas por cor, armadilhas de teclado, contraste baixo e controles sem rótulo.
Legível por máquina: JSON