Case flow with screen reader: clues and guesses

You open the case of the day with the screen reader on. The prompt announces age and complaint. Then focus jumps to an unnamed button, then to a decorative chart, and "clue 1" exists only as color in the corner. You form a hypothesis, but the search field says only "edit". The proximity feedback blinks green with no word. The closing exists on screen and vanishes in speech. This text walks through the flow of the playable case with a screen reader: clues (up to six), hypotheses, submission, proximity, closing and what the interface must announce and order at each step. It differs from the catalog of visual assistive technology (products and readers) and from the WCAG map in digital accessibility in medical software. Here the object is the pedagogical walkthrough of the case, not the list of software.

Nothing in this article claims effectiveness for NEXO. We describe design principles, public criteria (W3C, accessible game guidelines) and features checked in the accessibility statement. Fictional cases with a real clinical presentation, with up to six clues, only teach if each step of the flow is readable in the accessibility API, not only in the visual layout.

Key points

• The case flow has stable steps: opening, clue, hypothesis, submission, proximity, next clue or closing; the screen reader needs names, order and landmarks at each one.
• DOM focus order must follow the pedagogical sequence, not the randomness of CSS; WCAG criterion 2.4.3 addresses exactly this.
• Progressive clues (up to six) need a label with a number and content in real text; revealing only through animation or color fails in speech and in braille.
• Hypothesis fields and submit buttons need an accessible name that describes the action; "edit" and "OK" are not enough.
• Proximity and closing require a word beyond color; the detail of the long explanation after the closing is another moment of the cycle (see useful feedback and the public statement).
• In NEXO, the /accessibility page describes labels on clues and feedback, semantic HTML and independence from color in proximity; with no claim of learning outcome. Usage limits, when relevant, are in /economia.

Flow map: from opening to closing

In a daily diagnosis game, the case is not a static page. It is a path: you read the context, receive clues on demand, propose hypotheses, receive proximity and, when you get it right or run out of attempts, reach the closing. Case-based learning organizes this cycle around a concrete clinical problem (how it works). Training differential with progressive clues reinforces the weight of each finding (train with clues). With a screen reader, the same path only works if each state change is named and focusable.

Nearly 6% of medical students in the United States reported a disability in 2021, more than double the figure for 2015, and they request accommodations that include digital access (Huth et al., 2025; prevalence and accommodations: Meeks et al., 2020). In online science courses, more than half of students with disabilities reported inadequate accommodation after the digital migration; inclusion recommendations need to be universal, not only individual (Gin et al., 2022). Interactive content tested with a screen reader shows that many types of activity "work" only in part and need an explicit alternative (Böhm and Lux, 2025). Digital resources for visual impairment need reader description, keyboard navigation and adherence to W3C guidelines (Almeida et al., 2020).

Imagine a fictional case with a real clinical presentation: a young adult with chest pain and dyspnea for a few hours, up to six clues. Clue 1 covers sudden onset; clue 2 covers saturation; clue 3 covers an exam finding. You move hypotheses up and down (embolism, coronary syndrome, pneumothorax, anxiety). Every step must exist in the accessibility tree: appearing in the rectangle on screen is not enough.

Accessible game guidelines call for predictable structure, meaningful landmarks, progress indicators and screen reader support in menus and gameplay (Game Accessibility Guidelines). WCAG addresses focus order, names, relationships and status changes (W3C, Focus Order 2.4.3; Info and Relationships 1.3.1). The mental map of the flow, for those who hear the interface, is:

• Where I am (case title, clue number, status "in progress" or "closed").
• What I can do now (reveal clue, edit hypothesis, submit, report a problem).
• What just changed (new clue, proximity, correct answer, network error).
• Where to go next (explanation, next case, exit).

Cognitive load in health education already calls for reducing noise and preserving working memory for what is being taught (van Merriënboer and Sweller, 2010; Mayer, 2010). Hunting for the unnamed button or hearing "chart" instead of the clue is pure noise. It connects with metacognition: you only monitor your own reasoning if the interface does not consume all your attention.

