Enhancing Game Accessibility: Best Practices for Subtitles and Closed Captions
Carrie Henner discusses the importance of subtitles in gaming, common issues, and best practices to improve accessibility and player experience.
File
Design considerations and best practices for subtitling your game (Kari Hattner, Hangar 13 Games)
Added on 09/30/2024
Speakers
add Add new speaker

Speaker 1: So yeah, I'm Carrie Henner. I currently work as a producer at Hangar 13 Games where we recently shipped Mafia III, which is an open world crime drama. But my interest in subtitles began in 2008 when I started working at Crystal Dynamics on Tomb Raider Underworld. As the most junior producer on the team, I was given what most people consider an enviable job of owning the localization pipeline, where I was not only responsible for importing and exporting text and audio assets, but for implementing and timing the subtitles for all the languages that we supported. Subtitles are a common accessibility feature, but there's no consistently agreed upon standard for how they should look and behave. Their presentation can impact not just the player's understanding and enjoyment of your game's narrative, but in some cases can impact their ability to progress through the game. My goal in this session is to broaden your understanding of who's using subtitles, summarize their top complaints with the existing implementations, and suggest best practices from games and other media. Along the way you might discover why there's no one-size-fits-all solution. I hope you leave here understanding the questions you need to ask when designing subtitles for your games and where you might deviate from established norms. A lot of players use subtitles for a variety of reasons. Developers without a lot of exposure to accessibility topics would probably list hearing impairments like hearing loss or deafness. Others might talk about localization, languages that aren't supported with localized audio, or players who want to play in the developer's language, which they might consider as the author's intended experience or may just be a higher quality than the localized version. Less considered are the contextual reasons that players use subtitles. Loud environments like parties or game conventions, or super quiet environments like when your family is asleep in the next room or while commuting on public transit. Or you might just have a bad speaker setup, not know how to configure 5.1 speakers, or just have poor speaker quality. Finally, there are a few game-related reasons that you might want to enable subtitles. Bad audio mixes, although I think that's getting better. That was more common in generations past. Characters with difficult-to-understand speech. And just players who want all the extra narrative detail they can get by listening in on the background conversations. In Tomb Raider Underworld, there wasn't a lot of dialogue. Lara talked mostly to herself, a lot of it was just in cutscenes, and there wasn't any competition from in-game information. As we started working on the reboot for 2013, the scope quickly became too large for the existing system. It was going to have multiple characters talking to each other, a lot of ambient background VO, and cinematics that had upwards of five or more characters. At that time, I started to research subtitle guidelines and discovered the Gamasutra article, Subtitles, Increasing Game Accessibility Comprehension, by UX designer Gareth Griffiths. A lot of his suggestions were based on user research he conducted at his game studio, but he also pointed me to resources from British television broadcaster standards like the BBC and Ofcom. While there are a lot of differences between television programs and games, having standards like these provide a methodical way for you to examine the design of your subtitles and compare against any standard. This research led to the development of new features for our subtitle system in Tomb Raider, specifically markup for duration, color of the font, and adding italics, as well as adding multiple display positions to display two subtitles at the same time, as you can see in this example. The response was mixed from the community, although a lot of the complaints about the subtitles focused on the letterboxing, which wasn't a new feature for our game, and the perceived amount of closed capturing. The team was more excited, however, by recognition we received from the game accessibility community, such as the Game of the Year award that one of the writers at Dagger System, who are outside, bestowed on the game. Coverage like this increases internal studio interest in continuing to develop innovative accessibility features, so I'm really excited to see all the coverage that Uncharted has gotten, because I think that will spur a lot of other AAA companies into developing more features. In Rise of the Tomb Raider, we added the option to disable the colors, decrease the opacity of the letterbox, modify the colors themselves, and add a drop shadow to the font. Compiling the top reasons that people complain about subtitles, they all boil down to the same thing. They're not rootable for some reason. Three themes consistently emerge when examining the complaints. One, they don't contrast enough from what's directly behind them on screen. In this example from The Walking Dead, it's hard to distinguish the dull gray or green subtitle at certain parts of the line. I recommend a web developer resource like WebAIM's Color Contrast Checker to test your fonts in a variety of background situations. Brightly colored fonts can also get lost on lighter backgrounds, which can be addressed by adding an outline to the font, letterboxing by adding an opaque or semi-opaque overlay to the screen. Drop shadow alone is not recommended because it leaves a significant portion of each letter without distinction from the background, but it works well with other features like letterboxing. The added benefit of letterboxing is that it helps dyslexic players by stopping game visuals from interfering with the letter shapes. The second issue is that subtitles are often too long or otherwise intrude on the player's gameplay experience. In this example from Destiny, three lines of text display two complete sentences. Not only is it hard to read at a glance, but in some games it can spoil upcoming moments by revealing something too soon. This can be addressed by breaking the subtitles into meaningful chunks. The subtitling industry considers comfortable reading speed to be 160-180 words per minute with a recommended display of two lines of 80 characters, restricted to the width of 68% of the screen for a 16x9 display and 90% of the width of a 4x3, which I will put on a slide later. Finally, subtitles are often too small to read, especially for a limited duration. In this example from Dishonored 2, the subtitle takes up about one third of the screen. If you were to follow the recommendations I just mentioned, it would look more like this. This might look extreme on the other end of the size spectrum, but it demonstrates a way for developers to compare their solution to the recommended standard, at which point they can choose to deviate from it if they want. In each of these examples, I tried to isolate each of the three complaints, but they are often seen in combination. In this example from Deus Ex Mankind Divided, four lines of barely visible text are on screen, and the screen is covered in additional in-game text. I don't know if you can see, it's like a paragraph down here. I can only imagine what players who have to rely on subtitles think when they encounter a scene like that. It would be very hard to understand. Now I want to walk you through ten best practices for subtitle design, concrete actions that you can take when developing your system, and reasons to consider when and why you might deviate from them. The first of these is accuracy. Don't edit the text of your subtitles unnecessarily. Review the scripts before recording. Spell check is only going to catch blatant misspellings. Missing and extraneous words are probably only going to be found during recording sessions. If you have time during recording, try to mark edits as you do that. Otherwise, you have to conduct a full comparison of the script to the audio when the files are returned to the studio. I think this is a great test for dev QA, not just because I want to offload work onto them, but because it's actually allowing them to discover bugs before they enter the game. If they have access to the tools of editing the script or editing the subtitle files, they can fix bugs before anyone else sees them. The few reasons that you might not adhere to 100% accuracy, which is one, there just might be times when you don't have enough time to display a lot of speakers talking, or people speaking extremely fast. You can identify the worst cases by playing your game and user testing with a variety of players. Depending on your writing team, heavily accented characters' dialogue and slangy or casual pronunciations may be written phonetically for voice actors. However, BBC guidelines recommend that you should only indicate accents sparingly. Use a few words that are spelled phonetically, but you don't want to slow down the reading pace. You have to weigh the clarity of the subtitle against maintaining accuracy in your script. Another consideration for editing text is to support young readers. I don't work in making children's games, so I will just say that if you're working on content for children, that you do additional research on what's appropriate for your target demographic. I'm going to list a bunch of resources later that have more information. A lot of them talk about covering children's content. This example from Tomb Raider demonstrates a situation where a subtitle failed to match the audio. There were multiple conversations going on in the foreground and background. We made the decision to replace multiple subtitles with a single caption to explain the scene. The second best practice is critical dialogue. Make sure that all critical dialogue is subtitled and that subtitles can be enabled before VO is encountered. For games with an attract mode or initial scenes before the main menu, you should request that the subtitle option be set during the boot sequence the first time the game is played. Alternatively, you should include this as part of the option setting dialogue any time a new game is started. In either case, it should always be available to modify from the main and the in-game options menu. You should never have to exit the game to change the subtitle setting. Some platforms like Xbox, Android, and iOS have system-level settings that applications can access to determine the player's preference for subtitles. This is a nice touch, but since it's not always used by everyone, players are often going to go to the settings anyway. This example from Infamous First Light demonstrates a lightweight approach to determining the subtitle preference by putting the button icon and the captioned subtitles on the screen during the opening cutscene. Some developers don't subtitle minor VO that's not crucial for game progression. For games with bustling with background characters, this can render a rich world flat for players who rely on subtitles. My recommendation is that rather than excluding whole sections of dialogue from subtitling, you develop a priority display system to manage background VO so it can display during moments when it won't distract from critical VO. In this example from Deus Ex, Newscast plays without subtitles during the mission briefing, which deprives players of understanding the motivation behind their upcoming actions. I thought this was interesting because the cutscene itself has subtitles, it was just the newscast part that wasn't subtitled. I wondered if somewhere in their system they had marked all newscasts as a lower priority for subtitling because they're often just background details that don't need to be subtitled. If that's the case, it demonstrates why you can't make a blanket rule to exclude certain characters from subtitling. You have to test the critical path for coverage. Most users have an expectation for subtitle placement built from their experience at the movies, on TV, and with other games. Subtitles should be centered near the bottom of the screen. On a 16x9 display, the maximum width should be 68% and up to 90% on a 4x3 display. Two lines of text at 80 characters each should be your goal. Even if subtitles are the last piece of content to go into your game, you should account for their position in your UI design from the outset. In this example from Final Fantasy XV, I appreciate how the placement of the speaker name label adapts to the presence of other elements in the HUD. I think we could do a lot with responsive designs like these to facilitate the best situation for each gameplay scenario. There's a few situations I've noticed game subtitles deviating from these placement standards. One is when off-screen characters are talking via radio or other communication devices, like in a sci-fi game or a lot of military games. The other is when gameplay information already appears in the lower half of the screen, like in sports games and UI-heavy RPGs. In this example from Deus Ex, the director's communications appear in the upper left of the screen with his portrait and a visualization of the audio as he speaks. This is an example from NBA 2K17, where the subtitles appear over gameplay information. In this case, I would have recommended that the subtitles move above the score banner or even towards the top of the screen. Multiple subtitles should be stacked by introducing new ones at the bottom of the screen, pushing the previous ones upward. I haven't found a lot of reasons to deviate from this recommendation, although in Tomb Raider we often violated this practice to maintain a consistent screen position for individuals in a conversation so that all of Lara's lines were on the top and all of her, you know, the other person in the conversations were on the bottom. This allowed for each line to remain on-screen longer without moving. Differentiating between speakers is important when they're off-screen, but even when they're visible players might not notice who's talking. With a user-controlled camera, there's no guarantee the player will see who's talking unless you're in a moment with authored cameras like a cinematic. The most common method to identify characters are name labels. These don't need to be used on every line, but when you're introducing a character or they haven't spoken in a while, it's nice to have them at the beginning of the line. You could also try different colors of font per speaker, as in the Walking Dead and Tomb Raider examples, but be sure to adhere to high-contrast guidelines when developing these. Feature portraits seem to be most common when there's a discrepancy between in-game models and cinematic models, like you often see it with Japanese RPGs where there may be anime-style cutscenes and, you know, old-school 8-bit models in-game. In any of these situations, you should provide the option to enable or disable this feature separate from subtitles themselves, because a lot of people find this to be extraneous. This example from Until Dawn demonstrates best practices in both stacking, by introducing the new subtitles at the bottom of the screen, and speaker differentiation, by clearly attributing each line to the appropriate speaker. Off-screen direction should be indicated through arrows, italics, captions, or other means. You could also consider alignment using left or right justified text to indicate direction, but I think this would be difficult to implement for a small amount of use cases. In this example from Rise of the Tomb Raider, both the italic style of the font and the captions from above serve to indicate the direction of the off-screen speaker. There's a pretty simple best practice for subtitle duration. Allow the player enough time to read the subtitle. But what does that mean? 160 to 180 words per minute is considered comfortable reading speed, which translates to 15 to 17 characters per second. You can use this rubric to compare your audio files to your subtitles and find issues before they're reported. For next-level localization, you could also consider the distinct needs of different languages. On Tomb Raider, our duration markup could be used on a per-language basis, and we used this in cases where there was a significant discrepancy, about 30% difference, between the localized audio and the English source. Subtitles need to be clearly visible when they're on screen. The minimum recommended size for 1080p display is 46 pixels. The font should be written in mixed case using a sans-serif font. Avoid using all caps unless for specific emphasis. If your game font is highly stylized, you should consider using a simpler font for subtitles or offer that as an option in your game. Due to their temporal nature, the size should be larger than what you use in menus or other areas of the HUD. Games that allow the user to control how quickly the subtitles are displayed, such as by forcing user input to progress to the next line, can consider using a smaller font, but 32 pixels is considered the lowest minimum you should go. In this example from Batman Arkham Knight, the subtitles are competing for the player's attention on the screen due to multiple elements employing the same too-small font. In video games, closed captioning refers to providing text for non-speech audio. Providing robust closed captions for most games would be difficult without the development of a priority display system. I believe most games would benefit from occasional captions that relay critical information for game progression or for understanding the narrative. The two ways that I did this was to play the game with the sound off and look for areas where I had difficulty progressing or failed skill checks of some kind. I then would play the game with the sound on and pay close attention to non-speech audio like gunshots, people screaming, to look for areas that are impacted by non-speech VO. In Tomb Raider, one moment stood out immediately when I was playing the game with the sound off. In this scene, Lara has to defend herself from several pouncing wolves while caught in a trap. There wasn't enough time to knock the arrow and aim the bell unless you heard cues of the wolf's snarling. Hearing players had a significant advantage, so a caption was implemented to warn players of an imminent attack. Customization options for players to control subtitle display and behavior is the best way to satisfy the needs of all the various user groups. All of the ideas I have discussed today should be considered for separate options. Font, font size, speaker indicators, edge effect, letterboxing, letterbox transparency, and closed captioning. Additionally, I suggest that you allow the subtitles to be previewable in the menu to reduce trial and error. Life is Strange, which I think Ian showed before, offers the expected options of whether the subtitles are on or off, in what language they are, and unique customization options of size and whether or not to enable letterboxing. Here's a side-by-side example of the normal size without letterboxing and the hella large size with letterboxing. The latest Hitman game provides a preview of the subtitle settings within the options menu. If so many choices seem overwhelming, bundle options together into preset combinations to simplify the process, minimal and standard, or subtle and clear. You can always provide a custom option for those who want more control under the hood. Creating excellent subtitles is within the grasp of every developer, given time up front for planning the technical needs of your system and for accommodating their position on screen. Multiple disability groups can help you source players for user testing if you need additional testers. Also, don't forget supplementary content like game trailers and early preview builds, like early access programs, open and closed beta. These are the first exposure your players are going to have to your games and they make a lasting impression on whether they might buy that game or not. Finally, I just want to say, if you feel overloaded, don't worry. Developing any one of these things is going to improve your subtitles beyond what they already are right now. So if you can keep these issues in mind, make them high contrast, don't make too much text on the screen at one time, and make them large enough to read, you're on the right track. Here's a list of resources, hopefully you guys can take photos of it, that I used in preparing this content. I suggest you just bookmark them and review them when the time comes to develop your subtitles. Using these as standards against which you can compare your implementation will help you discover what works best for your game and your situation, and help you think through all the issues you might encounter in a methodical way. Thanks.

ai AI Insights
Summary

Generate a brief summary highlighting the main points of the transcript.

Generate
Title

Generate a concise and relevant title for the transcript based on the main themes and content discussed.

Generate
Keywords

Identify and highlight the key words or phrases most relevant to the content of the transcript.

Generate
Enter your query
Sentiments

Analyze the emotional tone of the transcript to determine whether the sentiment is positive, negative, or neutral.

Generate
Quizzes

Create interactive quizzes based on the content of the transcript to test comprehension or engage users.

Generate
{{ secondsToHumanTime(time) }}
Back
Forward
{{ Math.round(speed * 100) / 100 }}x
{{ secondsToHumanTime(duration) }}
close
New speaker
Add speaker
close
Edit speaker
Save changes
close
Share Transcript