Bug 208025

Summary: Web Inspector: VoiceOver doesn't read selected tab
Product: WebKit Reporter: Nikita Vasilyev <nvasilyev>
Component: Web InspectorAssignee: Nikita Vasilyev <nvasilyev>
Status: RESOLVED WONTFIX    
Severity: Normal CC: bburg, hi, inspector-bugzilla-changes, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: All   
OS: All   
Attachments:
Description Flags
Patch
hi: review-, nvasilyev: commit-queue-
[Video] Before the patch
none
[Video] After the patch none

Nikita Vasilyev
Reported 2020-02-20 12:51:46 PST
When clicking on a tab, voice over should read it.
Attachments
Patch (4.60 KB, patch)
2020-02-20 13:04 PST, Nikita Vasilyev
hi: review-
nvasilyev: commit-queue-
[Video] Before the patch (2.01 MB, video/quicktime)
2020-02-20 13:07 PST, Nikita Vasilyev
no flags
[Video] After the patch (2.33 MB, video/quicktime)
2020-02-20 13:11 PST, Nikita Vasilyev
no flags
Radar WebKit Bug Importer
Comment 1 2020-02-20 12:51:59 PST
Nikita Vasilyev
Comment 2 2020-02-20 13:04:55 PST
Nikita Vasilyev
Comment 3 2020-02-20 13:07:57 PST
Created attachment 391324 [details] [Video] Before the patch
Nikita Vasilyev
Comment 4 2020-02-20 13:11:36 PST
Created attachment 391327 [details] [Video] After the patch
Blaze Burg
Comment 5 2020-02-25 16:33:44 PST
Comment on attachment 391322 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=391322&action=review > Source/WebInspectorUI/UserInterface/Views/ConsoleTabContentView.js:61 > + WI.consoleContentView.prompt.focus(); How does VO properly access the Console tab title if focus stays with the prompt element?
Devin Rousso
Comment 6 2020-02-25 17:07:52 PST
Comment on attachment 391322 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=391322&action=review >> Source/WebInspectorUI/UserInterface/Views/ConsoleTabContentView.js:61 >> + WI.consoleContentView.prompt.focus(); > > How does VO properly access the Console tab title if focus stays with the prompt element? Can you explain why a rAF is needed? Is it because the element isn't in the DOM tree, or some other reason? Rather than rely on the uncertain firing order of rAFs, how about we set some state on `WI.consoleContentView` (or use a "cookie" object passed to `showContentView`) that will focus the prompt in the next `layout()`? I'm imagining something along the lines of `WI.SourcesTabContentView.prototype.showScopeChainDetailsSidebarPanel`. > Source/WebInspectorUI/UserInterface/Views/TabBar.js:-635 > - event.preventDefault(); > - event.stopPropagation(); Removing this now means that dragging on the tab bar (e.g. reordering tabs) is treated like normal selection, meaning that you can continue a drag to select text. We don't want that.
Nikita Vasilyev
Comment 7 2020-02-25 17:10:14 PST
Comment on attachment 391322 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=391322&action=review >> Source/WebInspectorUI/UserInterface/Views/ConsoleTabContentView.js:61 >> + WI.consoleContentView.prompt.focus(); > > How does VO properly access the Console tab title if focus stays with the prompt element? It doesn't for Console. It just reads "Console prompt". I think ideally when switching to the Console tab, it should: 1. Immediately focus on the console prompt so if I start typing it should go to the right place. 2. Yet read the Console tab title. I don't know how to satisfy both requirements. With this patch it just reads "Console Prompt" instead of "console tab", "Console Prompt".
Devin Rousso
Comment 8 2020-03-05 16:27:55 PST
Comment on attachment 391322 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=391322&action=review >>>> Source/WebInspectorUI/UserInterface/Views/ConsoleTabContentView.js:61 >>>> + WI.consoleContentView.prompt.focus(); >>> >>> How does VO properly access the Console tab title if focus stays with the prompt element? >> >> Can you explain why a rAF is needed? Is it because the element isn't in the DOM tree, or some other reason? Rather than rely on the uncertain firing order of rAFs, how about we set some state on `WI.consoleContentView` (or use a "cookie" object passed to `showContentView`) that will focus the prompt in the next `layout()`? I'm imagining something along the lines of `WI.SourcesTabContentView.prototype.showScopeChainDetailsSidebarPanel`. > > It doesn't for Console. It just reads "Console prompt". > > I think ideally when switching to the Console tab, it should: > 1. Immediately focus on the console prompt so if I start typing it should go to the right place. > 2. Yet read the Console tab title. > > I don't know how to satisfy both requirements. With this patch it just reads "Console Prompt" instead of "console tab", "Console Prompt". I don't think we want to do this. Automatically focusing the Console prompt means that as soon as the user selects the Console Tab, they're unable to immediately change tabs again (e.g. if they mistakenly selected it). They'd have to tab all the way back to the tab bar to switch tabs again.
Nikita Vasilyev
Comment 9 2020-03-26 13:43:17 PDT
Comment on attachment 391322 [details] Patch This patch focuses on the tab element when clicking on it. MacOS Safari doesn't focus on click, and we shouldn't either. ScopeBar and NavigationBar don't steal the focus on click either. However, there's one exception: when a ScopeBar or NavigationBar item is already focused, clicking on the other item within the same group moves the focus. We should do the same for the tab bar. Perhaps, unify this logic in the future.
Nikita Vasilyev
Comment 10 2020-05-04 19:32:14 PDT
This is no longer relevant. The underlining issue has been addressed in a different (and proper) way in Bug 208542 - Web Inspector: AXI: annotate tab panels.
Note You need to log in before you can comment on or make changes to this bug.