Android: only report text changes for the input-focused node (double speech)
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 48/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- android, rust
- Ambito
- accessibility, mobile-dev
Direzione di ricerca
Start by reading AdapterChangeHandler::node_updated and the existing unit tests for text-change events. Check how input focus is represented and compare the event behavior with android.widget.TextView. Done means unfocused node text updates no longer emit TYPE_VIEW_TEXT_CHANGED, while updates to the focused edit field remain announced; verify that the content-change and live-region events still cover their cases.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
The Android adapter sends TYPE_VIEW_TEXT_CHANGED for every node whose text changed. Screen readers echo that event whether or not the source node is focused, so an update to an unfocused node (for example a read-only log the app updates) is spoken on top of whatever the app announced itself, and the user hears it twice.
Proposed fix
Report the event only for the node with input focus, as android.widget.TextView does. Changes to other nodes are still covered by the window content-change event, and live regions by their own event. The change is a few lines in AdapterChangeHandler::node_updated plus a unit test.
Testing
Tested on a physical realme RMX5032 running Android 16 (API 36) with Google TalkBack 17.1.0 and with BackTalk, in an app using this adapter: the double speech is gone and typing in the focused edit field is still announced.
AI disclosure
I used an AI assistant (Claude) to help investigate and write this change. I reviewed the diff and ran the checks and the device testing myself.
I saw that AccessKit no longer accepts external pull requests (#832), so I'm opening an issue instead. If the plan looks reasonable, I'd be glad to send the PR as a member; I have the change ready and can share it however you prefer.
- Lingua principale
- Rust
- Stelle
- 1.5k
- Fork
- 127
- Merge medio
- 16h 45m
- PR unite (30g)
- 12
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di AccessKit/accesskit
-
Document sub-treesAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno
-
Document `Role::ColorWell`Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 56/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 52/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di AccessKit/accesskit
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
Y-ASLant/ElegantClipboard#178 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
linxiv-dev/linXiv#384 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
bug drawings ui
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
userFRM/egui-charts#1595 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
smoltcp-rs/smoltcp#1235 ·
I maintainer di solito rispondono entro 1 giorno
-
scope:core type:security
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno