Fix: Keyboard focus does not land on selected item when opening location dropdown

[Copilot]

When the location dropdown is expanded via keyboard, focus remains on the trigger button instead of moving to the currently selected section item, leaving keyboard users unable to identify where focus is.

Changes

• sectionPicker.tsx — onPopupToggle: When the popup opens, schedules a setTimeout(0) callback (to allow DOM render) that focuses the currently selected section element by curSectionId. Falls back to the first keyboard-navigable item in #sectionPickerContainer if no selected element is found.

if (shouldNowBeOpen) {
    setTimeout(() => {
        let curSectionId = this.state.curSection && this.state.curSection.section
            ? this.state.curSection.section.id : undefined;
        let elementToFocus: HTMLElement;
        if (curSectionId) {
            elementToFocus = document.getElementById(curSectionId) as HTMLElement;
        }
        if (!elementToFocus) {
            let sectionPickerPopup = document.getElementById("sectionPickerContainer");
            if (sectionPickerPopup) {
                elementToFocus = sectionPickerPopup.querySelector("[tabindex]:not([tabindex=\"-1\"])") as HTMLElement;
            }
        }
        if (elementToFocus) {
            elementToFocus.focus();
        }
    }, 0);
}

The fallback selector [tabindex]:not([tabindex="-1"]) intentionally excludes programmatically-only focusable elements, ensuring only keyboard-reachable items receive focus.

• sectionPicker_tests.tsx: Added 3 tests using sinon fake timers covering: focus on selected section when popup opens, fallback focus to first item when no section selected, and no focus change when popup closes.

Original prompt

[Location - Dropdown]: Keyboard focus does not land over the selected item after expanding the "location dropdown" using keyboard.

Work Item Details

Note: Please focus on the descriptions and information that provide context about the task requirements, functionality, and implementation details. Dates, priorities, and administrative metadata are less relevant for coding tasks.

Description

Test Environment:

OS: Win 11 version 22h2 build 25151.1000
Application: OneNote Clipper
URL: https://www.onenote.com/clipper

Browser: Edge Version 105.0.1300.0 (Official build) dev (64-bit)

Pre-requisite:
Install OneNote clipper from https://www.onenote.com/clipper and sign-in with Microsoft work account.

Repro Steps:

1. Go to https://www.onenote.com/clipper URL. 
2. Select "Clip to OneNote" button in top right corner.
3. Navigate to "Location dropdown" under 'Article' button through Tab key and press enter key.
4. Observe the issue here.

Actual Result:

Keyboard focus does not land over the selected item after expanding the "location dropdown" using keyboard.

Expected Result:

Keyboard focus should land over the selected item after expanding the "location dropdown" using keyboard.

User Experience:

Keyboard user will face difficulty if focus is not landing first items after expanding 'location dropdown' so the end users will not be able to identify that the focus is actually on which control so the end users will get confused.

MAS Reference:

Focus Order - Liquid (microsoft.com)

Have feedback to share on Bugs? Please help fill Trusted Tester Bug Feedback (office.com).

Tags

A11yCT; A11yMAS; A11ySev3; ClipperA11y; FC-Jun22; HCL-Clipper; HCL-E+D; HCL-OneNote; MAS2.4.7; OneNoteClipper_Web; UnderReview; Web

RCA Analysis

Was change validated in devMain first before porting to fork?

Why was Flighting|Backout not used?

Impact of bug (# users affected):

RCA and Mitigation/Fix Details:

What are you doing to prevent this in the future?

Comments

Mani Revathi Yegadasu (Wed, 28 Feb 2024 07:35:45 GMT): Verified the issue in the below environment:

URL :https://www.onenote.com/clipper

OS: Windows 11 OS build 26058.1000

Edge Dev Version: Version 123.0.2400.1 (Official build) dev (64-bit)

Issue is still repro.

Work item: AB#6210624
Created via Azure DevOps