I did a bunch of research on this in the past and concluded that the best option for me was posting invisiclues here on the forum, with [spoiler] tags.
Works pretty well in my experience. They’re easy to read and edit. People can ask questions. I believe they’re screen reader compatible, and if not, we can file a big on Discourse and they’ll fix it.
NVDA reads spoilers just like normal text. If you’re in line-by-line mode there’s a break before each, I think? But no indication that they’re supposed to be hidden.
They’re not. And there’s not some easy, direct way to fix it: accessibility would require a fundamentally different approach.
Ah, that’s annoying. I was assuming that there would be an ARIA role that would hide it, and that could be easily added. I guess the code could replace the actual text instead of just using a CSS blur filter, but…getting it the right size might be a problem? Hmm. Actually you could just measure it before you replace it? That shouldn’t be too difficult…
The hiding, per se, isn’t the problem. The UI to let a screenreader user find how to ask for the spoiler they want while not receiving spoilers they don’t want, while adhering to the principle I alluded to above of giving the user a reasonable expectation of the consequence of selecting a given link (or, more generally, selectable UI element) is the tricky part.
When a similar topic came up a while ago, I had the impression from my (admittedly only cursory) research that the HTML elements summary and details might work well with screen readers.
If I understand/remember correctly, then the summaries would appear as “buttons” to screen reader users, which they could presumably tab through to find the hint they’re interested in, and then expand that to show the spoiling details.
Huh. What am I missing? That part seems extremely trivial to me: it’s already clickable: for me that part is audible with NVDA on the default settings. If there are ways to hide content from a screenreader, there are definitely ways to add aditional details: why wouldn’t it work to simply toggle the content that the screenreader reads between the spoilered content and, say, the word “spoiler” or “reveal hidden content”?
Edit: I should stop speculating and just go try implementing it and see what the issues are, huh?
I think it’s easier than it looks. I’ve almost got it figured out, except that I can’t get the screen reader to pro-actively announce the change after revealing the spoiler text. (EDIT: I got it to announce the change.)
When I test it with iOS Voiceover, the spoiler text is not read aloud, but is announced as a button, “reveal spoiler.” When I activate the button, the text is revealed and the spoiler is read aloud.
Relevant issues:
One of the ways a screenreader offers to find desired content on a web page is to read aloud the text of the available links. An accessible page needs to accommodate the results of doing so being meaningful. Saying “spoiler spoiler spoiler spoiler” for that case doesn’t cut it.
Everyone is right about it being a straightforwardly solved technical problem in the context of a solitary element. What I’ve been trying to convey is that presenting a whole collection of such information in a way that’s meaningfully navigable is a different and more complicated problem.
All screen readers I’m aware of allow the user to navigate by headings as well as from one focusable element to the next. So as long as the questions/sections are headings, the user can just skip ahead to the next heading, and continue reading from there.
(Sighted users operating by keyboard can press Page Down to scroll to the next page, and tab from there.)
I’m sorry, but I’m still confused. Isn’t that provided by the way the page is laid out? Why would it be any different for a screenreader user?
Trying your demo with NVDA and a blindfold, it seems pretty close: if it actually announced the changes when you toggled the link it’d be perfect, wouldn’t it? What more are you looking for?
Yeah, I forgot role="alert". But as to why it’d still be imperfect…
Suppose there’s a question with just one answer. A screenreader user reads it. They won’t know, at this point, that there’s only one answer. So they hit tab, and now they’re on the next selectable element, and the only thing they’re told about it is: “A”. It would be obvious to a sighted user that they’re in a different question and what question it was. A screenreader user would have no idea where they were. Accessible design strives to avoid leaving a user with no idea where they are. Now, we could tack on “Answer 1 of 1” or something, but that doesn’t make this a non-issue 'cause we still don’t want to leave the screenreader user with no idea where they are if they hit tab too many times.
And if all the information is on one page, it’d be easy for them to end up receiving spoilers they don’t want while trying to get their bearings. With Deadline, even the section names are initially hidden for some things.
Well, yeah, but it’s only non-obvious because you have a bug where you don’t include the list index in the expanded version. If you fixed that it’d be clear that going from “A. blah blah blah” to “A.” has taken you from the end of one list to the start of another. Personally I’d number the list items instead of lettering them, too.
Edit: and yeah, you could also do them in <details> and <summary> tags if you wanted them to be nested for even more convenient navigation for both sighted and screenreader users: I probably would have. But it’s not terrible as-is.
Peter Scheyen had the Invisiclues in html format on his Infocom page: https://web.archive.org/web/20070714065201/http://www.csd.uwo.ca/Infocom/Invisiclues/
That was the one I was thinking of! Ty!
That’s the one I recall, too.
Not a very thorough survey, but the five questions I selected from the Enchanter invisiclues don’t click through.
Sorry, didn‘t notice that the dump is incomplete. There seems to be a mirror of the original site at http://infocom.elsewhere.org/scheyen/
Now we’re cookin’ with gas, thanks!
nice! thanks for running that down.
Glad, I could help. But the real kudos must go to whomever is maintaining the mirror. The wayback machine is obviously not the tenacious memory we need 