guides
Acessibilidade da Banca Digital e o EAA
Os bancos e as instituições financeiras estão diretamente abrangidos pelo European Accessibility Act. Eis onde a banca digital mais frequentemente falha nos padrões de acessibilidade e por onde começar a corrigir.
Por que razão a banca e a acessibilidade se cruzam mal
A banca deveria proteger as pessoas. Gerir o seu dinheiro — consultar saldos, efetuar pagamentos, pedir empréstimos, rever extratos — é uma parte fundamental da vida financeira moderna. Quando as plataformas de banca digital são inacessíveis, as pessoas com maior probabilidade de serem excluídas são muitas vezes aquelas que têm menos alternativas.
Clientes idosos com perda de visão associada à idade que dependem de leitores de ecrã. Pessoas com deficiências motoras que não conseguem usar um rato. Clientes surdos que não conseguem recorrer ao apoio ao cliente por telefone e precisam de tratar de tudo online. Estes são utilizadores reais, presentes na base de clientes de qualquer banco, e o European Accessibility Act torna agora o seu acesso uma exigência legal.
A banca e os serviços financeiros são explicitamente nomeados no âmbito do EAA. O prazo de 28 de junho de 2025 aplicou-se aos serviços financeiros tal como se aplicou ao comércio eletrónico e às telecomunicações. Para os bancos, isto não é opcional.
As falhas de acessibilidade mais comuns na banca
Início de sessão e autenticação inacessíveis
Os fluxos de início de sessão são a porta de entrada para todos os serviços bancários e frequentemente apresentam problemas de acessibilidade:
- CAPTCHA sem alternativa em áudio, deixando os utilizadores cegos incapazes de passar a autenticação
- Fluxos de palavra-passe de utilização única (OTP) que dependem de SMS — alguns utilizadores com deficiências cognitivas têm dificuldade em gerir a autenticação em várias etapas sob pressão de tempo
- Tempos limite de sessão que não avisam os utilizadores antes de terminar uma sessão e que não podem ser prolongados — os utilizadores que demoram mais tempo a concluir tarefas (o que inclui muitos utilizadores com deficiência) veem-se repetidamente desconectados
O critério WCAG 2.1 2.2.1 Tempo Ajustável (Nível A) exige que os limites de tempo de sessão sejam ajustáveis ou prolongáveis.
Campos de formulário sem etiqueta e inacessíveis
A banca envolve muitos formulários: transferências de fundos, configuração de pagamentos, alterações de morada, pedidos de empréstimo. As mesmas falhas de acessibilidade de formulários que afetam qualquer website são particularmente onerosas na banca — um utilizador cego que não consiga preencher um formulário de pagamento não consegue aceder a um serviço bancário essencial.
A falha mais comum: campos de formulário sem elementos <label> corretamente associados. Sem uma etiqueta, os leitores de ecrã anunciam “editar texto, em branco” e o utilizador não sabe o que introduzir. Abordamos isto em detalhe no nosso guia sobre mensagens de erro acessíveis e aplica-se igualmente aos campos de formulário padrão.
Extratos e documentos PDF inacessíveis
Extratos mensais, termos e condições, contratos de empréstimo, documentos de informação de produtos — os bancos produzem volumes enormes de conteúdo em PDF, e quase todo ele é gerado a partir de sistemas que produzem PDFs inacessíveis.
Um PDF acessível tem uma estrutura marcada (tagged), uma ordem de leitura lógica, níveis de cabeçalho significativos e texto alternativo para quaisquer imagens que contenham informação. Um PDF exportado de um documento Word ou gerado por um motor de relatórios sem processamento de acessibilidade normalmente não tem nada disto. Para saber mais, consulte o nosso guia de acessibilidade de PDF.
Navegação por teclado deficiente nos fluxos de transação
Transferir fundos, configurar um beneficiário, consultar o histórico de transações — os fluxos complexos e de várias etapas que são comuns na banca contêm frequentemente componentes que só funcionam com um rato: menus pendentes que não respondem à entrada por teclado, seletores de data sem suporte de teclado, caixas de diálogo de confirmação que aprisionam o foco do teclado.
Aplicações móveis inacessíveis
O EAA abrange tanto as aplicações móveis como os websites. As aplicações bancárias, em particular, tendem a ter componentes nativos que se comportam de forma diferente dos elementos web, com camadas de acessibilidade que requerem trabalho explícito para serem implementadas corretamente.
As falhas comuns na banca móvel incluem: elementos interativos demasiado pequenos para tocar de forma fiável (o critério WCAG 2.5.5 Tamanho do Alvo, Nível AAA, sugere um mínimo de 44×44 pixels CSS), contraste insuficiente em temas de interface personalizados e barras de separadores ou padrões de navegação personalizados que não expõem o seu estado às APIs de acessibilidade.
Contraste insuficiente no design da interface
O design de interfaces bancárias tende frequentemente para o minimalismo e para o uso de cinzento claro sobre branco para informação secundária — números de conta, referências de transação, texto de apoio. Estes falham frequentemente o critério WCAG 1.4.3 Contraste Mínimo (Nível AA), que exige um rácio de 4,5:1 para texto normal.
O custo de confiança da inacessibilidade
A banca é uma relação de confiança. Quando um utilizador com deficiência não consegue aceder aos seus extratos de conta, não consegue configurar um débito direto de forma independente, ou é forçado a ligar para uma linha telefónica (que pode ela própria ter barreiras de acessibilidade) para concluir tarefas que os seus pares sem deficiência fazem online, a mensagem é clara: este serviço não foi concebido para si.
O custo reputacional dessa mensagem, num setor em que a confiança do cliente é fundamental, é significativo. O custo legal ao abrigo do EAA é cada vez mais concreto. E o custo prático — os clientes que discretamente mudam para um concorrente que funciona com a sua tecnologia de apoio — é mais difícil de medir, mas muito real.
Por onde começar
O EAA exige um padrão WCAG 2.1 Nível AA em todos os seus serviços digitais. Para a maioria dos bancos, alcançar isto em todos os pontos de contacto digitais em simultâneo não é viável — há demasiada superfície a cobrir. Dê prioridade pelo impacto no cliente:
Prioridade máxima:
- Fluxos de início de sessão e autenticação — se os clientes não conseguem entrar, nada mais importa
- Gestão essencial de conta: consultar saldo, consultar transações, transferir fundos
- Descarregamento de extratos e documentos PDF
Segunda prioridade:
- Configuração e gestão de pagamentos
- Fluxos de pedido de empréstimos e produtos
- Fluxos essenciais da aplicação móvel (correspondendo às prioridades da web)
Para cada área, execute tanto a análise automatizada (que deteta problemas de contraste, etiquetagem e estrutura) como testes manuais com tecnologia de apoio (que detetam falhas de navegação por teclado, problemas de gestão de foco e problemas de anúncio dos leitores de ecrã).
Execute uma análise gratuita do seu website bancário público para ver onde se encontra atualmente relativamente aos problemas automatizáveis. Para uma revisão abrangente dos fluxos bancários autenticados — onde vivem a maioria das falhas de acessibilidade complexas — fale com a nossa equipa sobre um programa de auditoria estruturado.
Teste a acessibilidade da sua plataforma bancária