What Tabletop Role-Playing Games Can Teach Us About Web Accessibility

I’ve spent much of my career building websites and working to make the web more accessible. I’m also an enthusiastic tabletop role-playing gamer. I love the collaborative storytelling, creative problem-solving, and unexpected challenges that come with games like Dungeons & Dragons.

Over time, I started thinking about how those two interests could work together. 

Tabletop role-playing games encourage players to consider situations from another character’s perspective, work within a set of constraints, and collaborate to overcome obstacles. Those are valuable skills for anyone designing or developing digital experiences, and that connection inspired me to create Access & Barriers, a tabletop role-playing tool designed to help people think more critically about what accessibility really means and make better decisions about the websites they build and maintain.

The web still has a significant accessibility problem

According to the World Health Organization, an estimated 1.3 billion people worldwide experience significant disability. This represents approximately 16% of the global population. For organizations serving large, diverse audiences, web accessibility has a direct influence on who can use their digital platforms and access their services, yet accessibility barriers remain widespread. 

The WebAIM State of Web Accessibility 2026, based on its evaluation of one million website homepages, found that 95.9% of homepages contained automatically detectable failures of the Web Content Accessibility Guidelines (WCAG), up from 94.8% in 2025. What’s especially concerning is that six categories, spanning well-documented accessibility issues with established solutions, accounted for 96% of the errors detected. 

The common accessibility issues include:

• Low text contrast
• Missing alternative text (alt text) for images
• Missing form labels
• Empty links
• Buttons without accessible text/names
• Missing document language

As technology advances, websites are becoming increasingly complex. Enterprise digital platforms depend on sophisticated interfaces, third-party integrations, and content management systems that must accommodate changing business requirements. Each new feature introduces decisions that can improve or compromise accessibility.

For organizations investing heavily in their digital presence, these web accessibility findings raise important questions:

• How can teams prevent recurring accessibility problems? 
• How can they recognize barriers before those barriers reach production? 
• And how can they maintain accessibility as their platforms grow and evolve?

The answers require more than knowing the standards. Teams need to understand how people with different abilities, technologies, circumstances, and needs interact with the experiences they build. They need to anticipate how accessibility influences whether people can accomplish what they visit a website to do, and then apply that understanding to decisions.

Why accessibility requires us to think beyond the interface

When developers discuss website accessibility, the focus is often on technical requirements. We talk about semantic HTML, keyboard navigation, screen readers, and color contrast, as meeting established accessibility standards is responsible web development.

Technical requirements, however, describe individual aspects of a broader experience real people have while trying to accomplish something.

• Someone visiting a university website might need to apply for admission, register for classes, or access financial aid information. 
• A customer on an enterprise website might need to compare products, complete a purchase, or submit a support request.
• A member of the community trying to find the latest news on a wildfire might need access to live, real-time updates, maps, press conference coverage, and evacuation information

These activities can involve multiple pages, forms, interactions, and external systems, and a barrier anywhere in that process can prevent someone from completing their task. They can interrupt sales, prevent access to essential services, increase support demands, erode trust, and create accessibility-related compliance risks. 

As I explored in a previous article about changing digital accessibility enforcement requirements, organizations also need to consider their legal responsibilities, particularly when their websites support education, healthcare, or federally funded programs. 

Accessibility conversations become more productive when teams consider the full experience of using a website. We need to understand what people are trying to accomplish, what could prevent them from succeeding, and how our decisions influence the outcome. 

That’s the thinking I wanted to explore when developing Access & Barriers.

Bringing tabletop role-playing mechanics into accessibility education

In a traditional tabletop role-playing game, players create characters with different abilities and characteristics. A game facilitator introduces scenarios, presents obstacles, and helps the players work through what happens next.

Access & Barriers uses a similar structure to explore disability and accessibility.

Participants work with character profiles that describe individual circumstances, abilities, disabilities, and available resources. They navigate scenarios involving everyday activities and consider how the surrounding environment affects their ability to complete a task.

