Spoiler issues with VoiceOver

bug
, ,
1

Continuing the discussion from Spoiler blur not compatible with screen readers:

I’ve had a report from a VoiceOver user that the new spoiler code doesn’t work:

Have any of my fellow screenreader users been experiencing difficulties with the updated spoilers feature on the forum? At least I ASSUME there’s been an update—it used to be that spoiler text would read as normal with no indication that anything was supposed to be hidden, which of course wasn’t ideal. The update seems to have fixed this issue by putting content behind a collapsible area labeled “show hidden content”, but for some reason the text isn’t being picked up when I press the button to expand/reveal it. For reference I’m using Voiceover, Apple’s native screenreader, and I’ve noticed this both on iOS and Mac OS.

3 Likes
3

Someone else said

I have the same issues when using NVDA on Windows.

And a third person concurred.

Sorry, but it doesn’t seem like the current code works adequately! Probably would be better to even roll back to the old code.

1 Like
6

Hey @Dannii, thanks for identifying this issue. I’ve just pushed out a fix, which should now improve the behavior so that screen readers read the contents of the spoiler once it is toggled.

4 Likes
7

I’ve upgraded my forum, but the screen-reader users are reporting that nothing has changed for them.

1 Like
8

Are you sure the plugin is upgraded to the latest version? (commit 0ee68da)

It seems to be working here on Meta for me with VoiceOver. We are also using aria-live as polite for this which means the screen reader won’t be so assertive and disruptive. Instead, it will wait for the user to be idle to speak the contents.

Testing this will be read

1 Like
9

Yep, the spoiler plugin is at 0ee68da1.

1 Like
11

Keegan, can you say a little more about how you’re testing this? Your screenshot looks like a desktop browser. Are you using macOS VoiceOver? (In what browser?)

macOS VoiceOver is a very different product from iOS VoiceOver. It’s common for there to bugs in macOS VoiceOver that don’t appear in iOS VoiceOver, and vice versa. (For various reasons, iOS VoiceOver is vastly more popular among visually impaired users than macOS VoiceOver.)

When I just attempted to test your post https://meta.discourse.org/t/spoiler-issues-with-voiceover/257450/8?u=dfabulich on iOS Safari 16.3.1, this is what I saw:

Here’s a transcript:

  • The video starts with focus on the video. Then I swipe right to focus the blurred spoiler text.
  • VoiceOver announces: “Show hidden content. Button. Collapsed. Double tap to expand.”
  • I double-tap. The spoiler text is visually unblurred.
  • VoiceOver announces: “Hide content. Expanded. Hide content.” I claim that this is a bug in Discourse. It should have read the text content aloud, as it did in keegan’s video.
  • I swipe right, navigating to the next UI control.
  • VoiceOver announces: “One person liked this post. Click to view. Toggle button.”
  • I swipe left, navigating back to the unblurred spoiler text.
  • VoiceOver announces: “Hide content. Button. Expanded. Double tap to collapse.”
  • I then swipe right and left again just to double check that the same behavior occurs, and it does.

We have reports from users on the intfiction.org forum that the spoiler blur is busted in NVDA as well, which might be worth testing on your end.

2 Likes
12

Hey @dfabulich, thanks for sharing these details. Yes, I was testing primarily on Chrome (macOS VoiceOver and Windows 11 Narrator).

I’ll do some more digging/testing and see if I can push out fix soon that solves the issue for iOS, NVDA and other major devices.

Thanks!

3 Likes
13

Yeah, neither of those are remotely popular screen readers, and should not be your primary platforms for testing.

Here’s the major industry survey of screen reader users, from WebAIM.

https://webaim.org/projects/screenreadersurvey9/ (they re-run this survey once every few years; this is from 2021)

Now, you’ve gotta read this survey carefully, because it first talks about desktop browsers, and has a chart “Primary Screen Reader” https://webaim.org/projects/screenreadersurvey9/#primary but it’s specifically referring to primary “desktop/laptop” screen reader.

That chart indicates that “VoiceOver” isn’t very popular, but it’s referring to macOS VoiceOver in that section. (If you scroll down to the “Operating Systems” section, you’ll see that macOS itself isn’t very popular among screen reader users.)

JAWS for Windows is the leading screen reader, followed by NVDA for Windows. macOS VoiceOver is a distant third. Windows Narrator clocks in at 0.5% usage!

Note that JAWS costs money (and its licensing scheme is onerous), and NVDA is free. But also, NVDA tends to be buggier than JAWS; IME, anything that works in NVDA also works in JAWS.

Later, it talks about “Mobile Screen Readers Used” https://webaim.org/projects/screenreadersurvey9/#mobilescreenreaders

That chart shows that the OS builtin screen readers dominate, with iOS VoiceOver (71.5%) and Android TalkBack (29.1%). (These add up to more than 100% because some people use both.)

Missing from this survey is a “time on mobile vs. time on desktop” survey, but, in my experience, the vast majority of bug reports I hear from screen reader users are from iOS users and NVDA users.

So, therefore, I recommend testing in this priority order:

  1. iOS Safari VoiceOver. I recommend mobile over desktop (because, I claim without data, that mobile is significantly more popular among visually impaired users) and iOS over Android, because iOS is overwhelmingly more popular than Android among visually impaired users.
  2. Windows NVDA on Chrome. NVDA is not quite as popular as JAWS, but it’s buggier. Anything that works in NVDA will also work on JAWS, but not necessarily vice versa.
  3. Windows JAWS on Chrome.
  4. Android TalkBack on Chrome.
  5. macOS VoiceOver on Safari.

But I think you’ll find that just testing in iOS Safari VoiceOver gets excellent bang for your buck. I normally test iOS Safari only, and then Windows NVDA on Chrome when I want to be very thorough, and then I typically stop.

It’s been at least five years since I’ve seen a user report a bug that occurs in Windows JAWS but not Windows NVDA. I think I’ve never seen a user report a bug on Android TalkBack at all.

4 Likes
14

Any progress on this issue yet?

15

aria-live isn’t meant to be toggled. You should set it to polite at the start and leave it on. With the existing implementation, it never gets to recognize a change has been made because changes never happen while it’s on.

1 Like
16

The problem for me (NVDA/Windows) seems to be that you have an outer div with an aria-label. I believe that in most screenreaders, this is not an annotation of the contents, it’s a replacement for inaccessible content. At least, the aria-label is the only thing that’s getting read for me.

Here’s a recording of the spoiler in this thread: reading the time scrubber at the bottom of the video, then a blank (dunno what that is), then the visible spoiler (“button expanded hide content”) and then the “2 replies” dropdown.

Note that if I use NVDA’s debug feature and mouse over the expanded text to read it, it does read. But I haven’t found any way to get it to read the text without using the mouse. So that doesn’t seem to be a valid way to test whether it’s actually accessible…

2 Likes
17

I’ve made a PR with some accessibility improvements:

3 Likes
19

Thanks @Dannii for the PR :slight_smile:

I’ve just reviewed it and added some comments, just some very minor things, but otherwise it looks good!

1 Like
21

Thanks @Dannii, your PR has been merged :slight_smile: this issue should now be resolved

2 Likes