Accessibility question (bold in screen readers)

[VictorGijsbers]

I’m making a game where objects you can interact with are printed in bold. Is this accessible for people who use, e.g., screen readers, or would they need a different way of setting apart these words? Is there some standard or preferred way of doing that?

[bg]

Here is some information from some older posts, linked from this ifwiki page: Accessibility for players with low vision - IFWiki

I’m not sure if recommendations have changed since then.

@Neil

Screen readers won’t read out any font attributes unless the user searches for them specifically. For example, with JAWS, you need to place the cursor on the text of interest and type the insert+F keys. Needless to say, I never do that. Symbols like asterisks are read out individually, so a series of five asterisks would be read “asterisk, asterisk, asterisk, asterisk, asterisk.”. Definitely annoying, and I stop listening, or move the cursor, after a few reiterations. It’s probably not a good idea to place important text between a series of symbols. I don’t have any suggestions on how to highlight text for screen readers, although bracketing it in single asterisks always catches my attention (although I can imagine for sighted users it may be a bit ugly).

@Neil

If game writers want to highlight important objects in the text, consider adding an option that will mark the words with, say, an asterisk. It is the only way that I can think of to ensure visually-impaired players, regardless of what screen reader they use, will pick it up without the need to press shortcut keys on individual words to find out if the font has changed. This may be distracting, in a different way than is highlighted text to sighted people, but I think players would get used to it pretty quickly. I know for Inform 7 at least that adding such an option isn’t tough to do.

There’s an Inform 7 extension, Keyword Interface by Aaron Reed, that offers the player different options to mark keywords (using text color, bold type, etc.). When I used that extension, I modified it to add more options: asterisks, the word “keyword:” preceding the keyword, and I forget what else.

[Hidnook]

@bg

When I used that extension, I modified it to add more options: asterisks, the word “keyword:” preceding the keyword, and I forget what else.

If you can find your version of that extension, please share it!

[Mewtamer (Jeffery wright)]

Orca+F will read text attributes, but this isn’t something I think to do, and I only know the keyboard shortcut because someone mentioned the JAWS command and it turns out its the same in Orca ignoring the fact my modifier key is set to the otherwise useless caps lock… and if espeakup has such functionality, I have no idea what its command is, and in general, my preference is to use console interpreters and aboid web-based stuff.

As for using punctuation for emphasis, with the settings I’m using, Orca reads * as “Star” and switches from reading individual * to counting at four-in a row without spaces(e.g. **** is read “four star characters” while *** is read “star star star”). espeakup doesn’t speak * unless I turn up the punctuation level, even reading 3*3 as “three three” at the punctuation level I use most of the time and I only think to crank punctuation up when writing code when making heavy use of symbols that are usually unvoiced in prose but which need to be voiced for code to make sense(granted, if espeakup’s keyboard shortcuts for punctuation level weren’t tied to caps lock + F9/10(which are a bit hard to locate with my keyboard having an unbroken function row merged in the the qwerty block) or my keyboard didn’t require me to hold Fn(which is next to left control and awkward to press at the same time as caps lock) for the function keys to function properly when they aren’t being alted or ctrled, maybe I’d shift punctuation level more often… and if Orca has punctuation levels that can be changed on the fly, I don’t know the hotkeys).

So yeah, I can’t think of a way of emphasizing text that would work with both of the screen readers I use on my desktop, much less without possibly being distracting for sighted players.

[VictorGijsbers]

I suppose Aaron’s extension will allow me to give options to the player. I’ll check it out!

[VictorGijsbers]

Aaron’s extension was overkill for what I wanted to do. It’s great if you want to highlight specific kinds of terms in automatic game output, e.g., make sure that nouns are also printed bold in disambiguation messages. I just need some terms to stand out in, e.g., room descriptions. So for now I’ve gone with this:

Keywording style is initially 0. [We use 0 for bold, 1 for stars, and 2 for 'keyword:']

To say o:
	if keywording style is 0:
		say "[bold type]";
	if keywording style is 1:	
		say "*";		
	if keywording style is 2:
		say "keyword:".
		
To say x:
	if keywording style is 0:
		say "[roman type]";
	if keywording style is 1:	
		say "*".
		
Keywording is an action out of world. Understand "keyword" or "keywords" as keywording.

Carry out keywording:
	if keywording style is 0:
		say "Usable nouns will now be flanked by asterisks.";
		now keywording style is 1;
	otherwise if keywording style is 1:	
		say "Usable nouns will now be prefaced by the word 'keyword'.";
		now keywording style is 2;	
	otherwise if keywording style is 2:
		say "Usable nouns will now be printed in bold.";
		now keywording style is 0.

If required, it’s easy to add more styles, but I suppose this should already help out a lot.

[Dannii]

For Parchment I have thought of using semantic elements like <em> for each corresponding Glk style, though I don’t know how much that would really help. And it wouldn’t help at all for the user1/user1 styles which is what authors often change.

[Draconis (Daniel Stelzer)]

Anecdotally, when the Å-machine web interpreter was updated to use <h2> for player inputs, <a> for links, and appropriate ARIA roles for things like emphasis, screen reader users reported that it was much easier to navigate. I think the emphasis role was the least important of these, though.

[averyhiebert]

For what it’s worth, it should be possible with HTML/CSS to insert invisible text (i.e. the asterisks option that people have mentioned here) that is still read by screenreaders, but the recommended ways of doing this are kinda hacky, and I have only had mixed success with this when trying to add screenreader support to my HTML point-and-click Ink template.