In practice, treat the flow as a mental bedside protocol: history (statement), examination (clues), hypotheses, test (submission), result (proximity) and plan (explanation). A preceptor who observes reasoning out loud does something similar. The screen reader is that automatic out-loud voice: if the protocol is not named in the interface, the presentation of the case to oneself breaks in the middle. That is why landmarks and headings are not an engineering detail; they are the backbone of clinical reasoning in the digital medium.

Before the first clue: page, landmarks and focus

Before any clue, the reader builds the map of the screen. Landmarks (main, navigation, complementary) and a level 1 heading with the case title allow skipping the app chrome. A skip link to the main content avoids an endless Tab through the menu. If the browser tab title is generic ("App"), the window list does not help those switching tasks on shift.

Initial focus order matters. When the case opens, focus should land on the heading or the first block of the statement, not on a promotional banner or a forgotten modal. Focusable elements hidden visually but still in the Tab order create silent "holes". WCAG requires that the sequence preserve meaning and operation (Focus Order). In web games and simulations, consistent structure and context description guide those who cannot see the scene (Floe, Web Games and Simulations).

The keyboard is the reader's companion: Tab, Shift+Tab, Enter, Space and arrow keys. Visible focus must exist for those who see partially and for those who teach while looking at someone else's screen. The post on digital accessibility places keyboard and names in clinical software; here the focus is the sequence of the playable case.

A quick five-minute test at the opening:

• List headings: does the case title appear?
• List landmarks: is there a main with the statement?
• Tab from the top to the "reveal clue" button without a trap.
• Confirm that decorative images have empty alt and that clinical images have useful alt.

Medical education institutions still communicate inclusion unevenly on public pages (Ikedionwu et al., 2025). In study material, inclusion starts lower down: in the DOM of the case. Accountability for students with disabilities points in the same direction (Meeks, Stergiopoulos and Petersen, 2022). Disclosure barriers among residents show that many hesitate to ask for accommodation (Pereira-Lima et al., 2023); designing the flow to be readable by default reduces dependence on a request just to "be able to hear clue 1".

Consistency between sessions also counts. If yesterday the focus opened on the prompt and today it opens on the ranking, the mental model collapses. Saving reading preferences (when the product has them) and keeping the case shell stable reduce the reorientation load. Accessible game guidelines call for a predictable structure and accessibility feature details visible in the product and on the site (Game Accessibility Guidelines); the statement at /accessibility fulfills the public part of that request at NEXO, without claiming effectiveness.

Progressive clues: what the reader needs to hear

Up to six progressive clues are the heart of the method: information arrives in slices, and the weight of each finding changes the differential. For the screen reader user, a "slice" needs to be a named block. Labels like "Clue 2 of 6" plus the full clinical text beat "new content" without context. If the clue is just a colored card with an icon, the speech becomes "button" or "image".

Reveal on demand: the "show next clue" control must have a stable accessible name and, when activated, focus must move to the heading or region of the new clue. Avoid injecting the text only into an aggressive aria-live region that reads the whole paragraph without control. Prefer focus on the clue heading and reading on the user's command; a short live message can announce "Clue 2 available". Live region documentation recommends polite in most cases (APG Alert; MDN Live regions).

Clinical images in the clue (tracing, photo, report) call for a text alternative of the finding that matters, not the file name. Multimedia principles call for aligning words and images (Mayer, 2010). Dual encoding helps in study when text and image reinforce each other (dual encoding); if the essential finding is only in the figure, the clue disappears for those who listen.

Abbreviations ("BP", "HR", "SpO2") confuse speech synthesis. Expanding them at the first mention in the clue reduces strange spelling out. Short lists within the clue ("for", "against") with headings or real ul guide better than a single eight-line paragraph.

Visible progress ("3 of 6") needs a text equivalent. A purely visual bar fails. Accessible game guidelines call for progress indicators and reinforcement that is not only textual when the instruction is critical (Game Accessibility Guidelines). In MOOCs designed with WCAG and consultation of preferences, screen reader users showed a positive association with good performance compared with those who did not declare a preference; those with low vision without an adequate reader were at a relative disadvantage (Rodriguez-Ascaso et al., 2024). The design of the clue is part of that equation.

A diagnostic pause in reasoning (diagnostic pause) fits between clues: a "review previous clues" control with a navigable list keeps working memory from carrying everything alone. Educational design ethics already calls for not harming the learner through the format (ethics in game design).

