A few weeks ago I started writing a post about the challenges a player with a disability might face in trying to participate in a tabletop role-playing game. I ended up trashing it because, after a few weeks on Twitter collecting experiences, I realized I’m not the one who you should be listening to for those stories. If you want to know what its like to be a blind gamer go follow @BlindTemple, @brailleknights or @AccessibleGames on Twitter and ask them. There’s others too, those are just the people I follow. So I’m not going to tell you what its like to be a fan of tabletop role-playing games with a disability. Instead, I am going to try and tell you how to make the digital document file for your game accessible to them.
There are gamers with all types of disabilities. Apocalypse World and PbtA put a huge spotlight on the mental health of the players, and because of that things like the X-Card and consent at the table are just par for the course now. I don’t want to repeat work that has already been done to a much higher degree of quality than I could produce myself. So this post will focus on players who have some degree of vision loss. Not all users with sight loss are totally blind. Some have partial sight. Some can see in contrast. Some lost their sight later in life, some were born blind. Even colorblindness counts here. These users are some of the most often neglected because the means of making a digital document accessible to them requires the most consideration, which are unfortunately also the least understood considerations that you should be taking as a creator. Nobody wants to exclude blind readers from accessing their games, but few people understand how to enable them, and there’s no lesson more daunting to learn than the one you don’t understand the scope of. Well, worry not, because its not as hard as you think. But first, answers to some common questions…
Question: “Blind people can use the internet?”
Answer: It’s the 21st century, next question please.
Question: “What percentage of my readers do people with vision loss actually make up? How many readers are actually being impacted?”
Answer: That’s not the right question. If this is your gut reaction you’re already not thinking about this correctly. At best, this is an attempt at deflection. It doesn’t matter how many there are. The thing is, if someone can’t access your document then they’re not going to keep trying. That’s why you don’t hear from them very often.
Question: “What I have to do to make it accessible would mess up the way I want my layout to look.”
Answer: That’s not a question, it’s a speculation, and its wildly incorrect. Making your document accessible won’t change anything for your sighted readers. If you do it right, and you do it when you’re supposed to do it, they’ll never know.
Question: “Can I get sued if I don’t do this?”
Answer: I mean… yes and no. Nobody gets sued because their website or document file is inaccessible, they get sued because they were made aware that its inaccessible by a user or customer being blocked from accessing it, and they then established a clear pattern of not doing anything about it. Even then, ADA is an old law. Older than the internet. There’s enough wiggle room in its verbiage that the owners of inaccessible sites and files can argue in court that web sites are not “places of public accommodation”. That’s a load of crap to the rest of us with any sense, but that’s how it is today and you can blame every person who ever worked against net neutrality, in favor of corporations, that the internet isn’t considered a public utility. So, can you get sued? Yes. Is it worth someone’s time to sue you and will you lose the lawsuit if they do? That’s not a simple answer, and I’m not a lawyer.
Question: “I’ve read the Americans with Disabilities Act and it doesn’t say I’m required to make my digital documents accessible.”
Answer: Again, not a question. While you’re technically not wrong about this, strictly speaking to the letter of the law, you’re wrong in the sense that it is morally incorrect to double down on this. But you’re right, it doesn’t explicitly say you are required. So if that’s all you need to hear there’s no sense in reading further. Have a good one. Don’t let the door hit you in the ass.
For everyone who wants to give a shit, let’s continue. These are basic guidelines. I will go over how to implement these guidelines in different software packages in future posts, they each deserve their own mention as they don’t all do the same things in the same ways. Also, I have to learn how to use many of them, so we’re both learning things as we go here.
The First Rule
The first rule is more something to bear in mind than a rule. Accessibility is not a template you slap on to your document after its finished. You can do it that way, but you’re doubling your work and it will make your life easier if you can internalize these things and implement them as you create your document. It might take you an extra 30 minutes to create proper heading level structure as you’re typing your book in Word, but it’ll take you an extra week to fix it in Acrobat after it’s been exported to PDF. So just keep that in mind; accessibility has to start in design, or it gets exponentially more difficult to incorporate.
One additional note, it is possible for something to be accessible but not useable. Like everything else, you can overdo it. If you’re very worried about it you most likely will. That’s okay though, you’ll get the hang of it. Take your feedback from your blind readers the same way you’d take it from anyone else and grow as you go. That is the real first rule; have empathy.
Heading Levels and Document Structure
This is probably one of the most important things to remember to do. A screen reader user has commands available to them that enables them to navigate directly to certain heading levels, and correctly using a heading level structure is how you set them up to do so. The first basic rule is that heading levels must be nested logically. This means that your document should start with heading level 1, hereafter referred to as “H1”. Typically this is the title of the book, on page 1. It is the first text you encounter when you begin reading. As a generic rule you should only have a single H1 in your document, though there’s space for exceptions to this especially with books that are quite large. If you make each chapter heading an H1, for example, nobody would get confused. After the H1, implement subsequent nested heading levels as needed as long as they are nested logically. H2 follows H1, H3 follows H2, so on and so forth. Don’t skip heading levels and go from H2 to H5, that’s not logical.
The mistake people usually make in using heading levels, aside from not using them at all, is to use them to create desired visual styling. Maybe you like how “Heading 3” in Word makes your text look, but you should only use the Heading markup if the text is actually a level 3 heading. To achieve your desired visual styling, try the font size, font color and font style controls like everyone else uses.
The other rule is that the programmatic heading levels must match the visually logical heading level structure. When you look at your document you can generally see what text you intended to be a heading level and what level in the hierarchy you intended it to be. You have to use the heading level markup that matches what you see visually. Text that does not look like a heading should not have heading markup, and text that does look like a heading must use heading markup.
While we’re on the topic of heading levels and desired visual styling, it is an important note that your heading level text styling should appear consistent throughout your entire document. How you make your H2 text look should be the way your H2 text looks everywhere it appears. In the above example image of a page from the famous dragon game, the visual styling of each heading level is consistent throughout the book. This is a cognitive concern more than a vision concern. If your level 2 heading text has different size, color or font every time you use it, people are going to have a hard time parsing what the logical structure is supposed to be, and that’s extra true for anyone with problems focusing, or short term memory concerns.
As a final note on document structure, it is a requirement that documents in excess of 20 pages be bookmarked. Best practice is to bookmark it no matter how many pages it is. The good news is that if you use the correct heading level structure throughout then all the guesswork is taken out of where the bookmarks should go: just bookmark it to match the heading structure.
Images and Graphics
Game books are full of evocative art, and for a screen reader user to know what it all is, your art needs text alternatives. Any image that has meaning, adds context to the text around it, or is meant to be supportive of the document needs to have alt text. Different software implements alt text differently, but in general the alt text should describe the image contents without being overly verbose about it. “A troll” is acceptable alt text for the image shown here, to the right, but “a troll wielding a large stone hammer” is better. “A troll wielding a large stone hammer, emerging from the mists of a rocky crag” is even more descriptive, sparks more imagination, but doesn’t take it too far. More than that might be encroaching upon too verbose. Alt text should also not start with words like “image of” or “picture of” because screen readers know what it is and they are going to tell the user that it’s an image by default.
Some images do not require alt text because they are not meaningful. Separator bars, background images, decorative frames and the like are just that: decorative. Decorative images can be marked as such and screen readers will ignore them.
Opinions vary within the screen reader community, but in general you should avoid marking every image as decorative thinking that it’s all just audio clutter to them. Artwork is meant to inspire us to imagine the game in greater detail, or to create stories within the game. Just like a sighted user gets that experience from looking at the art, so too does a screen reader user. They get it from the image alt text, and depriving them of the book’s artwork is denying them that experience. If the individual reader doesn’t want to parse the art, they have commands to skip it.
Text Size and Color Contrast
Text size is a big problem for folks with partial vision loss, but they do have tools on their devices to magnify the screen. Even so, you should avoid using very small text for a plethora of reasons. There’s no hard and fast rule for what the minimum size is, but I personally tend not to go below 9 point. Text spacing on the other hand, there are hard and fast rules for…
- Line height (line spacing) to at least 1.5 times the font size; so at 10 point font your line spacing should be 15 point.
- Spacing following paragraphs to at least 2 times the font size; so 20 points if your text is 10 point.
- Letter spacing (tracking) to at least 0.12 times the font size; that’s 1.2 for 10 point text.
- Word spacing to at least 0.16 times the font size; or 1.6 for 10 point text.
If you don’t use 10 point text size you’ll have to mathmagically figure it out yourself.
It is often best to try and avoid serif fonts because sans-serif fonts are much more consumable to folks with dyslexia. You can even take it a step further and use a font that is specifically dyslexia-friendly. Generally though, just bear in mind serif fonts tend to run together for some sighted readers with cognitive concerns.
On the subject of text, you want to avoid using images of text where it is possible use actual text. A lot of PDFs of old books are guilty of this; they aren’t actually text, they’re scanned images of the pages of the book: every page is one large image of text. It is completely impossible for a screen reader user to read them. When you absolutely must use an image in place of text (i.e. such as your game’s logo), reference the above section on images and alt text. The alt text for the image must contain the text that is in the image.
Color contrast is important for readers with partial vision loss or color perception issues. Here is a tool I use in my day job to check color contrast ratios. The minimum color contrast ratio for text against its background color is 4.5:1 or higher. For large text, defined as 18 point or 14 point bold, the requirement drops to 3:1. For reference, black text on white paper has a contrast ratio of 21:1, so that’s always a safe bet. 3:1 is also the minimum contrast requirement for non-text elements, like icons. Logos are weirdly exempt from contrast requirements, most likely because of how many huge super-corporations complained that they had to fix something, and instead leveraged their influence to make the system bend to them instead of the other way around. Don’t be like those people.
On the subject of color, no element of your game should be identifiable via color alone. You can color-code your attribute scores if you want: red for Body, blue for Mind, green for Soul. Just make sure there’s some other means of identifying the element. A good rule of thumb is to use two or more visual characteristics to identify things if a reader is supposed to be able to extract some form of meaning by looking at it. One in 12 men, and 1 in 200 women are colorblind. This is a pretty well known rule in the board game creation community, but I have not been a part of the TTRPG creator community for very long so in case that’s not as well known a rule, there you go.
Tables, Charts and Lists
Oh boy! Tables! TTRPGs love a good table. Some of them are nothing but tables. Tables, tables, tables… Who doesn’t love tables? I know the answer. It’s blind readers. Blind readers hate tables.
The short, simple solution here is “don’t use tables”, but there’s a lot more to it than that in reality. Type it out where possible. Instead of a table to list out weapons, their weight, cost and damage ratings, just type it out. “A dagger costs 2 gold pieces, weighs 1 pound and deals 1d4 piercing damage.” That’s much easier to parse non-visually than a table. But I get it; this is the one thing you absolutely will resist because you must have these tables in your book. Fine, I understand. Make sure you do these things…
- Actually use a proper table. Don’t create a table out of white space and lines you draw on the page. In whatever software you’re using (I’ll cover those in the future), figure out how to create an actual data table and use it.
- DO NOT use tables for LAYOUT. In HTML it is possible to hide the table semantics from screen readers and get around this rule, but I am not so certain it’s that easy to do in desktop publishing. So, again, the year is 2021, do not use a table for layout purposes. If you want columns of text, create columns of text correctly. Don’t shortcut by using a one row, two column table. Visually it may look the same, but non-visually it isn’t.
- If your software lets you create a table, then it also lets you give that table headers. You need to use them.
- Do not use merged cells.
- Do not use merged cells.
- If your book is strictly digital, maybe don’t put interactive elements like hyperlinks in the table cells. This won’t always cause issues, but it can potentially cause issues.
So those are basic guidelines. Tables and how to navigate them non-visually is quite a dense topic, and it could be its own long, boring post all of its own. If your table is what we call a “complex table”, meaning it has merged cells that span multiple rows, or multiple columns, or more than one header row (such as a horizontal header row as well as a vertical header column, or a top level header row for organizing a second level of headers), then it just got much, much more complicated. In general, all you can usually do (unless you’re building your table in HTML) is correctly use the tools available to you within the software you’re using. Beyond that, just understand that the platform is often quite limiting when it comes to the complex tables you are trying to create.
Thankfully, TTRPGs don’t frequently use charts these days. If you find yourself trying to insert one into your book chances are good that what you’re actually inserting is an image of a chart. If that’s the case, it needs alt text like any other image, but the alt text needs to explain the data the chart is showing and that’s often far too verbose for image alt text. If it’s not, great! Cram it in there. But if the chart is very complex then it needs to be explained by some long form text based method, such as a caption, or a body of text near the chart. The alt text can describe the general trend of the chart and/or direct the reader to a more comprehensive explanation of its data.
There are visual considerations to account for when using charts as well. Data points need to be labeled and visually identifiable. Charts too follow the rule for not using color alone to represent data. Typically charts use color in addition to a pattern fill to represent the data points, but you’re free to use whatever method at your disposal to make it clear as long as you don’t use color alone.
Lists are much easier than tables or charts to digest. There are two kinds of lists: ordered (or numbered) and un-ordered (or bulleted). All you have to do is use an actual list, via whatever means your software gives you to create them. Don’t indent the text and then draw bullets with the shape tool, it will confuse a non-visual reader. That’s really the only way you can screw one up. Lists are, in general, much more accessible than tables or charts.
Too long; didn’t read
I’ve already written so much, but I feel like there’s so much more left to say. These are the basics. Let’s recap, because I know you glossed over reading most of this.
- Have empathy for your blind readers and their experiences.
- Don’t wait until your book is finished to make it accessible.
- Use correct heading levels, and only for their intended purpose.
- Bookmark your shit!
- Meaningful images need alternative text.
- Text should not be an image.
- Color contrast ratio minimum is 4.5:1, 3:1 for non-text elements
- Don’t use color alone to communicate meanings.
- Tables suck, be careful with them.
- Charts suck even more than tables.
There may be points I’ve neglected to cover. There are definitely points I neglected to cover. Now that I’m here at the end I realize its not possible to make this a single post. So now I begin the task of learning what software is commonly used in publishing and start breaking down how to use those platforms to make accessible documents. Preliminary research tells me InDesign and Affinity are where I should start, and I’m going to cover Microsoft Word as well because it’s actually really good for making accessible documents. Stay tuned for more on those at some future date. I have no schedule for those posts, I’m doing this in my free time.
Don’t pity me, I do these things to myself.