Acessibilidade em Serviços Bancários e Financeiros: O que a Lei Exige em 2025

Em 2025, uma cliente com deficiência visual tenta solicitar uma hipoteca no site de um grande banco. O formulário de solicitação não tem rótulos visíveis, as mensagens de erro não são anunciadas pelo leitor de tela dela e o indicador de progresso é construído inteiramente em CSS, sem texto alternativo acessível. Ela abandona o processo por completo. Enquanto isso, a equipe jurídica do banco já está lidando com uma carta de notificação — uma das 3.117 ações judiciais sobre acessibilidade de sites ajuizadas apenas no ano passado em tribunais federais dos EUA, um aumento de 27% em relação ao ano anterior. Para as instituições financeiras, 2025 é o ano em que o argumento jurídico e ético em favor da acessibilidade convergiu em algo impossível de ignorar.

Por que os serviços financeiros enfrentam obrigações de acessibilidade ampliadas

Serviços bancários não são opcionais. As pessoas precisam de acesso ao seu dinheiro, crédito e contas de investimento para participar plenamente da vida econômica moderna. Para clientes com deficiência, serviços financeiros acessíveis não são um luxo — são essenciais para participação econômica e independência. Essa realidade é cada vez mais refletida na forma como tribunais, reguladores e legisladores tratam as instituições financeiras.

Bancos são “locais de acomodação pública” e, portanto, estão cobertos pelo Título III da Americans with Disabilities Act (ADA). Nos termos do Título III da ADA, locais de acomodação pública — uma categoria ampla que inclui bancos e outros negócios abertos ao público — são obrigados a fornecer serviços acessíveis para pessoas com deficiência. Embora a ADA tenha sido promulgada em 1990 e inicialmente focada no acesso físico, os tribunais vêm ampliando gradualmente seu alcance para plataformas digitais, aplicativos móveis e portais de banco on-line.

Com o crescimento do banco digital, aproximadamente dois terços dos adultos nos EUA agora dependem de plataformas on-line — sites e aplicativos — para gerenciar suas finanças. Essa mudança tornou a infraestrutura digital inacessível não apenas inconveniente, mas genuinamente discriminatória. Para aproximadamente 61 milhões de pessoas com algum tipo de deficiência nos EUA, bancos e instituições financeiras devem garantir que suas plataformas digitais estejam em conformidade com a Seção 508 e a ADA, já que a acessibilidade na web é fundamental para que pessoas com deficiência possam usar esses serviços. A falta de acesso a sites, aplicativos e documentos on-line — como formulários e PDFs — pode levar a litígios, uma tendência que está em constante crescimento.

O setor financeiro também enfrenta uma teia mais ampla de exposição regulatória além da ADA. As instituições financeiras enfrentam múltiplas exigências de acessibilidade: o Título III da ADA exige que bancos, como locais de acomodação pública, forneçam serviços acessíveis, cada vez mais interpretados como incluindo sites; a Seção 504 se aplica a instituições financeiras que recebem recursos federais; a Seção 508 rege serviços financeiros contratados pelo governo; e leis estaduais como a Unruh Act da Califórnia e a New York Human Rights Law oferecem proteções adicionais. Além disso, o Consumer Financial Protection Bureau (CFPB) analisa a acessibilidade como parte do crédito justo e da proteção ao consumidor, e o Office of the Comptroller of the Currency (OCC) inclui acessibilidade em suas orientações de gestão de risco.

O cenário jurídico dos EUA em 2025: recorde de ações e aumento das apostas

O ambiente de litígios nunca foi tão intenso. Autores de ações ajuizaram 3.117 processos sobre acessibilidade de sites em tribunais federais em 2025 — um aumento de 27% em relação a 2024. As ações judiciais sobre acessibilidade de sites em tribunais federais se recuperaram após dois anos de queda, com o número total de processos alegando que pessoas com deficiência não conseguiam usar sites porque eles não foram projetados para serem acessíveis chegando a 3.117.

