---
schema_version: "1"
id: 0788a8c7aa29d8ef96eff4cf54e961f0e1b566547c0b37f613a8513e9bcf4373
title: Acessibilidade e design inclusivo – Padrões
collection: architect
version: current
locale: pt-br
portal_url: https://docs.salesforce.com/architect/current/pt-br/well-architected/guides/fairness-accessibility-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/pt-br/well-architected/guide/fairness-accessibility-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 3b111cfba3f7a33ed83b8e17af40242af67355b65def70d35b72d6bd8b930f9e
products:
  - Estrutura bem arquitetada
  - Architect Site Content Repo
---
# Acessibilidade e design inclusivo – Padrões

<br>

Saiba mais sobre a [justiça](/docs/architect/pt-br/well-architected/guide/fairness.html) bem criada → [Acessibilidade com Lightning e Experience Cloud](/docs/architect/pt-br/well-architected/guide/fairness.html#accessibility-with-lightning-and-experience-cloud)

## Conformidade com WCAG 2.2 AA

**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)              |

## Arquitetura do Leitor de tela

**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         |

## Navegação do teclado

**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                                     |

## Design visual e contraste

**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                       |

## Teste e validação de acessibilidade

**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 |