The tool introduces several concepts that are important to understanding accessibility:

• Dynamic disabilities: A person’s abilities and needs can change throughout the day or over time, depending on factors such as fatigue, illness, pain, or environmental conditions
• Multiple disabilities: A person may experience several disabilities that interact and influence how they navigate a situation
• Temporary disabilities: An injury or medical condition can create accessibility needs that last for a limited period
• Energy and frustration: Physical effort, cognitive demands, and repeated obstacles can affect someone’s ability to continue an activity
• Environmental and systemic barriers: Physical spaces, technologies, processes, and policies can create obstacles that limit participation

Access & Barriers uses a concept commonly called spoon theory to help participants consider energy limitations. Characters have a number of spoons representing available energy. Activities consume spoons, and certain challenges can increase fatigue or frustration. As a character’s energy decreases, other conditions or limitations may become more pronounced.

These mechanics encourage participants to consider how seemingly small obstacles can accumulate. A task that requires minimal effort for one person might demand considerable planning, physical energy, or assistance from someone else. The tool also distinguishes between scenarios and campaigns. A scenario focuses on completing a particular task, while a campaign connects multiple scenarios into a longer experience.

Consider planning a vacation: 

Booking a flight, reserving a hotel, navigating an airport, and reaching a destination could each become a scenario within a larger campaign. The decisions and experiences in one scenario may influence what happens in the next. For a wheelchair user, damage to a mobility device during air travel could affect the remainder of the trip. That interconnected experience is particularly relevant to digital accessibility. 

People move between pages, applications, devices, and services, and accessibility challenges can carry forward from one interaction to another.

A simple task reveals a complicated accessibility problem

I introduced Access & Barriers during a presentation for the WordPress Accessibility Meetup, where attendees participated in scenarios and helped explore the challenges facing different characters.

One of those scenarios involved Meg, a character based on my daughter, who has multiple disabilities and uses a wheelchair. Meg had recently moved into a third-floor apartment. Her task was to go downstairs, collect her mail, and return to her apartment. She needed an important check from the mailbox to pay her rent.

The objective sounded straightforward, but the scenario introduced several accessibility complications.

First, Meg had to navigate an apartment door without an automatic opener. The participant playing Meg decided to put on a prosthetic leg to help maneuver through the doorway, even though using the prosthetic could be uncomfortable and required additional energy.

Next, Meg reached the elevator and pressed the button. Nothing happened. She waited, growing increasingly frustrated, before discovering that the elevator was out of service. When she contacted the building supervisor, she learned the problem might be addressed later. The supervisor was also unwilling to commit to collecting her mail.

Meg remained on the third floor, unable to reach the mailbox independently. Meanwhile, her attempts to resolve the problem consumed energy and increased her frustration.

During the exercise, participants began exploring alternatives. 

• Could someone bring the mail upstairs? 
• Was there a neighbor who could help? 
• How could the building prevent the situation from happening again?

The discussion became particularly interesting when we considered the difference between helping Meg accomplish the immediate task and addressing the conditions that created the barrier. Having someone collect her mail could resolve today’s problem, but a dependable, accessible way to retrieve it would give Meg greater independence in the future.

The scenario also demonstrated the cumulative effect of accessibility barriers. An inaccessible doorway, broken elevator, and unhelpful building super each introduced a challenge, and together, they prevented someone from completing an essential task.

We can apply the same reasoning to digital experiences:

• A keyboard user successfully navigates most of an online form, only to encounter an inaccessible control on the final step
• A student completes an application but cannot access the portal required to submit supporting documents
• Someone with a cognitive disability follows a multi-step process until a session timeout erases their progress
• A screen reader user accesses an organization’s website but encounters an inaccessible third-party tool when attempting to complete a transaction

