Issue metadata
Sign in to add a comment
|
Mac: Simplified fullscreen bubble should be announced when VoiceOver is enabled [Accessibility Eng bug] |
||||||||||||||||||||||||
Issue descriptionChrome Version : 52.0.2729.3 OS Version: OS X 10.11.4 What steps will reproduce the problem? 0. Turn on voiceover (Usually Cmd+F5) 1. At, e.g., https://permission.site click "Fullscreen" What is the expected result? VoiceOver should say "Press [ESC] to exit fullscreen" What happens instead of that? Says other stuff - not that. There are 2-3 parts to fix this (in no particular order) A) The blocking bug ( Issue 577011 ): i.e. fix for other platforms with View::NotifyAccessibilityEvent B) Hooking up ax_platform_node_mac.mm to actually map/announce ui::AX_EVENT_ALERT things to voiceover (some combination of NSAccessibilitySubroleAttribute to @"AXApplicationAlert" and NSAccessibilityPostNotification[WithUserInfo] + NSAccessibilityAnnouncementRequestedNotification (see Issue 101062 for more info, also there are some existing PostNotificaiton call sites in browser_accessibility_manager_mac.mm [except ui::AX_EVENT_ALERT is under "// These events are not used on Mac for now"]. Maybe infobars sometimes announce already on Mac, but I didn't look into this) C?) Maybe some mac-specific adornment for the entire window with NSAccessibilityFloatingWindowSubrole -- see jeremya@'s notes on Issue 101062 Note that infobars in views do seem to use ui::AX_EVENT_ALERT, so we should make sure ax_platform_node_mac.mm processes those to VoiceOver on Mac the same way that ChromeVox does on ChromeOS. When fixed, we can close Issue 101062 - that's for the old UI so will be obsolete. Steal blockedon Issue 577011 from Matt unless he complains to do (A) Close-Fixed the blocked launch bug -- Issue 596360
,
Jul 10 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 16 2016
,
Dec 12 2016
,
Mar 6 2017
,
Mar 27 2017
,
Apr 21 2017
,
Apr 21 2017
,
Dec 20 2017
I'll take this - I think there are some avenues to explore. Hoping to get something in m65 or m66.
,
Jan 25 2018
,
Feb 14 2018
This one's still live. This isn't a regression since there is no Cocoa counterpart to this bubble (the Views one is always used everywhere). I'm going to tag this M-X for the moment - tapted@, did the exploration mentioned in #9 get anywhere?
,
Feb 15 2018
not yet.. the avenue to explore is: we currently only notify events using
void NotifyMacEvent(AXPlatformNodeCocoa* target, ax::mojom::Event event_type) {
NSAccessibilityPostNotification(
target, [AXPlatformNodeCocoa nativeNotificationFromAXEvent:event_type]);
}
for alerts with associated text, this needs to use NSAccessibilityPostNotificationWithUserInfo instead something like
NSDictionary* notification_info = @{
NSAccessibilityAnnouncementKey : [self AXValue],
NSAccessibilityPriorityKey : @(NSAccessibilityPriorityHigh)
};
NSAccessibilityPostNotificationWithUserInfo(
self, // or does it need to be an NSWindow?
NSAccessibilityAnnouncementRequestedNotification,
notification_info);
,
Mar 23 2018
MacViews triage: Let's fix this in M-68.
,
Mar 27 2018
,
Mar 29 2018
** Bulk Edit ** FYI: Starting 04/13 M68 will be in canary, M68 Dev promotion will be on 04/26.
,
Apr 16 2018
,
Apr 25 2018
Pls mark the bug as fixed if CL is landed in trunk and nothing else is pending. Thank you.
,
Apr 27 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9b735e2affd26b188a5f10668d6083d5946a1aa4 commit 9b735e2affd26b188a5f10668d6083d5946a1aa4 Author: Leonard Grey <lgrey@chromium.org> Date: Fri Apr 27 20:16:35 2018 a11y: Announce exclusive access bubble This is roughly similar to patricialor@'s work in https://codereview.chromium.org/2010493005/ Per offline conversation,this wasn't submitted at the time due to some related bugs that are now fixed. This works well in ChromeVox AFAICT. In VoiceOver, testing on permission.site, pointer lock works well, but fullscreen's announcement can sometimes be cut off by VoiceOver returning to read the rest of the page. Waiting until the animation is complete helps a little but doesn't fully fix it, but I'm not sure what else we could do. Bug: 610583 , 577011 Change-Id: Ic1ef5ba8f81d432eb1f64335be3f6bb6e4ff31f1 Reviewed-on: https://chromium-review.googlesource.com/1015554 Commit-Queue: Leonard Grey <lgrey@chromium.org> Reviewed-by: Nektarios Paisios <nektar@chromium.org> Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org> Cr-Commit-Position: refs/heads/master@{#554476} [modify] https://crrev.com/9b735e2affd26b188a5f10668d6083d5946a1aa4/chrome/browser/ui/views/exclusive_access_bubble_views.cc [modify] https://crrev.com/9b735e2affd26b188a5f10668d6083d5946a1aa4/chrome/browser/ui/views/subtle_notification_view.cc [modify] https://crrev.com/9b735e2affd26b188a5f10668d6083d5946a1aa4/chrome/browser/ui/views/subtle_notification_view.h [modify] https://crrev.com/9b735e2affd26b188a5f10668d6083d5946a1aa4/ui/accessibility/platform/ax_platform_node_mac.mm
,
Apr 27 2018
Pls mark bug as fixed if nothing else is pending. Thank you.
,
Apr 30 2018
Tested this issue on Mac 10.13.3 using chrome#68.0.3415.0 as per C#0.Voice over is reading "Press [ESC] to exit fullscreen" when we press 'Full screen' button. Please find the attached screencast for reference & confirm on the fix & expected behavior. Thanks..!
,
Apr 30 2018
That's WAI until we can figure out a way to get VoiceOver to prioritize it more. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by tapted@chromium.org
, May 31 2016