Resolving Accessibility Focus Loss before Desktop Mode Launch

Everyone is here, so let's begin. Daniel and Nora represent Window Management, Jun joins from Accessibility Engineering, and Elena owns System Qualification. The Vale desktop-mode launch candidate is due to freeze on October twenty-second. Yesterday's dock test found that screen-reader navigation stops after an external monitor is disconnected and reconnected. The picture and mouse pointer look normal, which is why the visual smoke test missed it. We need to understand the failure, agree on a usable recovery path, and decide whether automatic workspace restoration belongs in the launch build. Please make the user impact clear before we discuss the schedule.

The user can hear the connection sound but cannot discover a focused control on the external workspace. Keyboard arrows still move application selection visually, yet the screen reader announces nothing. Touch navigation on the handset sometimes remains available, but our default dialog appears on the external display, so the user may not know where to continue. Asking them to turn accessibility off and on is not an acceptable launch recovery. The feature must communicate where focus moved and provide a path that works without sight. We should treat this as loss of independent control, not merely a missing spoken message.

I have the window traces from the failing reconnect. Input focus points to a valid application window, which explains why keyboard events still work. Accessibility focus is a separate state, and its restoration request names a node from the previous display session. The new display has a different window tree, even when the monitor is physically the same. Our workspace-restoration module remembers the last selected application and sends a focus request before the new root is exposed to accessibility. That ordering is suspicious, but I need to check whether the failure is caused by an early request or by a request that can never be valid.

The failure reproduced in seven of ten reconnect cycles with automatic restoration enabled. With restoration disabled, manual desktop entry passed all ten cycles using the same dock and applications. That comparison is promising but small. I also noticed that the first connection after a clean boot passes, while subsequent connections fail more often. We should test repeated sessions, not just one disconnect. The qualification script currently asks whether a window is drawn and whether a key is delivered. It needs an observable accessibility outcome, such as reaching a named control and activating it through the screen reader.

I reviewed the restoration code this morning. It persists an application task identifier together with an accessibility node identifier. The task can survive a display disconnect, but the node identifier is meaningful only within its window connection. We should not restore those two values in the same way. Preserving the task helps users keep their work; replaying an old node can leave focus nowhere. Before proposing a large framework change, I want to replay the sequence with node restoration removed and task restoration retained. That will show whether the convenience feature can be separated from the correctness defect.

Let's establish the expected behavior for both connection and disconnection. Jun, what should the user hear, and where should navigation begin? Daniel, identify who owns that transition rather than letting the window manager and workspace module each assume the other has done it. Elena, please preserve a recording of the screen-reader output alongside the window trace. A screenshot cannot tell us whether the user has a usable starting point. I also want the handset path covered, because a correct external workspace is not enough if disconnecting it leaves the phone itself inaccessible.

On connection, the user should receive one concise announcement that the external workspace is available, followed by a valid focus target in its current window tree when they choose to enter it. On disconnection, navigation must return to an available handset control, with an announcement that explains the change. We should avoid automatically reading a whole window hierarchy, which would overwhelm the user. Restoring the exact old node is not required if it no longer exists. Restoring a meaningful context is the goal: the application can remain open, and focus can begin at its current heading or a stable workspace control.

The window manager should publish window availability and input-focus changes, but it should not invent an application node. The workspace controller can request entry after the accessibility tree is ready, and the accessibility service can choose a valid target from that current tree. In the failing trace, the controller sends a remembered node before tree availability, receives a rejection, and never asks again. I will add trace markers for window connection, tree availability, entry request, focus result, and the return-to-handset event. That gives us a causal sequence instead of relying on a delay that happens to work on one monitor.

Removing the remembered node fixes one problem, but a fixed retry delay would still be fragile. A slow application may publish its tree later than our timer, while a fast reconnect could create another session before the retry fires. I propose a request tied to the current window connection, canceled when that connection disappears. It waits for the tree-ready signal and then asks for a semantic starting point, not a numeric node from storage. If the application never exposes a usable tree, we should focus a workspace control that lets the user return to the handset and report the unavailable content.

That gives us three distinct outcomes to test: successful entry into an accessible application, a clearly announced fallback when content is unavailable, and cancellation when the display vanishes. The current script would classify all three as a drawn window and miss the difference. I will add a delayed-tree application and a deliberately unavailable tree as controls. We also need to verify that cancellation does not steal focus from the handset after disconnection. A late external request that moves focus away from the user's active phone task would be a new regression, even if the original reconnect case improves.

The product team wants automatic workspace restoration because it is prominent in the launch demonstration. Disabling it for everyone would change the experience they have prepared. Could we ship the new focus request with a longer qualification window and keep the launch scope? I need your honest assessment of the remaining risk, not just the time needed to write the code. We have four days before the candidate freeze and eight before launch. If the corrected design needs a broader matrix than we can finish, I would rather say that now than negotiate away the tests on Wednesday.

The implementation is small, but the behavior crosses task restoration, display lifecycle, and accessibility-service state. I cannot call it low risk because the patch is short. We need repeated hotplug, application restart, locked-handset transitions, and multiple accessibility services. I recommend deferring automatic entry for this launch while retaining saved tasks. Users would receive an accessible prompt and choose when to enter the external workspace. That path already has broader coverage. We can qualify the event-driven restoration for a maintenance release without making the launch depend on a new lifecycle contract that has only a few days of testing.

