Most people who use a screen reader are almost certainly going to be more familiar with their favourite browser than a custom program. I’d say the web is a generally safe platform for accessibility.
It will be once we get ARIA support into the web apps and properly tuned. I only recently got this into Quixe and I suspect it’s still rough.
As always, I’ll be at my happiest when there are web-based and raw interpreter-playable files available. Terps are capable of tons of customisation, though this is applicable mostly to people who are already used to terps… if they’re not, Dannii’s right in that a web program is safer for accessibility.
But I understand that Twine is currently not very accessible…? Is it somehow incompatible with screen readers, or something? Anyway, I may be thinkin of something else, but if I’m correct then it means that web based is not necessarily equal to high accessibility - it still requires care in choosing your development tool.
Actually, I’d like to write all of this - and Dannii’s comment - into my first post, but I’d best be absolutely certain - is it true that, at this time, Twine is not compatible with screen readers?
This is great. It’s good to have information on the consequences of some design choices to accessibility. Is there any feedback on preferred format for feelies? Do I need to have plain text versions of my pdf files, or are pdf okay as long as the text is typed and not scanned?
I think PDF documents are accessible to most, if not all, screen readers. Still, having a text-only version would be safest (and I always choose to read a text version).
Neil
Thank you both - updated accordingly!
EDIT - Neil, I found an old thread of yours which is very relevant - https://intfiction.org/t/notes-on-screen-reader-accessibility/5660/1.
It approaches the issue from the other side - “which development tools are most accessible, and/or produce the most accessible games?”, whereas I approach the issue from “what can I do, as an author, to make sure my game is accessibly and most usable?”. I’m not sure I can fit most of your points into my main post, but our threads complement each other nicely.
I did find a post where you talked about highlighting keywords, and fitted that in. Cheers!
Peter,
I’m not sure how up-to-date that thread is. The Inform 7 IDE is a bit easier to use. The web builder for Twine games seems impossible to use with screen readers.
Things relevant to your posting:
I don’t think real-time delays are a problem with screen readers, except that users would not necessarily know the text has changed. The user would have to check for changes, but that’s not necessarily a problem since it is likely the new text will be noticed when the user starts to read or attempts a command. Any effects based on really short time intervals, though, would be missed, like the “teletype” actions described in real-time delays.
Hyperlinks are a bit of a hit-and-miss. “Simple” html links work, although I can’t really define simple. Just remember that the fancier you make your texdt, and whatever funky magic you do to manipulate how links work, will probably be very hard to use with screen readers.
Hyperlinks work in glulx, but I think that will depend on the screen reader. It’s tricky to activate these links in offline interpreters, and it takes patience an an experienced user to know how to do it. In fact, I wouldn’t play a game offline if it depended on links; just too tedious. I think online play is okay, though.
The accessibility of extra windows will depend on the type of screen reader and the knowledge base of its user. Windows created by the Flexible Windows extension can be read, but it is very confusing to read because it mixes the text in the window with the text in the main window. This makes reading the contents … challenging. I would recommend having an option to remove the window and put the text in the main window.
Neil
Wow. And here I thought playing in an interpreter would be automatically better in practically every case - I never considered hyperlinks in Glulx. I’ve added your whole post in, cheers!
The default Twine 2 format (Harlowe) makes heavy use of custom tags, and my understanding is a lot of screen readers are just not equipped to handle that? But I’ve also heard reports that other formats also have problems. As a Twine author I’d certainly appreciate more clarity on this front.
Ok, I’ll update my original post accordingly - but vaguely. Don’t want to discourage people from using Twine, or indeed using any available tool. Thanks!
I tend to sprawl all over the place, and a sprawling guide is no help at all to anyone. If anyone ever has any editing tips for me, to make it all more readable and useful, please chime in. Thanks!
You can use The IFWiki to collaborate on articles and present them in a clean way, without the discussion about the text. The wiki also gives us the change history, to note every future alteration.
Okay so I’ve been messing around a bit with Twine and screen readers tonight. Both the Harlowe and Snowman formats seem to work properly with the latest version of NVDA if you add aria-live=“polite” aria-atomic=“false” to the main story tag (which is
for Snowman and for Harlowe). This also I think works for the latest version of JAWS, but I was working with a limited-time trial version there so I don’t know for sure.
My ability to test this stuff is limited because A) I don’t know what I’m doing, B) I don’t have access to all the software and hardware I’d need to be comprehensive about this, and C) I really don’t know what I’m doing. But if I’m understanding properly, this might at least improve Twine accessibility for some users?
It definitely would! It’s exactly the sort of dev-tool-specific information that has very practical application! Much appreciated!
Oreolek, Wikis are wonderful things but they go over my head and try my patience. They’re just not for me, I’m afraid. But if anyone wants to do that, I’m glad to offer my assistance, based on the information that’s coming to light on this thread.
Note to self: Wade Clark had some great accessibility notes a while back. Self, you keep forgetting to go check them out, so I’m forced to remind you publicly in an attempt to shame you into just getting it looked at already.
It’s up to you, of course, to decide whether you want to do it or not, but for me the most tedious part of editing a wiki is marking up the text to make it conform with the style guides. But if you create your own sandbox page, you don’t have to worry about marking up the text. You can just paste the text in, and people can edit it at will, and at some point in the future people can try to neaten it up and make it an “official” public page.
“WebAIM - Web Accessibility In Mind” looks like a useful website.
Among other things, it has a contrast checker tool. You enter in your text color and the background color, and it tells you whether there’s enough contrast between the two.
That seems amazingly useful! I’ve added it in, thanks!
I have some screen-reader questions.
They read out the text as speech/sound, right? How do they handle nonstandard words? I’m thinking things like:
Made-up words
Weird fantasy names
Super-obscure English words
Foreign words and names
Dialog which the author intentionally misspells to indicate the character’s accent or speech difficulty
Partial words, e.g. you found a piece of a page that was ripped in half
Screen readers pronounce words properly when they’re spelled correctly, in most cases. Of course, homynyms sound the same. Unusual words - words not in the dictionary - are announced phonetically. It can be really hard to figure out how to spell these unusual words. If they can’t figure it out by sound, screen reader users need to follow the word character-by-character with the cursor to figure out how to type it. This is a problem for the built-in text-to-speech options in interpreters because you can’t scan text in this way. I’m guessing some screen readers can’t do it, either.
Neil
If an author is using a lot of made up words (like the spell names in Scroll Thief), how could they make it easier for screen readers to handle? Would it help to allow abbreviations of some sort, or respellings?