Implementation-Ready Research Report: Accessibility and Nonvisual Equivalence for Simulation Earth

Full report

On this page

Executive Overview of Semantic and Environmental Equivalence

The deployment of the Simulation Earth environment on the IARPA server-rendered infrastructure presents a complex human-computer interaction challenge. The application requires rendering a highly dynamic, multidimensional, WebGL-driven fictional simulation accessible to users without relying on visual perception, fine motor control, vestibular tolerance, high bandwidth, or immersive hardware. Delivering true nonvisual and low-capability equivalence necessitates the absolute decoupling of the visual presentation layer from the underlying data model. The visual globe must be treated merely as a projection of the state; the semantic Document Object Model (DOM) is the authoritative, deterministic record of truth. This research synthesizes the current Web Content Accessibility Guidelines (WCAG) 2.2 principles, the XR Accessibility User Requirements (XAUR) developed by the W3C Web Accessibility Initiative1, and modern browser interaction protocols to architect a definitive technical blueprint. By establishing strict access boundaries—treating the supplied environment as a project brief and defining the evidentiary artifacts that an implementation team must later collect—this analysis ensures that nonvisual, keyboard-only, and low-capability alternatives are designed as synchronized, first-class experiences. The simulation must never present stale data, nor can it force users to memorize arbitrary spatial gestures or rely solely on automated accessibility checkers that verify syntax but cannot validate human operability.

Semantic Information Architecture

The foundational requirement for nonvisual equivalence is a semantic information architecture that translates the multidimensional state of Simulation Earth into a linear, predictable, and navigable structure. A screen reader interprets a web page through the accessibility tree, which is a specialized derivation of the DOM4. Because the 48 synthetic cells and their associated events are dynamically manipulated, their relationships must be explicitly defined in semantic HTML, ensuring that the visual interface and the nonvisual experience remain perfectly synchronized. The application state must be reflected in a predictable landmark structure to allow assistive technology users to bypass repetitive content. The \<header\> element must act as the primary banner, containing global simulation state indicators and the authority labels that strictly distinguish factual Current Statistics from fictional Simulation Earth projections. This distinction is critical for research provenance and must not rely on color coding alone; explicit visually hidden text or robust text labeling must accompany every data point. The \<nav\> landmark serves as the routing mechanism, housing the Scenario Command Center, branch comparison toggles, and view configurations. The \<main\> landmark is the locus of interaction, containing the primary WebGL canvas and its synchronized Sibling DOM. Finally, an \<aside\> complementary region must house the Scenario Event Studio, derived consequence channels, historical context, and the off-screen selection compass, while the \<footer\> maintains timeline playback controls, speed adjustments, and data export/import capabilities. Every conceptual entity within the simulation requires an operable text-based representation. The Current Mode and Scenario state must be wrapped in an aria-live="polite" region that broadcasts high-level changes. Branches and What-If scenarios require structural containment, ideally utilizing nested \<details\> and \<summary\> elements or a carefully managed role="tree" widget to convey the divergence of projection candidates. Consequence channels, which display the outcomes of simulation variables, must be rendered as live data tables or definition lists (\<dl\>, \<dt\>, \<dd\>) to clearly associate variables with their computed outcomes and allow screen-reader users to interrogate the data systematically5. The timeline and chronology controls require highly specific widget roles. A standard HTML range input or an element explicitly assigned role="slider" is mandatory for the timeline6. Because the underlying timestamp value is numeric but the conceptual value is a specific date, the slider must dynamically utilize the aria-valuetext attribute. While aria-valuenow handles the numerical progression, aria-valuetext translates this into human-readable strings, such as "August 5, 2026 CE," which must update programmatically on every tick of the simulation6.

Nonvisual Globe Model and Canvas Accessibility

The WebGL \<canvas\> element presents rendered pixels to the screen but exposes no semantic information to the browser's accessibility tree, effectively acting as an opaque black box to screen readers8. To bridge this gap without degrading graphics processing unit (GPU) performance, the architecture must implement a synchronized Sibling DOM or internal fallback content structure4.

Accessibility-Tree and DOM-Mirror Architecture