As ações judiciais sobre acessibilidade de sites representaram 36% do número total de ações com base no Título III da ADA ajuizadas em tribunais federais em 2025 — 3.117 de 8.667 casos. E essa cifra quase certamente subestima a exposição real. Mais notavelmente em 2025, ações e acordos sobre acessibilidade digital deixaram de se limitar aos tribunais federais. Autores passaram a ajuizar cada vez mais em tribunais estaduais, especialmente em Nova York e na Califórnia. Esses tribunais permitem que os autores recebam indenizações financeiras, não apenas medidas liminares, custas judiciais e honorários advocatícios.

Para instituições financeiras especificamente, os litígios sobre acessibilidade na web no setor bancário continuam comuns: de acordo com o State of Digital Accessibility Report (SODAR), 57% dos profissionais de serviços financeiros relataram envolvimento em ações legais relacionadas à acessibilidade digital apenas no último ano. Acordos raramente são baratos. Os valores de acordos geralmente variam de US$ 5.000 a US$ 75.000, além de honorários advocatícios, custos de redesign e despesas de monitoramento. Quando esses custos são multiplicados por cartas de notificação, ações em tribunais estaduais e prazos obrigatórios de remediação, a exposição financeira cresce substancialmente.

O Department of Justice vem enfatizando cada vez mais a fiscalização da acessibilidade digital, deixando claro que serviços de banco on-line devem ser tão acessíveis quanto agências físicas, com novas diretrizes exigindo conformidade com WCAG 2.1 Nível AA para serviços digitais até abril de 2026. A futura regra do Título II para entidades governamentais estabelece um precedente que a fiscalização no setor privado provavelmente seguirá, e instituições financeiras com qualquer contrato governamental ou depósitos segurados federalmente fariam bem em tratar WCAG 2.1 AA como piso, não teto.

O European Accessibility Act: agora aplicável e mirando diretamente o setor bancário

Para instituições que operam na União Europeia ou atendem clientes no bloco, 2025 marcou um ponto de virada decisivo. O European Accessibility Act (Diretiva (UE) 2019/882) se aplica a partir de 28 de junho de 2025 em todos os Estados-Membros e busca eliminar barreiras para consumidores com deficiência, harmonizando requisitos de acessibilidade no mercado interno para determinados produtos, serviços e ambientes construídos. Não se trata de uma obrigação futura — desde 28 de junho de 2025, as organizações devem cumprir o EAA conforme transposto na legislação nacional de seu Estado-Membro, e a fiscalização está ativa, com reguladores atentos.

O EAA é incomumente explícito em sua cobertura de serviços financeiros. A partir de 28 de junho de 2025, empresas dentro do escopo precisam garantir que projetam seus sites, aplicativos móveis, contratos e todas as formas de comunicação com consumidores — incluindo serviços de call center, bem como dispositivos como terminais de pagamento e caixas eletrônicos — de forma acessível para pessoas com deficiência. A diretiva abrange “serviços bancários ao consumidor”, incluindo contratos de crédito, serviços de pagamento e determinados serviços de investimento; no entanto, negócios puramente de depósito não estão no escopo de “serviços bancários ao consumidor” sob este ato — apenas contas de pagamento e moeda eletrônica são cobertas.

O EAA exige que “operadores econômicos” de produtos e serviços dentro do escopo forneçam determinadas informações de forma acessível por meio do princípio dos dois sentidos, tornando sites e aplicativos móveis acessíveis ao torná-los perceptíveis, operáveis, compreensíveis e robustos. “Operadores econômicos” incluem prestadores de serviços financeiros, incluindo bancos, prestadores de serviços de pagamento e emissores de moeda eletrônica. A norma técnica que sustenta o EAA é a EN 301 549, que faz referência a requisitos de acessibilidade harmonizados por meio da EN 301 549, a norma europeia para acessibilidade em TIC que incorpora critérios WCAG 2.1 Nível AA para conteúdo e documentos digitais.

As penalidades por não conformidade são severas e variam por Estado-Membro. O descumprimento pode resultar em multas de até €100.000 ou 4% da receita anual, tornando a conformidade com o EAA uma prioridade crítica para qualquer empresa que atenda clientes na UE. Notavelmente, o EAA tem alcance extraterritorial: se sua empresa atende clientes na UE, você pode precisar cumprir a norma independentemente de onde esteja sediada, criando obrigações de conformidade dupla ao lado da ADA para empresas dos EUA.

