Geospatial Site Selection and Locked Context Handoff: Architectural and UX Specifications for Deterministic Simulations

Full report

On this page

The integrity of a geospatial simulation relies entirely on the absolute provenance, stability, and durability of its spatial inputs. In complex planetary simulations—particularly those modeling highly sensitive, fictional nuclear events—the location selected by a user serves as the foundational causal context for all subsequent mathematical modeling, consequence analysis, and deterministic replay. When software architectures fail to preserve the exact spatial coordinates generated by a 3D globe interaction, substituting them with generic, editable configuration fields, they introduce cascading precision loss, coordinate drift, and erosion of user trust. This document establishes an exhaustive specification for the capture, preservation, display, validation, and passing of map-selected locations into an event-sourced simulation workflow. Leveraging established standards from geographic information systems (GIS), the Institute of Electrical and Electronics Engineers (IEEE), the World Wide Web Consortium (W3C), and the Open Geospatial Consortium (OGC), this framework ensures that a map-selected site remains an immutable, understandable, and strictly auditable scenario input.

1. Recommended Site-Selection Contract

The architectural relationship between an interactive 3D globe and a simulation event creator must operate under a strict, unidirectional data contract. The 3D globe is the sole authoritative source for spatial initialization; the event creator is exclusively a downstream consumer and contextualizer of that spatial data.

1.1 Capture at Click Time

When a user interacts with the 3D globe, the application must translate the two-dimensional screen-space pixel interaction into a three-dimensional Cartesian coordinate, and subsequently into a geodetic coordinate. Advanced web-based geospatial rendering engines, such as CesiumJS, provide specific mechanisms for this. The application must prioritize raycasting against the underlying terrain and 3D tilesets (e.g., via scene.pickPosition) to capture precise elevation data1. If the click falls outside rendered terrain, the system must fallback to raycasting against the reference ellipsoid (e.g., via camera.pickEllipsoid) to ensure a valid intersection with the planetary body2. At the exact millisecond of this intersection, the application captures:

• The raw geodetic coordinates (Latitude, Longitude, Altitude).
• The 3D camera's transform matrix, viewing direction, and frustum4.
• The real-world interaction timestamp.
• The active in-simulation date and time.

1.2 Immutability and Handoff

Upon successful capture, the coordinates undergo a locked context handoff into the event creator interface. From this moment forward, the coordinate values are rendered strictly immutable. They form the permanent anchor of the simulation branch. The user is deliberately prevented from typing over the coordinates or manually adjusting the numeric latitude/longitude strings. Permitting manual coordinate entry severs the visual-spatial link established by the globe click, invalidating the camera snapshot and introducing the risk of typographical errors that could silently drastically alter the simulation outcome.

1.3 Asynchronous Enrichment and Fallback Mechanisms

Once the immutable coordinate is secured, a background worker initiates a reverse-geocoding request to enrich the coordinate with human-readable semantic data (e.g., place names, administrative hierarchies, land/water classification)6. This enrichment is strictly decorative and contextual; it is never permitted to overwrite or "snap" the authoritative coordinate to a nearby feature centroid6. If the reverse-geocoding service experiences network failure, times out, or returns an unacceptably low confidence score, the simulation creation process must not be blocked. The application seamlessly substitutes the missing semantic label with a raw geographic description (e.g., "Unknown Location" or "Oceanic Region") while utilizing the flawless immutable coordinate for all underlying physical calculations.

1.4 Site Alteration and State Preservation

Because the coordinates within the event creator are read-only, the system must provide a dedicated Change site on globe action. Invoking this action triggers a transient state preservation routine. The user's currently inputted configuration parameters (e.g., fictional weapon yield, detonation altitude, atmospheric conditions) are cached in the application's state manager. The interface then dismisses the event creator and restores control to the 3D globe. When the user selects a new location, the previous site record is completely discarded, a new immutable record is generated, and the event creator reappears, automatically re-hydrating the cached configuration parameters over the newly established geographic context.

2. Canonical Location Record

To support auditability, deterministic replay, and seamless data transfer across the application's rendering and simulation layers, the geospatial handoff must be formalized into a Canonical Location Record. This technology-neutral data contract is designed to comply with ISO 19115-1 and ISO 19115-2 standards for geographic information metadata, which provide the framework for documenting spatial provenance, lineage, and spatial representation8. Furthermore, integrating concepts from the W3C PROV-O ontology ensures the origin and transformations of the spatial data are cryptographically trackable10. The following schema defines the Canonical Location Record. In all instances of conflict between semantic names and geographic coordinates, the latitude and longitude fields serve as the absolute authority.

