Acessibilidade digital em softwares médicos: o que conferir

Rampa de acesso com corrimão verde

Prontuário eletrônico, portal do paciente, app de telessaúde, sistema de agendamento: quase todo o cuidado em saúde passa hoje por uma tela. Quando essa tela só funciona para quem enxerga bem, ouve bem e usa o mouse com precisão, parte dos pacientes e dos profissionais fica para trás. A Lei Brasileira de Inclusão define pessoa com deficiência como aquela que tem impedimento de longo prazo de natureza física, mental, intelectual ou sensorial, que, em interação com barreiras, pode obstruir sua participação plena na sociedade (Lei 13.146/2015). Um software mal desenhado é uma dessas barreiras.

O NEXO é um jogo diário de diagnóstico médico: um caso clínico por dia, seis pistas progressivas e feedback por proximidade na CID-10 em cinco níveis.

Este guia resume as normas abertas que orientam a acessibilidade digital, o que os estudos encontraram em sites, prontuários e apps de saúde e o que conferir antes de adotar ou desenvolver um sistema.

Principais pontos

  • A referência internacional é a WCAG, do W3C, organizada em quatro princípios e três níveis de conformidade.
  • No Brasil, a Lei Brasileira de Inclusão exige acessibilidade nos sites de empresas com sede ou representação no país e de órgãos de governo, e o eMAG orienta os sites do governo federal.
  • Estudos com sites, prontuários e apps de saúde encontram falhas repetidas: contraste baixo, links e botões sem nome, imagens sem texto alternativo e navegação por teclado incompleta.
  • Muitas falhas são encontradas com um teste curto: teclado, leitor de tela, ampliação e cor.
  • Envolver pessoas com deficiência desde o desenho do sistema é a recomendação mais constante das revisões.

Sumário

O que é acessibilidade digital em saúde

A Lei Brasileira de Inclusão define acessibilidade como a possibilidade e a condição de alcance, com segurança e autonomia, de espaços, transportes, informação e comunicação, incluindo seus sistemas e tecnologias, por pessoa com deficiência ou com mobilidade reduzida (Lei 13.146/2015). No software, isso quer dizer que cada função pode ser percebida, operada e entendida por quem usa leitor de tela, ampliação, teclado, comando de voz ou legendas.

A WCAG 2.2 diz que seguir suas recomendações deixa o conteúdo mais acessível para pessoas cegas ou com baixa visão, surdas ou com perda auditiva, com movimento limitado, com deficiência de fala ou fotossensibilidade, e em parte para pessoas com deficiência de aprendizagem ou limitações cognitivas (W3C, WCAG 2.2).

Rebaixamento de calçada em granito, com a guia de pedra descendo em rampa suave até o nível da rua, ao lado de uma grelha de escoamento.
A rampa na calçada foi feita para cadeiras de rodas e acabou servindo também a carrinhos, malas e bicicletas; na tela, o raciocínio é o mesmo. Crédito: Nick-philly, CC BY-SA 4.0 (licença), via Wikimedia Commons (página do arquivo).

Quem depende de um software acessível

Leitura editorial: no ambiente de saúde, a acessibilidade atende ao menos três grupos. Os pacientes, que marcam consultas, leem resultados e falam com a equipe por portais e apps. Os profissionais com deficiência, que precisam registrar, prescrever e consultar o prontuário com a mesma segurança dos colegas. E qualquer pessoa numa situação temporária, como um braço imobilizado, uma tela pequena no plantão ou um ambiente barulhento.

As normas de referência: WCAG, Lei Brasileira de Inclusão e eMAG

WCAG 2.2, do W3C

A WCAG (Web Content Accessibility Guidelines) é a recomendação do W3C para conteúdo web acessível; a versão 2.2 publicada traz a data de 12 de dezembro de 2024 (W3C, WCAG 2.2). As recomendações se organizam em quatro princípios (W3C, WCAG 2.2):

  1. Perceptível: a informação e os componentes da interface precisam ser apresentados de forma que o usuário consiga perceber.
  2. Operável: os componentes e a navegação precisam poder ser operados.
  3. Compreensível: a informação e a operação da interface precisam ser compreensíveis.
  4. Compatível: o conteúdo precisa ser interpretado por uma ampla variedade de programas, inclusive as tecnologias assistivas.