Guesses and submission: accessible names and order

Forming a guess is the clinical move of the game: diagnosis name or code. The search field or combobox needs a visible, associated label ("Diagnostic guess" or "ICD code"), not just a placeholder that disappears on typing. List results must be announceable item by item, with the full name of the term. Submit button: "Submit guess", not "OK".

Order in the form: label, field, short help ("you can search by name or code"), then submit. Error messages ("no results", "empty field") in text tied to the field, with focus moved to the error when it makes sense. Avoid validating only by border color.

If there is a list of recent or favorite guesses, each item needs a distinct name. "Button", "button", "button" in the controls list is a classic failure. The same goes for "remove guess" versus "submit".

Workers who use a screen reader on the job often combine more than one reader and report less difficulty when they have a backup (McDonnall et al., 2025). This does not authorize ranking products here: the catalog and official pages are in the post on visual assistive technology. In this flow, the point is for the case interface to survive any reasonable reader: semantic HTML, names and focus.

Confidence calibration (confidence calibration) and the knowledge gap versus the reasoning gap (knowledge or reasoning gap) depend on you knowing what you sent. If the reader does not confirm the chosen hypothesis before Enter, the error becomes noise. A summary "You are about to send: pulmonary embolism" right before the button reduces blind submission.

In fictional cases with a real clinical presentation, the wrong hypothesis still teaches if the proximity cycle and the next clue remain audible. When the field swallows the chosen name or the submit button disappears from Tab after the first error, the student with a reader abandons the case not for lack of reasoning but because of an operation failure. This resembles motor timeout in teaching apps: the barrier is not clinical. Designing the form to be stable (same names, same order, same messages) on every attempt is part of the pedagogical design, not just of engineering.

From the guess to the closing: proximity and explanation

With each hypothesis, many diagnosis games return proximity: same chapter, close, distant. This short return is not the long explanation at the closing; it is the navigation signal in ICD space. Color independence is mandatory: congenital color vision deficiency is common enough to justify a text label in medical material (PMID 10562750; safe practice: PMID 28731005). Scientific communication already documents misuse of color as the only channel (PMID 33116149).

For the screen reader, proximity needs a complete accessible name: "Proximity: same chapter" or "Proximity: distant", not just "status" or an icon. If there is animation, it cannot be the only channel; respecting the reduce motion preference prevents nausea and distraction. A short, polite live region can announce the proximity; do not announce it again on every silent re-render.

Feedback in clinical education is information about performance with the intent of improving the next cycle (van de Ridder et al., 2008). Meta-analyses show that the effect depends on the type and mode of delivery (Wisniewski, Zierer and Hattie, 2019). The post on useful explanation goes deeper into the content and timing of pedagogical return. Gamification can use accuracy and consistency without relying on unlabeled confetti (evidence on gamification). Formative assessment lives on this return that informs the next cycle (formative assessment).

After the proximity, focus should return to a predictable point: the hypothesis field (for a new attempt) or the "next clue" button. Leaving focus in limbo after the announcement is one of the most costly failures in study time. Those who play with a screen reader rebuild the differential space through the sequence of announcements; if the proximity vanishes into silence, the next hypothesis becomes a guess without a map.

Closing the case (correct answer or end of attempts) changes the screen mode. The reader needs a clear state announcement ("Case closed: target diagnosis available") and a heading that opens the results area. Moving focus to that heading is safer than dumping the whole explanation into a live region. The transition from the guess to the debrief is the point where many apps "forget" the accessibility API: the visual changes theme, confetti rises, and the accessibility tree is left without a heading or with focus stuck in the modal.

The long explanation after closing (why, the clues that supported it, the differential) is a document structure problem: headings, real text, named links, tables with headers. This pedagogical axis of feedback usefulness is in useful explanation; care with assistive technologies in the post-case prose connects with the statement at /accessibility and with the guide on visual assistive technology, without repeating a product catalog. Here the point of the flow is the transition: from the guess to the debrief without losing the user in silence or in ad spam.

