As the infrastructure phase of my project winds down, it’s probably time for me to consider accessibility. This is an area I have no prior exposure to beyond recognizing it as a concern. I found two intfiction.org threads that seem helpful on this score:
Accessibility and Usability Notes for Authors and IFTFS Accessibility Testing Project Report
Any other resources out there I should be aware of, ideally in a ‘hand-holding an idiot, step-by-step’ format?
This recent thread had some good thoughts as well.
From the general thread above, to some specific TADS things:
So it appears to be an Adv3lite thing, or at least not a default TADS capability, in that my WIP only allows it for adjacent rooms. Anyone aware of an ADV3 library or extension for this, before I start coding? :]
Deeper on this a bit, the Cookbook implementation appears to be challenged, specifically in QTADS. Lectrote, Gargoyle, Frobtads and Parchment all handle this well:
statusLine.statusDispMode = StatusModeText;
QTADS, however, seems to insist on Suffixing every output with the Room Name. To wit:
ROOM
A room description.
There is an object here. ROOM
Particularly intrusive when the system messages do not contain trailing spaces:
ROOM
A room description.
Obvious exits: EastROOM
Now, maybe QTADS is not invoked when screen readers are employed? Though I understand them to be intended for any window interface. Am I missing something, and this is Helpful, Actually?
And one level deeper. Building on the Cookbook solution above, it seemed to me that adding exit listings when Stats Banner disabled was a nice touch. Here is my code:
"\bWill you be using a screen reader? (Yes or no.)";
if(yesOrNo()) {
local xStatusLine = nil;
local xLookDesc = true; // this adds exits to Room descriptions
// disable status banner and list exits in all room descriptions
statusLine.statusDispMode = StatusModeText;
gExitLister.exitsOnOffCommand(xStatusLine, xLookDesc);
gExitLister.exitsOnOffExplained = nil; // OnOffCommand sets to true, but not wanted here
"Note you can change exit listing mode with the EXITS command, if desired.\n ";
inputManager.pauseForMore(true);
// resize banner given exit description repurposing above
statuslineBanner.clearWindow();
statuslineBanner.setSize(0, BannerSizeAbsolute, true);
statuslineBanner.sizeToContents();
// statuslineBanner.removeBanner(); // uncomment to remove completely
}
cls();
In QTADS, in addition to the double-Room naming, this disables the banner. In Lectrote, Gargoyle, Parchment and Frobtads, it preserves a 1-line Banner. Q: while this has some aesthetic appeal to the sighted, is this still intrusive to readers and should I just go ahead and remove the banner? (With option to restore if desired.) Am inclined for the latter.
Initially, per the Cookbook, I put this code in a
screenReaderInit: InitObject
execute() {
// above code here!
}
;
gExitLister.exitsOnOffCommand(xStatusLine, xLookDesc); did not care for that, seems xLookDesc was not settable early. Worked fine when I put it here:
gameMain: GameMainDef
initialPlayerChar = me
/* transcript creation code from tomasb */
newGame() {
//local date = new Date();
//ScriptAction.performFileOp('transcripts/' + date, nil);
inherited;
}
showIntro() {
// above code here, before other intro work!
"I envy you the journey you are about to undertake...\n";
}
;
Ok, interesting side effect. When I do this, QTADS’ room suffix goes away! Seems statuslineBanner.removeBanner(); is the way to go.
Accessibility question: when using a screen reader, is bolded text flagged to the player in any way? If not, is there a way to emphasize text to players using screen readers?
I can partially answer part of your question, at least: in HTML, elements can be tagged with the “emphasis” or “strong” roles, to tell screen readers to emphasize them. The former is set by default on <em> and <i> tags (inline emphasis), the latter on <strong> and <b> tags (interrupting emphasis).
Thanks for the response, I guess I was poking specifically at non-web interactions - someone playing via an interpreter, technically including Parchment I suppose, though that does not seem to have HTML TADS support.
IAC I did some online poking around and came across a few articles, including this one and this other one. My takeaway is that while some readers do support emphasized text, it is considered intrusive to consume and is a non-default option if supported at all.
It seems the best solution is to clue something’s importance in the text itself, not rely on markup. That kinda feels like writing advice too?
I’d say that’s mostly right. Most screen readers these days do support reading of emphasis and other text characteristics like foreground and background color, font name, size, style, etc. These are usually separate options to give more granular control, and they’re usually all off by default to cut down on noise. Even relatively low-key text can sound busy.
I’m happy to report that text characteristics are described in both HTML TADS on Windows and FrobTADS on Linux, although in my case I used the NVDA (Windows only) screen reader for both, since I don’t use desktop Linux and I’m only average with Espeakup. Glancing at the docs, though, it doesn’t look like it reads any of this. Someone who uses different software might want to check this on their setup.
It’s good advice for static writing and IF which doesn’t use emphasis at all, but I’m not sure how well it translates to a game which will have a keywords system or something of the like. The advantage of being able to point the player directly at important stuff is lost when they have to read carefully over everything, just to pick out something that the author didn’t think worth hiding in the text to begin with. That itself might become an accessibility problem (and not just for screen readers) if the game relies on the player knowing what’s been emphasized. I don’t know enough about writing TADS to suggest anything specific to that system, but if you don’t mind some general suggestions:
You could surround emphasized text with distinguishing punctuation marks. * or / are usually read out by default, and any user who’s spent any time IMing is probably familiar with this form of emphasis. I use it myself, even on platforms which support markdown. It may still be a little distracting if it happens a lot, but so long as the player is informed and has the option to turn it off, I don’t see the harm in offering it. A lot of text-to-speech (TTS) engines also pause briefly when reading parenthetical text (just like humans do), so that’s another option.
A final option might be to give the player a command which lists recently displayed keywords, although how it should decide what (and how much) to list might be hard to answer.
Overall, as a player, I’d prefer the *delimited* or (parenthetical) forms. It adds a little noise to the output, but it’s unambiguous, and you get the same benefits as a sighted player reading through and making note of highlighted text. I also wouldn’t mind too much if I had to turn on reporting styles/colors once and a while for particular games, but it’s not guaranteed that it’ll work on all systems, and others might find it too intrusive, as you mentioned.
Thank you so much for this feedback, especially the above. With no experience of my own, I am combating some legendary obliviousness here. Might I ask another question? One source on the internet observed that italicized text sometimes confounds screen readers, though that article was maybe 5 years old. Do you happen to know if that is still true? I had kind of assumed that was a non-issue.
Not an issue as far as I’m aware. Most screen readers just ignore font styles unless told otherwise. Some may present the document view slightly differently (mine will break a line when text attributes change) but it’s not disruptive or anything.
Always happy to help out with this kind of stuff. Your efforts and questions are very appreciated!