Fluxo do caso com leitor de tela: pistas e hipóteses

Você abre o caso do dia com o leitor de tela ligado. O enunciado anuncia idade e queixa. Em seguida o foco salta para um botão sem nome, depois para um gráfico decorativo, e a "pista 1" só existe como cor no canto. Você formula uma hipótese, mas o campo de busca diz apenas "editar". O feedback de proximidade pisca em verde sem palavra. O fechamento existe na tela e some na fala. Este texto percorre o fluxo do caso jogável com leitor de tela: pistas (até seis), hipóteses, submissão, proximidade, fechamento e o que a interface precisa anunciar e ordenar em cada etapa. Diferencia-se do catálogo de tecnologia assistiva visual (produtos e leitores) e do mapa WCAG em acessibilidade digital em softwares médicos. Aqui o objeto é o passeio pedagógico pelo caso, não a lista de softwares.

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.

Nada neste artigo afirma eficácia do NEXO. Descrevemos princípios de desenho, critérios públicos (W3C, orientações de jogos acessíveis) e recursos conferidos na declaração de acessibilidade. Casos fictícios com apresentação clínica real, com até seis pistas, só ensinam se cada etapa do fluxo for legível na API de acessibilidade, não só no layout visual.

Principais pontos

• O fluxo do caso tem etapas estáveis: abertura, pista, hipótese, submissão, proximidade, próxima pista ou fechamento; o leitor de tela precisa de nomes, ordem e landmarks em cada uma.
• Ordem de foco no DOM deve seguir a sequência pedagógica, não o acaso do CSS; critério 2.4.3 da WCAG trata exatamente disso.
• Pistas progressivas (até seis) pedem rótulo com número e conteúdo em texto real; revelar só por animação ou cor falha na fala e no braille.
• Campos de hipótese e botões de envio precisam de nome acessível que descreva a ação; "editar" e "OK" não bastam.
• Proximidade e fechamento exigem palavra além de cor; o detalhe da explicação longa depois do fechamento é outro momento do ciclo (ver feedback útil e a declaração pública).
• No NEXO, a página /accessibility descreve rótulos em pistas e feedback, HTML semântico e independência de cor na proximidade; sem afirmação de resultado de aprendizagem. Limites de uso, quando relevantes, estão em /economia.

Mapa do fluxo: da abertura ao fechamento

Em um jogo diário de diagnóstico, o caso não é uma página estática. É um percurso: você lê o contexto, recebe pistas sob demanda, propõe hipóteses, recebe proximidade e, ao acertar ou esgotar tentativas, chega ao fechamento. Aprendizagem baseada em casos organiza esse ciclo em torno de um problema clínico concreto (como funciona). Treinar diferencial com pistas progressivas reforça o peso de cada achado (treinar com pistas). Com leitor de tela, o mesmo percurso só funciona se cada mudança de estado for nomeada e focável.

Quase 6% dos estudantes de medicina nos Estados Unidos declararam deficiência em 2021, mais que o dobro de 2015, e pedem acomodações que incluem acesso digital (Huth et al., 2025; prevalência e acomodações: Meeks et al., 2020). Em cursos online de ciências, mais da metade dos estudantes com deficiência relatou acomodação inadequada após a migração digital; recomendações de inclusão precisam ser universais, não só individuais (Gin et al., 2022). Conteúdo interativo testado com leitor de tela mostra que muitos tipos de atividade "funcionam" só em parte e pedem alternativa explícita (Böhm e Lux, 2025). Recursos digitais para deficiência visual pedem descrição por leitor, navegação por teclado e aderência a diretrizes W3C (Almeida et al., 2020).

Imagine um caso fictício com apresentação clínica real: adulto jovem com dor torácica e dispneia há algumas horas, até seis pistas. A pista 1 fala de início súbito; a pista 2 de saturação; a pista 3 de achado de exame. Você sobe e desce hipóteses (embolia, síndrome coronariana, pneumotórax, ansiedade). Cada passo precisa existir na árvore de acessibilidade: não basta aparecer no retângulo da tela.