Boa notícia para equipes de compliance: Tanto a ADA quanto o EAA convergem para a mesma base técnica. Ambas as leis compartilham a WCAG 2.1 Nível AA como base técnica, o que significa que um único programa bem executado de WCAG 2.1 AA atende simultaneamente aos requisitos centrais de ambos os frameworks.

WCAG no setor bancário: o que o padrão realmente exige

Espera-se que sites e aplicativos móveis de bancos estejam alinhados com as Web Content Accessibility Guidelines (WCAG) 2.1 Nível AA, e tribunais dos EUA frequentemente fazem referência à WCAG ao avaliar a conformidade com a ADA em serviços bancários digitais. A WCAG é organizada em torno de quatro princípios fundamentais — Perceptível (usuários devem ser capazes de perceber a informação, por exemplo, suporte a leitores de tela e texto alternativo), Operável (navegação e elementos de interface devem ser utilizáveis via teclado e tecnologias assistivas), Compreensível (conteúdo e interações devem ser previsíveis e fáceis de entender) e Robusto (sites devem funcionar com tecnologias assistivas atuais e futuras).

A versão mais recente, WCAG 2.2, introduz critérios de relevância particular para o setor bancário. A WCAG 2.2 introduziu Autenticação Acessível (Mínima), que visa facilitar o login para pessoas com deficiências cognitivas, evitando testes que dependam demais de memória, transcrição ou resolução de quebra-cabeças — isso é importante em aplicativos bancários porque muitas equipes continuam adicionando fricção em nome da segurança. Botões minúsculos, links muito próximos e itens de menu apertados tornam o aplicativo mais difícil de usar para pessoas com destreza limitada, e a WCAG 2.2 adicionou Tamanho do Alvo (Mínimo) no Nível AA, exigindo que alvos de ponteiro tenham pelo menos 24 por 24 pixels CSS, salvo exceções.

Plataformas bancárias enfrentam desafios únicos de WCAG devido às suas interfaces inerentemente complexas. Apesar das exigências legais, usuários com deficiência frequentemente encontram barreiras significativas ao acessar serviços bancários. Problemas como incompatibilidade com leitores de tela, formulários inacessíveis e tratamento de erros mal projetado podem tornar toda a experiência de banco on-line frustrante e inutilizável. Esses desafios surgem com frequência após a etapa inicial de login, já que muitos bancos têm focado em melhorar a acessibilidade de seus sites públicos, enquanto a experiência pós-login é frequentemente negligenciada.

O princípio se aplica de ponta a ponta. Um serviço bancário é tão acessível quanto seu elo mais fraco. Se uma única etapa falha, todo o processo falha — independentemente de quão bem as outras partes estejam implementadas. Para os bancos, isso tem implicações legais: um serviço só é considerado acessível se puder ser usado em sua totalidade, do início ao fim.

As falhas de acessibilidade mais comuns em plataformas financeiras

Saber onde os bancos falham de forma consistente é tão importante quanto saber o que as regras exigem. Entre os um milhão de principais home pages na internet, 95 por cento têm barreiras de acessibilidade que interferem na capacidade de pessoas com deficiência de usá-las, segundo um relatório de 2025 da WebAIM. Em serviços financeiros especificamente, certos padrões de falha aparecem com regularidade preocupante.

Aqui estão as categorias de falha mais críticas para plataformas bancárias e financeiras:

