New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 916923 link

Starred by 3 users
Status: Available
Owner: ----
Cc:
sdy@chromium.org
█ nek...@chromium.org
dmazz...@chromium.org
ellyjo...@chromium.org
dominickn@chromium.org
█ bgalbs@google.com
pcovell@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

MacPWAs: Voiceover ignores text selection

Project Member Reported by ccameron@chromium.org, Dec 20 
See attached video. The initial window on the left is from a PWA and the second window on the right is from Chrome.

Voiceover "works" in both of the windows -- if the user tabs through the links, interacts with menu items, etc, everything is appropriately hilighted.

The one place where things do not work correctly is when dealing with selected text. In Chrome (and Safari), text that is selected is read aloud. In a PWA, that doesn't happen.
a11y-hilight.mov
12.7 MB View Download

Comment 1 by ccameron@chromium.org, Dec 20 

From some poking around, it's not clear to me how the text selection is communicated to voiceover. I see where we send the selected range at [0] (in the user info), but the function also works without user info (and in that case I really don't see what methods are being called to find the selected text).

We are indeed getting the ui::AXEventGenerator::Event::DOCUMENT_SELECTION_CHANGED  notification at [0] in all cases.

I tried all sorts of permutations of NSAccessibilityPostNotification[WithUserInfo] -- spamming especially GetWindow (because that hops processes), no luck.

I'd also like some guidance here about the relative importance of this. Is this a commonly used feature? And in fact ... what are the commonly used features (and are they working in PWAs?). Clicking on UI elements (buttons, fields, etc) works fine, but there may be important use cases I don't know of.

[0] https://cs.chromium.org/chromium/src/content/browser/accessibility/browser_accessibility_manager_mac.mm?rcl=6f1767b5152bce9c75aab05b70c64b01a017463b&l=243

Comment 2 by sdy@chromium.org, Dec 20

Cc: nek...@chromium.org
nektar@: Do you have any thoughts on the above comment (c#1), or mind experimenting with VoiceOver interaction in Mac PWAs? If you haven't tried them yet, there's more information at go/mac-pwas or I can show you.

Comment 3 by ccameron@chromium.org, Dec 25 

Of note is that ordinary navigation works (ctrl+shift+alt+up/down/left/right), so this is limited to mouse navigation to non-active elements (radio buttons, links, etc, are spoken appropriately)

Comment 4 by ccameron@chromium.org, Jan 2

Cc: ellyjo...@chromium.org
Attaching a video of screenreader navigation on a PWA
screenreader.mov
5.9 MB View Download
►

Sign in to add a comment