Orientações de jogos acessíveis pedem estrutura previsível, landmarks significativos, indicadores de progresso e suporte a leitor de tela em menus e jogabilidade (Game Accessibility Guidelines). A WCAG trata ordem de foco, nomes, relacionamentos e mudanças de status (W3C, Focus Order 2.4.3; Info and Relationships 1.3.1). O mapa mental do fluxo, para quem ouve a interface, é:

• Onde estou (título do caso, número da pista, estado "em andamento" ou "fechado").
• O que posso fazer agora (revelar pista, editar hipótese, enviar, relatar problema).
• O que acabou de mudar (nova pista, proximidade, acerto, erro de rede).
• Para onde ir depois (explicação, próximo caso, sair).

Carga cognitiva no ensino em saúde já pede reduzir ruído e preservar memória de trabalho para o que ensina (van Merriënboer e Sweller, 2010; Mayer, 2010). Caçar o botão sem nome ou ouvir "gráfico" no lugar da pista é ruído puro. Dialoga com metacognição: você só monitora o próprio raciocínio se a interface não consumir toda a atenção.

Na prática, trate o fluxo como um protocolo mental de beira de leito: anamnese (enunciado), exame (pistas), hipóteses, teste (submissão), resultado (proximidade) e plano (explicação). Quem preceptor observa o raciocínio em voz alta faz algo parecido. O leitor de tela é essa voz alta automática: se o protocolo não estiver nomeado na interface, a apresentação do caso para si mesmo quebra no meio. Por isso landmarks e headings não são detalhe de engenharia; são a espinha do raciocínio clínico no meio digital.

Antes da primeira pista: página, landmarks e foco

Antes de qualquer pista, o leitor monta o mapa da tela. Landmarks (main, navigation, complementary) e um heading de nível 1 com o título do caso permitem pular o chrome do app. Skip link para o conteúdo principal evita Tab eterno pelo menu. Se o título da aba do navegador for genérico ("App"), a lista de janelas não ajuda quem troca de tarefa no plantão.

Ordem de foco inicial importa. Ao abrir o caso, o foco deve cair no heading ou no primeiro bloco de enunciado, não em um banner promocional nem em um modal esquecido. Elementos focáveis escondidos visualmente, mas ainda no Tab, criam "buracos" silenciosos. A WCAG exige que a sequência preserve significado e operação (Focus Order). Em jogos e simulações web, estrutura consistente e descrição de contexto orientam quem não vê a cena (Floe, Web Games and Simulations).

Teclado é o companheiro do leitor: Tab, Shift+Tab, Enter, Espaço e setas. Foco visível precisa existir para quem enxerga parcialmente e para quem ensina olhando a tela alheia. O post de acessibilidade digital situa teclado e nomes no software clínico; aqui o foco é a sequência do caso jogável.

Teste rápido de cinco minutos na abertura:

• Liste headings: o título do caso aparece?
• Liste landmarks: há um main com o enunciado?
• Tabule do topo ao botão "revelar pista" sem armadilha.
• Confirme que imagens decorativas têm alt vazio e que imagens clínicas têm alt útil.

Instituições de educação médica ainda comunicam inclusão de forma desigual nas páginas públicas (Ikedionwu et al., 2025). No material de estudo, a inclusão começa mais baixo: no DOM do caso. Accountability para estudantes com deficiência aponta na mesma direção (Meeks, Stergiopoulos e Petersen, 2022). Barreiras de revelação em residentes mostram que muitos hesitam em pedir acomodação (Pereira-Lima et al., 2023); desenhar o fluxo legível por padrão reduz a dependência do pedido só para "conseguir ouvir a pista 1".

