bestgirlfriend.ai
ui.hero.eyebrowDefault

Declaração de Acessibilidade: Metas WCAG 2.1 AA + Exceções

Declaração de acessibilidade em português claro: meta WCAG 2.1 AA, pipeline axe-core + Lighthouse, uma exceção de cor de marca documentada. Reporte uma barreira.

ui.hero.by ui.hero.lastRevised

Olha, a maioria das declarações de acessibilidade nesse ramo ou mente na cara ("100% em conformidade com a WCAG AA!") ou cola um boilerplate genérico que enterra cada exceção conhecida atrás de uma cortina de jargão de conformidade. Esta aqui é mais curta, organizada em torno do que você realmente precisa saber, e franca sobre a única exceção documentada que a gente aceita. Escrevi do jeito que eu ia querer ler se fosse eu o leitor.

O bestgirlfriend.ai é um comparador editorial que cobre apps de namorada virtual, apps de namorado virtual, sites de cam, criadores de modelos reais e jogos adultos. Acessibilidade faz parte da base editorial, não é um recurso enfiado depois no lançamento. Esta página documenta os padrões que a gente segue, as técnicas que usa, a única exceção que aceita e por quê, as lacunas que ainda devemos e o canal pra reportar uma barreira.

Esta declaração se alinha com a Section 508 dos EUA (29 U.S.C. §794d, harmonizada com a WCAG 2.0 AA pelo ICT Refresh de 2018), com o padrão harmonizado europeu EN 301 549 v3.2.1 (referenciado pela Diretiva de Acessibilidade Web 2016/2102 e pelo European Accessibility Act 2019/882, em vigor desde 28 de junho de 2025), com as Regulações de Acessibilidade dos Órgãos do Setor Público (Sites e Aplicativos Móveis) (No. 2) de 2018 do Reino Unido e com a Lei de Acessibilidade para Ontarianos com Deficiência de 2005 e sua Regulação de Padrões Integrados de Acessibilidade. A gente é uma publicadora privada, não um órgão do setor público, mas se cobra o mesmo nível de conformidade porque o piso legal é a linha de largada certa.

O bestgirlfriend.ai segue a WCAG?

A gente mira no WCAG 2.1 nível AA em toda página pública e bate na meta em todos os critérios de sucesso, menos uma exceção documentada: a cor de marca #E94B6A sobre o creme #FAF7F2 dá um contraste de 3,46:1, abaixo do piso de 4,5:1 do AA pra texto corrido. O coral fica restrito a botões, badges, links e detalhes decorativos (a superfície de 3:1 sob a WCAG 1.4.11), nunca no texto corrido. Todo outro critério de sucesso é atendido, e a exceção fica registrada, com as medições, no nosso design system.

Última revisão: 2026

Conformidade é algo que você continua fazendo, não uma caixinha que marca uma vez. O site é projetado pra WCAG 2.1 AA, os quatro princípios (perceptível, operável, compreensível, robusto) estão embutidos no jeito que as páginas são desenhadas, e todo commit passa por checagens automáticas antes do merge. O único trade-off que a gente aceita é o contraste do coral da marca, e a gente fala isso de cara em vez de esconder numa nota de rodapé de conformidade parcial lá embaixo. O resto desta página documenta o que isso significa, concretamente.

Quais padrões a gente segue?

WCAG 2.1 nível AA é a nossa meta de engenharia. Ela é referenciada pela Section 508 dos EUA (ICT Refresh 2018), pelo padrão harmonizado europeu EN 301 549 v3.2.1, pela Diretiva de Acessibilidade Web 2016/2102 da UE, pelo European Accessibility Act 2019/882 (em vigor desde 28 de junho de 2025), pelas regulações de acessibilidade do setor público do Reino Unido de 2018 e pela Regulação de Padrões Integrados de Acessibilidade da AODA de Ontário.