• Fluxos de login e autenticação inacessíveis. Muitas equipes continuam adicionando fricção em nome da segurança, como forçar usuários a copiar códigos de uso único entre aplicativos sem suporte a preenchimento automático, exigir lembrança complexa de caracteres de senhas parciais ou usar desafios de imagem ou quebra-cabeça sem opções acessíveis. Segurança e acessibilidade não são mutuamente exclusivas — suporte a gerenciadores de senhas e alternativas de CAPTCHA em áudio atendem a ambos os requisitos.
• Botões e ícones sem rótulo. Uma falha importante é a ausência ou fragilidade de rótulos: botões que exibem apenas um ícone podem se tornar sem sentido para um leitor de tela se não forem rotulados corretamente. Um botão de transferência que é renderizado apenas como uma seta visual se anuncia para um usuário de leitor de tela simplesmente como “button”, sem fornecer contexto algum.
• Tabelas de transação e dashboards inacessíveis. Bancos e serviços financeiros enfrentam desafios decorrentes de aplicativos complexos, interfaces de gestão de contas e requisitos de segurança, com um padrão comum sendo tabelas complexas sem cabeçalhos adequados, dados de conta mal estruturados e widgets de dashboard inacessíveis.
• Expiração de sessão sem aviso adequado. Bancos frequentemente limitam o tempo que um visitante pode permanecer em uma página por motivos de segurança. Ao interagir com páginas que têm limites de tempo, os visitantes precisam ser capazes de desativar ou, pelo menos, estender o limite de tempo. Deixar de fornecer isso é uma violação direta da WCAG 2.1 (SC 2.2.1).
• Documentos PDF inacessíveis. Clientes com deficiências motoras têm dificuldade em navegar em sites que não têm design amigável ao teclado, e documentos financeiros importantes, como extratos mensais, relatórios e cartas em formato PDF, muitas vezes não são projetados para leitores de tela, tornando difícil o acesso para clientes com deficiência visual.
• Baixo contraste de cor. Se um texto cinza estiver em um fundo claro, usuários podem não perceber o status de um pagamento ou um aviso de tarifa, e se os estados desabilitado e ativo parecerem quase iguais, as pessoas podem não saber qual ação está disponível.
• Assinaturas eletrônicas inacessíveis. Documentos on-line usados e disponibilizados por bancos às vezes exigem uma assinatura eletrônica. Devem ser oferecidas adaptações para que pessoas com deficiência possam assinar esses documentos, por exemplo, oferecendo métodos alternativos de assinatura, como um carimbo de assinatura ou software de reconhecimento de voz.

Construindo uma plataforma bancária acessível: um exemplo prático de código

Interfaces financeiras acessíveis exigem cuidado no nível do código. Um formulário de login é frequentemente a primeira coisa que uma pessoa com deficiência encontra, e define o tom de toda a experiência. Abaixo está um exemplo de formulário de login bancário devidamente estruturado e acessível, que usa HTML semântico, atributos ARIA e permite preenchimento automático por gerenciadores de senha:

<!-- Accessible bank login form -->
<form id='login-form' novalidate aria-labelledby='login-heading'>
  <h1 id='login-heading'>Sign In to Your Account</h1>

  <div class='form-group'>
    <label for='username'>Username or Account Number</label>
    <input
      type='text'
      id='username'
      name='username'
      autocomplete='username'
      aria-required='true'
      aria-describedby='username-hint'
    >
    <span id='username-hint' class='hint-text'>
      Enter the username you created at registration
    </span>
  </div>

  <div class='form-group'>
    <label for='password'>Password</label>
    <!-- Do NOT block paste — password managers must work -->
    <input
      type='password'
      id='password'
      name='password'
      autocomplete='current-password'
      aria-required='true'
    >
  </div>

  <!-- Accessible error region -->
  <div
    role='alert'
    aria-live='assertive'
    id='login-error'
    class='error-region'
    hidden
  >
    <!-- Errors injected here are announced immediately -->
  </div>

  <!-- Accessible CAPTCHA: audio option required -->
  <div class='captcha-wrapper'>
    <!-- Use accessible reCAPTCHA or SMS/email OTP instead of visual-only CAPTCHA -->
  </div>

  <button type='submit'>Sign In</button>

  <p>
    <a href='/forgot-password'>Forgot password?</a>
    <a href='/forgot-username'>Forgot username?</a>
  </p>
</form>

Padrões-chave demonstrados acima: cada campo de entrada tem um <label> explícito vinculado via for/id; atributos de autocomplete são definidos para que gerenciadores de senha e tecnologias assistivas possam pré-preencher campos; colar nunca é bloqueado; mensagens de erro usam role='alert' para que leitores de tela as anunciem imediatamente; e o CAPTCHA tem uma alternativa acessível. Esses padrões se aplicam igualmente a formulários de solicitação de empréstimo, telas de transferência de fundos e páginas de configurações de conta.