Consistência entre sessões também conta. Se ontem o foco abria no enunciado e hoje abre no ranking, o modelo mental desaba. Salvar preferências de leitura (quando o produto as tiver) e manter a casca do caso estável reduzem a carga de reorientação. Orientações de jogos acessíveis pedem estrutura previsível e detalhes de recursos de acessibilidade visíveis no produto e no site (Game Accessibility Guidelines); a declaração em /accessibility cumpre a parte pública desse pedido no NEXO, sem afirmar eficácia.

Pistas progressivas: o que o leitor precisa ouvir

Até seis pistas progressivas são o coração do método: informação chega em fatias, e o peso de cada achado muda o diferencial. Para o leitor de tela, "fatia" precisa ser um bloco nomeado. Rótulos do tipo "Pista 2 de 6" mais o texto clínico completo batem "novo conteúdo" sem contexto. Se a pista for só um cartão colorido com ícone, a fala vira "botão" ou "imagem".

Revelação sob demanda: o controle "mostrar próxima pista" deve ter nome acessível estável e, ao ativar, o foco deve ir para o heading ou região da pista nova. Evite injetar o texto só em uma região aria-live agressiva que lê o parágrafo inteiro sem controle. Prefira foco no heading da pista e leitura sob comando do usuário; live curta pode anunciar "Pista 2 disponível". A documentação de regiões live recomenda polite na maior parte dos casos (APG Alert; MDN Live regions).

Imagens clínicas na pista (traçado, foto, laudo) pedem alternativa textual do achado que importa, não o nome do arquivo. Princípios de multimídia pedem alinhar palavras e imagens (Mayer, 2010). Dupla codificação ajuda no estudo quando texto e imagem se reforçam (dupla codificação); se o achado essencial estiver só na figura, a pista some para quem ouve.

Abreviações ("PA", "FC", "SpO2") confundem síntese de voz. Expandir na primeira menção da pista reduz soletração estranha. Listas curtas dentro da pista ("a favor", "contra") com headings ou ul reais orientam melhor do que um parágrafo único de oito linhas.

Progresso visível ("3 de 6") precisa de equivalente textual. Barra só visual falha. Orientações de jogos acessíveis pedem indicadores de progresso e reforço não só textual quando a instrução for crítica (Game Accessibility Guidelines). Em MOOCs desenhados com WCAG e consulta a preferências, usuários de leitor de tela mostraram associação positiva com bom desempenho frente a quem não declarou preferência; quem tinha baixa visão sem leitor adequado ficou em desvantagem relativa (Rodriguez-Ascaso et al., 2024). O desenho da pista é parte dessa equação.

Pausa diagnóstica no raciocínio (pausa diagnóstica) cabe entre pistas: um controle "revisar pistas anteriores" com lista navegável evita que a memória de trabalho carregue tudo sozinha. Ética de desenho educacional já pede não prejudicar o aprendiz pelo formato (ética no design de jogos).

Hipóteses e submissão: nomes acessíveis e ordem

Formular hipótese é o lance clínico do jogo: nome do diagnóstico ou código. O campo de busca ou combobox precisa de label visível e associado ("Hipótese diagnóstica" ou "Código CID"), não só placeholder que some ao digitar. Resultados da lista devem ser anunciáveis item a item, com nome completo do termo. Botão de enviar: "Enviar hipótese", não "OK".

Ordem no formulário: label, campo, ajuda curta ("pode buscar por nome ou código"), depois enviar. Mensagens de erro ("nenhum resultado", "campo vazio") em texto ligado ao campo, com foco movido para o erro quando fizer sentido. Evite validar só por cor da borda.

Se houver lista de hipóteses recentes ou favoritas, cada item precisa de nome distinto. "Botão", "botão", "botão" na lista de controles é falha clássica. O mesmo vale para "remover hipótese" versus "enviar".

Trabalhadores que usam leitor de tela no emprego frequentemente combinam mais de um leitor e relatam menos dificuldade quando têm reserva (McDonnall et al., 2025). Isso não autoriza ranquear produtos aqui: o catálogo e as páginas oficiais estão no post de tecnologia assistiva visual. Neste fluxo, o ponto é a interface do caso sobreviver a qualquer leitor razoável: HTML semântico, nomes e foco.