I support manual entry as a launch scope decision, provided it is the same coherent experience for all users and is genuinely accessible. Please do not silently disable restoration only when a screen reader is active. That would hide the underlying defect and make behavior change when accessibility settings change. The prompt must be reachable from the handset, clearly state where the workspace will open, and preserve the user's current task. We should test it with keyboard-only navigation and touch exploration. A workaround that requires someone sighted to click the external monitor would not meet the requirement.

There is a clean boundary we can use. The saved task list remains intact, but reconnect no longer initiates automatic entry. The handset presents the existing workspace-entry control, and choosing it creates a fresh focus request against the current display. This does not close applications or discard documents. We must verify that the manual path never reads the stored accessibility node; otherwise we would only move the same bug behind a button. I can trace that today. The event-driven automatic design stays on a separate branch until its lifecycle tests are complete.

I can validate that boundary before the freeze, but the ten passing cycles are not enough to approve it today. I need two dock models, both handset orientations, locked and unlocked states, and two screen-reader configurations. We will also include no-screen-reader controls to confirm that the common launch path remains consistent. The acceptance task is concrete: reconnect, find the handset entry control, enter the workspace, navigate to a named application action, activate it, disconnect, and continue on the handset. A visual frame, an input event, or a spoken connection sound alone cannot substitute for that end-to-end task.

The launch scope will use explicit workspace entry for all users and preserve saved application tasks. Automatic entry is deferred to a later maintenance candidate, subject to full qualification. This is conditional approval of the scope, not approval of today's build. Daniel owns the manual-path trace and node-reference audit by three this afternoon Seoul time. Nora owns the launch change by Monday noon. Jun owns the prompt wording and navigation review by Monday at four. Elena owns the acceptance matrix, with preliminary results Tuesday evening. I will update the demonstration owner and remove any promise of automatic entry from launch material.

I will implement the scope change without adding a new timing heuristic. The launch path will request focus only after the user selects entry and the current window connection is available. Any remembered node from an earlier session will be ignored. I will add a check that a disconnected display cancels pending entry, while saved task state remains available for the next session. The change description will list what users keep and what they must now choose explicitly. That should let product and support explain the experience accurately instead of describing it as a random loss of convenience.

I will review the prompt on the handset with an actual screen-reader workflow, not only inspect its text. The control needs a descriptive label, a predictable position in navigation order, and feedback after activation. If the external content cannot be entered, focus must remain on a usable handset action and the message must explain that the workspace is unavailable. I will also check announcement duplication during rapid reconnects. Repeating the same connection message five times can obscure the action the user needs. We should communicate state changes once and preserve the user's ability to interrupt speech.

My audit will compare input focus, accessibility focus, and active task identity at every transition. I will attach traces for successful manual entry, rejected old-node restoration, and disconnect during a pending request. I will also verify that documents remain in the saved task rather than being recreated as empty windows. We should not solve navigation by throwing away the work users were trying to resume. If the manual path shares an unsafe restoration helper, I will isolate that dependency before Nora's change lands. A feature switch is only a valid containment if the excluded code truly stops running.

The matrix will require successful independent completion in every supported configuration, with no unreachable prompt, lost task, or late focus theft. We will run thirty reconnect cycles per configuration and record the full task result, not just the first successful announcement. Delayed-tree and unavailable-tree controls must reach the documented fallback. I will pair automated traces with screen-reader audio and manual keyboard checks. Any failure that prevents returning to the handset blocks launch approval. Cosmetic wording issues can be reviewed separately, but we will not downgrade a navigation failure to a cosmetic category simply because the screen looks correct.

The launch decision review is Wednesday, October twenty-first, at ten in the morning Seoul time. We will examine Elena's evidence, Jun's usability review, and Daniel's confirmation that the old node path is absent. If the explicit-entry path fails an accessibility gate, we hold desktop-mode approval rather than ask users to disable their tools. If it passes, the October twenty-second freeze can proceed with the narrower feature scope. I will schedule a separate design review for automatic entry on October twenty-eighth. Launch approval will not automatically approve that later feature or inherit its future test results.

For the later design, I want the focus policy agreed before implementation. We should define when restoring context is helpful, when a fresh starting point is clearer, and how a user can decline external entry. The policy must account for a changed application window, not assume the old control still exists. I can bring examples from the qualification sessions with user actions and spoken output aligned. Those examples will make the discussion concrete without turning it into a debate about whether accessibility users need the same convenience. They need a reliable choice, and our architecture should support that choice deliberately.

I will keep the automatic-entry work separate and document its lifecycle states. A request can be waiting for a window, waiting for an accessibility tree, completed, canceled, or rejected. Each transition needs an observable reason. There will be no request that silently remains pending after its display connection is gone. I will bring a state-transition test proposal to the October twenty-eighth review, including application replacement during reconnect. That gives us a path to restore the convenience later without relying on remembered node identifiers or a timeout that merely makes the demonstration look smooth.

Before Wednesday, I will ask a reviewer who has not seen the workaround to follow the entry instructions with the display image hidden. The purpose is to discover assumptions our experienced testers may overlook, such as knowing which screen owns a dialog. This does not replace accessibility specialist review, but it is a useful check on the support wording. I will record any assistance required as a failed independent task, not silently help the reviewer through it. We should be able to explain the supported experience clearly enough that the test does not depend on insider knowledge.

We have a decision and a verification path. Today's immediate task is to prove the manual route preserves both work and independent navigation; the automatic design can wait for its own evidence. I will send the scope update to product and support this afternoon, including the explicit entry step and the conditions that still block approval. Please raise any shared-code dependency before Monday's candidate is built. I would rather change the plan while we still have room than discover at freeze that the supposedly disabled restoration logic runs through another helper. Thank you; I will look for the first trace package at three.