O problema dos fornecedores terceirizados

Uma das questões mais espinhosas na conformidade de acessibilidade bancária é a responsabilidade de fornecedores. Muitos bancos usam portais de banco on-line criados e operados por fornecedores terceirizados. Quando esses portais são inacessíveis, o banco — não o fornecedor — é a entidade que é processada. Os tribunais têm sido consistentes em afirmar que terceirizar uma função não terceiriza a responsabilidade legal.

O EAA é explícito nesse ponto. Empresas financeiras podem estar diretamente dentro do escopo do EAA, mas seus provedores e fornecedores a jusante de serviços e produtos dentro do escopo também podem ter obrigações sob o EAA, ou verão seus clientes de serviços financeiros repassar obrigações a eles por meio de contratos. Isso significa que equipes de compras precisam tornar a acessibilidade um critério de avaliação de fornecedores, não um pensamento tardio. Cada serviço terceirizado — gateways de pagamento, software de originação de empréstimos, módulos de autenticação de clientes, chatbots, mecanismos de geração de PDF — deve atender ao mesmo padrão WCAG que o código de primeira parte.

O princípio da jornada integrada é especialmente relevante aqui. Uma transação típica consiste em várias etapas consecutivas: login, autenticação, a própria transação e documentação. Essas etapas são interconectadas e frequentemente gerenciadas por diferentes sistemas subjacentes. O fator crítico não é se componentes individuais são acessíveis, mas se todo o fluxo de trabalho funciona. O EAA segue exatamente essa abordagem: a jornada do usuário é avaliada como um todo, e não em suas partes individuais.

Estratégia de conformidade: passando do reativo ao proativo

Muitas instituições financeiras ainda tratam a acessibilidade como um problema jurídico reativo — corrigem problemas apenas após receber uma carta de notificação. Essa abordagem é cada vez mais insustentável. Estima-se que entre 7 e 10 cartas de notificação privadas sejam enviadas para cada 1 ação ajuizada em tribunal. Essas cartas geralmente alertam que uma ação judicial será proposta a menos que o destinatário torne seus recursos digitais acessíveis. Quando uma queixa formal chega, a instituição já foi identificada como alvo.

Um programa proativo de acessibilidade em serviços financeiros deve incluir os seguintes elementos:

1. Auditoria de base em todas as propriedades digitais. Encomende uma auditoria combinando testes automatizados e manuais do seu site público, portal bancário autenticado, aplicativos móveis e PDFs críticos. Ferramentas automatizadas detectam cerca de 30–40% dos problemas de WCAG, portanto testes manuais com usuários reais de tecnologias assistivas são essenciais para revelar o restante.
2. Priorize primeiro os fluxos de transação centrais. Comece com as funções bancárias centrais — acesso à conta, transações e extratos — e depois amplie para serviços adicionais. Corrigir o formulário de login, a tabela de histórico de transações e a tela de transferência de fundos gera o maior impacto para usuários com necessidades mais críticas.
3. Incorpore acessibilidade no seu SDLC. Problemas de acessibilidade são uma ordem de grandeza mais baratos de corrigir durante o design e desenvolvimento do que após a implantação. Inclua critérios de aceitação de acessibilidade em cada user story e integre varredura automatizada ao seu pipeline de CI/CD para capturar regressões antes que cheguem à produção.
4. Avalie e contrate fornecedores com base em acessibilidade. Exija documentação VPAT (Voluntary Product Accessibility Template) de todos os fornecedores de tecnologia. Se você estiver trabalhando com o governo federal ou qualquer organização que receba recursos governamentais, precisará obter um VPAT para todas as suas propriedades digitais, seja seu site, aplicativo móvel ou portal do cliente.
5. Treine equipes de conteúdo e compliance. PDFs inacessíveis, texto alternativo mal escrito e campos de formulário sem rótulo são frequentemente criados por pessoal não técnico. Treinamentos regulares garantem que a acessibilidade não regrida por meio de atualizações de conteúdo rotineiras.
6. Mantenha monitoramento contínuo. O monitoramento contínuo detecta problemas antes que afetem clientes ou gerem reclamações. Implante varreduras automatizadas em uma cadência regular e configure alertas quando páginas recém-implantadas introduzirem regressões de acessibilidade.
7. Publique uma declaração de acessibilidade. Documente seu nível de conformidade, limitações conhecidas e um canal claro de feedback para usuários que encontrarem barreiras. Isso demonstra boa-fé e é explicitamente exigido pelo EAA.