Calibração da confiança (calibração da confiança) e lacuna de conhecimento versus lacuna de raciocínio (lacuna de conhecimento ou de raciocínio) dependem de você saber o que enviou. Se o leitor não confirma a hipótese escolhida antes do Enter, o erro vira ruído. Um resumo "Você vai enviar: embolia pulmonar" imediatamente antes do botão reduz envio cego.

Em casos fictícios com apresentação clínica real, a hipótese errada ainda ensina se o ciclo de proximidade e pista seguinte permanecer audível. Quando o campo engole o nome escolhido ou o botão de envio some do Tab depois do primeiro erro, o estudante com leitor abandona o caso não por falta de raciocínio, mas por falha de operação. Isso se parece com timeout motor em apps de ensino: a barreira não é clínica. Desenhar o formulário estável (mesmos nomes, mesma ordem, mesmas mensagens) a cada tentativa é parte do desenho pedagógico, não só da engenharia.

Do lance ao fechamento: proximidade e explicação

A cada hipótese, muitos jogos de diagnóstico devolvem proximidade: mesmo capítulo, próximo, distante. Esse retorno curto não é a explicação longa do fechamento; é o sinal de navegação no espaço CID. Independência de cor é obrigatória: deficiência congênita de visão de cores é frequente o bastante para justificar rótulo textual em material médico (PMID 10562750; prática segura: PMID 28731005). Comunicação científica já documenta mau uso de cor como único canal (PMID 33116149).

Para o leitor de tela, proximidade precisa de nome acessível completo: "Proximidade: mesmo capítulo" ou "Proximidade: distante", não só "status" ou ícone. Se houver animação, ela não pode ser o único canal; respeitar preferência de reduzir movimento evita enjoo e distração. Live region curta e educada pode anunciar a proximidade; não anuncie de novo a cada re-render silencioso.

Feedback em educação clínica é informação sobre desempenho com intenção de melhorar o próximo ciclo (van de Ridder et al., 2008). Meta-análises mostram que o efeito depende do tipo e do modo de entrega (Wisniewski, Zierer e Hattie, 2019). O post sobre explicação útil aprofunda conteúdo e timing do retorno pedagógico. Gamificação pode usar precisão e constância sem depender de confete sem rótulo (evidência em gamificação). Avaliação formativa vive desse retorno que informa o próximo ciclo (avaliação formativa).

Depois da proximidade, o foco deve voltar a um ponto previsível: campo de hipótese (para nova tentativa) ou botão "próxima pista". Deixar o foco no limbo depois do anúncio é uma das falhas mais caras em tempo de estudo. Quem joga com leitor de tela reconstrói o espaço do diferencial pela sequência de anúncios; se a proximidade some no silêncio, a próxima hipótese vira chute sem mapa.

Fechar o caso (acerto ou fim das tentativas) muda o modo da tela. O leitor precisa de um anúncio claro de estado ("Caso fechado: diagnóstico alvo disponível") e de um heading que inaugure a área de resultado. Mover o foco para esse heading é mais seguro do que despejar a explicação inteira em live region. A transição do lance para o debrief é o ponto em que muitos apps "esquecem" a API de acessibilidade: o visual troca de tema, confetes sobem, e a árvore de acessibilidade fica sem heading ou com foco preso no modal.

A explicação longa depois do fechamento (porquê, pistas que sustentavam, diferencial) é um problema de estrutura de documento: headings, texto real, links nomeados, tabelas com cabeçalho. Esse eixo pedagógico de utilidade do retorno está em explicação útil; o cuidado com tecnologias assistivas na prosa do pós-caso dialoga com a declaração em /accessibility e com o guia de tecnologia assistiva visual, sem repetir catálogo de produtos. Aqui o ponto do fluxo é a transição: do lance para o debrief sem perder o usuário no silêncio ou no spam de anúncios.

