While testing our product that uses tabster, the Accessibility Insights fast pass failed because the aria-hidden-focus rule is being broken by one of tabster's components. Our component is a Toolbar that uses tabster to enable circular arrow navigation in the toolbar, and the element breaking this rule is a that gets added above and below the children of the toolbar.

This case has been noted while trying to implemente the TreeView Widget. Seems like if an element on the tree has aria-expanded the navigation is stopped. Something related to this PR #152

Here's a reproduction: https://codesandbox.io/s/serene-satoshi-klc49q?file=/example.tsx

Hello,
We are using tabster in our project and it seems that tabster is adding a dom element at the bottom of the page which causes the screen reader to read as "button collapsed".

Screenshot for the DOM element being rendered:

Screen Recording for the occurring issue:

Additional Notes:
I made sure that the mentioned DOM element added by tabster is causing the issue by deleting the element from DOM (from the dev tools) and the screen reader does not read "button collapsed".

Do let me know if more information is needed from my side.

The origin for the issue is based on a lazy loaded component that adds an aria live region in the body of Teams.

To reproduce the issue you can start the latest version of Teams and start a performance trace.

Then run the following code in the console.
document.body.appendChild((() => { e = document.createElement("div"); e.innerText = "Hello world!"; return e; })())

Stop the performance trace, and you should see something like this:

The 111ms is done on a fairly new desktop computer, with 4x slowdown the time to compute is more than 500ms.

The reason for the recalculate style is tabster, and specifically within

When the body gets the new child appended, tabsters timeout will later run, and move the <i> element to the bottom of the body. This causes the recalculate style to happen.

Above is a GIF showing the focus cycle, starting with only Tab pressing and then Shift + Tab when it reaches the last element.
As shown, element traversing works normally with Tab but not in the reverse direction with Shift + Tab as, when using the latter, focus is going to the parent element only instead of the inner element.

Here's the code:

const Card = () => {
  getGroupper(tabster);

  const tabsterAttrs = getTabsterAttribute({
    groupper: {
      tabbability: undefined
    }
  });

  return (
    <div tabIndex={0} {...tabsterAttrs}>
      <Button tabIndex={0}>Cool button</Button>
    </div>
  );
};

https://codesandbox.io/s/card-focus-example-61tbjw?file=/src/App.jsx

From the documentation, I couldn't understand if this is an unintended side-effect of focus trapping or intended behavior. Can you please clarify?

Current Behavior

Right now, Modalizers MUST have a aria-label attribute. otherwise tabster will console.warn:

🚨 Modalizer element must have aria-label

According to ARIA specs both aria-labelledby and aria-label can be used for labelling an element in a valid way.

Proposal

Allow Modalizers to have aria-label OR aria-labelledby as required attribute.

Details and illustrations of support behaviour here: https://github.com/ling1726/fluentui/blob/spec/react-table/packages/react-components/react-table/Spec.md#navigation-modes

repro: https://codesandbox.io/s/sleepy-sound-gnx484?file=/example.tsx

The popover in this examlple in in DOM order - i.e. the third button is after the popover in DOM order

1. tab to the popover trigger
2. press enter to open the popover
3. press tab
4. Notice focus skips the third button
   

Currently there are a lot of hypotheses around the design of tabster for performance, none of them are actually concrete since we have no data to really compare against.

@fluentui/[email protected] required some unnecessary dependencies to be added:

1. @azure/data-tables
2. workspace-tools

As soon as a newer version is release of @fluentui/bundle-size this should be cleaned.

We are using the tablist component from @fluentui/react-components version 9.0.1. @fluentui/react-tabster requires tabster@^1.4.2 (package.json); note the caret which permits upgrades to minor versions.

We start seeing the following error after upgrading tabster to 1.5.1.

This error happens when a tab item is clicked. This is due to the useTabster hook in @fluentui calls the getCurrentTabster or createTabster methods.

export const useTabster = (): TabsterTypes.TabsterCore | null => {
  ...
  return getCurrentTabster(defaultView) ?? createTabster(defaultView, tabsterOptions);
};

The getCurrentTabster returns an instance of TabsterCore and the createTabster returns an instance of Tabster. createTabster() method assigning TabsterCore instance to the windows object instead of the Tabster instance. See code below:

/**
 * Creates an instance of Tabster, returns the current window instance if it already exists.
 */

