I wonder how feasible it is to create a tutorial that is specifically geared towards screen readers? I’m envisioning something where it not only says “Try checking your INVENTORY” but “focus on the command line, type INVENTORY, then press the enter key” or something to make it clearer for people who can’t see/don’t know how to interact with the command line-style > prompt. What other features are difficult for screen reader users to figure out? I’d imagine many are game-side accessibility issues, which is the problem.
I just started playing with screen readers (since this topic was started) and I’m wrestling with the concept of not forcing a blind player to parse unnecessary information. Sighted people can ignore a familiar chunk of information by glancing elsewhere, but a screen reader is like using an interface that’s on rails with tunnel vision. It goes at one speed and you can only see what’s exactly in front of you. This also makes time a precious commodity for blind players. Switching to another track requires that enough spoken words have been consumed to make an informed decision.
There’s a design concept known as Brutalism. I believe many of the talking points are relevant for blind accessibility. Stripping something to the bare necessities, basically. Dieter Rams also talked about efficiency of design and function in his ten principles. When we talk about usability, we are talking about digital product design.
I think if I were to make a blind accessible game, I would do away with a traditional user interface all together and make the whole thing a visible log of text. If you have a settings menu, log the current choice position and log the changed setting, etc. (Be explicit and terse in non-story related feedback.) Basically, log everything the user will hear spoken and the screen reader will simply parse that text and ONLY that text. I think that would be the ultimate interface for a blind person.
I recently tried playing a text adventure game online (through the browser) with a screen reader and even having the reader repeat “greater than” > after every new command was executed was tiring and annoying. Yeah, that little arrow symbol became a point of contention for me. (I’m not very practiced with screen readers, but I am using Windows Narrator and NVDA with default settings.)
If someone were to make a tutorial, they may focus it on a single story format or interpreter and provide best practices. I’m more about Twine-like experiences so it’s easier for choice systems to completely control what gets outputted to the browser window. I wonder what the best blind-friendly interpreter for text adventures is.
I’ve only used them to experiment with, but you can also navigate to the next/previous header, link, pargraph, and so on. Also, turn the speech rate up as high as you can understand it – and you may get faster at listening too. Even from my limited experimentation, you do get much quicker and more comfortable with it over time.
But yeah, a lot of the “focus on the command line, type INVENTORY, then press the enter key” kind of stuff seems like… why would you assume this person doesn’t know how to use a computer just because they can’t see? Especially if you’ve watched blind people stream and seen the level of not-very-accessible “how do we puzzle out how this thing works?” that they deal with all the time.
Um… I’m pretty sure normal menus are just fine? Well, accessible ones in graphical games where they tell you which item you’re on. I think Inform’s usual menu extensions might kinda suck. The biggest thing I’ve learned about menus that was unintuitive to me as a sighted person is that I’m always annoyed at menus that don’t wrap bottom-to-top when you’re navigating with the arrow keys. But with a screenreader… especially with commonly used menus like the main menu of a graphical game, people seem to find it much more convenient to be able to hammer an up or down arrow to get to one end or the other, and then count positions from there (or usually the bottom one is Quit). I’ve definitely seen that called out by a blind guy who did accessibility consulting: don’t make your menu’s keyboard navigation wrap around.
Regarding wrap/no wrap with menus, I’m not sure there’s is a good, hardline rule for always wrapping or never wrapping… that said, I do find the ability to jump to the beginning/end of a long list type menu or to jump by more than one step size useful. It’s also useful to be able to jump to specific menu entries… E.g. consider having home/end on the keyboard jump to the beginning/end of a list-type menu, pageUp/Down move by say 5 or 10 menu entries if you have a very long menu or allowing the use of letter keys to jump to entries starting with that letter or having numbered menu entries, automated touch tone telephone system style for short menus with fixed entries.
Though again, this is just suggestions, I’m not convinced there are any hard, fast, one size fits all rules that actually make sense.
Huh, I thought I’d read accessibility guidelines saying there should be wraparound. This explanation makes sense, but Jeffrey’s “it depends” seems to track more. So much of accessibility is context-dependent.
I’d be inclined to make use of a sound effect that denotes the last choice of a menu and still allow wrapping to occur. A simple, short, “dun” sound might suffice. Then again, maybe letting a user toggle wrapping is the better choice. Just like, we have standardized music, speech, effects volumes for a game’s audio menu, I wonder what a standardized blind accessibility menu would entail for basic webpage parsing.
UI Rant: If a pull-down menu has more than 10 choices, it’s probably a lazy organization of information. Like, when you have to choose which language you want to use… and you have 100 choices. Break it down by continent, then language, then dialect.
IME (as a sighted person who’s used screenreaders), when you’ve reached the last choice of a menu option it moves (or should move) onto the next item in the DOM. If you can’t leave the menu via keyboard navigation because of a poorly-implemented wrap or something, that’s a keyboard trap which is very bad. A lot of this functionality is built into the <menu> and <select> elements too, no need to hand roll anything. (Also to note: the <select> element wraps by default) (and the <menu> element has the home and end buttons jump to the first and last items in the list already)
Deviding languages by continent seems a bit problematic… After all, Portuguese is spoken both in Europe and South America, Spanish in Europe, and both North and South America, and English is spoken on every human settled continent if I’m not mistaken, though agreed, if you have a really long list of options, looking for a way to divide them into a tiered menu is often a good idea, though in many cases, alphabetizing and letting the user cycle options starting with a specific letter by repeatedly pressing that character works well, though admittedly, that doesn’t work for all sets of options… As an aside, when organzing my bookmarks in Firefox, I try to avoid items in the same directory sharing the same first character and try to avoid giving bookmarks names starting with the letter O to avoid conflicts with the open all in tabs option at the bottom of any subdirectory with multiple bookmarks. The net result is that most of the bookmarks I access regularly, I can open with at most a half-dozen keystrokes… alt+b, f, I brings up the latest threads with new posts page for this forum, alt+ B, y, g, o opens the /videos page for all the YouTube channels I have bookmarked beginning with the letters G and H, alt+b, c, f, b brings up my Online Banking portal, etc. Or to go from the keystrokes to folder names, alt+B open the bookmarks menu and I go:
Forums > Interactive Fiction
YouTube > GH > Open all in tabs
Consumerism > Finances > Bank Pre-blindness, I believe I had Consumerism named shopping but renamed it because s corresponds to the menu option to search my bookmarks and I renamed the bookmark for my online banking to just Bank because I got tired of renaming it everytime my bank got bought out or merged with another bank.
Of course, this is just some examples of how I organize a menu I have near complete control over to fit my use case.
Yeah, thanks. I still don’t think of it as a hardline rule, but it had never occurred to me at all before that there could be a downside to wrapping, so hearing someone who strongly preferred it not to has stuck with me as a thing to consider.