Controles pós-fechamento (reabrir pistas, copiar resumo, reportar problema, ir ao próximo caso) entram na ordem de Tab depois do heading de resultado. Nomes descritivos. Se houver modal de celebração, ele precisa ser fechável por teclado, com foco preso de forma deliberada e restaurado ao fechar; senão vira armadilha. Um roteiro mínimo de QA com leitor ligado: enviar hipótese errada, ouvir proximidade, revelar pista, acertar, ouvir "caso fechado", Tab até "explicação" e ler o primeiro heading do porquê.

Ferramentas do ecossistema de estudo depois do caso: Researcher, Closer, Curator e Creators, sempre com o mesmo cuidado de nomeação quando linkadas na tela de resultado. O mesmo padrão de nome e foco que vale na pista vale no link de saída: "Abrir Researcher" diz mais do que "saiba mais".

Tabela: etapa, anúncio e falha comum

Use a tabela ao revisar o caso jogável com leitor de tela ligado. Os contrastes são técnicos.

Etapa do fluxo	O que o leitor precisa ouvir	Falha comum	Resposta de desenho
Abertura do caso	Título do caso; landmark main; enunciado	Foco em banner; título genérico	h1 + main; skip link; foco no enunciado
Revelar pista	"Pista N de 6" + texto clínico	Só cor/animação; botão "botão"	Nome do controle; foco no heading da pista
Imagem na pista	Alt do achado relevante	Alt vazio ou nome de arquivo	Alt escrito depois de ver a imagem
Campo de hipótese	Label + valor escolhido	Só placeholder; lista muda	label associado; confirmação antes de enviar
Enviar	"Enviar hipótese"	"OK" / ícone sem nome	Nome da ação
Proximidade	Palavra do nível (capítulo, próximo, distante)	Só verde/amarelo/vermelho	Texto + ícone nomeado; live curta
Fechamento	Estado "fechado" + heading de resultado	Explicação inteira em aria-live	Foco no heading; prosa estável
Pós-caso	Ações seguintes nomeadas	Modal sem Escape; foco perdido	Tab order; fechar e restaurar foco

Depois da tabela, pergunte: se eu só ouvir headings, landmarks e nomes de botões, consigo jogar o caso do enunciado ao fechamento? Se a resposta for não, o fluxo ainda não está acessível.

Como o NEXO entra

O NEXO é um jogo diário de diagnóstico com casos fictícios com apresentação clínica real e até seis pistas progressivas. A página /accessibility declara, entre outros pontos, rótulos descritivos para elementos interativos, pistas clínicas e feedback do jogo; HTML semântico com hierarquia de headings no site; contraste; alt em imagens significativas; ausência de mídia em autoplay; e independência de cor nos níveis de proximidade (cor com rótulo de texto). A mesma página registra limitações conhecidas sem transformar isso em marketing. Nenhuma frase aqui afirma que esses recursos melhoram retenção, nota ou desempenho clínico. É descrição conferível.

Quem está conhecendo a plataforma pode ler o que é o NEXO. Aprendizagem baseada em casos situa o método (como funciona). Limites de uso, quando relevantes, estão em /economia. O ângulo deste post é o walkthrough do fluxo com leitor de tela. Na mesma pauta, ver acessibilidade cognitiva, feedback multimodal no lance, explicação pós-diagnóstico e como escrever casos clínicos inclusivos.

Perguntas frequentes

Este post substitui o guia de tecnologia assistiva visual?

Não. Produtos, leitores e práticas clínicas de TA visual estão em tecnologia assistiva visual. Aqui o objeto é o fluxo do caso (pistas, hipóteses, fechamento) e o que a interface deve anunciar.

Preciso anunciar cada pista inteira em aria-live?

Em geral, não. Live curta para "pista disponível" ou proximidade; foco no heading; leitura do corpo sob controle de quem usa o leitor.

Ordem visual pode divergir da ordem de foco?

