Acessibilidade em Sistemas de Saúde: WCAG e Inclusão no PEP
Como garantir acessibilidade em prontuários eletrônicos para profissionais e pacientes com deficiência visual, motora ou cognitiva.
# Acessibilidade em Sistemas de Saúde: WCAG e Inclusão no PEP
Quando falamos em tecnologia na saúde, raramente discutimos acessibilidade. Porém, profissionais de saúde com deficiência visual, motora ou cognitiva utilizam esses sistemas diariamente. Pacientes acessam portais e aplicativos. A acessibilidade não é um diferencial — é uma obrigação ética e, em muitos contextos, legal.
O cenário atual
A maioria dos sistemas de prontuário eletrônico foi desenvolvida sem considerar acessibilidade desde o início. Interfaces repletas de ícones sem descrição textual, formulários que não funcionam com teclado, cores sem contraste adequado e fluxos que dependem exclusivamente de cliques precisos com mouse.
Na prática: Sistemas de saúde acessíveis não são diferencial — são obrigação legal e ética. Profissionais com deficiência e pacientes em portais devem ter experiência equivalente.
Para um médico com baixa visão ou um enfermeiro com mobilidade reduzida nas mãos, essas barreiras transformam o trabalho diário em um exercício de frustração.
WCAG: o padrão internacional
As Web Content Accessibility Guidelines (WCAG), mantidas pelo W3C, são o padrão internacional para acessibilidade digital. A versão 2.1, com nível AA, é o mínimo recomendado para sistemas de saúde.
Os quatro princípios WCAG
Perceptível — A informação deve ser apresentável de formas que o usuário possa perceber. Isso inclui alternativas textuais para imagens, legendas para áudio e contraste adequado.
Operável — A interface deve ser navegável por diferentes mecanismos de entrada: teclado, voz, dispositivos adaptativos. Nenhuma funcionalidade pode depender exclusivamente do mouse.
Compreensível — O conteúdo e a operação devem ser entendíveis. Linguagem clara, comportamento previsível, ajuda contextual.
Robusto — O conteúdo deve ser interpretável por diferentes tecnologias assistivas, incluindo leitores de tela atuais e futuros.
Deficiência visual e prontuários eletrônicos
Baixa visão
Profissionais com baixa visão precisam de:
- Contraste mínimo de 4.5:1 para texto normal e 3:1 para texto grande
- Possibilidade de aumentar fonte sem quebra de layout
- Indicadores que não dependam apenas de cor (verde/vermelho para normal/alterado)
- Modo escuro ou alto contraste como opção
Cegueira total
Para usuários de leitores de tela (JAWS, NVDA, VoiceOver):
- Todos os elementos interativos devem ter labels acessíveis
- Tabelas precisam de cabeçalhos marcados semanticamente
- Formulários devem ter associação correta entre label e campo
- Alertas e notificações precisam ser anunciados via ARIA live regions
- A ordem de leitura deve fazer sentido lógico
Impacto prático
Imagine um farmacêutico cego validando uma prescrição. Ele precisa que o leitor de tela anuncie claramente: medicamento, dose, via, frequência, alergias do paciente e interações. Se essas informações estão em uma tabela sem marcação semântica ou em imagens sem texto alternativo, a validação segura é impossível.
Deficiência motora e navegação por teclado
Navegação completa por teclado
Todo o fluxo de trabalho no PEP deve ser executável sem mouse:
- Tab para navegar entre elementos
- Enter/Space para ativar botões
- Setas para navegar em menus e listas
- Atalhos de teclado para ações frequentes
- Indicador visual claro do foco atual
Controle por voz
Profissionais com limitação severa nos membros superiores podem utilizar software de reconhecimento de voz (Dragon NaturallySpeaking, Voice Access). O sistema precisa ter elementos nomeáveis e previsíveis para que comandos de voz funcionem.
Tempo de interação
Sessões não devem expirar rapidamente sem aviso. Ações que exigem precisão de clique (como arrastar e soltar) devem ter alternativas acessíveis.
Deficiência cognitiva e design inclusivo
Linguagem clara
- Evitar jargões desnecessários em interfaces voltadas ao paciente
- Instruções objetivas e curtas
- Feedback imediato sobre ações realizadas
Consistência de layout
- Elementos de navegação sempre na mesma posição
- Padrões visuais repetidos entre telas similares
- Redução de carga cognitiva com agrupamento lógico de informações
Prevenção de erros
- Confirmações antes de ações irreversíveis
- Possibilidade de desfazer ações recentes
- Mensagens de erro claras com indicação de como corrigir
Acessibilidade para pacientes
Portais do paciente
Quando o paciente acessa seus exames, agendamentos ou prontuário resumido, a interface deve ser acessível para:
- Idosos com pouca familiaridade tecnológica
- Pessoas com deficiência visual usando leitores de tela
- Pacientes com tremores ou limitações motoras
- Pessoas com dificuldade de leitura
Consentimentos e termos
Documentos como termos de consentimento e LGPD precisam ser legíveis por tecnologias assistivas. PDFs de imagem (escaneados) são barreiras absolutas.
Implementação prática
Auditoria de acessibilidade
O primeiro passo é uma auditoria completa do sistema existente:
- Testes automatizados (axe, Lighthouse, WAVE)
- Testes manuais de navegação por teclado
- Testes com leitores de tela reais
- Avaliação por usuários com deficiência
Priorização de correções
Nem tudo precisa ser corrigido simultaneamente. Priorize:
- Fluxos críticos (prescrição, evolução, alertas)
- Barreiras que impedem completamente o uso
- Conformidade com contraste e navegação por teclado
- Labels e ARIA para leitores de tela
Design system acessível
Criar um design system com componentes nativamente acessíveis evita que cada nova funcionalidade precise ser corrigida depois. Botões, formulários, tabelas, modais — todos com acessibilidade embutida.
Legislação brasileira
A Lei Brasileira de Inclusão (Lei 13.146/2015) determina que sistemas e páginas web de empresas e órgãos públicos devem ser acessíveis. O Decreto 5.296/2004 regulamenta a acessibilidade digital. Embora a fiscalização ainda seja limitada, a tendência é de aumento da cobrança.
O argumento além da obrigação
Acessibilidade beneficia todos. Contraste adequado ajuda em ambientes com muita luz. Navegação por teclado acelera profissionais experientes. Linguagem clara reduz erros de interpretação. Componentes bem estruturados facilitam manutenção do código.
Perguntas Frequentes
Como integrar o prontuário com outros sistemas do hospital?
A integração pode ser feita por padrões como FHIR (APIs RESTful modernas), HL7 v2 (mensageria tradicional) ou integrações proprietárias. A escolha depende dos sistemas envolvidos. FHIR é preferível para novas integrações por sua simplicidade e comunidade ativa. Cada integração exige testes extensivos antes de produção.
O que é uma API de saúde e por que é importante?
API (Application Programming Interface) é o mecanismo que permite que sistemas diferentes troquem dados automaticamente. Em saúde, APIs permitem que prontuário, laboratório, farmácia, imagem e faturamento conversem sem intervenção manual. Padrões como FHIR definem como essas APIs devem funcionar para garantir interoperabilidade.
Integrações proprietárias criam dependência de fornecedor?
Sim. Integrações em formatos proprietários dificultam a substituição de sistemas e aumentam o custo de manutenção. A adoção de padrões abertos (FHIR, openEHR) para novas integrações protege o investimento institucional e facilita a evolução tecnológica sem lock-in. A portabilidade de dados deve ser cláusula contratual.
Conclusão
A acessibilidade em sistemas de saúde não é um recurso opcional ou uma funcionalidade de nicho. É uma responsabilidade de quem desenvolve, contrata e implementa essas ferramentas. Profissionais de saúde com deficiência têm direito a exercer sua profissão com ferramentas que não os excluam. Pacientes com deficiência têm direito a acessar suas informações de saúde com autonomia. Construir sistemas acessíveis desde o início custa menos do que remediar depois — e é simplesmente o correto a se fazer.