nolanlawson / pinafore

Alternative web client for Mastodon (UNMAINTAINED)
https://pinafore.social
GNU Affero General Public License v3.0
1.02k stars 176 forks source link

Accessibility, macOS: Pressing X does not automatically speak #2180

Open TheQuinbox opened 2 years ago

TheQuinbox commented 2 years ago

I'm not sure if this is intentional, but it works in every other setup I've tried on Windows, and i actually really like it.

If you're using a screen reader, and press X to show/hide a content warning, the toot gets reread, with that applied. On the Mac, however, this does not happen, making me have to scroll over it again to read the toot.

macOS Ventura, latest Safari, and VoiceOver.

MarcoZehe commented 2 years ago

This is because the aria-label gets updated, but neither Chromium browsers nor Safari fire an appropriate Mac platform event for this. On Windows, a name change event gets fired on the focused item which NVDA picks up on, and JAWS sometimes does too if it feels like it. I had this working in Firefox for Mac nicely, but it caused a different problem and got reverted later, so Firefox also doesn't notify Voiceover of the name change event any more. The funny thing is that VoiceOver reacted positively to the AXTitleChangedEvent on Pinafore, even though Safari and Chromium don't even expose AXTitle on Article elements. Firefox did, until it was removed ten months ago to be on par with Safari. Which means that it now has the same bug in Pinafore as Safari and Chrome/Edge do. AFAIK, there is nothing we can do from the app side of things to get this working. Browsers and/or VoiceOver need to change. Unfortunately, Apple are very inconsistent with what they expose when to VoiceOver. AKA there is no definitive documentation on when to use AXTitle or AXDescription, or both.

nolanlawson commented 2 years ago

Hm, there are sometimes hacks that the app author can do to get this to work correctly. E.g. remove the DOM node from the DOM and re-insert it. I don't know if it's worth it for Pinafore to try to work around browser/screenreader bugs though.

Thanks for the context @MarcoZehe !

MarcoZehe commented 2 years ago

Yeah, this might work, @nolanlawson, but it gets complicated by the fact that you'd be removing and reinserting the focused node for this. Or do you mean only the part that contains the text, and not the other information?

nolanlawson commented 2 years ago

@MarcoZehe Ah you're right, this would get very tricky very fast. Also I have no evidence this would actually work; just a hunch based on behavior I've seen from screen readers in the past.

It's a shame that this doesn't work out-of-the-box. :confused:

joel350 commented 2 years ago

Thanks

pitermach commented 1 year ago

How about using the live region that was recently added for the boost/favorite notifications to speak the post label when the CW is toggled? THis would probably have to be either tied to the user agent - do this only if someone is using a Mac, or a setting. I know of at least one Windows Screen Reader - ZDSR, which also doesn't react to the title change so it might be useful there as well.

Feel free to tell me how horrible of an idea this is

jcsteh commented 1 year ago

That would result in double speaking on browser/screen reader combinations which behave correctly, though. And using a live region alone would be bad for everyone, especially braille users.

Edit: I guess if it were Mac only, there's only one screen reader on Mac. However, one of the browsers may eventually be able to work around this and support name change, at which point we'd be double speaking.

nolanlawson commented 1 year ago

This sounds a bit brittle to me - I try to avoid UA sniffing as much as possible... Is there a bug filed on WebKit/VoiceOver somewhere?