GDC 2026 Roundtable – Accessibility at Scale: Doing More with Less

Accessibility at Scale Roundtable:
Doing More with Less 

Presented by the IGDA at GDC 2026

While accessibility has grown across the games industry, there are many constraints that we are all facing. Progressing from a desire to act or adhoc wins to something more sustainable is a key part of making and maintaining progress. Often, we know that it’s about making the biggest impact with the smallest steps.

At GDC we provided a space to discuss doing more with less – whether that’s processes, champ groups, dev tools or beyond. The roundtable was hosted by Cari Watterton (she/her) Senior Accessibility Designer at Scopely, and Jordan DeVries (they/them) UI/UX Director on Star Wars Jedi at Respawn.

We used an online questions form to have the participants submit and vote on questions for discussion at the roundtable, then we picked the highest-voted submissions. Below is a summary of the roundtable (completely anonymised) and with links to useful resources relevant to the discussion.

How do you navigate challenges between accessibility and aesthetics in UI & UX?

Initially the discussion covered individual challenges like text size and contrast, but then swayed into more general advice for the challenge of accessibility vs aesthetics in UI. Overall attendees agreed that for UI and UX in particular the core is that it’s designed for a purpose and that, on the scale of function vs form, UI sways towards function. If it can’t be used – it becomes a digital paperweight.

A default that looks good, ideally mixing in accessibility by design where possible, then layered with customisation options would be an ideal solution that preserves both the aesthetics of the default experience, but allows players with different capabilities to still use the UI and play the game. In this vein attendees called out specifically things like “the death of the author”: when releasing a game and being used by players, it becomes theirs. Ultimately surmising that an experience that can be played is better than an experience which looks good but excludes players. 

Practical tips from this question included:

  • Cutting the fat: Put less on the screen and make them more distinguishable.
  • Modularity: Make things modular.
  • Accessibility Early: Integrate accessibility earlier on and in wireframes.
  • No one size fits all: Design for customisation.

How can you test the accessibility of your game, particularly for indie devs who don’t experience the disabilities you’re designing for?

The room is in agreement that the best way to test for accessibility is to hire lived experience consultants – whether that be through a service or on an individual level. If you’re a developer who is trying to assess the accessibility of your game yourself, you will bring your own bias and lack of objectivity and about how it should be played. Always outsource your feedback where possible.

For finding testers with lived experience of disability, there are a lot of good community resources:

If budget is an issue, while there is no replacement for lived experience of disability and you should always pay your consultants and testers, there were a few suggestions from the room on less-impactful alternatives.

  • Trading Services: Especially in indie, you might be able to trade reviews/work with other folks.
  • Leverage your community: Put out a call to action on social platforms and offer discounts on your game and/or swag for participants.

When it comes to crediting people, consider best practices for this. Avoid putting them in special thanks – especially if they’re a paid accessibility consultant. You can also put out thanks and appreciation on social platforms or LinkedIn.

If you have no other recourse, you can look to the online resources around accessibility in games, and as a last resort trying to simulate the experience can be helpful (e.g., wear a blindfold while playing your game).

What area of accessibility is still largely ignored?

The room brought many topics to the table for this question across a range of broad and narrow areas, including: 

  • Misophonia (sound sensitivity)
  • Full blind accessibility
  • Horror games (phobias, jump scares, content warnings)
  • Mobility accessibility (e.g. repetitive motion, timing windows)
  • Sensory customisation (e.g. reducing flashing, noises, etc.)
  • Plugins and APIs (lack of use of valuable accessibility third-party)
  • Cognition in games (cognitive load, reading level)

Where difficulty may be an artistic choice, how and where do you draw the line knowing it will exclude some people by necessity?

Difficulty is not the same for everyone; what is difficult for one person is not difficult for someone else. Inherently games need challenge to be a game, and someone won’t play on an easy difficulty if it’s not fun for them – they’ll choose a level of challenge that meets their capabilities. Overall the room resounded that difficulty should be determined by the player.

The room raised a few examples such as DOOM: The Dark Ages, which didn’t just offer options to make it easier, but also made it harder. Celeste is another example – seen as the gold standard in accessibility. Its assist mode is customisable and extensive, can be done at any time, and is worded respectfully in a way that acknowledges that different players need different ways to experience the core ‘perseverance’ of the gameplay. 

In terms of drawing the line, if you absolutely can’t find a way to expand it to as many players as possible, then inform players clearly what the barriers are. Bonus points for releasing a demo to let players decide if they can/want to play.

The room also raised multiplayer as a place where it’s thought accessibility can’t be done, as developers expect players will abuse it and lead to competitive advantages. The room raised a few examples of accessibility in multiplayer. First, Fortnite with their audio visualization wheel. This is highly successful, as it’s provides audio information through a second channel. No new information is actually being shown. While this feature did change the meta, it did so holistically without unfair advantage. Second, Overwatch. With a roster of characters of different healths, speeds, shields, aiming methods; this naturally creates a range of different playstyles that can accommodate different capabilities. For example, Moira as a low-precision character, or Orisa as a character for someone with slower reactions due to her portable shield.

How can you engage the rest of your team in the accessibility process?

If you struggle to engage the rest of your team in accessibility, there are a number of great ways to help bridge the gap and build understanding and empathy. 

  • Disability is a club that anyone can join: use this slogan, and point out that anyone wearing glasses is using an assistive device. 
  • Data: Show stats of how many are disabled to show it’s not a small number and similarly, show usage stats which prove accessibility extends beyond disability.
  • Make it familiar: point out where they are already doing accessibility, intentionally or accidentally, in the game.
  • Accessibility accolades: inform on storefront tags, awards and dedicated press sites (Can I Play That?, Game Accessibility Nexus) that can boost your games visibility and discoverability.
  • Competing media: Note that games are competing with other media and that media is becoming increasingly accessible.
  • Aging and gaming: Encourage them to think about aging; simple things like needing glasses or lower mobility, and the importance of building games that we can still all play when we’re older.

The room also noted that sometimes pushback isn’t because they don’t care about accessibility, but that they haven’t thought about it before. Be open, empathetic and encourage them to be curious. Note that you might also get a lot of pushback on trying to get accessibility features in a very tight timeline. You might be able to think about small wins in these times – such as reusing debug options as accessibility features.

Overall, building a team that cares involves a culture change. Things like incorporating accessibility into core game pillars, making it part of the game documentation, and creating a safe space to talk about difficulties or questions the team might have. Consider building a champions network.

One closing statement on this tackled the big issue, if you’re genuinely trying to work with or convince someone who doesn’t care (which is very rare) you need to put yourself first and consider where to spend your energy.

How do I convince my company to spend resources on accessibility?

The room gave a lot of good answers, referencing back to the cases from the previous point on engagement, specifically:

One additional point was that we keep seeing companies adding and building upon accessibility in their games. This suggests that these features are working to increase their revenue and audience. Looking at your competitors or gold standard for accessibility can also help to make a case for it at your studio.


Thank you to everyone who came along to the roundtable at GDC! As a reminder, please consider joining the IGDA GA-SIG Discord Server if you haven’t already.

0 comments on “GDC 2026 Roundtable – Accessibility at Scale: Doing More with Less

Leave a Reply

Your email address will not be published. Required fields are marked *