Issue metadata
Sign in to add a comment
|
Voice over read the same label element for both normal tab and incognito tab |
||||||||||||||||||||||||
Issue descriptionApp Version: 58.0.3029.84 dev iOS Version: 10.3.1 Device: iPhone Precondition: Device Settings -> General -> Accessibility -> VoiceOver -> On Steps to reproduce: 1. Launch chrome and open one normal and incognito tab 2. Tap on tab switcher button 3. Tap the title of the normal tab and open label element popup ( double tap with two fingers and long press to open label element popup) 4. Save the element with some name (eg: hello) 5. Tap on the tab title of incognito. Observed results: Voice over read the same element name that is saved for the normal tab in step4, vice versa (i.e. the element label provided for incognito is read when the title of normal tab is selected) Expected results: On tap of the (incognito/normal tab)tab title the voice over should read the element label only if it exists. Number of times you were able to reproduce: 5/5 Bug reproducible after clean install: Yes Bug reproducible after clearing cache and cookies: Yes Bug reproducible on Chrome Mobile on Android: NA Bug reproducible on Firefox/Safari: Firefox: NA, Safari: NA Bug reproducible on current stable build (App Version, iOS Version): Yes on M57 Bug reproducible on the current beta channel build (App Version, iOS Version): Yes Link to video/image: https://drive.google.com/a/google.com/file/d/0B8Cek8RsDbF8Vmdha05FekNfdFk/view?usp=sharing
,
May 4 2017
I didn't know about this feature, it seems like a nice pragmatic escape hatch for VoiceOver users! Thinking a bit about how it is implemented in the system: - The label override is stable across restart of the app. So they serialize somehow a trace of it. - Here the issue is that both labels are overridden while the user only intended it for one of them. This can give a clue on how it is implemented: they might keep a list of ancestors classes in the view hierarchy and each element that matches accessibility label and list of ancestors classes would be overridden. - When you have 2 normal tabs, only the first tab is modified, not the second, so the previous heurisitic needs to be refined: maybe they keep the subview position (index) also? This is corroborated when trying with 2 normals and 2 incognito tabs: changing the second tab in one stack changes the second tab in the other stack. One easy proposal: change "New tab" into "New incognito tab" for the accessibility label (not the displayed label) of the incognito stack tabs. That way the two stacks won't collide within the VoiceOver heuristic.
,
May 24 2017
,
May 25 2017
Yes I think the proposal would be a good improvement.
,
May 25 2017
,
May 28 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 28 2018
,
May 31 2018
Ed, can you take a look at this tab switcher voiceover issue? The fix will likely be shared between the old stack view and the new tab grid UI. I'm not sure if we should prioritize this though, since it looks like it only reproduces using a label customization action.
,
Oct 1
Closing bugs for older tab switcher UIs. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by sczs@chromium.org
, May 3 2017Owner: lpromero@chromium.org
Status: Assigned (was: Untriaged)