Só se a sequência ainda preservar significado e operação. No caso jogável, o caminho pedagógico (enunciado, pista, hipótese, proximidade, fechamento) deve ser o caminho do Tab e da leitura linear (WCAG 2.4.3).

Proximidade só com cor basta se o contraste for alto?

Não. Contraste ajuda quem vê; não substitui palavra para daltonismo nem para leitor de tela. Cor com rótulo textual e, se houver, ícone nomeado.

Como isso se liga à explicação depois do diagnóstico?

São momentos distintos: proximidade é sinal curto no lance; explicação é debrief estruturado. Utilidade do retorno: explicação útil. Acessibilidade digital ampla: softwares médicos.

Vale testar só com um leitor de tela?

Melhor testar o fluxo com mais de uma combinação de leitor e navegador quando possível; estudos com trabalhadores cegos sugerem reserva de ferramentas (McDonnall et al., 2025). Sem ranquear marcas neste texto.

Checklist final

• Abertura: h1 do caso, landmark main, skip link, foco inicial no enunciado.
• Pistas (até seis): controle nomeado; "Pista N de 6"; texto real; alt clínico; foco na pista nova.
• Hipótese: label associado; confirmação do termo; botão "Enviar hipótese".
• Proximidade: palavra do nível; live curta; foco previsível depois.
• Fechamento: anúncio de estado; heading de resultado; explicação fora de live agressiva.
• Pós-caso: ações nomeadas; modal fechável; sem armadilha de teclado.
• Nada de informação só em cor, só em animação ou só em imagem.
• Conferir declaração em /accessibility; limites em /economia.

Jogue o caso do dia.

Referências

1. Almeida AMP, et al. Development of an online digital resource accessible for students with visual impairment or blindness. Work. 2020. PMID 32007977.
2. Böhm A, Lux T. Analyses of the Accessibility of Interactive Learning Content in H5P. Stud Health Technol Inform. 2025. PMID 40380646.
3. Gin LE, et al. New Online Accommodations Are Not Enough. CBE Life Sci Educ. 2022. PMID 35496702.
4. Huth K, et al. Accessible by design: a guide for health professions educators. 2025. PMID 39773717.
5. Ikedionwu I, et al. Evaluating Disability-Inclusive Content on U.S. Medical Schools Websites. Acad Med. 2025. PMID 40550114.
6. Mayer RE. Applying the science of learning to medical education. Med Educ. 2010. PMID 20604850.
7. McDonnall MC, et al. Screen reader use among legally blind workers. 2025. PMID 40614067.
8. Meeks LM, et al. National prevalence of disability and clinical accommodations in medical education. 2020. PMID 33178890.
9. Meeks LM, Stergiopoulos E, Petersen KH. Institutional accountability for students with disabilities. Acad Med. 2022. PMID 34670236.
10. Pereira-Lima K, et al. Barriers to disability disclosure in residency. 2023. PMID 37166801.
11. Rodriguez-Ascaso A, et al. Performance of students with different accessibility needs in Design for All MOOCs. 2024. PMID 38451899.
12. van de Ridder JM, et al. What is feedback in clinical education? Med Educ. 2008. PMID 18230092.
13. van Merriënboer JJ, Sweller J. Cognitive load theory in health professional education. Med Educ. 2010. PMID 20078759.
14. Wisniewski B, Zierer K, Hattie J. The Power of Feedback Revisited. Front Psychol. 2019. PMID 32038429.
15. Colour vision deficiency and colour as sole channel: PMID 10562750; PMID 28731005; PMID 33116149.
16. W3C. WCAG 2.2 Understanding: Focus Order; Info and Relationships. Focus Order; 1.3.1.
17. W3C APG / MDN. Live regions and alert pattern. APG Alert; MDN.
18. Game Accessibility Guidelines. Full list. gameaccessibilityguidelines.com.
19. Floe Inclusive Learning Design Handbook. Web Games and Simulations. handbook.floeproject.org.