“You get down off a goose, not a dragon?”
1 Like
I went with “duck”. 
But there were three answers!
I see now that the original Zork Users Group Zork 2 Invisiclues (PDF) didn’t have the sample question; the subsequent Infocom Zork 2 Invisiclues (PDF) did.
1 Like
This isn’t, mind you, a herculean project. But it’s not a project for someone avoiding spoilers.
I’ve found there’s a Lost Treasures of Infocom (Un-)Invisiclues PDF which is great for checking the text, but which doesn’t have any illustrations, maps, or sample questions… except for Hitchhiker’s for which it has the maps. (There were separate map PDFs for others, not sure if it’s all of them.) And Classic Text Adventure Masterpieces of Infocom includes a revealed-Invisiclues PDF much like Lost Treasures’ but doesn’t have Hitchhiker’s and does include maps for Plundered Hearts and Trinity, which weren’t in Lost Treasures, and also for Stationfall, which was. I couldn’t find a readily downloadable copy of the PDF, but one can download the whole cd-rom image. (Lost Treasures II didn’t have an Invisiclues PDF.)
Wow. I knew it was a bother to try to collect all the ancillary Infocom materials but it’s worse than I thought!
I’ve also been struggling with coming up with a decent way to make these accessible. There’s an inherent struggle here to manage that in the face of deliberately withholding information. What I have right now is pages with lots of links whose link text is just A, B, C, D, which flunks accessibility in a big way on two counts: links should communicate meaningfully where they’re going, and you shouldn’t have the same link text going to different places.
I’m leaning toward the best approach being that every clue (or other thingy with hidden content) gets its own page or popup window. In context, with the question being alone on the page or window, links labelled A, B, C, D are maybe okay. (“Use more popup windows” isn’t often heard in accessibility circles, but this is a weird case.)
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.
2 Likes
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.
3 Likes
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.
1 Like
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?
- Heading level 2: Jungles of Miznia
- Heading level 3: How do I get into the gondola?
- List: link A, link B (or buttons): yu toggle them on or off.
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/
3 Likes
That was the one I was thinking of! Ty!