To represent the 48 synthetic cells, the application must avoid generating a flattened list of 48 arbitrary items, which imposes excessive cognitive load and strips the data of its geographic relationships. The architecture must utilize a Discrete Global Grid System (DGGS) mapped to a hierarchical logical structure10. A DGGS uses a hierarchical tessellation of cells to partition the globe, allowing for recursive regional grouping11. The canvas sibling DOM must utilize the WAI-ARIA Graphics Module to convey structural meaning to assistive technologies without triggering incompatible widget behaviors12. The root container of the DOM mirror must utilize role="graphics-document" and an appropriate aria-label, such as "Simulation Earth 3D Projection." To manage navigation, the synthetic cells must be subdivided logically into hemispheric or continental regions utilizing role="group". Each region contains its respective synthetic cells, defined with role="graphics-object". Individual historical events, consequence clusters, or selection markers nested within a cell are represented using role="graphics-symbol". The role="application" attribute must be strictly prohibited on the globe container or the overarching \<main\> element14. Applying role="application" disables the screen reader's virtual cursor, stripping users of standard navigation commands such as heading jumps or list exploration, and forces the developer to manually intercept and route every keystroke. Instead, a roving tabindex combined with role="region" and aria-roledescription="globe" must be implemented to preserve user autonomy while signaling the specialized nature of the interaction area.

Navigating Synthetic Cells without Spatial Gestures

A screen-reader user navigates the globe by moving focus through the structured DOM mirror. To translate the spatial realities of the 3D globe into a logical text flow, the off-screen selection compass must perform dynamic spatial-to-logical mapping. When focus rests on a specific synthetic cell, a visually hidden description linked via aria-describedby must state the cell's adjacent relationships, providing situational awareness (e.g., "Bounded by Cell 11 to the West, Cell 24 to the South"). Visual users rely heavily on zooming to manage information density. The DOM mirror must synchronize with this behavior through programmatic clustering. When zooming out visually, the DOM mirror must dynamically collapse individual cells into their parent role="group" nodes, preventing tab-key exhaustion and allowing the user to navigate by macro-regions. When zooming in, the mirror expands the focused region, surfacing the individual role="graphics-object" cell nodes and their nested events. Furthermore, visual users depend on peripheral markers and edge-indicators to locate off-screen events. For nonvisual equivalence, an Off-Screen Compass must be implemented as a persistent, dynamically updated list accessible via a skip-link at the top of the globe container. This compass aggregates all active selection markers and historical tour waypoints that currently sit outside the visual frustum of the camera. Activating a waypoint in the compass list shifts DOM focus directly to that specific node in the mirror and simultaneously triggers a camera pan in the WebGL canvas, ensuring state synchronization for users who employ screen magnifiers alongside screen readers.

Keyboard Behavior and Focus Management

The simulation requires complex interactions, including spatial rotation, multi-level zoom, branch comparison, and event creation. These interactions must be fully operable via a keyboard interface without relying on mouse drags, pinch-to-zoom, or complex gesture memorization. Focus management across the 48-cell simulation grid mandates a roving tabindex pattern to maintain a logical tab sequence15. Standard tab-key navigation through all 48 cells and their nested events would result in an insurmountable focus order. Instead, only the currently active or previously selected synthetic cell receives tabindex="0". All other cells in the DOM mirror receive tabindex="-1". When keyboard focus is on the active cell, the user employs the Arrow Keys to navigate to adjacent cells natively. Keyboard usability extends to the Scenario Command Center and Scenario Event Studio, which utilize complex modal and drawer layers. Focus must be strictly and deterministically managed. When a modal opens, focus must be trapped within the dialog context, and aria-hidden="true" must be applied to all background elements to prevent screen readers from reading occluded content. Upon the closure of the modal, focus must programmatically restore to the exact trigger element that spawned it16. If an event preview drawer opens from within the Command Center modal, a strict Escape-key hierarchy must be enforced: pressing the Escape key must dismiss only the topmost layer. A single press closes the drawer and returns focus to the modal; a subsequent press closes the modal and returns focus to the main simulation layer. When the application's information-density controls are used to hide visual panels, any operable element contained within those panels must be explicitly removed from the tab order using display: none or visibility: hidden. Failure to do so results in ghost-focusing, where the keyboard focus disappears into a visually hidden element, severely disorienting sighted keyboard users and switch-access users.

Screen-Reader Announcements and Live Region Policies

In a highly deterministic simulation executing multiple speeds, branching timelines, and complex variables, the sheer volume of state changes introduces the risk of "accessible starvation" or cognitive overload4. A rigid politeness and throttling policy is mandatory to govern how the application speaks to the user. All dynamic text must be routed through a dedicated live-region manager that triages announcements into assertive, polite, and silenced queues.

