Infrastructure: Fix native accessibility-state projection gaps on macOS and Win32
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 30/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- react-native, typescript
- Área
- accessibility, mobile-dev, testing
Línea de trabajo
Start with the Button and TabList native-state cases in button.stories.tsx and tablist.stories.tsx, then review the merged focus plan and PR #4314 evidence. Reproduce the AX/UIA tree attributes on supported macOS Fabric and Win32 Paper runtimes before identifying the owning component or renderer. Done means native state and updates match the public contract, with truthful driver normalization, passing native assertions, a Win32 Input regression, and updated evidence; link any upstream blocker.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Goal
Resolve the native accessibility-state projection gaps documented by the delivered assertion/focus work, rather than treating behavior tests as native state conformance. Parent: #4275. Bug follow-up to #4255 and PR #4314.
Observed state - 2026-10-01
Current story callbacks explicitly skip two macOS native-state assertions:
- Button disabled state: the source records that RNmacOS 0.81.9 Fabric does not project
accessibilityState.disabledto AXEnabled. - TabList selected/disabled state: the source records missing AXSelected/AXEnabled projection.
The merged focus plan separately records Win32 TextInput announcing UIA IsEnabled=true when configured noneditable, nonfocusable, and accessibility-disabled.
These are native observation gaps, distinct from the verified focus exclusion, callback/selection ownership, and activation guards. This audit verified the retained skip/source evidence; it did not requalify those observations against a newer native runtime.
Reproduction
On the current supported native runtimes, inspect the real AX/UIA tree for the Button/TabList focus fixtures and disabled Input fixture, then compare enabled/selected state before and after prop/state changes. Record resolved fork versions, native tree attributes, helper identity, and actual application behavior.
Use the isolated Button and TabList native-state WDIO cases; their current macOS skip text is evidence to replace, not permission to fake the expected attributes in JavaScript.
Acceptance criteria
- Reproduce or disprove each documented gap on current macOS Fabric/Win32 Paper, with explicit native attribute and runtime evidence.
- Identify the owning component/renderer/upstream transport and implement or consume the correct native fix; preserve the intended distinction between editability, focusability, and disabled semantics.
- Native AXEnabled/AXSelected/UIA state reflects the declared public contract, including updates and selected-to-unselected transitions.
- Driver normalization remains truthful: unsupported native state is explicit, never synthesized from component-owned status text or defaulted to
false. - Remove the two macOS skips only after their real native assertions pass, and add an enabled-state regression for the affected Win32 Input contract.
- Physical activation, UIA Toggle/SelectionItem.Select, AX custom-action dispatch, and screen-reader behavior remain separately identified; state reads do not claim those actions were qualified.
- Update the focus/accessibility evidence and relevant tests/docs/changesets. If an upstream fix is required, link its issue/change and keep the blocked coverage explicit.
Evidence
- Button native disabled-state case
- TabList native selected/disabled-state case
- Executed evidence and remaining renderer limits
- Coordinate #4343/#4349 and #4214, without closing native-state coverage using React prop tests.
- Lenguaje dominante
- TypeScript
- Estrellas
- 1.4k
- Forks
- 179
- Merge medio
- 2 d 9 h
- PR fusionados (30 d)
- 30
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de microsoft/fluentui-react-native
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
microsoft/fluentui-react-native#4174 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
microsoft/fluentui-react-native#4343 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
microsoft/fluentui-react-native#4344 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 20/100
microsoft/fluentui-react-native#4345 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
microsoft/fluentui-react-native#4347 ·
Los mantenedores suelen responder en 1 día
Todos los issues de microsoft/fluentui-react-native
Issues similares
-
level/task reporter/qa type/bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
wazuh/wazuh-dashboard-plugins#9310 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
cybersemics/treecrdt#267 ·
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 85/100
wiz-sec-public/backstage-plugin-wiz#16 · 1 comentario ·
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
solana-foundation/solana-com#2245 ·
Los mantenedores suelen responder en 1 día