keyboard focus is going unnecessary to whole section: A11y_ Visual Studio Code Client_ Inline Suggestions _Trigger, review, and accept suggestions _Usable.

[keerthiduvvuri]

GitHub Tags:

#A11yUsable; #A11yTCS; #Win32; #DesktopApp; #BM_Visual Studio Code Client Copilot_Win32_June2025; #Visual Studio Code Client; #FTP; #Win11; #Benchmark; #VSCode2025;

Environment Details:

Application Name: Visual Studio Code Client Win32
Visual Studio Code insider Version: 1.101.0 – insider(user setup)
Edition Windows 11 Enterprise
Version 24H2 OS build 26100.4202

Repro Steps:

1. Open the "Visual Studio Code" dialog box.
2. In Visual Studio Code, create a new JavaScript (*.js) file.
3. In the code Paste this code function calculateDaysBetweenDates(begin, end) { and press enter.
4. A suggestion will appear, press tab to accept the suggestions.
5. Observe that keyboard focus is going unnecessary to whole section.

Actual Result:

keyboard focus is going unnecessary to whole section.

Expected Results:

Unnecessary Keyboard focus should not be provided to whole section.

User Impact:

Keyboard users will face difficulty of accessing the suggestions if there is an extra Keyboard focus is provided.

Attachment:

250613_A11y_.Visual.Studio.Code.Client_.Inline.Suggestions._Trigger.review.and.accept.suggestions._Usable.webm

[POPeeeDev]

I first found where the issue was located in the source code:

Dialog Focus Handling
src/vs/base/browser/ui/dialog/dialog.ts (lines 338-421)
Tab handling for focus movement between dialog elements

Then using my mathematical framework (IRE, CGT, FFA) to identify the accessibility ("keyboard focus") issue and formulate a precise explanation for the "help wanted" issue, I asked CoPilot to make a plan. I'm not familiar with the GitHub pull and fork process and don't want to familiarize myself with it but I think the root cause section should help anyone who is working on this.

Analysis Using Computational Group Theory (CGT) and FFA

Configuration Space (Ω)

• Ω here is the set of all possible focusable UI elements in the dialog:
  Ω = {links in message, inputs, checkbox, dialog buttons, links in footer}

Group Actions (G)

• G = {Tab, Shift+Tab, RightArrow, LeftArrow}
• Each g ∈ G acts on ω ∈ Ω to move the focus.

Orbit(ω)

• Orbit(ω) = {resulting focus element as you move with G from ω}
• The code builds the array focusableElements and cycles through it with next/previous logic.

Goodness Function (G = θ(Ω) − C)

• θ(Ω): Intended focus: only actionable, visible elements in correct order.
• C: Cost = Confusion/Redundancy = When extra elements (e.g., entire sections, invisible or decorative elements) are unnecessarily included in the focus ring.

---

Detecting the Issue Mathematically

Symmetry/Redundancy Problem

• Symmetry group G should only permute between actual actionable elements.

• If non-actionable or large container elements (like whole sections) are included, the orbit of G introduces redundancy:
  Ω′ = Ω ∪ {unnecessary section-container elements}

• This breaks the Redundancy Reduction axiom (Axiom 6: "Redundancy elimination"), and increases C (cost/confusion).

Canonical Focus Orbit

• Canonical Orbit:
  Focus should only traverse actionable controls in the intended visual order.

• Observed Orbit:
  If the code (or DOM structure) accidentally allows focus to move to a section container (e.g., the whole dialog or a section that is not an input/button/link), then the focus ring "jumps" to these containers, expanding the orbit artificially:
  Orbit(ω) = {...inputs, section, ...footer, ...}

• This violates the Canonical Selection axiom:
  ω* = argmin_{ω in Ω} L(ω)
  (where L(ω) = confusion/extra tab stops)

Root Cause in Code

• The code constructs focusableElements by querying querySelectorAll('a'), inputs, checkbox, buttonBar.buttons, and footerContainer.querySelectorAll('a').
• BUT: If the DOM includes sections or containers with tabindex or is otherwise focusable (e.g., through ARIA or browser quirks), these can get focus even though not present in focusableElements.
• Additionally, the focusout handler may return focus to the container (this.element) if focus moves out, causing the "whole section" to receive focus.

Summary in FFA Terms

• Utility: User only wants to focus actionable controls.
• Cost: User is forced to tab through non-actionable, redundant sections, increasing navigation steps and confusion.
• G(ω) = Utility − Cost is degraded.

---

Diagnosis for Help Wanted Issue

When navigating the dialog via keyboard (Tab/Shift+Tab/Arrows), focus sometimes lands on the entire dialog section or non-actionable containers, rather than just actionable controls (inputs, buttons, links). This creates unnecessary tab stops and confuses screen reader and keyboard users.

Formal (Mathematical) Problem Statement

• Given: Ω = {focusable elements as intended}, G = group of navigation keys
• Current Implementation: Orbit(ω) includes unintended container elements:
  Ω′ = Ω ∪ {dialog section, container divs}
• Violation: Redundancy Reduction (Axiom 6), Canonical Flow (Axiom 14)
• Effect:
  • Users experience focus on whole sections, not just actionable controls
  • Increases C (cost/confusion), reduces G(ω) (goodness/utility)

---

How to Fix (in Math and Code)

• Enforce:
  Orbit(ω) = Only actionable elements (inputs, buttons, links, checkbox)
• In Code:
  • Ensure only actionable elements receive focus (remove tabindex from containers)
  • In focusout, do not set focus back to container elements, only to actionable elements
  • Use the strictest possible criteria for focusability in focusableElements

---

Suggested Help Wanted Issue Description

### Focus Trap Redundancy: Unintended Section Focus During Keyboard Navigation

#### **Problem**
When using keyboard navigation (Tab, Shift+Tab, Arrow keys), focus sometimes lands on the entire dialog section or non-actionable container elements, not just actionable controls (inputs, buttons, links, checkbox). This creates extra, redundant tab stops and confuses users.

#### **Mathematical Diagnosis (Reflectology Axioms)**
- **Configuration Space (Ω):** All actionable controls in dialog.
- **Group Action (G):** Navigation keys (Tab, Shift+Tab, Arrows).
- **Redundancy Detected:** Orbit(ω) (focus traversal) includes unintended section/container elements (Ω′ = Ω ∪ {section}).
- **Axiom Violation:** Redundancy Reduction (Axiom 6), Canonical Flow (Axiom 14).
- **Goodness Function Degraded:** G(ω) = Utility − Cost reduced due to extra tab stops.

#### **Expected Behavior**
- Focus should only move among actionable controls.
- Section/container elements should not be focusable.

#### **How to Fix**
- Remove `tabindex` from containers unless necessary.
- In `focusout`, do not set focus to the dialog section or containers.
- Ensure focusableElements only contains actionable controls.

#### **References**
- See [Reflectology/Reflections Sites/AxiomList.txt](https://github.com/Reflectology/Reflections/blob/main/Sites/AxiomList.txt) for formal axioms.
- Accessibility guidelines: [WAI-ARIA Authoring Practices — Dialog Modal](https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/)

---

TL;DR:
Mathematically, the focus orbit should be minimal and only include actionable controls. Current implementation allows focus to land on non-actionable containers, breaking axiom-driven minimalism and user expectations. Fix by strictly limiting focusable elements.

[vs-code-engineering]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[aiday-mar]

Hi thank you for filing this issue. I have looked at the video which helped me understand the issue better. I just tested this behavior on MacOS and I see that when the focus is set on the whole hover status bar sub-part it reads an overview of the elements in the statusbar it contains. I assume you are a screen reader user so I wanted to ask you if you find this useful? This would allow the screen reader user to have an overview of the available action before jumping inside with the Tab key.

The initial reason I made all the hover parts focusable is because I wanted screen reader users to call Open Accessibility Help on every subpart. Currently when you call this command on the status bar, you see the following text:

This is a hover status bar.
It has an action with label View Problem and keybinding ⌥F8.
It has an action with label Quick Fix... and keybinding ⌘..
It has an action with label Fix using Copilot and keybinding ⌘I.
Disable accessibility verbosity for this feature (Option+F6).
Exit this dialog (Escape).
Configure keybindings for commands that already have assignments (Option+A).

The accessibility help view essentially summarizes the actions in the status bar when focusing on the whole status bar.

Also pinging @rperez030 and @meganrogge who both work with accessibility. Just for context, the author of the issue mentions here that when tabbing in the editor hover, the focus should not be placed around the whole sub-part when it comes to the hover status bar and the inline-completions hover sub-part, and should instead directly jump into the individual actions they contain. If we implement this we may have to rethink how the hover accessible help is implemented. I wonder what your thoughts are on this?