Announcement Dictionary and Throttling Rules

The Live Region Manager must implement a sophisticated debounce function to handle massive data shifts. If 20 consequence channels update simultaneously due to a branch commit, the system must intercept the array of changes, wait 1000ms, and output a consolidated string: "Scenario committed. 20 variables updated. Focus on Consequence Channel for details." This prevents the screen reader from locking up the user's audio channel with a relentless queue of individual variable updates.

Magnification, Reflow, and Visual Accessibility

Visual accessibility extends far beyond screen-reader compatibility. Users with low vision, including those utilizing software screen magnifiers or high browser text zoom, require fluid CSS architectures to maintain operational equivalence without forcing two-dimensional scrolling, which drastically reduces task completion rates. At 400% browser zoom, a standard 1280px desktop viewport mathematically reflows to a 320px CSS width, roughly equivalent to a narrow mobile viewport. The application layout must transition seamlessly from a multi-pane desktop dashboard to a stacked, single-column workspace. Nested scrolling regions must be eliminated; attempting to scroll a small div within a magnified viewport often results in cursor trapping. The Scenario Command Center and Event Studio must convert absolute-positioned modals into full-screen, relative scrolling layers. The WebGL canvas must scale relative to the viewport to maintain aspect ratios, while critical actions must become sticky within the safe areas to remain constantly accessible. Text and raster elements must not pixelate under magnification; the WebGL rendering context must detect window.devicePixelRatio and scale the internal resolution buffer dynamically.

High Contrast and Forced-Colors Behavior

Information mapping on the globe must not rely on color alone17. Data visualizations, heatmaps, and event clusters require dual-encoding (e.g., color combined with geometric patterns or explicit text labels). A synthetic cell experiencing a "Crisis" state encoded in red must also feature a distinct geometric marker, such as a pulsating crosshatch pattern or a triangle marker, differentiating it from a "Stable" green cell featuring a static circle. The application must respond natively to the forced-colors: active CSS media query, which triggers when users rely on Windows High Contrast Mode or similar operating-system-level contrast overrides19. When forced-colors: active is detected, CSS background gradients, box-shadows, and complex WebGL visual shaders must be simplified or deactivated. The DOM mirror or the 2D fallback map must be surfaced if the WebGL canvas cannot render high-contrast boundaries natively. Borders must be rendered using the CanvasText system color, and backgrounds must use the Canvas system color to inherit the user's customized, accessible palette19. Focus indicators require specific architectural attention to meet WCAG 2.2 Level AA standard 2.4.11. Indicators must be constructed with a minimum 1 CSS pixel perimeter or a 4 CSS pixel shortest-side block, utilizing an outline-offset of at least 2px to ensure a 3:1 contrast ratio against adjacent colors22. Using box-shadow for focus rings is strictly prohibited in environments supporting forced-colors, as the property computes to none under these constraints19. Standard CSS outline must be utilized to guarantee visibility. Furthermore, to combat label occlusion on the 3D globe—which causes severe readability degradation for low-vision users—the application must feature a configurable "Label Density" toggle. At lower densities, collision-detection algorithms must hide overlapping text, strictly prioritizing the user's currently selected cell and its immediate adjacent nodes.

Motion, Vestibular Safety, and Autoplay Policy

Animation and unprompted camera movement in a 3D WebGL space are known triggers for vestibular disorders, simulation sickness, and migraine episodes. The system must rigorously respect the prefers-reduced-motion: reduce media query, modifying rendering pipelines to eliminate hazardous visual vectors.

Reduced-Motion and Autoplay Policy

Touch, Switch, and Alternative Input Specification

The mobile configuration relies on a safe-area bottom sheet and a single scrolling workspace. The touch interface must accommodate diverse human factors, including resting tremors, stylus usage, and voice-control software dependencies. All interactive elements—including timeline markers, synthetic cell boundaries, and control buttons—must maintain a minimum active bounding box of 44x44 CSS pixels22. If a geographic cell projection is rendered smaller than this threshold at a low zoom level, the underlying touch target must programmatically expand beyond the visual boundary to capture inputs accurately. Swiping the bottom sheet must not inadvertently trigger elements on the WebGL canvas underneath; the application layer must strictly consume the event (event.stopPropagation()) to prevent ghost interactions. Conflicts between drag gestures and standard scroll behavior must be managed. Dragging the globe generally requires a single finger; however, to prevent trapping users who rely on screen-reader touch exploration (where a single finger reads the screen), the application must ensure that single-finger swiping solely moves the accessibility focus. Globe rotation for screen-reader users must be mapped to distinct UI arrow buttons or a specific multi-finger pan gesture to prevent operational overlap. For Voice Control equivalence, users relying on systems like Dragon NaturallySpeaking or iOS Voice Control must be able to articulate "Click \[Accessible Name\]." Therefore, the visible text rendered on the screen must perfectly match, or constitute the starting string of, the DOM element's underlying aria-label23.