function createTabster(win, props) {
  let tabster = getCurrentTabster(win);

  if (tabster) {
    return tabster.createTabster();
  }

  tabster = new TabsterCore(win, props);
  win.__tabsterInstance = tabster;
  return tabster.createTabster();
}

When the getMover method is trying to access tabster.core, tabster.core is undefined.

Proposal change: assigning Tabster instance to windows and return it.

function createTabster(win, props) {
  ...
  let tabsterCore = new TabsterCore(win, props);
  tabster = tabsterCore.createTabster();
  win.__tabsterInstance = tabster;
  return tabster;
}

Another proposal change in Fluent UI side, change the return in the useTabster hook to call createTabster method only.

export const useTabster = (): TabsterTypes.TabsterCore | null => {
  ...
  return createTabster(defaultView, tabsterOptions);
};

Root.ts is using a call to new EventTarget in the following line:

But the EventTarget constructor is not supported in multiple older browser versions:

https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/EventTarget

A possible workaround is to try to create the EventTarget and if that fails use an HTML element for it:

/**
 * Creates an EventTarget object supported by the current browser.
 */
export function createEventTarget(): EventTarget {
  // EventTarget constructor is not supported in IE or Safari, but HTML element implements the interface with small overhead.
  try {
    const target = new EventTarget();
    return target;
  } catch (err) {
    return document.createElement('div');
  }
}

Make Tabster context more understandable (from reading the code perspective) and easier to work with (from the consumption perspective).

Repro: https://codesandbox.io/s/priceless-meninsky-wi9rje?file=/example.tsx

1. Focus 'Root trigger' button
2. Press Enter
3. 'Open popover' button should be focused
4. Press Enter
5. Press Escape
6. Focus is on the 'Root trigger' button

The problem here is that once the popover opens, the first focusable element (which is a deloser) is focused before the deloser can be created.

This means that the deloser on the first button can never be added to the deloser history

To follow the happy path and avoid the race condition, simply tab to the next button after 'Open popover' in steap 2 and shift tab back to 'Open popover'. This time the deloser is already created so the process will add it to deloser history

This Fluent UI issue is specifically about vNext menu, but the problem is with the tabbing behavior when rendered in SSR.

microsoft/fluentui#22174

This bug can be found using the following steps (reproducible in the storybook for groupper):

1. tab to the focus group container
2. hit enter to reach the first focusable button
3. click outside the focus group to move focus outside of it
4. tab back to the focus group, and observe that tab reaches the inner buttons & is then trapped within the group without needing to hit enter again