Cada critério de sucesso tem um nível: A (o mínimo), AA e AAA (o mais alto), e o nível AA exige cumprir todos os critérios A e AA (W3C, WCAG 2.2).

WCAG para software que roda fora da web

Prontuários instalados no computador e apps nativos ficam fora do escopo direto da WCAG. Para eles, o W3C publicou a WCAG2ICT, uma nota que explica como aplicar os princípios, diretrizes e critérios das versões 2.0, 2.1 e 2.2 a documentos e softwares que não são web; o texto é orientação informativa, e não norma (W3C, WCAG2ICT).

Lei Brasileira de Inclusão (Lei 13.146/2015)

O artigo 63 da lei torna obrigatória a acessibilidade nos sítios da internet mantidos por empresas com sede ou representação comercial no país ou por órgãos de governo, conforme as melhores práticas e diretrizes de acessibilidade adotadas internacionalmente, e pede que os sítios exibam símbolo de acessibilidade em destaque (Lei 13.146/2015). A definição de acessibilidade do artigo 3º inclui a informação, a comunicação e seus sistemas e tecnologias (Lei 13.146/2015).

eMAG, o modelo do governo federal

O eMAG (Modelo de Acessibilidade em Governo Eletrônico) está na versão 3.1, de abril de 2014, e se apresenta como uma versão especializada da WCAG voltada ao governo brasileiro (eMAG). A Portaria nº 3, de 7 de maio de 2007, tornou sua observância obrigatória nos sítios e portais do governo brasileiro (eMAG). Diferente da WCAG, o eMAG agrupa suas 45 recomendações por área (marcação, comportamento, conteúdo, apresentação, multimídia e formulário), e não por nível de prioridade (eMAG).

Comparação rápida

Norma Quem publica A que se aplica
WCAG 2.2 W3C (WCAG 2.2) Conteúdo web, com níveis A, AA e AAA
WCAG2ICT W3C (WCAG2ICT) Orientação para documentos e softwares fora da web
Lei 13.146/2015, art. 63 Presidência da República (Planalto) Sítios de empresas com sede ou representação no país e de órgãos de governo
eMAG 3.1 Governo federal (eMAG) Sítios e portais do governo brasileiro

Fonte da tabela: páginas oficiais citadas em cada linha, abertas em 11/10/2026.

Onde os softwares de saúde falham, segundo os estudos

Sites de saúde

Numa amostra de 139 sites de saúde entre os mais acessados do mundo, 91,3% das páginas iniciais tinham falhas de acessibilidade detectáveis, e as mais comuns foram contraste baixo, links vazios, imagens sem texto alternativo, botões vazios e campos de formulário sem rótulo (Mason et al., 2021).

Num estudo australiano com 185 páginas de serviços que atendem pessoas depois de um AVC, 81,1% tinham ao menos um erro pela WCAG, e o mais frequente, em 49,7% das páginas, foi o link vazio, que o leitor de tela é incapaz de anunciar (Giummarra et al., 2025). Só 17 sites publicavam uma declaração de acessibilidade, e os sites de órgãos de governo tiveram menos problemas do que os do setor privado (Giummarra et al., 2025).

Na pandemia, uma avaliação automática de 54 sites oficiais de agendamento da vacina contra a covid-19 nos Estados Unidos encontrou cumprimento abaixo do esperado das versões 2.0 e 2.1 da WCAG (Alismail e Chipidza, 2021).

Prontuário eletrônico

Um estudo testou três prontuários eletrônicos de código aberto com testes automáticos e manuais e com três leitores de tela (JAWS, NVDA e VoiceOver). Os três sistemas eram só parcialmente acessíveis, e os principais pontos a melhorar foram a navegação por teclado e a compatibilidade com leitor de tela (Moncy et al., 2023).

Apps de saúde

Num piloto com três apps de controle de peso bem avaliados nas lojas, nove pessoas com deficiência visual, de destreza ou cognitiva testaram cada app; as pessoas com deficiência visual deram as notas de acessibilidade mais baixas e relataram mais dificuldades (Radcliffe et al., 2021).

Como os serviços digitais de saúde são desenvolvidos

