adobe/react-spectrum

Provide a general summary of the issue here Scenario: useInteractionModality reports "mouse" when screen reader user interacts GIVEN a user has started their screenreader (JAWS or NVDA) and a chromium browser (Chrome) WHEN the user interacts with the page clicking a button THEN the hook useInteractionModality reports the modality as "mouse" 🤔 Expected Behavior? JAWS/NVDA + Chromium interactions are detected as virtual 😯 Current Behavior JAWS/NVDA + Chromium interactions are detected as mouse 💁 Possible Solution We created a very simple 'codepen' to log the event information for every browser and screen reader, to check if there is any difference in terms of the received information. https://es-d-95332884020260709-019f3c39-f927-7d3c-823e-4328eff26b40.codepen.dev/ We detected that the combination JAWS/NVDA + Chrome throws a clickevent and a pointerdown event after interacting with a button by pressing Enter. In addition, we receive pointerType as mouse. JAWS/NVDA + Firefox and V

Provide a general summary of the issue here When nesting <Tabs> inside another <Tabs> component, the transition animations severely break and can cause cause large layout shifts, when switching the outer <Tabs> component. This is caused by three distinct issues interacting with each other. 🤔 Expected Behavior? Nested TabPanels should not inherit transition CSS variables from parent TabPanels. (Perhaps the TabPanels should set these variables initially, or TabPanel should reset them to auto for nested childs). Workaround: .react-aria-TabPanels { position: relative; height: var(--tab-panel-height); width: var(--tab-panel-width); /* .... */ } .react-aria-TabPanel { padding: var(--spacing-3); border-radius: var(--radius); /* .... */ --tab-panel-width: auto; /* <-- Reset the variable for nested TabPanels */ --tab-panel-height: auto; } Outer TabPanels measuring logic should either wait for nested collections to finish building, or TabList should hold its space sy

Provide a general summary of the feature here Introduce an opt-in prop for date and time field components that implements a single tab stop pattern. 🤔 Expected Behavior? Tab: Moves focus into the field (landing on the first segment or the entire input). Arrow Left / Right: Moves focus between the internal segments (like it does now already) Tab (again): Exits the field and moves to the next focusable element in the DOM. 😯 Current Behavior Users have to press Tab key 3 to 4 times to navigate through a single date or time field. 🔦 Context In data-entry heavy applications, requiring users to press the Tab key 3 to 4 times to navigate through a single date / time field causes significant "Tab fatigue." For power users filling out large forms, this default segmented tabbing behavior severely slows down keyboard navigation compared to standard text inputs.