Original analysis and research design · Measurements refer to the identified reference; compare its digest with the current ZIP. No peer review or independent replication is claimed.
ORIGINAL RESEARCH DESIGN · STATIC EVIDENCE AND PROPOSED EVALUATION
Abstract
Accessibility history concerns the actions software makes possible, the information it exposes, and the conditions under which people can participate. A screenshot preserves only part of that history. This paper uses measured interface resources from EQ The Outer Brood (TOB) client — Release Client #630, September 11, 2025 — to define a reproducible accessibility investigation. XML and HTML resources provide identifiable candidates for studying navigation, state, scaling, and information delivery. Their counts do not establish accessible names, keyboard operation, assistive-technology compatibility, or anyone’s experience. The completed work here is an evidence assessment and a detailed research design. No client execution, accessibility-API inspection, keyboard experiment, or participant study is reported. The proposed protocol explains how future observations could become useful historical evidence without mistaking a plan for a result.
1. What the existing evidence contains
The reference inspection counted 728 elements in EQUI_KeyRingWnd.xml, including 6 Page, 6 Listbox, 12 Button, and 17 TooltipReference elements. These are parser totals. They do not identify 12 simultaneously visible buttons or show how a tooltip is delivered. Definitions may be reused, hidden, conditional, or interpreted by executable logic outside the inspected markup.
The Respawn XML contains 96 elements. Its HTML counterpart contains 11 start tags, including custom eq-button, eq-list, and eq-progress-bar forms. This vocabulary supports a sampling decision: investigate a choice, a list, and a changing quantity. It does not prove that equivalent controls exist in a running session. The two retained representations cannot establish which engine was active or that both were selectable.
Inventory’s 962-byte HTML entry includes 5 fragments. The literal include graph reaches 6 files totaling 159,775 bytes. An accessibility inspection confined to the entry could therefore omit relevant presentation definitions. Even that resolved subset excludes unmeasured executable, styling, and runtime relationships. Inspection record; Relationship record.
2. Why interaction evidence belongs in software history
An interface encodes assumptions about attention, dexterity, vision, hearing, memory, and available equipment. Those assumptions deserve study alongside rendering techniques and file formats. A menu that looks unchanged may acquire a new navigation route. A larger visual label may remain unavailable to another information channel. Conversely, a resource with unfamiliar syntax may participate in a usable interaction. Historical interpretation needs evidence about those differences rather than a ranking based on markup fashion.
For a long-maintained game, the research question is especially useful: how can presentation technology change while habitual actions remain recognizable? A dated client can help separate continuity in appearance from continuity in interaction, provided the corresponding environment is documented. The significance is not confined to this game. Maintaining learned workflows while replacing components is a recurring software-development problem. This reference offers an identified object from which to formulate a specific investigation, rather than proof of a general trend.
3. A model that separates representation from access
Use four records for each candidate control: its stored representation, its rendered appearance, its input behavior, and its exposed machine-readable information. Link them using a local study identifier. Do not assume a one-to-one correspondence: one file can describe multiple objects, one object can have multiple interaction states, and multiple objects may jointly complete a task.
A claim such as “the selection is available without a pointer” requires an observed route from a declared starting state to the target state. A claim such as “the selection is announced” requires a defined information channel and a recorded state transition. Neither follows from finding a list-related tag. A missing observation should remain unknown unless the test actually exercised the relevant condition. This separation prevents a convenient source count from becoming a substitute for user-facing evidence.
Microsoft’s UI Automation model distinguishes an element tree, properties, supported control patterns, and events. These provide an inspection vocabulary; the documentation does not establish that this client implements them. Microsoft UI Automation overview.
4. Standards as declared analytical lenses
WCAG 2.2 supplies testable web-accessibility criteria addressing keyboard use, focus, perception, and programmatic information. This paper does not assess conformance or establish that those criteria legally govern this game. W3C WCAG 2.2.
WCAG2ICT offers informative guidance for non-web software; it does not itself set requirements. The December 2025 note cited here postdates this reference. Using it now is a declared retrospective lens, not evidence of a September 2025 obligation. W3C WCAG2ICT, December 11, 2025.
WAI-ARIA describes semantics conveyed through supporting user agents and accessibility APIs. A custom HTML tag is not evidence that such mappings or keyboard behavior exist. This distinction matters when interpreting the selected eq- vocabulary. W3C WAI-ARIA 1.2.
5. Questions and sampling before execution
Predeclare three questions. Can a bounded selection task be completed without a pointer? Does a change of selection or progress produce distinguishable information through the chosen inspection and assistive channels? Does enlarging presentation preserve the selected task’s content and action route? These questions concern a particular task and environment; answering them would not characterize the whole game.
Choose candidate windows from the measured inventory, then establish runtime availability independently. Key Ring suggests category and list-selection questions; Respawn suggests selection and progress questions; Inventory suggests navigation among grouped views. A candidate that cannot be reached in the authorized environment is reported as unavailable to test. Do not substitute a different window silently. Record every exclusion and avoid selecting only windows that produce a favorable demonstration.
6. A bounded task matrix
| Task | Observation to collect | Interpretation boundary |
|---|---|---|
| Enter, traverse, leave | Route into a candidate window, visited targets, exit route, resulting focus | One route cannot establish coverage of every command |
| Choose a category and entry | Initial state, input sequence, visible and exposed selection changes | A label alone cannot establish the underlying item rule |
| Observe a bounded status change | Before/after value, timing, event, and available feedback | Without a verified state change, feedback absence is inconclusive |
| Repeat at enlarged presentation | Content clipping, overlap, target location, task completion | A single display condition cannot represent all low-vision needs |
Specify the endpoint in observable terms before each attempt: a particular category is selected, a declared window is closed, or an identified status changes. Avoid consequential actions, purchases, or irreversible gameplay events as test endpoints. A minimal authorized demonstration is preferable to completing a broad gameplay loop merely to obtain interface observations.
7. Environment and authorization record
Begin with a lawfully held copy and an authorized environment. Record the reference digest, relevant member hashes, operating-system build, display resolution, scaling settings, input layout, graphics configuration, and inspection-tool versions. Describe the UI configuration without publishing personal settings or paths. Keep an unmodified baseline and a separate working copy so that exploratory changes cannot silently alter the historical reference.
A disconnected or otherwise isolated setup may be insufficient to reach some windows. Treat that as a study limitation. Do not infer server responses, bypass access controls, or substitute a recreation while calling it the original service. If a separately authorized runtime supplies a task, identify its role and differences without publishing credentials or connection details. No runtime or service is supplied by this paper, and no such execution has been performed.
8. Keyboard, focus, and recovery protocol
For each reachable candidate, establish a reproducible starting view. Put the pointer aside, record the initial focus evidence, and attempt the declared task using documented or discoverable keyboard actions. Preserve the input sequence and distinguish a moving highlight from an actual selection. Record whether leaving and reopening the window restores a predictable location. A failure to discover a shortcut is different from demonstrating that no shortcut exists.
Count task completion, interventions, route length, and recovery steps. Define an intervention as external help or a change of input method needed to proceed. Choose a stopping rule beforehand; a fixed attempt budget limits ambiguity and fatigue. Repeat the baseline to detect accidental state changes. Compare a pointer-assisted attempt only as a diagnostic reference, not as proof that another input route must work identically.
9. Names, roles, state, and assistive output
Capture a minimal inspection record before and after one deliberate change. Ask whether the target can be distinguished from adjacent objects, whether its function is represented, and whether its selected, disabled, or expanded state changes consistently with visible behavior. Store only fields needed for the question. An apparently empty inspection tree is initially a tool-and-environment observation, not a verdict about every assistive technology.
Check the same inspection tool against a small independently authored control fixture on the same desktop. If the fixture is also unreadable, investigate the setup before attributing the result to the client. Test an explicitly named assistive-technology configuration separately if authorized and available. API exposure and actual spoken or braille output are different observations. Report contradictions rather than choosing whichever channel supports the preferred conclusion.
10. Scaling and sensory information
The publisher’s May 2023 announcement described incremental conversion and scaling while retaining a familiar appearance. That statement motivates a comparison; it does not establish this copy’s behavior. Publisher UI-engine announcement.
Vary one enlargement mechanism at a time, then repeat the same task. Separate operating-system scaling, application scaling, and display resolution. Record clipping and overlap against declared content regions rather than relying on a general impression of readability. Changing all three at once would make a difference difficult to explain.
For a chosen status, inventory the available visual, textual, and audible cues. Describe whether two task-relevant states remain distinguishable when one cue is unavailable. This is a proposed information-channel test, not a simulation of a disability. Do not deliberately expose participants to flashing or distressing stimuli. Unexpected sensory risks are grounds to stop and document the limit.
11. Controls, confounds, and analysis
Start with an unchanged configuration, repeat it, introduce one declared variation, and restore the baseline. Preserve failed restoration as a result. If different engines can be selected through supported means, compare matched tasks and record the selection evidence. Coexisting XML and HTML files alone cannot create an engine comparison. If only one representation is reachable, restrict the claim accordingly.
Define completion proportion as completed attempts divided by eligible attempts, with exclusions listed separately. Report both numbers; a percentage can hide a very small sample. Summarize route length and intervention counts per task, without combining them into an unexplained accessibility score. Familiarity, fatigue, task order, display hardware, latency, custom configuration, and inspection-tool behavior can all confound comparisons. Counterbalance order where practical and retain deviations from the protocol.
With no participant observations, the investigator can report reproducible technical behavior only. Even a successful task does not establish comfort, sustained use, or inclusion. Those questions require an appropriately designed study with people whose experiences are relevant.
12. Participant privacy and useful negative findings
Any later study involving people needs understandable consent, voluntary participation, accessible instructions, a withdrawal process, and any applicable ethics review. Do not recruit participants under a claim that this archive has approved a study. No participants or approvals are claimed here. A technical pilot should use synthetic task content where possible and avoid collecting diagnoses or account histories that the question does not require.
Separate any necessary consent records from research outputs. Publish aggregated observations or sanitized task traces rather than names, voices, character names, chat, home paths, or account identifiers. Screen and event captures can contain incidental personal information; reduce their scope before recording and review them before sharing. A short structured observation may preserve the necessary evidence with much less exposure than an unrestricted video.
Negative findings are useful when their conditions are precise. “The target state could not be reached under this declared setup” preserves a boundary for the next investigator. “This game is inaccessible” exceeds it. Missing provider information, unstable focus, or an unsuccessful restoration can each become a reproducible question, provided alternatives and tool checks accompany the report.
13. Preservation outputs and proportionate inputs
A valuable contribution would combine an exact question, sufficient input identifiers, task script, environment description, sanitized observations, controls, and unresolved explanations. Record what would falsify the interpretation. A future maintainer could then compare interaction evidence with a changed representation instead of relying on memory or a screenshot alone.
The public measurements are sufficient to review this paper’s selection rationale. Selected lawful markup may be sufficient for a structural follow-up; a runtime question needs additional authorized context. The research design does not demonstrate that every investigator needs the complete installation or decide distribution rights. Client ZIP and torrent access remain available through the existing download flow. After studying material, readers are encouraged to prepare methods, corrections, and inconclusive results using the contribution guidance; no application or upfront contact is required.
The historical value lies in preserving distinctions: a declared control and an operable control, visual continuity and interaction continuity, a missing observation and a demonstrated limitation. This paper supplies an auditable path toward those distinctions. The runtime evidence remains to be collected.
CONTINUE READING