Uma revisão de escopo sobre serviços de saúde digital incluiu 15 publicações, das quais 2 definiam acessibilidade e 5 usaram a WCAG para avaliá-la (Jonsson et al., 2023). Outra revisão, com 25 fontes, concluiu que as necessidades variam conforme o tipo de deficiência e que o desenho participativo, com pessoas com deficiência desde a fase de ideia, leva a soluções mais acessíveis (Henni et al., 2022).

Uma revisão de escopo publicada em 2026 reuniu 80 documentos e apontou o desenho acessível, o codesenho com os usuários e as normas internacionais de acessibilidade como os fatores que mais favorecem uma saúde digital equitativa (Umucu et al., 2026).

O prontuário também pode registrar necessidades de acessibilidade

Num ambulatório de oftalmologia, um questionário no prontuário eletrônico perguntava, no agendamento, se o paciente precisava de algum apoio de acessibilidade; de 250.932 atendimentos, 9,4% tiveram algum pedido, mais frequentemente de mobilidade (Varadaraj et al., 2022). Os autores consideram que esse registro padronizado pode ser levado a outros serviços (Varadaraj et al., 2022).

Como ler esses estudos

Pergunta O que os estudos acima permitem dizer
As falhas são comuns? Sim, em sites de saúde de vários países, com maioria de páginas com ao menos um erro
Quais falhas aparecem mais? Contraste baixo, links e botões sem nome, imagens sem texto alternativo, formulários sem rótulo
E o prontuário? Num teste com três sistemas de código aberto, a acessibilidade foi parcial
O que ajuda? Desenho participativo, normas internacionais e testes com leitor de tela

Fonte da tabela: síntese do Editorial a partir de Mason et al., 2021, Giummarra et al., 2025, Moncy et al., 2023, Henni et al., 2022 e Umucu et al., 2026.

Duas maçanetas pretas do tipo alavanca numa porta dupla, diante de uma cortina clara de listras horizontais.
A maçaneta de alavanca abre com o cotovelo, com a mão cheia ou com pouca força; um bom software também oferece mais de um jeito de chegar ao mesmo lugar. Crédito: marya from San Luis Obispo, USA, CC BY 2.0 (licença), via Wikimedia Commons (página do arquivo).

O que conferir num software médico

Os critérios abaixo vêm da WCAG 2.2 e cobrem as falhas que mais aparecem nos estudos. A coluna de exemplo é leitura editorial.

Critérios essenciais

Critério da WCAG 2.2 O que pede Exemplo em saúde
1.1.1 Conteúdo não textual (A) Alternativa em texto para todo conteúdo não textual (WCAG 2.2) Ícone de alergia com nome lido pelo leitor de tela
1.4.1 Uso de cor (A) A cor nunca é o único meio de passar uma informação (WCAG 2.2) Resultado crítico em vermelho e também com a palavra "crítico"
1.4.3 Contraste mínimo (AA) Contraste de pelo menos 4,5:1 para texto comum (WCAG 2.2) Texto cinza-claro em fundo branco reprova
1.4.4 Redimensionar texto (AA) Texto ampliável até 200% sem perda de conteúdo ou função (WCAG 2.2) A prescrição continua legível com zoom
2.1.1 Teclado (A) Toda função operável pelo teclado (WCAG 2.2) Assinar e enviar a receita usando só o teclado
2.4.11 Foco não encoberto (AA) O item com foco do teclado fica visível, ao menos em parte (WCAG 2.2) Barra fixa do prontuário cobrindo o campo em edição reprova
2.5.8 Tamanho do alvo (AA) Alvos de toque ou clique com pelo menos 24 por 24 pixels CSS, com exceções (WCAG 2.2) Botões de dose pequenos e colados uns nos outros reprovam
4.1.3 Mensagens de status (AA) Mensagens de status anunciadas pela tecnologia assistiva sem mudar o foco (WCAG 2.2) "Prescrição salva" anunciada ao leitor de tela

Fonte da tabela: critérios da WCAG 2.2 citados em cada linha; exemplos do Editorial.

A WCAG também tem um critério de nível AAA que pede que animações disparadas por interação possam ser desligadas, salvo quando forem essenciais (W3C, WCAG 2.2).

Um teste rápido antes de adotar um sistema