O business case além da conformidade

As exigências de conformidade são convincentes por si só, mas o business case para bancos acessíveis vai além. 65% dos usuários mudariam de instituição financeira por melhores recursos de acessibilidade, mas apenas 48% estão satisfeitos com os recursos de acessibilidade de seu banco digital atual, o que representa tanto um desafio quanto uma oportunidade para instituições financeiras melhorarem seus serviços.

De acordo com o U.S. Centers for Disease Control and Prevention, 28,7% dos adultos — mais de um em cada quatro — nos Estados Unidos têm algum tipo de deficiência, o que se traduz em aproximadamente 70 milhões de adultos. Quando ativos digitais são inacessíveis, mais de um quarto dos consumidores dos EUA que poderiam ser clientes em potencial são excluídos do acesso a bens e serviços de uma empresa. Some-se a isso familiares e cuidadores que tomam decisões financeiras por pessoas com deficiência, e o impacto no mercado endereçável total é enorme.

O design acessível também melhora sistematicamente a usabilidade para todos. Rótulos claros em formulários, contraste de cor adequado e navegação lógica por teclado não são apenas adaptações para deficiência — são simplesmente bom design de interface. O design inclusivo ajuda a tornar serviços cotidianos mais fáceis de usar para pessoas com deficiência, e isso é particularmente importante para sites financeiros, onde usuários precisam acessar informações sensíveis e concluir transações com segurança e independência. Uma base de clientes envelhecida, usuários em dispositivos móveis sob luz solar intensa e qualquer pessoa usando o telefone com uma mão se beneficiam das mesmas escolhas de design que atendem usuários com deficiências permanentes.

O risco reputacional funciona nos dois sentidos. Um banco processado por não conformidade com a ADA pode sofrer danos reputacionais significativos, especialmente se a ação judicial atrair atenção da mídia. Por outro lado, instituições que lideram em acessibilidade constroem confiança e lealdade mensuráveis com clientes historicamente pouco atendidos pelos serviços financeiros.

Principais conclusões

• A pressão legal é real e está acelerando. As ações federais com base na ADA sobre acessibilidade de sites chegaram a 3.117 em 2025 — um aumento de 27% — enquanto o European Accessibility Act passou a ser aplicável em junho de 2025, com multas de até €100.000 ou 4% da receita anual. Instituições financeiras estão na mira de ambos os frameworks.
• WCAG 2.1 Nível AA é o padrão mínimo de fato em todos os lugares. Tribunais dos EUA a citam em acordos, o DOJ a exige para entidades do Título II, e a espinha dorsal técnica do EAA (EN 301 549) a incorpora diretamente. Mirar na WCAG 2.2 prepara você para o futuro próximo enquanto atende às exigências atuais.
• Toda a jornada do usuário deve ser acessível — não apenas a homepage. Portais bancários pós-login, fluxos de transação, extratos de conta, documentos em PDF e módulos de pagamento de terceiros têm a mesma exposição legal. Um serviço só é compatível se o fluxo de trabalho de ponta a ponta for utilizável por pessoas com deficiência.
• Contratos com fornecedores devem incluir obrigações de acessibilidade. A responsabilidade legal permanece com o banco quando um portal de terceiros falha em cumprir a WCAG. Replique os requisitos do EAA e da ADA para todos os fornecedores de tecnologia e exija documentação VPAT antes da implantação.
• A remediação proativa é materialmente mais barata do que a defesa reativa. Cartas de notificação, acordos, honorários advocatícios, contratos de monitoramento impostos por tribunais e custos de redesign superam de forma consistente o custo de construir produtos acessíveis desde o início. Integre acessibilidade agora ao seu SDLC e aos seus processos de compras.