Acessibilidade e design inclusivo – Padrões
Saiba mais sobre a justiça bem criada → Acessibilidade com Lightning e Experience Cloud
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Plataforma | Padrões de design | ✅ WCAG 2.2 Nível AA é a barra de acessibilidade mínima para trabalho personalizado (Experience Cloud, LWCs, temas personalizados), verificada pela equipe de criação |
| Plataforma | Padrões de design | ✅ Princípio perceptível: Existem alternativas de texto para imagens e ícones; as legendas acompanham vídeos |
| Plataforma | Padrões de design | ✅ Princípio operável: Toda a funcionalidade pode ser operada apenas por meio de teclado, sem precisar de mouse ou toque — as tecnologias auxiliares de controle de voz e acesso de alternância dependem do mesmo modelo de teclado/foco |
| Plataforma | LWC | ✅ Componentes da Web Lightning padrão são usados conforme projetado, proporcionando acessibilidade de linha de base automaticamente |
| Plataforma | LWC | ✅ Componentes personalizados implementam acessibilidade explícita validada por meio de testes com leitores de tela |
| Plataforma | Planos de teste | ✅ O teste de acessibilidade está incluído em todas as fases de teste (não ad hoc nem opcional) |
Anti-Padrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Plataforma | Padrões de design | ⚡️ WCAG 2.2 Nível AA é tratado como opcional ou “belo ter” em vez do requisito mínimo |
| Plataforma | Padrões de design | Imagens e ícones não têm alternativas de texto; vídeos não têm legendas |
| Plataforma | Padrões de design | A funcionalidade exige interação com o mouse ou o toque sem alternativa de teclado |
| Plataforma | LWC | Componentes personalizados são criados sem implementação ou validação de acessibilidade |
| Plataforma | LWC | Componentes de entrada personalizados usam elementos div e estilo CSS sem significado semântico ou acessibilidade ao teclado |
| Plataforma | Planos de teste | ⚡️ O teste de acessibilidade é ad hoc, opcional ou realizado apenas antes do lançamento (não durante todo o desenvolvimento) |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Plataforma | LWC | Elementos HTML semânticos (cabeçalho, navegação, principal, lado, rodapé, artigo, seção) são usados em Componentes da Web Lightning personalizados |
| Plataforma | LWC | ✅ Marcos, papéis e propriedades de ARIA são aplicados quando HTML semântico apenas não pode transmitir o comportamento da interface |
| Plataforma | LWC | ✅ Atualizações de conteúdo dinâmico usam regiões ativas aria anunciando alterações aos usuários do leitor de tela |
| Plataforma | LWC | ✅ Componentes interativos personalizados têm definições de papel explícitas que correspondem ao comportamento |
| Plataforma | LWC | ✅ Os rótulos de formulário são explicitamente associados a todas as entradas de formulário usando elementos de rótulo adequados ou atributos aria-labelledby |
| Plataforma | LWC | ✅ Componentes de entrada do Lightning são configurados com atributos de rótulo obrigatórios que fornecem associação de rótulo integrada |
| Plataforma | Planos de teste | ✅ O teste é realizado com leitores de tela reais: JAWS e NVDA no Windows, VoiceOver no macOS e no iOS, TalkBack no Android |
| Plataforma | Planos de teste | ✅ O teste manual com tecnologia assistiva real é realizado por pessoas que entendem como os usuários do leitor de tela navegam |
| Plataforma | Padrões de design | ✅ O texto de espaço reservado nunca é usado como o único rótulo porque os espaços reservados desaparecem no foco e fornecem contexto insuficiente para leitores de tela |
Anti-Padrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Plataforma | LWC | ⚡️ As linhas de marcação dividas significam da hierarquia de conteúdo forçando os usuários do leitor de tela a navegar em linha |
| Plataforma | LWC | ⚡️ A ARIA não é usada quando apenas HTML semântico não pode transmitir o comportamento da interface |
| Plataforma | LWC | Atualizações de conteúdo dinâmico não usam regiões ativas aria; usuários do leitor de tela perdem alterações importantes |
| Plataforma | LWC | Componentes interativos personalizados carecem de definições de papel explícitas; os leitores de tela os anunciam incorretamente |
| Plataforma | LWC | ⚡️ Entradas de formulário não têm associação de rótulo explícita; o texto do espaço reservado é usado como único rótulo |
| Plataforma | Planos de teste | ⚡️ Ferramentas de acessibilidade automatizadas são usadas exclusivamente; o teste manual do leitor de tela não é realizado |
| Plataforma | Planos de teste | O teste é realizado por usuários visuais que não estão familiarizados com a maneira como os usuários do leitor de tela realmente navegam |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Plataforma | Padrões de design | ✅ A funcionalidade completa está acessível por meio do teclado sem exigir interação com o mouse ou o toque em qualquer ponto nas jornadas do usuário |
| Plataforma | LWC | ✅ Ordem de foco lógica segue o layout visual e o fluxo de interação |
| Plataforma | LWC | ✅ Quando o conteúdo dinâmico é carregado ou os modais são abertos, o foco é gerenciado programaticamente para orientar os usuários do teclado para o novo conteúdo |
| Plataforma | LWC | ✅ Componentes modais e pop-overs movem o foco para título modal ou primeiro elemento interativo em aberto; retorne o foco para o botão de acionador em fechamento |
| Plataforma | Padrões de design | ✅ Indicadores de foco visíveis mostram claramente qual elemento tem o foco do teclado em todos os momentos |
| Plataforma | Padrões de design | ✅ Indicadores de foco atendem ao requisito de contraste 3:1 em relação ao conteúdo envolvente |
| Plataforma | LWC | ✅ Os usuários podem navegar para dentro e para fora de todos os componentes usando apenas o teclado sem ficarem presos |
| Plataforma | LWC | ✅ Diálogos modais capturam o foco no modal enquanto estão abertos (impedindo o acesso a conteúdo oculto), mas o foco da versão é fechamento |
| Plataforma | Padrões de design | ✅ Atalhos de teclado para ações frequentes evitam conflitos com atalhos do leitor de tela e atalhos do navegador |
| Plataforma | Padrões de design | ✅ Atalhos de letra única são ativados apenas quando componentes específicos têm foco (não globalmente) para evitar conflitos com os comandos de navegação do leitor de tela |
| Plataforma | Documentação | ✅ Todos os atalhos de teclado personalizados são documentados em conteúdo de ajuda acessível |
| Plataforma | Planos de teste | ✅ As etapas de teste incluem navegação somente por teclado em todas as jornadas do usuário sem usar mouse ou toque |
Anti-Padrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Plataforma | Padrões de design | ⚡️ A funcionalidade requer interação com o mouse ou o toque; usuários somente de teclado não podem concluir as principais tarefas |
| Plataforma | LWC | ⚡️ A ordem de foco não segue o layout visual lógico; os usuários percorrem elementos em sequência inesperada |
| Plataforma | LWC | ⚡️ Os modais são abertos sem gerenciamento de foco; os usuários do teclado estão presos no botão de acionador agora oculto |
| Plataforma | LWC | ⚡️ O fechamento modal não retorna o foco ao botão de acionador; os usuários devem procurar seu lugar na página |
| Plataforma | Padrões de design | Indicadores de foco são suprimidos por motivos estéticos; os usuários não podem ver qual elemento tem foco |
| Plataforma | Padrões de design | Indicadores de foco têm contraste insuficiente (<3:1) |
| Plataforma | LWC | ⚡️ Os usuários ficam presos em regiões da interface sem mecanismo de escape (trampas de teclado) |
| Plataforma | LWC | ⚡️ O conteúdo integrado (iframes, widgets de terceiros) captura permanentemente o foco do teclado |
| Plataforma | Padrões de design | Atalhos de letra única acionam conflitos globais com os comandos de navegação de letra única do leitor de tela |
| Plataforma | Documentação | ⚡️ Atalhos de teclado personalizados não são documentados; os usuários não podem descobri-los |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Plataforma | Padrões de design | ✅ Proporção de contraste mínima de 4,5:1 para texto normal abaixo de 18pt ou 14pt em negrito |
| Plataforma | Padrões de design | ✅ Proporção de contraste mínima de 3:1 para texto grande e para componentes e gráficos de UI relevantes (borda de formulário, ícones informativos); elementos exclusivamente decorativos e desabilitados estão isentos |
| Plataforma | Experience Cloud | ✅ Temas personalizados e sites do Experience Cloud com marca incluem validação de contraste explícita usando ferramentas de desenvolvimento de navegador ou verificadores automatizados |
| Plataforma | Padrões de design | ✅ Há suporte para redimensionamento de texto para 200% sem perda de conteúdo ou funcionalidade (requisito de WCAG) |
Anti-Padrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Plataforma | Padrões de design | As proporções de contraste de texto ficam abaixo de 4,5:1 (texto normal) ou 3:1 (componentes de UI e texto grande) |
| Plataforma | Experience Cloud | ⚡️ Os temas personalizados são implementados sem validação de contraste; usuários com baixa visão não podem ler o conteúdo |
| Plataforma | Padrões de design | Redimensionamento de texto além de 200% quebra layouts perdendo conteúdo ou funcionalidade |
Padrões
| Onde procurar | Qual é a boa aparência |
|---|---|
| Plataforma | CI/CD | ✅ A varredura de acessibilidade do Axe Core ou do Lighthouse é integrada a pipelines CI/CD, capturando problemas estruturais em cada implantação |
| Plataforma | CI/CD | ✅ As compilações falham quando problemas críticos de acessibilidade são detectados |
| Plataforma | Planos de teste | ✅ O teste manual com leitores de tela, navegação somente do teclado e zoom do navegador para 200% é realizado regularmente ao longo do desenvolvimento |
| Plataforma | Planos de teste | ✅ O teste revela problemas de interação, incluindo confusão na ordem do anúncio, falhas no gerenciamento de foco e armadilhas de teclado |
| Plataforma | Negócios | ✅ Usuários com deficiência são incluídos nos testes de usabilidade em todo o processo de design |
| Plataforma | Negócios | ✅ O teste de usabilidade revela barreiras práticas que os testes automatizados e manuais de especialistas ignoram |
| Plataforma | Planos de teste | ✅ Testes automatizados (~57% dos problemas por volume), testes manuais (problemas de interação) e testes do usuário (barreiras do mundo real) são todos realizados |
Anti-Padrões
| Onde procurar | Qual é a aparência ruim |
|---|---|
| Plataforma | CI/CD | A varredura de acessibilidade não está integrada a pipelines de CI/CD |
| Plataforma | CI/CD | ⚡️ As compilações continuam apesar de problemas críticos de acessibilidade |
| Plataforma | Planos de teste | Teste manual com tecnologia assistiva não é realizado; apenas leitura automatizada é usada |
| Plataforma | Negócios | ⚡️ Usuários com deficiência não são incluídos nos testes de usabilidade |
| Plataforma | Planos de teste | ⚡️ O scanner de acessibilidade automatizado é executado uma vez antes do lançamento e o teste de acessibilidade é considerado concluído |