3. Coordinate Precision Policy

The storage, manipulation, and display of spatial coordinates require a rigid precision policy. The application must successfully navigate the tension between the microscopic mathematical precision required by 3D rendering engines and the macro-level contextual understanding required by the human user.

3.1 Storage Precision: The Necessity of IEEE 754 Float64

All coordinate data within the application's memory and database layers must utilize IEEE 754 double-precision floating-point format (binary64 or float64)13. Utilizing single-precision (float32) for global geospatial coordinates introduces catastrophic spatial degradation and visual artifacts known as coordinate drift or jitter18. In the IEEE 754 standard, a float32 value allocates 1 bit for the sign, 8 bits for the exponent, and only 23 bits for the significand (mantissa)20. Because floating-point precision degrades as the magnitude of the number increases, the worst-case scenario for planetary coordinates occurs near the antimeridian (±180° longitude). At this magnitude, a 23-bit significand yields a maximum spatial precision of approximately 1.7 meters at the equator22. When simulation events execute spatial joins, or when the 3D camera attempts to render fine meshes at these coordinates, the 1.7-meter ambiguity causes polygons to flicker (Z-fighting) and vertices to jump erratically19. By contrast, float64 allocates 52 bits to the significand13. This provides approximately 15 to 17 significant decimal digits, resulting in a worst-case precision of 3.16 nanometers on the Earth's surface22. This extreme precision guarantees that the location remains absolute, stable, and deterministic across camera motion, branch reloading, and mathematical transformations23.

3.2 Display Precision and Rounding Rules