Two-Dimensional Fallback and Low-Capability Modes

Privacy boundaries prohibit the collection of precise biometric or environmental data, and operational constraints dictate the absolute necessity for a robust experience without WebGL, high-performance JavaScript, or continuous high-bandwidth connectivity. If WebGL context creation fails, hardware acceleration is disabled by the user agent, or device processing capabilities are constrained, the system must deterministically fallback to a two-dimensional operational mode.

Low-Capability and 2D-Fallback Specification

WebXR Comfort and Equivalence Specification

The optional WebXR environment must adhere strictly to the W3C XR Accessibility User Requirements (XAUR)1. WebXR functionality cannot be required for any task; complete non-immersive equivalence is mandatory, and the immersion must remain comfortable for extended analytical sessions.

WebXR Comfort Specification

Multilingual and Bidirectional Layouts

Simulation Earth must separate deterministic simulation logic from localization formatting to ensure global accessibility. When an Arabic or Hebrew locale is selected, the application's flexbox and grid layouts must utilize modern CSS logical properties (e.g., margin-inline-start instead of margin-left). This ensures the interface mirrors perfectly. The timeline progression must visually invert, flowing right to left, while maintaining strict chronological integrity in the DOM structure so that screen readers continue to navigate forward in time. Date formatting requires careful programmatic attention. The timeline relies heavily on historical context and future projections. The BCE (Before Common Era) and CE (Common Era) labels must be fully localized via the application dictionary. A custom JavaScript date parser must feed the aria-valuetext attribute, ensuring that regardless of the visual layout, screen readers correctly announce dates (e.g., "August Fifth, Two Thousand Twenty Six") rather than rendering raw, localized numerical timestamp strings that obscure meaning.

Modality-Equivalence Matrix

The acceptance standard dictates that a user who cannot see, tolerate motion, use a pointer, or run WebGL must be able to comprehend the identical state, uncertainty, and provenance as a fully abled user.

Learning Equivalence Paths

Training and onboarding materials must not rely on visual cues (e.g., instructions like "Click the red button in the top left"). Instructions must remain highly semantic and structural to support all users.

• 2-Minute Orientation: "Welcome to Simulation Earth. The interface consists of a global header, the main simulation globe, and a bottom timeline. Use your Tab key or swipe gestures to explore the regions. Press Alt+Shift+T to jump directly to the timeline."
• 20-Minute Investigation: Users are instructed to navigate to the "Scenario Command Center" via the navigation landmark. They will search for "Resource Depletion," branch the scenario at the year 2030, and review the "Consequence Channels" data table to observe the immediate delta.
• 60-Minute Advanced Comparison: Users will utilize the aria-live regions and export/import functionality to save a local state, reset the environment to a baseline, load a comparative JSON payload, and systematically observe the delta announcements via the Live Region Manager.

Evidence Plan and Acceptance Criteria

Do not claim that automated tools (such as axe-core or Lighthouse) prove accessibility; these tools only verify baseline syntax and DOM structure. Actual acceptance requires native-device testing against rigorously defined scripts, ensuring authentic human operability.

Test Environment Matrix

• Desktop Environments: Windows 11 running Microsoft Edge (with UI Automation) and Chrome (paired with JAWS 2026 or NVDA); macOS running Safari (paired with VoiceOver).
• Mobile Environments: iOS 19 running Safari (with VoiceOver); Android 15 running Chrome (with TalkBack).
• Assistive Modes: High Contrast (forced-colors: active), Screen Magnifier (400% reflow), Switch Control (Bluetooth single-switch arrays), and native Voice Control.

Acceptance Execution Script

Task: Branch a historical event without sight or WebGL.

1. Setup: Disable JavaScript WebGL context in browser developer tools. Activate NVDA screen reader.

2. Action: User presses Tab to enter the navigation region and activates "Scenario Command Center."