WCAG 2.1 AA é a língua franca global da acessibilidade digital [Source: W3C, Diretrizes de Acessibilidade para Conteúdo Web 2.1, Recomendação W3C de 05 de junho de 2018 · verified 2026-05-26]. A Section 508 a referencia pelo ICT Refresh dos EUA [Source: Section 508 dos EUA, padrões ICT Refresh · verified 2026-05-26]. A EN 301 549 a referencia como o padrão harmonizado europeu [Source: ETSI EN 301 549, requisitos de acessibilidade pra produtos e serviços de TIC · verified 2026-05-26]. As regulações de 2018 do Reino Unido a citam explicitamente. A AODA a referencia pela Regulação de Padrões Integrados de Acessibilidade.

Escolher o AA significa que a gente satisfaz os cinco regimes a partir de uma só meta de engenharia. A gente fica de olho na WCAG 2.2 (publicada em outubro de 2023) e incorpora os critérios de sucesso dela onde não entram em conflito com a 2.1. Vamos mover a nossa declaração pública de conformidade pra 2.2 AA assim que os padrões de compras dos nossos mercados-chave a citarem.

O cenário de padrões converge na WCAG 2.1 AA como a meta de engenharia testável. Os cinco regimes que governam os nossos mercados, cada um ligado à referência canônica:

PadrãoRegiãoNível de conformidadeNosso statusReferência
WCAG 2.1 AAGlobal (W3C)Nível AAMira (1 exceção documentada)Recomendação W3C, 5 de junho de 2018
EN 301 549 v3.2.1União EuropeiaPadrão harmonizado, AAMira (1 exceção documentada)ETSI, março de 2021; referenciado pela WAD 2016/2102 e pela EAA 2019/882
Section 508 (ICT Refresh)Estados UnidosWCAG 2.0 AA harmonizado; AAMira (com delta WCAG 2.1 AA, 1 exceção documentada)36 CFR Parte 1194, U.S. Access Board 2018
Regulações de Acessibilidade do Setor Público do Reino Unido 2018Reino UnidoWCAG 2.1 AAMira (publicadora privada; voluntário)SI 2018/952
AODA / IASROntário, CanadáWCAG 2.0 AA (IASR §14)Mira (com delta WCAG 2.1 AA, 1 exceção documentada)O. Reg. 191/11, Padrões Integrados de Acessibilidade
Última revisão: 2026.

Quais são as exceções conhecidas de acessibilidade?

Duas. (1) Exceção de contraste da cor de marca: o coral #E94B6A sobre o creme #FAF7F2 dá 3,46:1, abaixo do piso de 4,5:1 do AA da WCAG pra texto corrido. O coral fica restrito a botões, badges, links e detalhes decorativos (a superfície de 3:1 sob a WCAG 1.4.11), nunca no texto corrido. (2) As imagens de Open Graph em algumas páginas de listicle ficam sem alt descritivo pra leitores de tela quando aparecem dentro de previews sociais de terceiros (cosmético; em correção). O chatbot AI Concierge ainda não concluiu a auditoria completa e não vai pro ar até concluir.

Listar as exceções conhecidas em público é a contraparte honesta de uma declaração de conformidade. A conformidade WCAG é binária no nível do critério de sucesso: ou a página atende ao critério, ou não. A gente não mistura um aviso de conformidade parcial no corpo da página; as exceções moram aqui, em linguagem clara, com a justificativa e o status de correção.

