Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: tab sequence of start/end slots in toolbar out of sink when focus brought back to toolbar #4983

Closed
SethDonohue opened this issue Jul 22, 2021 · 2 comments
Labels
bug A bug compliance:a11y Accessibility compliance. status:needs-investigation Needs additional investigation

Comments

@SethDonohue
Copy link
Contributor

SethDonohue commented Jul 22, 2021

🐛 Bug Report

In toolbar when any focusable content is slotted in the start or end slots and that content is the last focused content, then when returning focus back to the toolbar the focus is brought to the incorrect slotted item.

💻 Repro or Code Sample

stackblits:
https://fast-design-rybc3w.stackblitz.io/

  1. focus on "before toolbar button"
  2. tab to the "after toolbar button"
  3. shirt-tab (reverse tab) to toolbar, notice that focus is on first default slotted item and not the "end slotted button" as it should be.

🤔 Expected Behavior

Should tab back to the last focused item if there is focusable content in the start or end slots:

toolbarfocussequencereversetab

The arrow keys should navigate to all focusable slotted content within the toolbar including start and end. Seen here the arrow key is pressed after tabbing to the end slotted content, which leads to the next default slotted content item being focused.
toolbar-arrow-key-sequence

💁 Possible Solution

Ensure that the focusinHandler only controls focus when focus returns to the default slotted content.
I am working on a PR for this fix now.

🌍 Your Environment

  • OS & Device: MacOS, Windows,
  • Browser Microsoft Edge, Google Chrome, Apple Safari, Mozilla FireFox
@SethDonohue SethDonohue added the status:triage New Issue - needs triage label Jul 22, 2021
@chrisdholt
Copy link
Member

Adding the template here as it will likely help illustrate the problem:

    <template
        aria-label="${x => x.ariaLabel}"
        aria-labelledby="${x => x.ariaLabelledby}"
        aria-orientation="${x => x.orientation}"
        orientation="${x => x.orientation}"
        role="toolbar"
        @click="${(x, c) => x.clickHandler(c.event as MouseEvent)}"
        @focusin="${(x, c) => x.focusinHandler(c.event as FocusEvent)}"
        @keydown="${(x, c) => x.keydownHandler(c.event as KeyboardEvent)}"
    >
        <slot name="label"></slot>
        <div class="positioning-region" part="positioning-region">
            ${startTemplate}
            <slot
                ${slotted({
                    filter: elements(),
                    property: "slottedItems",
                })}
            ></slot>
            ${endTemplate}
        </div>
    </template>

@EisenbergEffect EisenbergEffect added area:fast-components bug A bug compliance:a11y Accessibility compliance. status:needs-investigation Needs additional investigation and removed status:triage New Issue - needs triage labels Jul 26, 2021
@chrisdholt
Copy link
Member

Closed with #4984

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A bug compliance:a11y Accessibility compliance. status:needs-investigation Needs additional investigation
Projects
None yet
Development

No branches or pull requests

3 participants