Post-closing controls (reopen clues, copy summary, report a problem, go to the next case) come in Tab order after the result heading. Descriptive names. If there is a celebration modal, it must be closable by keyboard, with focus deliberately trapped and restored on close; otherwise it becomes a trap. A minimal QA script with a screen reader on: submit a wrong guess, hear proximity, reveal a clue, get it right, hear "case closed", Tab to "explanation" and read the first heading of the why.

Study ecosystem tools after the case: Researcher, Closer, Curator and Creators, always with the same care in naming when linked on the result screen. The same pattern of name and focus that applies to the clue applies to the exit link: "Open Researcher" says more than "learn more".

Table: step, announcement and common failure

Use the table when reviewing the playable case with a screen reader on. The contrasts are technical.

Flow step	What the reader needs to hear	Common failure	Design response
Case opening	Case title; main landmark; statement	Focus on banner; generic title	h1 + main; skip link; focus on the statement
Reveal clue	"Clue N of 6" + clinical text	Color/animation only; button labeled "button"	Control name; focus on the clue heading
Image in the clue	Alt text for the relevant finding	Empty alt or file name	Alt text written after seeing the image
Guess field	Label + chosen value	Placeholder only; list changes	Associated label; confirmation before submitting
Submit	"Submit guess"	"OK" / icon with no name	Action name
Proximity	Level word (chapter, close, far)	Green/yellow/red only	Text + named icon; short live region
Closing	"Closed" state + result heading	Entire explanation in aria-live	Focus on heading; stable prose
Post-case	Named next actions	Modal without Escape; lost focus	Tab order; close and restore focus

After the table, ask: if I only hear headings, landmarks and button names, can I play the case from the statement to the closing? If the answer is no, the flow is not yet accessible.

How NEXO fits in

NEXO is a daily diagnosis game with fictional cases with real clinical presentation and up to six progressive clues. The /accessibility page states, among other points, descriptive labels for interactive elements, clinical clues and game feedback; semantic HTML with a heading hierarchy on the site; contrast; alt text on meaningful images; no autoplay media; and independence from color in the proximity levels (color with a text label). The same page records known limitations without turning that into marketing. No sentence here claims that these resources improve retention, grades or clinical performance. It is verifiable description.

Those getting to know the platform can read what NEXO is. Case-based learning situates the method (how it works). Limits of use, when relevant, are at /economy. The angle of this post is the walkthrough of the flow with a screen reader. On the same topic, see cognitive accessibility, multimodal feedback on the guess, post-diagnosis explanation and how to write inclusive clinical cases.

Frequently asked questions

Does this post replace the visual assistive technology guide?

No. Products, readers and clinical practices for visual AT are in visual assistive technology. Here the subject is the case flow (clues, guesses, closing) and what the interface should announce.

Do I need to announce every whole clue in aria-live?

Generally, no. A short live region for "clue available" or proximity; focus on the heading; body reading under the control of the screen reader user.

Can visual order differ from focus order?

Only if the sequence still preserves meaning and operation. In the playable case, the pedagogical path (prompt, clue, guess, proximity, closing) must be the path of Tab and linear reading (WCAG 2.4.3).

Is color alone enough for proximity if contrast is high?

No. Contrast helps those who see; it does not replace words for color blindness or for screen readers. Color with a text label and, if present, a named icon.

How does this connect to the explanation after the diagnosis?

They are distinct moments: proximity is a short signal in the move; explanation is a structured debrief. Usefulness of the return: useful explanation. Broad digital accessibility: medical software.

Is it worth testing with only one screen reader?

It is better to test the flow with more than one screen reader and browser combination when possible; studies with blind workers suggest caution with tools (McDonnall et al., 2025). No ranking of brands in this text.

Final checklist

• Opening: case h1, main landmark, skip link, initial focus on the prompt.
• Clues (up to six): named control; "Clue N of 6"; real text; clinical alt; focus on the new clue.
• Guess: associated label; term confirmation; "Send guess" button.
• Proximity: level word; short live; predictable focus afterwards.
• Closing: state announcement; result heading; explanation outside an aggressive live.
• Post-case: named actions; closable modal; no keyboard trap.
• No information conveyed only by color, only by animation or only by image.
• Check the statement at /accessibility; limits at /economy.

Play today's case.

References

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.