Sugestão prática do Editorial, para quem avalia um software antes de comprar ou implantar:

  1. Desconecte o mouse e tente fazer a tarefa principal, como abrir um paciente, registrar uma evolução e salvar, só com o teclado.
  2. Ligue o leitor de tela do sistema operacional e confira se botões, campos e alertas são anunciados com nome.
  3. Amplie a tela para o dobro e veja se algo some, se sobrepõe ou exige rolagem lateral.
  4. Veja a tela em tons de cinza e confira se alertas e status continuam claros.
  5. Peça ao fornecedor a declaração de acessibilidade e o relatório de conformidade com a WCAG.
  6. Teste com quem vai usar, incluindo profissionais e pacientes com deficiência.

Para quem desenvolve ou compra

  • Teste cedo e com pessoas. Os testes automáticos encontram parte das falhas; a combinação com testes manuais e leitores de tela foi o método do estudo com prontuários (Moncy et al., 2023).
  • Defina o que é acessível. A revisão sobre serviços de saúde digital encontrou poucas publicações com definição clara de acessibilidade (Jonsson et al., 2023).
  • Publique uma declaração de acessibilidade com o nível buscado e um canal para relatar barreiras.
  • Registre as necessidades do paciente no próprio prontuário, como no questionário do ambulatório de oftalmologia (Varadaraj et al., 2022).

Acessibilidade no NEXO

O NEXO publica uma declaração de acessibilidade em que diz buscar o nível AA da WCAG 2.1 e lista recursos do site: estrutura semântica com hierarquia de títulos, contraste mínimo para texto comum, layout que se adapta ao tamanho da tela e ao zoom, texto alternativo nas imagens com significado e mídia que só toca quando a pessoa pede. A mesma página traz um e-mail para relatar barreiras de acessibilidade.

No jogo, cada palpite mostra o nível de proximidade com cor, ícone e o nome do nível escrito, e as animações respeitam a preferência de reduzir movimento do sistema operacional.

Como o jogo funciona

No NEXO, cada caso chega em até seis pistas, uma de cada vez, e você dá o palpite pelo nome do diagnóstico ou pelo código da CID-10. A cada palpite errado, o jogo mostra a proximidade em cinco níveis, do capítulo diferente ao CID exato, e abre a próxima pista.

O Diário traz um caso por dia, igual para todos, e o Arquivo reúne os casos diários anteriores. O Multimídia traz imagem, áudio e outros exames, e o Continentes muda a epidemiologia de fundo. O Adrenalina acrescenta tempo. Como cada modo é liberado está na página de economia do NEXO.

Guardar, discutir e participar

O botão do Anki cria o card direto do NEXO e abre no app do Anki, busca os cards que você já tem e, quando o caso tem imagem, leva a imagem para o card. A aba Grupo do ranking, que reúne colegas convidados, permite comparar em que pista cada um acertou. Médicos generalistas ou especialistas com registro ativo podem revisar casos da sua área pelo NEXO Curator. Se você coordena uma residência, uma liga ou uma faculdade, conheça o NEXO Closer; pesquisadores em acessibilidade e educação médica podem propor estudos pelo NEXO Researcher, e quem produz conteúdo de medicina pode conhecer o NEXO Creators.

Perguntas frequentes

O que é acessibilidade digital em softwares médicos?

É a condição de um sistema de saúde, como prontuário, portal ou app, poder ser percebido, operado e entendido por pessoas com deficiência, inclusive com tecnologias assistivas. A referência internacional é a WCAG, do W3C (W3C, WCAG 2.2).

A lei brasileira exige acessibilidade em sites de saúde?

O artigo 63 da Lei Brasileira de Inclusão exige acessibilidade nos sítios da internet de empresas com sede ou representação comercial no país e de órgãos de governo (Lei 13.146/2015). Para dúvidas sobre um caso específico, consulte a assessoria jurídica da sua instituição.

Qual nível da WCAG um software de saúde deve buscar?

O nível AA é o mais citado como meta, inclusive em estudos que avaliam sites de saúde, e exige cumprir todos os critérios A e AA (W3C, WCAG 2.2).

A WCAG vale para prontuário instalado no computador?

A WCAG trata de conteúdo web. Para softwares fora da web, o W3C publicou a WCAG2ICT, que explica como aplicar os mesmos critérios (W3C, WCAG2ICT).

Qual a diferença entre eMAG e WCAG?

O eMAG é uma versão especializada da WCAG para o governo brasileiro e agrupa as recomendações por área, e não por nível (eMAG).

