Last of Us Part II Accessibility Lessons for Web Designers

When I review small business websites, accessibility is the area owners are most nervous about and least sure how to start. They have heard about lawsuits, seen accessibility widgets advertised, and read guidelines written in language that feels like a legal contract. Most end up doing nothing, because every option seems either expensive or vague.

I find it easier to start somewhere else entirely: with a video game that showed what thoughtful accessibility looks like when a team takes it seriously from the first screen. Nearly every idea in it maps onto something a small site can do in an afternoon.

What Naughty Dog actually built

The Last of Us Part II came out in June 2020 with more than 60 accessibility settings. That number got the headlines, but the number was never the impressive part. What stood out was how the options were organised and when they appeared.

Before the game even starts, it offers three presets: vision, hearing, and motor. Pick vision, and the game switches on text to speech for menus, a high contrast display, audio cues for navigation, and larger subtitles in one step. Every individual setting can still be adjusted afterwards. The high contrast mode is the one people remember: the environment turns a flat grey, allies turn blue, enemies turn red, and items glow yellow. It is not pretty. It is extremely clear.

Other settings target specific barriers. Subtitles can be resized, given a dark background, labelled with the speaker's name, and paired with an arrow showing where off screen speech is coming from. Every control can be remapped. Holding a button can be changed to tapping it. There is even an option to skip certain puzzles. The game won the Innovation in Accessibility award at The Game Awards that year, and several studios have since copied its approach.

Websites do not need sixty settings, because a lot of what the game provides as options are things a website should simply do by default. Here is how I map the game's main ideas onto the Web Content Accessibility Guidelines, the standard that most accessibility law refers to.

In the game	On a website	Relevant WCAG criterion
High contrast mode	Body text at a contrast ratio of at least 4.5 to 1 against its background	1.4.3 Contrast (Minimum)
Subtitle size slider	Text that still works when zoomed to 200 percent, without content cut off	1.4.4 Resize Text
Full control remapping	Every link, button and form usable with a keyboard alone	2.1.1 Keyboard
Highlighted interactable items	A visible focus outline on whatever the keyboard is on	2.4.7 Focus Visible
Speaker names and direction in subtitles	Captions on video, and labels that say what each form field is for	1.2.2 Captions, 3.3.2 Labels
Reduced camera shake options	Respecting the visitor's reduced motion setting for animations	2.3.3 Animation from Interactions

Two of those rows cover most of the problems I find. On the sites I audited last year, low contrast text turned up on roughly two thirds of them, usually pale grey body copy on white chosen because it looked elegant in a mockup. Missing focus outlines came a close second, almost always because a theme removed the browser's default outline and never replaced it. If you are choosing colours from scratch, the guide on choosing a colour palette for a website includes checking contrast as part of the process.

The common shortcut is an accessibility overlay: a script you paste into your site that adds a floating button with options like bigger text, high contrast and a screen reader mode. Several companies sell these with promises of instant compliance.

The Last of Us Part II is the best argument I know against them. Its high contrast mode works because the developers decided, object by object, what was an enemy, an ally and an item. An overlay cannot know what matters on your page. It can invert colours and enlarge everything, but it cannot add a missing label to your contact form or make your custom dropdown menu reachable by keyboard. Many disabled users also already have their own tools, such as screen readers or browser zoom, and some report that overlays interfere with them.

I will be honest that I have not seen every overlay product, and some may be better than others. But in every case I have tested, the underlying problems were still there once the widget was switched off, and fixing those problems directly took less time than configuring the widget.

A good accessibility setting is a decision someone made about what matters on the screen. A widget cannot make that decision for you.

Presets are the idea most sites miss

The single idea I would steal from the game is the preset screen at the very start. It acknowledges that people arrive with different needs and lets them say so once, rather than hunting through menus. Websites have a version of this built into browsers and operating systems already. Visitors can set dark mode, reduced motion, and larger default text in their own device settings, and modern CSS can respond to all three through media queries such as prefers-reduced-motion and prefers-color-scheme.

Respecting those settings costs very little. A few lines of CSS can turn off a sliding carousel or a parallax header for anyone who has asked their device to reduce motion. That is the web equivalent of the game remembering your preset, and it means you do not need a settings panel of your own. We covered the wider design side of this in what in game settings menus teach about simple website design.

For this week, try the game's own test on your site. Unplug your mouse, or just leave it alone, and try to complete your most important task, booking, buying, or sending a contact form, using only the Tab, Enter and arrow keys. Note every point where you cannot see where you are or cannot reach the next control. That list is your accessibility to do list, and it will be shorter than you fear.