While stored at nanometer precision, displaying 15 decimal places in the user interface creates "false precision." Presenting a coordinate as 34.981240918237412 implies an absurdity: that the user intentionally targeted a specific sub-atomic particle. Because the simulation must remain fictional and explicitly avoid optimizing real-world weapons employment, false precision is counterproductive. The user interface must truncate and round display coordinates to 4 or 5 decimal places14. Five decimal places represent an accuracy of approximately 1.11 meters at the equator, providing sufficient granularity to identify specific city blocks or geographic features without implying militant exactitude26. Rounding must follow the IEEE 754 standard for round-to-nearest, ties-to-even (frequently termed Banker's Rounding) to prevent cumulative statistical bias during localized display formatting20.

3.3 Formatting, Localization, and Copying

• Directional Formatting: The application must utilize signed Decimal Degrees (DD) format rather than Degrees, Minutes, Seconds (DMS)26. Negative values denote South and West (e.g., \-34.1234, 118.1234). ISO 6709 standards for geographic point location advocate for standardized machine-readable strings29. Decimal Degrees minimize parsing ambiguity when users copy data into external analytic tools.
• Approximate Labels: If the reverse geocoder returns a label\_confidence score below an established threshold (e.g., 0.60) due to low-density polygon mapping6, the UI must prepend a tilde (\~) to the place label (e.g., \~Mojave Desert). However, the numeric coordinate must never be marked as approximate, as the raycasted coordinate represents absolute truth.
• Copying Behavior: When a user highlights and copies the coordinate string from the interface, the clipboard must receive the rounded display value (e.g., 5 decimal places), ensuring complete symmetry between what the user perceives and what they extract.

4. Interface Specification

The site card acts as the visual terminus of the locked context handoff. Its design must instantly communicate that the location is established, immutable, and foundational to the surrounding scenario parameters.

4.1 Desktop and Mobile Wireframes

Desktop Interface (Sidebar/Modal Overlay) The site card sits permanently at the top of the event creator hierarchy. \+---------------------------------------------------------+ | \[ High-Resolution Minimap Centered on Impact Marker \] | | | | 📍 \~24km SW of Albuquerque, New Mexico | | 34.98124, \-106.81239 | | | | Geography: Land (Continental US) | | Sim Date: Oct 23, 2026 | Branch: Alpha-Primary | | | | \[ ✏️ Change site on globe \] | \+---------------------------------------------------------+ | Configuration Options | | \[ Fictional Event Type Dropdown \] | | \[ Yield Parameters \] | \+---------------------------------------------------------+

Mobile Interface (Full Screen Stack) On mobile viewports, screen real estate is heavily constrained. The interface discards the minimap to prioritize data density, relying on the user to utilize the Preview on globe functionality for spatial orientation. \+---------------------------------------------------------+ | \< Back to Main Menu \[ Preview 👁️ \] | \+---------------------------------------------------------+ | SITE CONTEXT | | 📍 \~24km SW of Albuquerque, New Mexico | | 34.98124, \-106.81239 | | \[ ✏️ Change site \] | \+---------------------------------------------------------+ | EVENT PARAMETERS | | \[ Fictional Event Type Dropdown \] | \+---------------------------------------------------------+

4.2 Accessibility: Read-Only Semantics vs. Disabled Controls

A common anti-pattern in UI design is placing immutable data inside a standard text input field and applying the HTML disabled attribute. From an accessibility and usability standpoint, this is highly detrimental. Disabled form fields are explicitly removed from the keyboard tab order, preventing keyboard-only users from navigating to them31. Furthermore, disabled text suffers from severely degraded color contrast (often rendering as faint gray), failing WCAG 2.2 Level AA contrast requirements32, and the text cannot be highlighted or copied by screen readers or typical cursor interactions. To maintain WCAG compliance while enforcing immutability, the coordinates must be rendered using standard text elements (e.g., \<p\> or \<span\>). If the design system rigidly mandates that the data visually resemble a form field, the element must utilize the WAI-ARIA attribute aria-readonly="true"34. This semantic marker instructs assistive technologies that the element is fully perceivable, focusable, and copyable, but its value cannot be mutated by the user35. This approach preserves the integrity of the locked handoff without disenfranchising users reliant on assistive devices.

5. Edge-Case Matrix

The mapping of continuous geometric space into discrete geopolitical and environmental boundaries generates numerous edge cases. The application handles these scenarios by subordinating semantic labeling to coordinate truth, often leveraging Discrete Global Grid Systems (DGGS)—such as H3 or S2—to perform high-speed, hierarchical spatial indexing and neighbor analysis37.

6. Preview and Confirmation Behavior

When a user wishes to visually verify their targeted location prior to committing to the simulation calculations, the "Preview on globe" capability must orchestrate a complex state transition without compromising the data payload in the event creator.

6.1 Camera Movement and Focus Restoration

Initiating the preview transitions the event creator out of the viewport. The 3D engine parses the globe\_camera\_snapshot stored within the location record. Utilizing the stored 4x4 transform matrix—which encapsulates position, heading, pitch, and roll4—the camera executes a smooth interpolation (flight) back to the exact viewing frustum active at the time of the click. During the preview, a high-contrast map marker designates the coordinate. If the user subsequently pans or rotates the camera, the underlying Canonical Location Record is unaffected. The camera and the data model operate in total isolation4. To return, an explicit "Return to Event Creator" overlay is presented. Clicking this overlay restores the modal with all transient form states (e.g., selected weapon yield, event type) fully preserved. To comply with accessibility best practices, keyboard focus is automatically shifted back to the "Preview on globe" button upon restoration, maintaining predictable tab ordering32.

6.2 Line-of-Sight, Occlusion, and Reduced Motion

The preview marker must respect the physical topology of the 3D globe. By executing depth tests against the terrain models (e.g., leveraging Cesium's depth-buffer capabilities), the marker accurately occludes behind mountains or buildings, reinforcing the spatial reality of the site1. If the user zooms out to a planetary scale, the marker must logarithmically scale to remain visible without obscuring the exact geographic coordinate. To support users with vestibular disorders, the application must query the operating system's prefers-reduced-motion CSS media feature. If enabled, the camera flight animation is completely bypassed, resulting in an instantaneous cut to the saved camera transform, thereby satisfying WCAG 2.2 animation interaction guidelines32.

7. Historical and Political Context

As an educational simulation capable of modeling events across varied timelines, the system must navigate the fluid nature of human political geography while anchoring itself to the static nature of planetary geometry. The geographic coordinate is the absolute truth; the semantic place label is a volatile, temporally dependent abstraction. The application strictly segregates these concepts. When the reverse geocoder is invoked, it must pass the simulation\_date as a query parameter. This ensures the bounding boxes and polygons assessed reflect the political reality of that specific era (e.g., rendering "Leningrad" rather than "St. Petersburg" if the simulation date is set to 1985). Furthermore, the simulation explicitly avoids adjudicating sovereignty. Relying on neutral disclosure patterns, the interface refuses to mask disputed coordinate spaces. The underlying consequence-analysis algorithms (which calculate fallout, thermal radiation, or hydrodynamic displacement) operate purely on the mathematical boundaries of the Discrete Global Grid Systems38 and remain entirely oblivious to the political names applied to the surface. Fictional labels (e.g., user-generated scenario names) are strictly quarantined to the branch\_name or scenario\_title attributes and are never merged with the geographic metadata.

8. Integrity and Replay Requirements

Scientific modeling and robust simulation ecosystems demand deterministic replay. If an analyst or student executes a scenario today, the application must be capable of generating the exact same causal context and downstream consequences when the branch is reloaded years later43.

8.1 Event-Sourced Architecture

To achieve absolute determinism, the application must utilize event-sourced state management. In this paradigm, state is not mutated in place; rather, every change is recorded as an immutable event in an append-only log12.

• Immutability of the Click: Selecting a site emits a SITE\_SELECTED event carrying the serialized Canonical Location Record. The simulation engine processes this exact payload and is strictly forbidden from re-casting or re-geocoding the coordinate at runtime12.
• Decoupled Rendering: Camera manipulations emit CAMERA\_MOVED events that update the rendering state but are purposefully ignored by the simulation state machine44.
• Explicit Provenance (Lineage): If a user clicks "Change site on globe", the system does not overwrite the old location. It appends a new SITE\_REVISED event. This creates a highly auditable chain of custody (lineage), allowing researchers to track the exact evolution of the user's decision-making process10.
• Mathematical Determinism: When a branch is reloaded, the application rebuilds the state by folding the event log sequentially. Because the IEEE 754 float64 coordinates are perfectly serialized, the spatial initiation point of the event is guaranteed to be mathematically identical across every replay43.

9. Accessibility Requirements

Navigating and interacting with a 3D WebGL globe presents profound barriers for users relying on assistive technologies or keyboard-only navigation. The application must dismantle these barriers, adhering to Web Content Accessibility Guidelines (WCAG) 2.2 Level AA and AAA standards where possible48.

9.1 Touch Precision and Target Sizing

Mobile interactions require generous touch targets to accommodate users with limited fine motor control or hand tremors. Under the WCAG 2.2 Success Criterion 2.5.8 (Target Size Minimum), interactive elements must possess a target size of at least 24x24 CSS pixels49. However, to achieve superior usability (and align with Level AAA standards), the "Change site on globe" button and all map interaction overlays must be engineered to a minimum of 44x44 or 48x48 CSS pixels51. Adequate spacing (minimum 8px) must separate interactive targets to prevent accidental misclicks49.

9.2 ARIA Landmarks and Keyboard Focus

The event creator interface must be programmatically structured using WAI-ARIA 1.2 landmark regions (e.g., \<main\>, \<aside\>, \<nav\>) to allow screen reader users to rapidly orient themselves and jump between the globe context and the configuration form53.

• Visible Focus: Keyboard focus indicators must satisfy WCAG 2.4.11 (Focus Appearance), ensuring a minimum 3:1 contrast ratio against the background color, with a bounding box outline no thinner than 2 CSS pixels54.
• Coordinate Phrasing: Raw coordinate strings (e.g., 34.98124) are cognitively exhausting when read aloud sequentially by a screen reader. The interface must utilize an aria-label to provide conversational phrasing (e.g., aria-label="34 point 9 8 1 degrees North, 106 point 8 1 2 degrees West")56.

9.3 Accessible Alternatives to 3D Navigation

Because operating a 3D globe requires complex pointer inputs, the application must provide a fully keyboard-accessible alternative for site selection. This is achieved via a text-based Gazetteer—an autocomplete search input bound by role="searchbox" and aria-autocomplete="list"58. When a user navigates this list via keyboard and selects a location, the application queries the gazetteer database, extracts the centroid coordinate of the resulting polygon, and programmatically generates a Canonical Location Record. This perfectly simulates a raycasted map click, seamlessly injecting the keyboard-only user into the standard locked context handoff workflow.

10. Acceptance Test Suite

To guarantee the integrity of the locked context handoff, the following 50 acceptance tests must be integrated into the application's automated testing pipeline (e.g., Cypress, Playwright).

Works cited

1. Scene.pick returning point inside the globe \- CesiumJS \- Cesium Community, https://community.cesium.com/t/scene-pick-returning-point-inside-the-globe/18940

2. What is the correct way to convert screen coordinates to Cartesian3 \- Cesium Community, https://community.cesium.com/t/what-is-the-correct-way-to-convert-screen-coordinates-to-cartesian3/2851

3. How to get cartographic/cartesian3 coordinates on mouse click \- Google Groups, https://groups.google.com/g/cesium-dev/c/mwW1mQ7kKgw

4. Camera \- Cesium Documentation, https://cesium.com/downloads/cesiumjs/releases/1.8/Build/Documentation/Camera.html

5. Camera \- Cesium Documentation, https://cesium.com/learn/ion-sdk/ref-doc/Camera.html

6. Geocoding: Delivering High Location Accuracy \- Esri, https://www.esri.com/arcgis-blog/products/analytics/analytics/geocoding-delivering-high-location-accuracy

7. What's included in the geocoded results | ArcGIS Pro documentation \- Esri, https://doc.esri.com/en/arcgis-pro/latest/help/data/geocoding/what-is-included-in-the-geocoded-results-.html

8. ISO 19115 | DCC \- Digital Curation Centre, https://www.dcc.ac.uk/resources/metadata-standards/iso-19115

9. A Guide to ISO 19115-1 \- DDI \- Confluence, https://ddi-alliance.atlassian.net/wiki/spaces/DDI4/pages/548405259/ISO+19115+Geographic+Information+--+Metadata

10. Geospatial Lineage Fundamentals & Architecture · Provenance Tracking, https://www.provenance-tracking.com/geospatial-lineage-fundamentals-architecture/

11. PROV-O: The PROV Ontology \- W3C, https://www.w3.org/TR/prov-o/

12. Event-Sourced State Management \- Emergent Mind, https://www.emergentmind.com/topics/event-sourced-state-management

13. Double-precision floating-point format \- Wikipedia, https://en.wikipedia.org/wiki/Double-precision\_floating-point\_format

14. Precision of coordinates \- OpenStreetMap Wiki, https://wiki.openstreetmap.org/wiki/Precision\_of\_coordinates

15. Accuracy of Decimal Places in Latitude and Longitude Degrees | Garmin Customer Support, https://support.garmin.com/en-US/?faq=hRMBoCTy5a7HqVkxukhHd8

16. What is meant with EPSG:4326 projection \- GIS Stack Exchange, https://gis.stackexchange.com/questions/387517/what-is-meant-with-epsg4326-projection

17. What is WGS84 | Virtual Surveyor \- Support Portal, https://support.virtual-surveyor.com/support/solutions/articles/1000261351-what-is-wgs84-

18. RayJoin: Fast and Precise Spatial Join \- Liang Geng, https://gengl.me/public/publications/ics24.pdf

19. Rendering Models with High Precision in Global Scenes \- Re:Earth Engineering, https://reearth.engineering/posts/high-precision-rendering-en/

20. IEEE 754 \- Wikipedia, https://en.wikipedia.org/wiki/IEEE\_754

21. Single-precision floating-point format \- Wikipedia, https://en.wikipedia.org/wiki/Single-precision\_floating-point\_format

22. Using Floating-Point Numbers to Represent Geographic Coordinates \- Aapeli Vuorinen, https://www.aapelivuorinen.com/blog/2023/06/30/floats-for-coordinates/

23. (Big worlds) Will ever a Built-In solution for Float Precision Loss be? \- Unity Discussions, https://discussions.unity.com/t/big-worlds-will-ever-a-built-in-solution-for-float-precision-loss-be/1697586?page=2

24. python \- The real difference between float32 and float64 \- Stack Overflow, https://stackoverflow.com/questions/43440821/the-real-difference-between-float32-and-float64

25. Measuring accuracy of latitude and longitude \- GIS Stack Exchange, https://gis.stackexchange.com/questions/8650/measuring-accuracy-of-latitude-and-longitude

26. GPS Coordinate Precision: Decimal Degrees and DMS Formats \- Industrial Monitor Direct, https://industrialmonitordirect.com/blogs/knowledgebase/gps-coordinate-precision-decimal-degrees-and-dms-formats

27. encoding \- proper/best type for storing latitude and longitude \- Stack Overflow, https://stackoverflow.com/questions/385132/proper-best-type-for-storing-latitude-and-longitude

28. 1\. Introduction — Floating Point and IEEE 754 12.3 documentation, https://docs.nvidia.com/cuda/archive/12.3.0/floating-point/index.html

29. ISO 6709 \- Wikipedia, https://en.wikipedia.org/wiki/ISO\_6709

30. International standard ISO 6709:2022 \- Afnor EDITIONS, https://www.boutique.afnor.org/en-gb/standard/iso-67092022/standard-representation-of-geographic-point-location-by-coordinates/xs138461/335073

31. WAI-ARIA: aria-disabled (State) \- DigitalA11Y, https://www.digitala11y.com/aria-disabled-state/

32. What's New in WCAG 2.2 \- Accessibility.Works, https://www.accessibility.works/blog/wcag-2-2-guide/

33. WebAIM's WCAG 2 Checklist, https://webaim.org/standards/wcag/checklist

34. ARIA: aria-readonly attribute \- MDN Web Docs, https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-readonly

35. Supported States and Properties | Accessible Rich Internet Applications (WAI-ARIA) 1.0, https://www.w3.org/TR/wai-aria-1.0/states\_and\_properties

36. WAI‑ARIA Explained: A Guide to Accessible Rich Internet Applications, https://www.levelaccess.com/blog/wai-aria-explained-a-guide-to-accessible-rich-internet-applications/

37. Discrete global grid \- Wikipedia, https://en.wikipedia.org/wiki/Discrete\_global\_grid

38. S2 \- H3, https://h3geo.org/docs/comparisons/s2/

39. Applied open-source Discrete Global Grid Systems \- AGILE-GISS, https://agile-giss.copernicus.org/articles/3/41/2022/

40. Full article: Area and shape distortions in open-source discrete global grid systems, https://www.tandfonline.com/doi/full/10.1080/20964471.2022.2094926

41. Discrete Global Grid Systems \- UNIGIS Salzburg, https://unigis.at/en/discrete-global-grid-systems-2/

42. Camera \- Cesium Documentation, https://cesium.com/downloads/cesiumjs/releases/b29/Documentation/Camera.html

43. Distributed Time-aware Provenance \- Andreas Haeberlen, https://haeberlen.cis.upenn.edu/papers/dtap-vldb2013.pdf

44. PROV2R: Practical Provenance Analysis of Unstructured Processes \- CS-UCY, https://www.cs.ucy.ac.cy/\~elathan/papers/toit17.pdf

45. Distributed Time-aware Provenance \- VLDB Endowment, https://www.vldb.org/pvldb/vol6/p49-zhou.pdf

46. Differential Provenance: Better Network Diagnostics with Reference Events, https://web.eecs.umich.edu/\~chenang/papers/hotnets-2015-diffprov.pdf

47. SACS: A Reproducible, Configuration-Driven Software Framework for Schematic Multi-Region Circuit Simulation and Integrated Analytics \- ResearchGate, https://www.researchgate.net/publication/410770140\_SACS\_A\_Reproducible\_Configuration-Driven\_Software\_Framework\_for\_Schematic\_Multi-Region\_Circuit\_Simulation\_and\_Integrated\_Analytics

48. Web Content Accessibility Guidelines (WCAG) 2.2 \- W3C, https://www.w3.org/TR/WCAG22/

49. Accessible tap targets \- web.dev, https://web.dev/articles/accessible-tap-targets

50. What Is the WCAG 2.5.8 Target Size Minimum and How Do You Meet It? \- TestParty, https://testparty.ai/blog/wcag-target-size-guide

51. Accessible Target Sizes \- Craft CMS, https://craftcms.com/blog/accessible-target-sizes

52. SC 2.5.8 Target Size (Minimum) \- Is "24 by 24 CSS pixels” reasonable? · Issue \#1831 · w3c/wcag \- GitHub, https://github.com/w3c/wcag/issues/1831

53. Landmark Regions | APG | WAI \- W3C, https://www.w3.org/WAI/ARIA/apg/practices/landmark-regions/

54. \[WCAG 2.2 Feedback\] Success Criterion 2.4.11 Focus Appearance (Minimum) (Level AA) \#1896 \- GitHub, https://github.com/w3c/wcag/issues/1896

55. Insufficient focus indication \- Evinced Knowledge Base, https://knowledge.evinced.com/system-validations/insufficient-focus-indication

56. ARIA Landmark Roles | Accessibility \- University of Arkansas, https://accessibility.uark.edu/accessible-technology/developing-accessible-websites/aria-landmark-roles.php

57. WAI-ARIA Landmarks and Screen Readers \- The University of Melbourne, https://www.unimelb.edu.au/accessibility/aria/wai-aria-landmarks-and-screen-readers

58. WAI-ARIA Authoring Practices 1.2 \- W3C, https://www.w3.org/TR/2018/WD-wai-aria-practices-1.2-20180719/

59. WAI-ARIA Authoring Practices 1.2 \- W3C, https://www.w3.org/TR/2021/NOTE-wai-aria-practices-1.2-20211129/