The desired behavior would be that if focus leaves a focus group without using Escape (e.g. through clicking elsewhere, using a screen reader's virtual cursor, or mixing modes in any of several other ATs), the focus group state is reset and the user would need to hit enter again to reach inner items if the tabability is set to limited or limited-tab-focus.

Hello Tabster Development Team,

I am currently exploring the use of Tabster in the context of web accessibility, with a specific focus on ensuring a seamless experience for users with accessibility needs, such as those utilizing screen readers.

As I navigate through this learning process, I recognize the importance of properly implementing and testing focus behavior, a key component in accessible web design. To that end, I am reaching out for guidance and best practices in this area.

Could you kindly provide specific recommendations on methodologies, tools, or resources effective for testing focus behavior in web projects? Are there particular tools or methods the Tabster team uses to ensure accurate focus behavior in real-world contexts, especially with manual testing using screen readers?

Additionally, I believe it would be beneficial if the Tabster documentation could include more information or links to resources about this topic.

Similar to keyborg, the actual tabster instance should be a browser singleton. All usages of tabster should be proxies that can be disposed at any time.

The main tabster singleton should only be disposed once the last proxy wrapper is disposed

This happened during the Modalizer revamp: Modalizer revamp by mshoho · Pull Request #218 · microsoft/tabster (github.com)

Reported issue: [Bug]: dialog directly mounted with open=true could not get focus · Issue #26824 · microsoft/fluentui (github.com)

Repro (also in the bug): Sandbox - CodeSandbox (csb.app)

What seems to be happening is that since [email protected] is that the autoroot creation is now async. This means that when a Fluent component that uses tabster is mounted, it generates errors because only the first usage of tabster initialized the autoroot. Since this is async, the React component can't actually use tabster on first render.

In the repro:

• The dialog is mounted
• tabster does not exist
• dialog initializes tabster
• dialog uses modalizer
• tabster error -> no autoroot created
• tabster creates autoroot
• modalizer is inactive because there was not root
• can't tab any element in the dialog
• use the console to call .focus() on an element
• now the modalizer is active

We are using tabster version - 4.1.1

We are seeing many 'using disposed tabster' errors in our product logs.
Callstack -

I looked at the code and this could be causing issue.
https://github.com/microsoft/tabster/blame/c1b46b478fd0d75fe95b5653d525658e2bf16d6a/src/Modalizer.ts#:~:text=this._hiddenUpdateTimer%20%3D,%2C%20250)%3B

There is a possibility that this code could be executed after tabster is disposed, which would cause this error.

    this._hiddenUpdateTimer = this._win().setTimeout(() => {
        delete this._hiddenUpdateTimer;
        this._hiddenUpdate();
    }, 250);

@mshoho

Seems like we're having problems trying to reproduce the WAI-ARIA Accordion spec behavior with Grouper and Mover combined.

Nice to haves for testing purposes

1. Reproduction of Accordion widget behavior in a storybook
2. Actual tests to ensure that we can respect the behavior.

Currently the behavior for mover is to have tab focus land on the first item when tabbing forwards, and the last item when shift+tabbing backwards (reproducible in the storybook: https://tabster.io/storybook/?path=/story/mover--circular, applicable to all stories apart from the Tabbable one).

One of the principles of good tab navigation is that it is symmetrical when moving both forwards and backwards, so we should ensure tabster doesn't break this by default. My guess would be that the first item in the group should be the default focus stop, unless overridden by an author.

https://codesandbox.io/s/pedantic-robinson-qklozr?file=/src/App.js

It's not possible to use arrows to navigate a group of checkboxes with the mover

Related to #305 -- with the fix in #306, Restorer will work in Safari & Firefox if the root node itself is removed from the DOM, but not if a child node containing document.activeElement is removed (note - CSS changes like display: none will still work, only DOM removal is an issue).

This seems like more of a minor use case/feature to support, since the primary use case is likely removing the root node. This issue is for tracking & to not lose the edge case after #306 is closed. Discussed w/ @ling1726

Focusable API has supported the isDefault attribute for a while now for Deloser scenarios. This should be extended to work with the Mover API.

The Mover API should also support an optional prop so that it should look for default focusables, this will avoid conflicts with other features such as `memorizeCurrent

Similarly to #3 all find* methods should allow custom accept conditions in Focusable API

MutationObservers do not track changes inside shadow roots meaning Tabster cannot track its tabster attribute for elements inside a shadow root.

Update MutationEvent to handle shadow roots.

As bundle size is critical for this project, we should add bundle size metrics and reports to keep a better track on this. The bundle-size used internally on FluentUI should be enough.

Create an option for a Mover API can can navigate from within a Groupper. The next/previous focused element should be the next/prev focusable element or the top level focusable Groupper within a Mover

Hi. We have two navigation groups and each sets tabster attributes. but when tabbing focus gets to first group and ignores next. When using shift tab, tab get to last element in second tab group and ignores first tab group. How can we use tabster with two tab groups next to each other?

Example here https://codesandbox.io/s/determined-chebyshev-p8v3do?file=/example.tsx

Hey folks,

I am using Fluent 9 Popover and wanted to verify that correct element is focused open opening the Popover. For the component I created, I can visually verify in Storybook that correct element is focused. However, when I want to make such assertion in unit tests, it seems to no longer be the case. Can tabster functionality be somehow verified in jest and jsdom environment? Or the only way to verify is to have e2e tests, rendering browser window?

Expected Behavior

When using Fluent UI v9 RadioGroup with react-tabster's useFocusableGroup RadioGroup native tabbing and keyboard behavior should be preserved.

Observed Behavior

When using useFocusableGroup with RadioGroup the native tabbing and keyboard behavior is overridden in unexpected ways.

In particular, with Tabster:

1. Each option in RadioGroup is a tab stop (i.e., tab presses move between the options) when the RadioGroup should be a single tab stop.
   1. Options are only supposed to be navigable with the arrow keys when using the keyboard. Arrow keys still work with Tabster.
2. When RadioGroup has a selected option tabbing or shift-tabbing to the RadioGroup from a different focusable element focuses the first or last option in the RadioGroup respectively. It should focus the selected option.

Example

Codesandbox Example

Related Issues

Fluent UI v8's ChoiceGroup had a similar issue with FocusTrapZone.

• ChoiceGroup focus conflict when it's the first component inside a focus zone

When we only have arrow navigable groups, the tabbing stops at the last group. We expect it to go out to the browser controls, or in the fullscreen case, cycle back to the first navigable group.

In this example: https://codesandbox.io/s/blissful-http-9r31z0?file=/example.tsx if you keep tabbing, you can see that the tabbing stops at the last group of arrow navigable group. Note: you need to open the example page itself to see this happening: https://9r31z0.csb.app/

To extra clarify: when we are at fullscreen, we expect that the first tab goes to the first group, the second tab goes to the second group, the third goes back to the first group and so on. But currently, the third and subsequent tabs will just stay on the last group.

I've tried exploring the useArrowNavigationGroup and useFocusableGroup hooks to see if there is something there we can use to achieve this, but no success.

Is this a bug? Any suggestions?

Problem description

When the useTableCompositeNavigation hook is used on a table, and when the aria-expanded attribute is applied on the table row, the arrow key navigation stops working.

Code example

import * as React from 'react';
import {
  useTableCompositeNavigation,
  Button,
} from '@fluentui/react-components';

export const TreeGrid: React.FC<IRecentMeetingsTreeRendererrerProps> = ({ recentMeetings }) => {
  const { tableRowTabsterAttribute, tableTabsterAttribute, onTableKeyDown } = useTableCompositeNavigation();

  return (
    <table
        role= "treegrid"
  {...tableTabsterAttribute }
      >
    <tbody>
    <tr
            role="row"
  tabIndex = { 0}
  aria - level={ 1 }
  aria - expanded={ true }
  {...tableRowTabsterAttribute }
          >
    <td
              role="gridcell"
  tabIndex = { 0}
  colSpan = { 4}
    > Meeting with manager < /td>
    < /tr>
    < tr
            role = "row"
  tabIndex = { 0}
  aria - level={ 2 }
  {...tableRowTabsterAttribute }
          >
    <td role="gridcell" tabIndex = { 0} > Re: meeting with manager < /td>
    < td role = "gridcell" > <Button>Agenda and notes < /Button></td >
      <td role="gridcell" > <Button>Chat with participants < /Button></td >
      <td role= "gridcell" > <Button>View recap < /Button></td >
        </tr>
        < tr
  role = "row"
  tabIndex = { 0}
  aria - level={ 2 }
  {...tableRowTabsterAttribute }
          >
    <td role="gridcell" tabIndex = { 0} > Re 2: meeting with manager < /td>
    < td role = "gridcell" > <Button>Agenda and notes < /Button></td >
      <td role="gridcell" > <Button>Chat with participants < /Button></td >
      <td role= "gridcell" > <Button>View recap < /Button></td >
        </tr>
        < /tbody>
        < /table>

  );
};

https://github.com/microsoft/tabster/blob/master/src/Deloser.ts#L299

This check has a false positive for forms with an input named id since element.id will point to the input element in the form.

Sandbox for reproduction: https://codesandbox.io/s/agitated-khorana-hzqyu2?file=/src/index.tsx

I'm not sure from which version this issue starts to manifest, but tabster v4.7.0 definitely does not have such issue.

Reproduction (CodeSandbox): https://codesandbox.io/s/fluent-ui-v9-tabster-with-monaco-editor-ldwt64?file=/src/example.tsx

When I press "tab" key inside monaco editor, I expect to either

• see 4 spaces appears in the editor,
• or accept the item from the auto-completion dropdown.

but instead my focus gets moved to the auto-completion box, or the button.

AH needs extra configuration to be RTL aware so that mover can know when to flip left/right arrow keys

AH needs to be able to configure RTL state at runtime

Is there a reason that Groupper is spelled with 2 p's? Group, Grouping, Grouper appear to be the proper spelling here. Is it a play on words? The spelling has made it all the way into our docs as well

https://react.fluentui.dev/?path=/docs/components-menu--default#groupping-items

Would like to know if this is somehow intentional, and if it was a misspelling, if it'd be possible to fix it in tabster.

When using Ctrl + Tab inside of an Element that is part of the Tabster Context and the app is in a Native Host, Ctrl + Tab is executed as Tab.

Expected Result.
Ctrl + Tab should not be handled by Tabster.

Our product is micro-frontend alike architecture, there's a host UI project and several guest UI projects that are all built and shipped differently, and all the dependencies are not shared. We discovered an issue during the upgrade of FluentUI v9, which is caused by different versions of tabster in host UI side and guest UI side.

A minimal repro could be found here: https://github.com/KagamiChan/multiple-fluentui-repro
I'm not using codesandbox because I need to use yarn resolutions to lock tabster version, please let me know if you prefer a codesandbox example.

tabster versions:
Host UI: 4.2.0
Guest UI: 4.6.0
main difference for this issue: tabster 4.3.0 introduces queue for initialization: #262

Steps to repro:

• click the button to mount guest UI
• error throws like below

what happened:

1. host UI is mounted, and tabster core (v4.2.0) is initialized, while modalizer is not
2. guest UI trying to mount, FluentUI tries to initialize modalizer, the getModalizer function and ModalizerAPI class is from guest UI (v4.6.0) so it calls tabster isntance's queueInit function
3. tabster instance is initialized by host UI (v4.2.0) and does not have queueInit function, the exception throws

This issue is blocking us from the Fluent UI upgrade because we have to upgrade host UI everywhere but that would be difficult (our product is not served on web but is embedded), could you please help take a look and help us unblock?

The keydown listener for Modalizer is always being added. This results in Tab key moving by 2 focusable elements when pressed inside an active modalizer

Currently modalizer focus trap, allows the focus to escape the document into the window. This behaviour should be configurable and allow the focus trap to be circular within the modalizer and never escape

A list-like set of grouppers brings many dummy inputs. Consider having some hybrid controlled/uncontrolled mode.

In working on PR#314 I noticed that Chrome/Puppeteer introduces a new headless mode:

More details here: https://developer.chrome.com/articles/new-headless/

When opting in to this new mode (by setting headlines: 'new' in the Puppeteer config) several tests fail. As this new mode will eventually become the default we should fix the tests issue or file bugs against Puppeteer.

@fluentui/react-tabster requires tabster@^1.4.2 (package.json); note the caret which permits upgrades to minor versions.

Fresh installs are failing because the latest [email protected] doesn’t export getCurrentTabster (index.ts) which @fluentui/react-tabster imports in useTabster.

Failed to compile.

./node_modules/@fluent-blocks/react/node_modules/@fluentui/react-tabster/lib/hooks/useTabster.js
Attempted import error: 'getCurrentTabster' is not exported from 'tabster'.

Since 1.5.0 is a breaking change, I think it should be released as 2.0.0 if the change was intentional. I think a patch should be released as 1.5.1 to restore getCurrentTabster so folks’ builds don’t break, or dependents should specify only patches with ~ or use a specific version in the meantime. As an indirect consumer of tabster, I have to override the tabster version dependency using our project’s package manager.

Problem

Currently mover stores all instances of itself as a static class member

This is bad since the dispose of the actual Mover instance is only called when a DOM change is detected by the mutation observer. In scenarios where there is a child window, closing the window will not trigger mutation observer events and dispose is never called.

Therefore all Mover instances are retained int he static member.

Solution

Refactor Mover and MoverAPI so that the collection of Mover instances is managed by MoverAPI so it can be safely disposed by consuming apps, by disposing APIs through disposeTabster.

This will mean that updateVisible will need to be hoisted from Mover to MoverAPI

Currently mover has hasDefault option, when it is true, mover looks for the focusable item that has focusable.isDefault attribute. Would be nice to make this option default true instead.

Current behavior

At the moment, deloser attributes assume a modal is opened when it's added to the DOM and is closed when it's removed from the DOM, returning the focus to the previous deloser once the modal is closed.

This is not ideal for native modals such as <dialog> since the element is always present at the DOM and it's visibility is dictated by display: none

reproduction

Requested change

Allow deloser to identify the element is not focusable anymore in the DOM although it's still present, therefore allowing return of the focus to the previous deloser.

Feture request

There are scenarios when the developer wants to complement or override key events handled by tabster (such as Right arrow key press) using a custom code that is executed only under some circumstances, such as when the keyboard focus is on some specific element. This need can be resolved by introducing the possibility to register a custom callback for the key events which are handled by tabster. Then, running event.preventDefault() in such callback can block the execution of the default tabster handler.

Safari does not fire focusout or any other events when a node is removed, which means focus isn't restored when the restorer source is unmounted, even though focus returns to the body.

This can be reproduced in the Restorer stories in Safari, and also in FUI in components with popups (e.g. Popover, Dialog, Menu, etc.).