3. Expected Evidence: NVDA announces "Scenario Command Center, dialog." Focus is securely trapped. The visual layout switches automatically to the relative 2D fallback.

4. Action: User tabs to the Timeline slider and presses Page Down.

5. Expected Evidence: NVDA announces "January 2030." The DOM Mirror updates its cell data accordingly without overwhelming the audio channel.

6. Action: User tabs to the "Create Branch" button and presses Enter.

7. Expected Evidence: The Live Region Manager announces "Branch created. Divergence year: 2030\. Focus moved to new branch title input."

Prioritized Backlog

The following backlog defines the immediate architectural imperatives for the implementation team, categorized by safety and risk.

Works cited

1. Inclusive Design for Immersive Web standards W3C Workshop position paper: Understanding XR Accessibility User Needs & Requirements (Oct 2019), https://www.w3.org/2019/08/inclusive-xr-workshop/papers/XR\_User\_Requirements\_Position\_Paper\_draft.html

2. A Systematic Literature Review of Handheld Augmented Reality Solutions for People with Disabilities \- PMC, https://pmc.ncbi.nlm.nih.gov/articles/PMC9607380/

3. The Art of the Possible \- W3C, https://www.w3.org/2021/07/chinese-ig-xr/slides/XR-accessibility.pdf

4. Accessible Hardware Accelerated Graphics (and WebGL) \- Quorum Programming Language, https://quorumlanguage.com/tutorials/accessibility/accessibleGraphicsWebGL.html

5. A More Accessible Map \- A List Apart, https://alistapart.com/article/cssmaps/

6. ARIA: slider role \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/slider\_role

7. content/files/en-us/web/accessibility/aria/reference/roles/slider\_role/index.md at main \- GitHub, https://github.com/mdn/content/blob/main/files/en-us/web/accessibility/aria/reference/roles/slider\_role/index.md?plain=1

8. HTML Accessibility \- Paul J. Adam, https://pauljadam.com/demos/canvas.html

9. Making three dimensional web user interfaces accessible \- Bogdan Cerovac, https://cerovac.com/a11y/2021/06/making-three-dimensional-web-user-interfaces-accessible/

10. ELI5: Discrete Global Grid System (DGGS) | Spatial Paralysis, https://spatialparalysis.xyz/blog/dggs-eli5/

11. Exploring the possibility of adding DGGS support to the S-100 Universal Hydrographic Data Model \- IHR, https://ihr.iho.int/articles/exploring-the-possibility-of-adding-dggs-support-to-the-s-100-universal-hydrographic-data-model/

12. How to make diagrams more accessible \- JointJS, https://www.jointjs.com/blog/diagram-accessibility

13. WAI-ARIA Graphics Module \- W3C, https://www.w3.org/TR/graphics-aria-1.0/

14. Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile, https://w3c.github.io/Mobile-A11y-TF-Note/TouchProposal\_Discussion.html

15. WAI-ARIA 1.0 Authoring Practices \- W3C, https://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/

16. Keyboard Navigation Best Practices for Web Apps | FocusFlow, https://focusflowapp.in/blog/keyboard-navigation-best-practices

17. Accessible Map Recommendations | Macmillan Learning, https://go.macmillanlearning.com/rs/122-CFG-317/images/Accessible%20Map%20Recommendations.pdf?version=0

18. ArcGIS Experience Builder Accessibility and Usability Information, https://kb.wisc.edu/accessibility/159221

19. An Introduction to High Contrast Accessibility \- DEV Community, https://dev.to/mpriour/an-introduction-to-high-contrast-accessibility-4im4

20. Review Request for prefers-contrast media query · Issue \#663 \- GitHub, https://github.com/w3ctag/design-reviews/issues/663

21. Styling for Windows high contrast with new standards for forced colors \- Microsoft Edge Blog, https://blogs.windows.com/msedgedev/2020/09/17/styling-for-windows-high-contrast-with-new-standards-for-forced-colors/

22. How Do You Meet WCAG 2.4.11 Focus Appearance Minimum? \- TestParty, https://testparty.ai/blog/wcag-focus-appearance-minimum

23. GIS accessibility guidance: Experience Builder \- Mass.gov, https://www.mass.gov/info-details/gis-accessibility-guidance-experience-builder

24. Investigating VR Accessibility Reviews for Users with Disabilities: A Qualitative Analysis \- arXiv, https://arxiv.org/html/2508.13051v1