A exceção de cor de marca, em detalhe. A nossa cor de destaque primária (#E94B6A, o coral em botões e badges) sobre o nosso fundo editorial (#FAF7F2, o creme quente) dá um contraste de 3,46:1. O WCAG 2.1 AA exige 4,5:1 pra texto corrido normal (SC 1.4.3) e 3:1 pra texto grande e pra componentes de UI e objetos gráficos (SC 1.4.11). O contraste de 3,46:1 atende ao piso de 3:1 da superfície de UI / texto grande e fica abaixo do piso de 4,5:1 pra texto corrido.

A gente decidiu aceitar o trade-off só pra superfície do detalhe de marca. O coral aparece nos botões de ação, sublinhados de link, badges, na barra de promoção fixa e em detalhes decorativos, todas superfícies onde vale o piso de 3:1. O texto corrido, os títulos e todo o resto do texto usam #1A1A1A quase-preto sobre o creme, que passa de 4,5:1 com folga. A decisão tá documentada no nosso design system junto com as medições de contraste, então o trade-off é revisável, não invisível.

A maioria dos sites de review desse ramo nem mostra esse tipo de trade-off de marca. Eles dizem que têm conformidade AA total, e a auditoria nunca pega o problema da cor de destaque porque a auditoria nunca rodou. A gente roda a auditoria, registra o resultado e te conta. É essa a diferença entre uma declaração de acessibilidade de verdade e um boilerplate copiado e colado.

Problemas em aberto:

IDProblemaSeveridadeStatusCorreção-alvo
A11Y-001Cor de marca (#E94B6A) sobre creme (#FAF7F2) = 3,46:1, abaixo do piso AA de 4,5:1 pra texto corridoExceção aceita (só UI/detalhe; texto corrido não afetado)Documentado nos tokens de designSem correção planejada sem mudar a cor de marca
A11Y-002Alt das imagens de Open Graph nos previews sociais de listicleCosmético (não afeta a leitura no site)Em correção3º trimestre de 2026
A11Y-003Auditoria completa WCAG 2.1 AA do chatbot AI ConciergeBloqueante (o chatbot não vai pro ar até ser liberado)Auditoria pendente antes do lançamentoAntes do lançamento

Se você esbarrar num problema que não tá nessa lista, por favor reporte. A lista é atualizada sempre que um problema novo é descoberto ou um existente é fechado.

Como eu reporto um problema de acessibilidade?

Manda um email pra [email protected] com a URL da página, o seu navegador e a tecnologia assistiva e uma descrição curta da barreira. A gente confirma o recebimento de todo report em até 2 dias úteis e tem meta de resolução ou contorno em até 7 dias úteis pra problemas bloqueantes. Os problemas que não conseguirem bater na meta de 7 dias recebem uma mitigação pública provisória mais uma data-alvo de correção no log de Problemas Conhecidos desta página.

A caixa de email dedicada é [email protected]. Pra ajudar a gente a reproduzir e corrigir mais rápido, por favor inclua quando der:

  • A URL da página onde você esbarrou na barreira.
  • O seu sistema operacional e navegador (e versão).
  • A tecnologia assistiva que você usou (leitor de tela, switch, lupa, controle por voz etc.) e a versão dela.
  • Uma descrição curta do que você esperava e do que aconteceu no lugar.
  • Um print ou gravação de tela, se tiver e você se sentir à vontade pra compartilhar.

Você também pode pedir esta declaração, um resumo de auditoria ou uma correção específica num formato alternativo (letra grande, email em texto puro, retorno por telefone) escrevendo pro mesmo endereço. A gente não exige nenhum desses dados pra investigar; eles só ajudam a reproduzir o problema.

O SLA é voluntário e tá publicado aqui pra ser verificável. Se a gente furar a confirmação de 2 dias ou a meta de 7 dias num problema bloqueante, isso é, em si, uma falha documentada e a gente vai documentar nesta página. As rotas de escalada legal, por exemplo, reclamações à Comissão de Igualdade e Direitos Humanos do Reino Unido, à linha do Departamento de Justiça ADA dos EUA ou ao seu equivalente nacional, ficam disponíveis independente de como a gente trate o report internamente.

E o suporte a leitor de tela?

A gente testa com NVDA e JAWS no Windows, VoiceOver no macOS e iOS e TalkBack no Android. Títulos, landmarks e listas são anunciados corretamente. Campos de formulário têm rótulo visível e programático. Ícones decorativos usam alt vazio ou aria-hidden. Imagens editoriais têm alt escrito por editores, não por desenvolvedores, então o alt reflete a intenção.

Leitores de tela não veem o que quem enxerga vê; eles fazem o parse da árvore do documento. É por isso que o HTML semântico, e não o ARIA, carrega o primeiro peso da acessibilidade aqui. A gente coloca ARIA em cima só onde a semântica nativa do HTML fica curta (live regions em conteúdo dinâmico, roles de diálogo em modais, estados de expandido em widgets de divulgação), seguindo a primeira regra do ARIA: se um elemento nativo já entrega a semântica, use ele. A cobertura de leitor de tela é re-testada a cada lançamento grande, e a gente guarda as transcrições de teste em arquivo.

Como a navegação por teclado é suportada?

Todo elemento interativo é operável pelo teclado. Um link de pular pro conteúdo principal é o primeiro item focável de toda página. A ordem de tabulação segue a ordem visual de leitura. Os indicadores de foco batem em 3:1 de contraste nos modos claro e escuro. O drawer mobile e o modal de idioma prendem o foco quando abertos e devolvem quando fecham, então quem usa só teclado nunca fica preso.

O contrato do teclado é a superfície que a gente testa com mais afinco, porque ele faz as vezes de toda tecnologia assistiva que emula um teclado, incluindo switches e teclados na tela. Os links de pular atendem ao WCAG 2.4.1 Contornar Blocos, os indicadores de foco visíveis atendem ao WCAG 2.4.7 Foco Visível, e a regra de não prender o teclado atende ao WCAG 2.1.2. O comportamento de prender o foco nos modais segue o padrão de diálogo do W3C ARIA Authoring Practices Guide, com o foco devolvido pro elemento que disparou quando fecha.

Quais recursos de acessibilidade já vêm embutidos?

Entre os recursos embutidos estão HTML semântico (header, nav, main, footer, article, aside), hierarquia de títulos rígida com um H1 por página, alt descritivo nas ilustrações editoriais, imagens decorativas marcadas com alt="", legendas de tabela com cabeçalhos escopados, transcrições em todo vídeo embutido, suporte a prefers-reduced-motion e indicadores de foco visíveis batendo 3:1 de contraste nos temas claro e escuro.

O inventário completo de recursos, mapeado pro critério de sucesso WCAG por trás dele:

Como o texto da direita pra esquerda é tratado?

As páginas em árabe (ar) e hebraico (he-IL) renderizam em layout da direita pra esquerda via propriedades lógicas de CSS (margin-inline-start, padding-inline-end) em vez de valores fixos de esquerda/direita. Todo componente, incluindo o header, a navegação, os botões de ação, o footer, a barra fixa mobile e os modais, espelha direitinho. A gente fez stress test do chrome inteiro num template AR dedicado antes do lançamento e documentou o resultado no nosso design system.

Suporte a direita-pra-esquerda não é questão de tradução; é questão de layout. Trocar o atributo dir do documento pra "rtl" inverte o inline-start e o inline-end no layout inteiro porque todo espaçamento, alinhamento e float é expresso em propriedades lógicas. O conteúdo bidirecional (URLs em latim dentro de prosa em árabe, por exemplo) é envolvido em elementos HTML <bdi> pra que o algoritmo bidirecional renderize de forma previsível. A gente mantém uma auditoria completa de direita-pra-esquerda numa página de teste em árabe dedicada e a re-roda antes de cada lançamento.

Como o modo escuro interage com a acessibilidade?

O modo escuro é um botão manual no header e respeita o prefers-color-scheme na primeira visita. O texto corrido fica em 4,5:1 ou mais nos dois modos; o texto grande e os componentes de UI ficam acima de 3:1 (com a exceção documentada do detalhe de marca). A cor nunca é a única portadora de significado, então quem tem deficiência de visão de cores ou está em ambiente monocromático não perde nenhuma informação ao trocar de modo.

Última revisão: 2026

O modo escuro é implementado por um atributo data-theme="dark" no elemento raiz do documento, trocando as propriedades customizadas de CSS na raiz. O botão persiste a escolha da pessoa no localStorage, e se ela não escolheu, a gente segue o prefers-color-scheme. As duas paletas são auditadas de forma independente contra os mínimos de contraste WCAG 1.4.3 e 1.4.11. O modo escuro vai além de gosto de estilo. As Diretrizes de Interface Humana da Apple e a acessibilidade do GOV.UK reconhecem ele como uma acomodação pra fotofobia, enxaqueca e condições de baixa visão, então a garantia de contraste vale nas duas direções.

Os vídeos têm transcrição?

Têm. Todo vídeo embutido usa o domínio youtube-nocookie.com e vem com uma transcrição escrita na página, logo abaixo do embed. As legendas ficam ativadas na fonte do YouTube. Os vídeos não dão autoplay, não ficam em loop automático e oferecem controles de pausar e parar. Quando a legenda da fonte tá faltando, a gente adiciona uma transcrição manual antes de publicar.

Transcrição não é opcional aqui. Ela serve leitores surdos e com deficiência auditiva (o público pra quem ela é escrita), leitores em ambientes sem som como trabalho e transporte, quem está aprendendo o idioma e se apoia no texto reforçando o áudio, e os buscadores e crawlers de IA que conseguem ler conteúdo legível por máquina que os pixels do vídeo não expõem. Um artefato, quatro retornos.

Como vocês lidam com movimento reduzido?

O site honra a media query prefers-reduced-motion do CSS. Quando a pessoa tem movimento reduzido ativado no nível do sistema operacional, a gente desativa parallax, carrosséis de auto-rolagem, animações em autoplay e transições decorativas. O movimento essencial de interface (indicadores de foco, abertura de dropdown) fica preservado porque comunica estado. Nada no site pisca mais de três vezes por segundo.

O limiar de três piscadas atende ao WCAG 2.3.1 Três Flashes ou Abaixo, o critério de prevenção de convulsões. A conformidade com movimento reduzido cuida de distúrbios vestibulares, náusea induzida por movimento e necessidades de acessibilidade ligadas à atenção, documentadas na literatura da força-tarefa de Acessibilidade Cognitiva do W3C. A implementação é uma media query só, aplicada na camada de tokens de design; nenhum JavaScript é necessário pra preferência da pessoa ter efeito.

Com que frequência vocês testam?

Em tempo de build: o axe-core roda contra toda story de componente e todo snapshot de página no CI. O build quebra em violações sérias ou críticas. Antes do merge: os pull requests têm um piso de 95 na pontuação de Acessibilidade do Lighthouse e a GitHub Action bloqueia merges abaixo disso. As passagens manuais de leitor de tela (NVDA, JAWS, VoiceOver, TalkBack) rodam a cada trimestre num conjunto representativo de páginas e ad-hoc em qualquer template novo.

O teste é em camadas: automático onde a ferramenta é confiável, manual onde gente ainda é o único sinal que importa.

  • Em tempo de build: o axe-core roda contra toda story de componente e todo snapshot de página no CI. O build quebra em violações sérias ou críticas.
  • Antes do merge: os pull requests têm um piso de 95 na pontuação de Acessibilidade do Lighthouse e a GitHub Action bloqueia merges abaixo disso.
  • Passagens manuais de leitor de tela: NVDA, JAWS, VoiceOver (macOS + iOS), TalkBack, a cada trimestre num conjunto representativo de páginas, ad-hoc em qualquer template novo.
  • Passagem só por teclado: todo tipo de página novo é navegado de ponta a ponta com o teclado antes do merge, e o registro do teste é arquivado junto com a mudança.
  • Auditoria de ordem de leitura: a ordem de tabulação é comparada com a ordem visual de leitura em todo template.
  • Simulação de daltonismo: o Sim Daltonism e o painel de renderização do Chrome DevTools simulam protanopia, deuteranopia e tritanopia em toda paleta publicada. A exceção de contraste da cor de marca fica registrada aqui.
  • Feedback de usuário real: toda barreira reportada pra [email protected] vira um ticket e é acompanhada publicamente na tabela de Problemas Conhecidos desta página.

A combinação segue a orientação de testes de acessibilidade do GOV.UK: a ferramenta automática pega mais ou menos 30 a 40% dos problemas, e o resto só aparece quando gente usa tecnologia assistiva em condições reais.

Qual é o SLA das reclamações de acessibilidade?

A gente confirma o recebimento de reclamações de acessibilidade em até 2 dias úteis no [email protected]. Barreiras bloqueantes (um recurso inutilizável com tecnologia assistiva) têm meta de resolução em até 7 dias úteis. Problemas não bloqueantes recebem uma data-alvo de correção documentada e ficam no log de Problemas Conhecidos até serem fechados. Os direitos de escalada legal continuam disponíveis abaixo deste SLA voluntário.

O SLA é voluntário e tá publicado aqui pra ser verificável. Se a gente furar a confirmação de 2 dias ou a meta de 7 dias num problema bloqueante, isso é, em si, uma falha documentada e a gente vai documentar nesta página. As rotas de escalada legal, por exemplo, reclamações à Comissão de Igualdade e Direitos Humanos do Reino Unido, à linha do Departamento de Justiça ADA dos EUA ou ao seu equivalente nacional, ficam disponíveis independente de como a gente trate o report internamente.

Como o chatbot AI Concierge lida com acessibilidade?

O chatbot AI Concierge (antes do lançamento) não vai pro ar até passar numa auditoria completa de WCAG 2.1 AA cobrindo operação por teclado, anúncios de leitor de tela (live region pra respostas em streaming), gestão de foco na abertura e fechamento do painel e conformidade com movimento reduzido. Até lá, todo conteúdo editorial é alcançável sem o chatbot, pelos accordions de FAQ na própria página.

Interfaces conversacionais estressam a acessibilidade de jeitos que páginas estáticas não estressam. O texto em streaming precisa de live regions ARIA educadas, o foco tem que se mover de forma previsível entre o gatilho, o painel e o fechamento, quem usa teclado precisa de uma saída documentada, e quem usa movimento reduzido precisa ter a preferência honrada na transição do painel. A auditoria do Concierge vai seguir o padrão de diálogo do W3C ARIA APG pro comportamento do painel e a orientação de live region do WAI-ARIA pras respostas em streaming. A gente vai anexar a transcrição completa da auditoria nesta página quando o chatbot for pro ar.

O que é a Section 508 e o European Accessibility Act 2025?

A Section 508 da Lei de Reabilitação dos EUA (29 U.S.C. §794d, ICT Refresh 2018) exige que agências e contratantes federais comprem e mantenham tecnologia da informação acessível, harmonizada com a WCAG 2.0 AA via 36 CFR Parte 1194. O European Accessibility Act (Diretiva 2019/882, em vigor desde 28 de junho de 2025) estende os deveres de acessibilidade a um amplo leque de produtos e serviços do setor privado, também harmonizado com a WCAG 2.1 AA via EN 301 549.

Os dois regimes convergem pra mesma meta de engenharia. É por isso que uma postura de conformidade satisfaz os dois, e por isso a gente escolhe a barra aplicável mais alta (WCAG 2.1 AA via EN 301 549 v3.2.1) e a trata como o piso em toda página pública do site, não só nas superfícies tocadas por contratos federais dos EUA ou obrigações de serviço da UE.

A data de vigência do EAA, 28 de junho de 2025, importa pra publicadoras privadas como a gente. É o momento em que "declaração de acessibilidade no site" deixa de ser cortesia e vira um artefato verificável por reguladores nos estados-membros que transpuseram a diretiva. A gente publicou esta declaração bem antes dessa data, com a única exceção documentada acima, porque a gente prefere ter a conversa sobre o trade-off da cor de marca agora do que ser perguntada sobre ele depois.

Cite esta página

Se você referenciar esta declaração num trabalho acadêmico, regulatório ou jornalístico, por favor cite assim:

Joly, A. (2026). Declaração de Acessibilidade: Metas WCAG 2.1 AA, Exceções e Reporte pro bestgirlfriend.ai. bestgirlfriend.ai. https://bestgirlfriend.ai/pt/accessibility

Um resumo legível por máquina é publicado em /llms.txt pra ingestão por crawlers de busca de IA.

Perguntas frequentes

Última revisão: 2026.

O bestgirlfriend.ai segue a WCAG?

A gente mira no Web Content Accessibility Guidelines (WCAG) 2.1 nível AA em toda página pública. Bate na meta em todos os critérios de sucesso, menos uma exceção documentada: a nossa cor de marca #E94B6A sobre o creme #FAF7F2 dá um contraste de 3,46:1, abaixo do piso de 4,5:1 do AA pra texto corrido. A gente usa a cor de marca só em botões, badges e detalhes decorativos (tratados como texto grande + UI sob a WCAG 1.4.11), nunca no texto corrido. O nosso alinhamento de padrões mapeia pra Section 508 dos EUA, EN 301 549 da UE, as regulações de acessibilidade do setor público do Reino Unido de 2018 e a AODA de Ontário.

Quais padrões a gente segue?

WCAG 2.1 nível AA é a nossa meta de engenharia. Ela é referenciada pela Section 508 dos EUA (ICT Refresh 2018), pelo padrão harmonizado europeu EN 301 549 v3.2.1, pela Diretiva de Acessibilidade Web 2016/2102 da UE, pelo European Accessibility Act 2019/882 (em vigor desde 28 de junho de 2025), pelas regulações de acessibilidade do setor público do Reino Unido de 2018 e pela Regulação de Padrões Integrados de Acessibilidade da AODA de Ontário. A gente acompanha os critérios de sucesso da WCAG 2.2 como meta de compatibilidade futura, mas a nossa declaração pública de conformidade fica em 2.1 AA até a 2.2 entrar nas leis de compras regionais.

Quais são as exceções conhecidas de acessibilidade?

Duas. (1) Exceção de cor de marca: o coral #E94B6A sobre o creme #FAF7F2 dá 3,46:1, abaixo do piso de 4,5:1 do AA pra texto corrido. A gente restringe o coral a botões, badges, links e detalhes decorativos (onde vale o piso de 3:1 de UI / texto grande pela WCAG 1.4.11), nunca no texto corrido; o trade-off tá documentado no nosso design system. (2) Algumas imagens de Open Graph em páginas de listicle ficam sem alt descritivo pra leitores de tela quando aparecem dentro de previews sociais de terceiros (cosmético; em correção). O chatbot não vai pro ar até passar numa auditoria completa de teclado e leitor de tela.

Como eu reporto um problema de acessibilidade?

Manda um email pra [email protected] com a URL da página, a sua versão de navegador e de tecnologia assistiva e uma descrição curta da barreira. A gente confirma o recebimento de todo report em até 2 dias úteis. Barreiras bloqueantes (um recurso fica inutilizável com tecnologia assistiva) têm meta de resolução em até 7 dias úteis. Problemas não bloqueantes recebem uma data-alvo de correção documentada e ficam na tabela de Problemas Conhecidos desta página até serem fechados. Os direitos de escalada legal continuam disponíveis independente do nosso SLA interno.

E o suporte a leitor de tela?

A gente testa com NVDA no Windows, JAWS no Windows, VoiceOver no macOS e iOS e TalkBack no Android. Títulos, landmarks e listas são anunciados corretamente. Campos de formulário têm rótulo visível e programático. Ícones decorativos usam alt vazio ou aria-hidden. Imagens editoriais têm alt descritivo escrito por editores, não por desenvolvedores, então o alt reflete a intenção. HTML semântico é a nossa primeira linha de defesa; ARIA entra em cima só onde a semântica nativa do HTML não dá conta, seguindo a primeira regra do ARIA.

Como a navegação por teclado é suportada?

Todo elemento interativo no bestgirlfriend.ai é operável pelo teclado. Um link de pular pro conteúdo principal é o primeiro item focável de toda página. A ordem de tabulação segue a ordem visual de leitura. Os indicadores de foco têm pelo menos 3:1 de contraste nos modos claro e escuro. O drawer mobile e o modal de idioma prendem o foco quando abertos e devolvem quando fecham, então quem usa só teclado nunca fica preso. O comportamento de prender o foco segue o padrão de diálogo do W3C ARIA Authoring Practices Guide.

Como o texto da direita pra esquerda é tratado?

As páginas em árabe (ar) e hebraico (he-IL) renderizam em layout da direita pra esquerda via propriedades lógicas de CSS (margin-inline-start, padding-inline-end) em vez de valores fixos de esquerda/direita. Todo componente, incluindo o header, a navegação, os botões de ação, o footer, a barra fixa mobile e os modais, espelha direitinho. A gente fez stress test do chrome inteiro num template AR dedicado antes do lançamento e documentou o resultado no nosso design system.

Como o modo escuro interage com a acessibilidade?

O modo escuro é oferecido como um botão manual no header e respeita a preferência prefers-color-scheme do sistema na primeira visita. O contraste do texto corrido fica em 4,5:1 ou mais nos dois modos pra superfície de prosa. A cor nunca é a única portadora de significado, então quem tem deficiência de visão de cores ou está em ambiente monocromático não perde nenhuma informação ao trocar de modo. A exceção de contraste do detalhe coral da marca vale nos dois modos.

Os vídeos têm transcrição?

Têm. Todo vídeo embutido no bestgirlfriend.ai usa o domínio youtube-nocookie e vem com uma transcrição escrita publicada na própria página, logo abaixo do embed. As legendas ficam ativadas na fonte do YouTube. Os vídeos não dão autoplay, não ficam em loop automático e oferecem controles de pausar e parar. Quando a legenda não existe na fonte original, a gente adiciona uma transcrição manual antes de publicar.

Como vocês lidam com movimento reduzido?

O site respeita a media query prefers-reduced-motion do CSS. Quando a pessoa tem movimento reduzido ativado no nível do sistema operacional, a gente desativa parallax, carrosséis de auto-rolagem, animações em autoplay e transições decorativas. O movimento essencial de interface (indicadores de foco, abertura de dropdown) fica preservado porque comunica estado. Nada no site pisca mais de três vezes por segundo, atendendo ao critério de prevenção de convulsões.

Com que frequência vocês testam?

O axe-core roda contra toda story de componente e todo snapshot de página no CI; o build quebra em violações sérias ou críticas. Os pull requests têm um piso de 95 na pontuação de Acessibilidade do Lighthouse e a GitHub Action bloqueia merges abaixo disso. As passagens manuais de leitor de tela no NVDA, JAWS, VoiceOver e TalkBack rodam a cada trimestre num conjunto representativo de páginas e ad-hoc em qualquer template novo. Todo template novo é navegado de ponta a ponta pelo teclado antes do merge.

Qual é o SLA das reclamações de acessibilidade?

A gente confirma o recebimento de reclamações de acessibilidade em até 2 dias úteis no [email protected]. Barreiras bloqueantes (um recurso inutilizável com tecnologia assistiva) têm meta de resolução em até 7 dias úteis. Problemas não bloqueantes recebem uma data-alvo de correção documentada e ficam no log de Problemas Conhecidos até serem fechados. Leitores da UE e do Reino Unido mantêm os seus direitos de escalada legal independente de como a gente trate o report internamente.

Como o chatbot AI Concierge lida com acessibilidade?

O chatbot AI Concierge (antes do lançamento) não vai pro ar até passar numa auditoria completa de WCAG 2.1 AA cobrindo operação por teclado, anúncios de leitor de tela (live region pra respostas em streaming), gestão de foco quando o painel abre e fecha e conformidade com movimento reduzido. Até lá, todo conteúdo editorial é acessível sem o chatbot, e respostas equivalentes ficam alcançáveis pelos accordions de FAQ na própria página. A auditoria vai seguir o padrão de diálogo do W3C ARIA APG pro comportamento do painel e a orientação de live region do WAI-ARIA pras respostas em streaming.

O que é a Section 508 e o European Accessibility Act 2025?

A Section 508 da Lei de Reabilitação dos EUA (29 U.S.C. §794d, ICT Refresh 2018) exige que agências e contratantes federais comprem e mantenham tecnologia da informação acessível, harmonizada com a WCAG 2.0 AA via 36 CFR Parte 1194. O European Accessibility Act (Diretiva 2019/882, em vigor desde 28 de junho de 2025) estende os deveres de acessibilidade a um amplo leque de produtos e serviços do setor privado, também harmonizado com a WCAG 2.1 AA via EN 301 549. Os dois regimes convergem pra mesma meta de engenharia, e é por isso que uma postura de conformidade satisfaz os dois.

Fontes

Os padrões, leis e diretrizes citados nesta página estão listados abaixo na ordem em que aparecem, com URLs estáveis. Re-verificados em 2026.

Páginas editoriais de confiança relacionadas

Aviso por jurisdição

Última verificação em 2026 · Veja o log de errata pra qualquer correção pós-publicação · Editora: Alexandra Joly · Metodologia · Processo editorial · Divulgação de afiliados

Declaração de Acessibilidade: Metas WCAG 2.1 AA + Exceções