In each situation, the person has a clear objective. The barriers emerge from decisions about how an environment, process, or technology works. Examining the complete task helps us identify where the experience succeeds, where it breaks down, and what meaningful access requires.

Using role-playing to improve website decisions

One goal of Access & Barriers is to give teams a practical way to discuss accessibility before they encounter a problem in production. Role-playing encourages people to ask questions, explore possibilities, and consider perspectives that might otherwise receive limited attention during a project. Those conversations can inform work across the website development process.

During discovery and planning, teams can examine tasks people need to complete and identify potential barriers early. For a university website, that might mean following the entire admissions journey, including interactions with third-party services. For an enterprise, it could involve evaluating how customers move between product information, account management, and support.

During design, scenarios can help designers consider how people navigate information and interact with components. What happens when someone magnifies the page? Can people distinguish essential information without relying on color? Does the interface provide enough time and guidance to complete a complex task?

During development, the same perspective helps developers make more thoughtful implementation decisions. Keyboard focus, screen reader announcements, error handling, and accessible component behavior all deserve attention while features are being built.

During content creation, teams can examine whether instructions are understandable, links communicate their purpose, and important information remains accessible to people using different technologies or experiencing cognitive fatigue.

During testing, scenarios help teams evaluate whether users can complete meaningful tasks across an entire experience. Automated testing remains valuable for identifying certain technical issues, while manual testing and testing with disabled users reveal barriers that automated tools cannot reliably detect.

Web accessibility improves when platform teams understand how their decisions affect users. In enterprise environments, where different departments and outside partners are often responsible for different parts of a digital experience, a structured exercise like this can create opportunities for teams to see how decisions in one area affect people throughout a user journey.

Role-playing supports empathy, but firsthand experience remains essential

Access & Barriers comes with an important responsibility: The characters represent people who experience disabilities, and the scenarios highlight barriers that affect their lives. Participating in a simulated scenario cannot reproduce someone’s lived experience with disability. Even people with similar disabilities can have very different experiences, needs, and preferences.

My personal understanding of disability has developed through experiences with my family, conversations with disabled people, and years of accessibility work. Those experiences have also taught me how much we can learn by listening to people speak about their individual circumstances.

Role-playing offers an opportunity to explore situations, question assumptions, and become more aware of potential barriers. 

Teams should build on that learning through research, collaboration, and testing with people who have disabilities. Involving disabled people throughout a project’s life cycle provides insights that strengthen design decisions and reveal challenges that internal teams may overlook. Those insights are especially valuable when websites support complex transactions, essential services, or large and varied audiences.

Web accessibility and business requirements can guide better solutions

Accessibility has become a central part of my professional development. I’ve earned the Certified Professional in Web Accessibility (CPWA), Certified Professional in Accessibility Core Competencies (CPACC), and Web Accessibility Specialist (WAS) credentials through the International Association of Accessibility Professionals (IAAP). I’m also a Section 508 Trusted Tester for Web on Windows through the U.S. Department of Homeland Security.

Those qualifications reflect years of studying accessibility standards, evaluation methods, and implementation practices. They’ve strengthened my technical knowledge, while my work as a developer has continually reinforced the importance of understanding how people experience the websites we build.

Early in my development career, I created a WordPress plugin I believed was accessible because I’d followed proper technical guidance and implemented ARIA attributes. When someone tested it with a screen reader, I discovered that the experience didn’t work as I’d expected. That experience reinforced the importance of understanding how people interact with the technology we build. 

Technically informed decisions still require validation through practical use, and I’ve carried that lesson into my work at Reaktiv, where accessibility informs how we approach design and development challenges.

Enterprise projects regularly involve competing requirements. Marketing teams need flexible publishing tools and engaging experiences. Business stakeholders want features that support organizational goals. Developers need to account for performance, maintainability, security, and accessibility. Our job is to understand those requirements and develop solutions that preserve accessibility while delivering the functionality the organization needs.

For example:

