Screen readers vs hidden and/or spoiler text

General IF Community Resources
1

A thing that has come up lately is ASCII art and its incompatibility with screen readers. It raises issues in several Infocom games that would otherwise be completely accessible via screen reader (Zork III, Seastalker, Infidel). It has also garnered discussion for at least one game currently in development.

I am having some difficulties evaluating another screen reader situation, and would like to hear some thoughts, advice, experiences that might lead to a solution:

There are, I’m sure, multiple occasions when the use of hidden and/or spoiler text are beneficial to readers and players. The “Invisiclues” format is a tradition that is nearly as old as Zork I. The IDP hosts *.Z5 Invisiclues that work very well (and would be nice to have online at IFDB). More recently, Dan Fabulich has made some very nice Invisiclues hints right here on this forum, using the “blur spoiler” feature.

Problem: My configurations of JAWS, NVDA, and Narrator all seem to read through “blur spoiler” text. I presume this is because, just as the name says, it is blurred. The reader application does not rely on visual data, so it “sees” right through the blurriness.

Aside: I have no expertise in configuring screen readers, so it could be configuration.

Problem 2: Screen reading z-code Invisiclues is a bit fiddly. Parchment is the only one that works out of the box (presumably because reading browser text is a universal need). Perhaps Frotz and Gargoyle could do the same with configuration changes, not sure.

What brings me to this post is the fact that Seastalker comes with these small cards in which text is masked by an overlay of red text. They can be read by viewing them through a red film. I am trying to provide an accessible version of these texts.

The game references the cards by card# and line# (the references are not in order), so a plain text listing of the entries would contain spoilers. It is a scenario that calls for a hidden text solution.

I can take pictures if needed.

The easiest answer for me, of course, would be tagged text on a web page. IFDB spoilers actually do cover text with text, so they work, but IFDB isn’t really made for presenting this kind of information.

I could do the Invisiclues thing with Inform (I’m sure there are source examples for the existing resourses), though that would be slow going for a long-retired OS guy like me.

If option two is the best, then I am wondering if someone more knowledgeable about screen readers can confirm that Parchmet is, in fact, the only option at this time.

Anyway, I’m quite sure that I’m out of my depth, so any advice would be welcome. I’ll answer questions as best I can.

2 Likes
2

What about versions of the cards that are rewritten to be fun for screen reader users? Just describing “You put a red film over the text and it yields hidden text!” isn’t very fun.

I’m sure this is totally heretical, but writing a riddle or a spell to be figured out, that makes the text appear when it’s solved… that seems like more fun. Does it have to be as close to the original experience as possible?

1 Like
3

Maybe the HTML elements <summary> & <details> could be a viable option.
Link: <details>: The Details disclosure element - HTML: HyperText Markup Language | MDN

The question/hint topic would be in the summary, and the spoiler in the details.

From a cursory web search, I’m not sure how well screen readers currently support this mechanism, but it seems an interesting approach. Some more links:
Accessible accordions part 2 - using <details> and <summary> - Hassell Inclusion and Expanding summary details tag accessibility | Pat Godfrey | Blog | User Experience and summary_element (html) | Accessibility Support and The details and summary elements | scottohara.me. (Quoting from the last link: “Generally screen readers do well with standard usage of the details and summary elements.”)

1 Like
4

Since the cards are metatext, the first goal is to get them into a digital format that preserves the experience of “uncovering” a bit of text while leaving other parts of the document hidden.

Right now, they are available in two formats. One, a pile of cards on my desk with a “decoder” nearby and two, documents with all text exposed.

People who do not use screen readers would be able to have a better experience if a solution can be reached, but my first priority is providing users of screen readers with an experience that mirrors–wherever possible–the experience of playing the game with all shipped packaging, documents, and feelies.

So before we could talk about altering the experience, we need a good way to deal with hidden text (though philosophically I’m not likely to spearhead an effort to modify Infocom games)

Some images:

1536×2048 858 KB

1536×2048 858 KB

1536×2048 680 KB

5

You could publish your documents as html, which could be saved locally or accessed by the web. Either way, it would be through the user’s browser, which offers the best option for getting what you want out of a screenreader.

(Better would be a ZIL hacker adding a real hint system to the Seastalker source… but that’s a can of worms.)

1 Like
6

I think a browser solution would be ideal. I don’t want to host the material because I am a fallible human (I would really prefer using IFTF resources to host accessibility documentation for continuity’s sake).

I can’t get spoiler tags to work with screen readers on this site, which could be a configuration problem on my end.

Hacking the game may not be ideal; perhaps a researcher would like to check different versions of the game. A separate z-code file (there is already a good model for doing Invisiclues) would work well, but so far these files only work with Parchment (and I think what really makes it work is its browser platform vs custom app). Though that might be configuration, too.

Thinking beyond my situation with Seastalker, I’d like to identify a best practice for handling hidden text with screen reader tech. I don’t think this will be the only time someone will want to use/access hidden text with a screen reader. This site hosts Invisiclues, for instance.

1 Like
7

I can reproduce this in iOS VoiceOver. I’ve filed a bug with the Discourse team here.

8

Looks like there’s a Spoilers extension for Mediawiki. If it actually works well with existing screenreaders, and if the IFwiki admins were willing to install it and consider IFwiki an appropriate home for the material, then that would be a possibility. Yes, a lot of ifs in that statement.

2 Likes
9

Thanks! I hope it’s an easy fix.

It does sound like a good option, though, and having the information there makes intuitive sense. Since this need is likely to arise again, I’d like to do whatever makes the most sense from a community perspective.