So after a big gap after the playtest release, I’ve just released the full version of TOMBS: Toot on my balls skeleton (turns out a full book worth of illustrations and layout is a lot of work for one person). This post is about how I made a screenreader accessible version of TOMBS, using my experience from working at a blindness organisation as well as TTRPG community guides.
TOMBS is a queer skeleton sex TTRPG, which I made after living through the pandemic, disability and lockdown kind of rocked my relationship to my body. Somehow the ancient undead remembering how sex works seemed like a great way to interrogate those feelings.
The screenreader accessible version of TOMBS
I launched the physical book at Hallozine in Narrm at the end of last month, but didn’t want to launch the PDF as is, because I don’t have the technical skills necessary to make a screenreader compliant PDF. And also because all my blind coworkers would roll their eyes everytime someone said a PDF was accessible, so that’s a pretty good indication it’s not the way to go.
It’s important to note that before getting to this stage I’d also taken steps to make sure the physical book was as accessible to people with a print disability as possible. An estimated 22% of Australians have some kind of print disability, and simple changes like using an accessibility designed font (in my case Atkinson hyperlegible) and ensuring a readable minimum font size (12pt minimum, 14pt+ is ideal) means I can include as many of those people as possible. By including these considerations at the start of book layout it was simple to do, however if I had tried to come back to make these changes at the end of the process it would have been much more difficult.
Screenreader accessibility is a different beast, and so I’d been keeping an eye on the approaches to making accessible TTRPG releases that have been popping up recently. Some, like the approach of using twine, are really cool but also didn’t really suit my needs. I ended up settling on making a html and ebook version, using this amazing guide from James Chip: https://jameschip.itch.io/html-and-epub-ttrpg-creation
Because I’ve already had the coding environment set up and knew how to use the console to operate pandoc (pandoc is software which handles converting a markdown file into formats like ebook), this was honestly a breeze. Using markdown was straightforward, and after a few hours of formatting and set up I had a beautiful looking and fully accessible html and ebook version, bar one or two minor issues.
The issues
1. The way pandoc handles alt text
By default, pandoc outputs alt text as both alt text and caption. It might not be clear why this is an issue, and it’s definitely not a major issue, but it does mean that every time a screenreader hits an image the person is going to get the exact same image description told to them twice. I’m not a screenreader user myself, but my understanding is that navigating the modern web means you’re already getting bombarded with poor formatting, emoji codes, and custom character readouts, which means anything that adds extra annoyance (like a double image readout) is just poking at a sore spot. Also, the intended use of captions is to add context or sources to an image, not to re-display alt text.
My solution for this, at least for the html version, was to use my css file to hide the figcaption elements from display. I’m still investigating an equivalent solution for the ebook.
2. As much as TTRPG’s love tables, screenreaders hate them
This is not a pandoc issue, but more an issue with the TTRPG space. We love tables, we love tabulated information. And as easy as they make it for our eyes to scan a bunch of numbers, they end up creating a situation where a screenreader is working line by line, left to right, to read out each cell in order. This can create the opposite effect, where nicely ordered information becomes overwhelming and devoid of context.
Some of the people I worked with who used screenreaders were experts at navigating this, including working with large datasets in spreadsheets, but I think it needs to be viewed as a skill not everyone is going to have.
I don’t have an easy solution to this issue. Over the course of editing TOMBS I moved as much information out of tables as possible, and ended up with only two tables related to dice rolls in the final document. Hopefully these tables, which have simple and consistent headers and are clearly described in the text, work for people, but we’ll see!
Final thoughts
Overall it was so easy to produce something that’s almost entirely screenreader friendly that I have to recommend this to everyone releasing a complex pdf. I also think it’s worthwhile for everyone in the TTRPG to learn more about accessibility, of which I’ve only covered a sliver here. I’ve been working at disability organisations for most of the last decade, and I’m still learning more about accessibility every day. So if you want to make sure everyone is included at your table, it’s worth starting to learn about now!