• A project may call for an interactive content carousel. We can explore ways to preserve its visual presentation while ensuring keyboard users can reach its content and screen reader users can understand its structure.
• Another project may require a load more button that dynamically adds content to a page. Without careful implementation, people using keyboards or screen readers may have difficulty determining what changed or finding the newly added content. Managing keyboard focus and communicating updates can make the interaction easier to use.

My goal in those conversations is to understand what the organization needs and identify a way to deliver it accessibly. That often requires collaboration between designers, developers, content teams, and project stakeholders.

Accessibility requires long-term technical stewardship

Accessibility is also a matter of technical stewardship. Design systems, custom components, publishing workflows, and third-party integrations influence the experiences an enterprise, higher education, or media website delivers. A problem introduced in one component can affect hundreds of pages, while an inaccessible integration can interrupt an otherwise accessible user journey.

• For a large university website with dozens of departments and hundreds of content contributors, an inaccessible form component might affect admissions, event registration, giving, and student services. Correcting the underlying component can improve access across departments, while publishing guidelines and training help prevent similar issues in the future.
• For a multinational enterprise using a shared customer portal across dozens of countries, with regional variations in language, payment methods, and account management, an inaccessible dropdown or authentication process might mean customers across multiple markets can’t place orders, manage their accounts, or access support.
• For a media publisher with millions of readers, an inaccessible subscription prompt or paywall might prevent people using screen readers or keyboards from accessing articles or managing their subscriptions.

In each case, a single accessibility issue in a shared component can affect a large audience and interrupt important business activities. Accessibility decisions must account for how components are reused, how content is managed, and how individual experiences connect across the organization. And because enterprise website development is ongoing, these considerations matter even more, as new features, integrations, templates, and content introduce new interactions that affect users.

An experienced development partner can help organizations:

• Anticipate accessibility barriers during planning and design, when teams have greater flexibility to address them.
• Build accessibility into reusable components so improvements benefit multiple pages and experiences.
• Evaluate integrations and user journeys to identify barriers that extend beyond the organization’s primary website.
• Support content teams with publishing tools and workflows that encourage accessible content.
• Maintain accessible experiences as business requirements, technologies, and digital platforms evolve over time.

The WebAIM findings demonstrate that familiar accessibility problems persist across the web, even with the technical guidance for addressing them widely available. Preventing those problems requires consistent attention to how websites are designed, built, tested, and maintained.

At Reaktiv, we view accessibility as part of delivering a high-quality digital platform. We work collaboratively with our clients to understand their business requirements, evaluate technical options, and make decisions that support both accessibility and the organization’s goals.

Building websites that work for the people who use them

Access & Barriers grew out of my interest in tabletop role-playing games and my commitment to making digital experiences accessible. Bringing those interests together has given me another way to help people learn about disability, recognize accessibility barriers, and think more carefully about the experiences they’re creating for others.

The tool is currently in development. I’m continuing to refine the characters, scenarios, and mechanics, and I’m looking for more opportunities to playtest the tool and learn from participants’ feedback. My hope is that it will encourage more teams to explore accessibility through collaborative problem-solving. The most valuable part of the experience is the conversation: Seeing participants ask questions, reconsider assumptions, and identify ways to create better access.

The same curiosity and commitment to problem-solving guide our work at Reaktiv. Whether we’re exploring an accessibility challenge through a tabletop role-play scenario or solving a complicated technical problem for a client, understanding the people affected by our decisions helps us build better solutions.

Enterprise websites have important work to do. They need to support business objectives, integrate with complex systems, and remain dependable as organizations evolve. They also need to work for the people who rely on them, including people with disabilities.

We’re committed to building a more accessible web while delivering digital platforms that help organizations achieve their goals.

If you’re planning a new website or looking to improve an existing digital platform, let’s talk about your project. We’d welcome the opportunity to collaborate with a team that values accessibility, thoughtful development, and meaningful business outcomes.