Accessibility Cookbook for the Empathically Challenged

Authoring TADS
1

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?

8 Likes
2

This recent thread had some good thoughts as well.

8 Likes
3

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?

1 Like
4

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";
    }
;
2 Likes
5

Ok, interesting side effect. When I do this, QTADS’ room suffix goes away! Seems statuslineBanner.removeBanner(); is the way to go.

2 Likes