O NEXO é acessível?

O NEXO publica uma declaração de acessibilidade com meta de nível AA da WCAG 2.1 e um canal para relatar barreiras. Para conhecer o jogo, leia o que é o NEXO.

Checklist de acessibilidade para softwares médicos

  1. Toda imagem e todo ícone com alternativa em texto.
  2. Informação passada por cor também passada por texto ou ícone.
  3. Contraste suficiente entre texto e fundo.
  4. Texto que amplia sem quebrar a tela.
  5. Tarefas completas pelo teclado, com foco sempre visível.
  6. Botões grandes o bastante e com espaço entre eles.
  7. Alertas e confirmações anunciados ao leitor de tela.
  8. Animações que podem ser reduzidas.
  9. Declaração de acessibilidade publicada, com canal de contato.
  10. Testes com pessoas com deficiência antes e depois de cada mudança grande.

Quer treinar diagnóstico com um caso curto por dia? Jogue o caso do dia no NEXO.

Referências

  1. Mason AM, Compton J, Bhati S. Disabilities and the Digital Divide: Assessing Web Accessibility, Readability, and Mobility of Popular Health Websites. J Health Commun. 2021. https://pubmed.ncbi.nlm.nih.gov/34657585/
  2. Giummarra MJ, Brown E, Rose TA, et al. How accessible are the websites of health services for people who have had a stroke? Int J Equity Health. 2025. https://pubmed.ncbi.nlm.nih.gov/40275299/
  3. Alismail S, Chipidza W. Accessibility evaluation of COVID-19 vaccine registration websites across the United States. J Am Med Inform Assoc. 2021. https://pubmed.ncbi.nlm.nih.gov/33993310/
  4. Moncy MM, Pilli M, Somasundaram M, et al. Evaluation of accessibility of open-source EHRs for visually impaired users. AMIA Annu Symp Proc. 2023. https://pubmed.ncbi.nlm.nih.gov/38222344/
  5. Radcliffe E, Lippincott B, Anderson R, Jones M. A Pilot Evaluation of mHealth App Accessibility for Three Top-Rated Weight Management Apps by People with Disabilities. Int J Environ Res Public Health. 2021. https://pubmed.ncbi.nlm.nih.gov/33915917/
  6. Jonsson M, Johansson S, Hussain D, et al. Development and Evaluation of eHealth Services Regarding Accessibility: Scoping Literature Review. J Med Internet Res. 2023. https://pubmed.ncbi.nlm.nih.gov/37590050/
  7. Henni SH, Maurud S, Fuglerud KS, Moen A. The experiences, needs and barriers of people with impairments related to usability and accessibility of digital health solutions, levels of involvement in the design process and strategies for participatory and universal design: a scoping review. BMC Public Health. 2022. https://pubmed.ncbi.nlm.nih.gov/34991540/
  8. Varadaraj V, Guo X, Reed NS, et al. Identifying Accessibility Requests for Patients With Disabilities Through an Electronic Health Record-Based Questionnaire. JAMA Netw Open. 2022. https://pubmed.ncbi.nlm.nih.gov/35394512/
  9. Umucu E, Lee B, Vernon A, et al. Inclusive Digital Health Strategies for Persons With Disabilities: A Scoping Review. JAMA Netw Open. 2026. https://pubmed.ncbi.nlm.nih.gov/42742940/

Páginas oficiais consultadas

  1. W3C. Web Content Accessibility Guidelines (WCAG) 2.2, acessada em 11/10/2026. https://www.w3.org/TR/WCAG22/
  2. W3C. Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT), acessada em 11/10/2026. https://www.w3.org/TR/wcag2ict-22/
  3. Brasil. Lei nº 13.146, de 6 de julho de 2015 (Lei Brasileira de Inclusão da Pessoa com Deficiência), acessada em 11/10/2026. https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2015/lei/l13146.htm
  4. Governo federal. eMAG, Modelo de Acessibilidade em Governo Eletrônico, versão 3.1, acessada em 11/10/2026. https://emag.governoeletronico.gov.br/
  5. NEXO. Accessibility Statement, acessada em 11/10/2026. https://nexo.wiki.br/accessibility

Voltar ao blog

Acessibilidade digital em softwares médicos: o que conferir