Good Intentions, Real Barriers: Investigating Accessibility in XR Workflows

Author: Mrunmai Abhyankar, The University of Texas at Austin

Editor Dylan Fox, Director of Operations, XR Access

Executive Summary

This project, conducted in collaboration with XR Access and the Metaverse Standards Forum (MSF), investigates why accessibility in eXtended Reality (XR) often breaks down between intention and execution—and what tools or systems could help bridge that gap. As XR technologies evolve, ensuring accessibility requires not just awareness, but practical, embedded support that fits real-world workflows.

Interviews with XR creators and accessibility specialists revealed several core challenges: accessibility is often introduced too late in the process due to deadline pressure or lack of ownership, while existing standards like WCAG are viewed as too complex or web-centric for immersive environments. Teams also lack integrated tools for testing and interpreting accessibility. There is limited shared language or structure for communicating accessibility needs across disciplines.

In response, I designed a guideline interface prototype (Figure 1) that makes guidelines easier to understand, filter, and apply. The interface allows users to explore categorized guidance based on user ability, platform, or team role, and presents success criteria, practical examples, and implementation tips in a clear, accessible layout. It aims to shift accessibility from a static checklist to an active, usable reference for inclusive XR design.

Goal

To explore how accessibility is currently approached in XR design and development, identify the barriers teams face in applying guidelines, and propose a solution that makes those guidelines easier to find, interpret, and implement in practice.

Research

I conducted 19 semi-structured interviews with a total of 21 participants:

10 XR creators (X1 – X10) — including designers, developers, creative technologists, and product managers working in spatial computing, XR platforms, and immersive content.
11 accessibility specialists (A1 – A11) — including consultants, researchers, advocates, and testers with deep experience in disability access, inclusive design, and policy.

Interviews lasted 45–60 minutes and focused on:

How accessibility currently fits into XR workflows (if at all)
How teams interpret and apply accessibility guidance
What tools, processes, or roles support (or hinder) inclusive outcomes
Where responsibility and decision-making around accessibility actually sits

The goal was not just to collect pain points, but to understand the underlying systems and team dynamics shaping accessibility efforts in XR. The interview script can be found in Appendix A.

Analysis

I used a structured way using a thematic matrix to present insights from stakeholder interviews (see Figure 2). By grouping similar responses, it highlights recurring themes across participants and brings attention to key challenges and opportunities in XR accessibility. This approach also allows for a clear comparison between the perspectives of XR creators and accessibility specialists. The sticky notes are color-coded to reflect the tone of participant quotes—red for negative, green for positive, and yellow for neutral or factual statements. This visual system helps quickly identify emotional cues and patterns across themes.

Key themes that emerged from this analysis include:

Approaches to Accessibility – Differences in when and how accessibility is integrated into XR development.
Challenges Faced – Technical, organizational, and knowledge barriers limiting accessibility implementation.
Existing Guidelines – The role of current accessibility standards, their limitations, and their applicability to XR.
Perceived Need for XR Accessibility Guidelines – The demand for structured resources, toolkits, and platform-level solutions.

High v/s Low Priority Approaches to Accessibility

Participants showed a clear divide in when accessibility is prioritized. Some teams incorporate it early in the design process, treating it as foundational.

“You really want to think about accessibility before you start design because accessibility is pretty much impossible to retrofit.” – X9

“I think accessibility is not something that you can incorporate towards the end. It’s something you start working with from the very beginning.” – X3

Others, however, approach accessibility reactively—only addressing it post-launch due to client demands, limited resources, or lack of awareness.

“A lot of that type of stuff gets deprioritized because, you know, we can barely make the thing as is, let alone add the accessibility, hitting the deadline.” – X7

XR creators in particular admitted to deprioritizing accessibility under deadline pressure or due to insufficient knowledge, while accessibility specialists expressed frustration with this approach.

“It’s not that they’re not doing it because they don’t like disabled people. It’s that they just didn’t think about it.” – X9

Only a few participants reported consistently integrating accessibility from the beginning.

“Someone should be [responsible for accessibility].” – X7

Insight: Many teams treat accessibility as an afterthought due to deadlines, resource constraints, or lack of awareness.

Systematic Lack of Technical and Organizational Support

Teams face both technical and organizational barriers when trying to implement accessibility. Many lack dedicated accessibility roles, making ownership unclear.

“The roles and responsibilities are not clarified when it comes to accessibility between, like, all the different roles.” – A2

“We don’t necessarily have a dedicated accessibility engineer… we mix it into the normal engineering process.” – X6

Tools and engines often don’t support accessible design out of the box, and cross-platform conflicts further complicate implementation. Some features were added by accident rather than intention, pointing to a lack of systematic processes. Testing with users is limited for most participants, and criteria for cognitive accessibility remain especially unclear, as noted by multiple accessibility specialists.

Insight: Lack of ownership and tooling leads to fragmented and inconsistent accessibility efforts.

Need for Clear and Practical XR Guidelines

Participants widely agreed that existing guidelines like WCAG (Web Content Accessibility Guidelines) are too complex and web-centric to apply cleanly to XR.

“WCAG is just so obtuse to try to read, you have to really understand accessibility to even interpret it.” – A7

While some teams attempt to use WCAG, many prefer internal, informal standards based on WCAG but are easier to act on. There’s a general understanding that guidelines are necessary, but their current form is often overwhelming or impractical.

“We’ll probably need something like how WCAG works for traditional websites.” – X2

“Unreal and Unity have accessibility guidelines… but nothing that pulls everything together.” – A1

Several noted that requirements often overlap or feel ambiguous in XR contexts. Testing was emphasized even when formal standards weren’t followed closely.

“There needs to be testing. There’s no substitute.” – X7

Insight: Teams need simpler, XR-specific guidelines that are actionable and not web-centric.

Appetite for Built-in Testing and System-Level Tools

There is strong demand for XR-specific accessibility resources that are easier to use, more visual, and context-aware. Participants requested interactive guides, code examples, and toolkits tailored to their development environments.

“Having a more standardized way of labeling things for non-developers would be really helpful.” – A4

Some suggested TLDRs or cheat sheets to lower the barrier to understanding. Several emphasized that guidelines should be built into platforms and tools, not left as external references.

“I think putting more focus on platform-level or native-level accessibility is needed” – X6

A universal, agreed-upon standard was seen as ideal but difficult to achieve. Many participants emphasized that accessibility challenges go beyond just tools and standards—it’s a multifaceted issue with no final fix.

“Accessibility will never be a ‘solved problem’.” – A9

Insight: There’s strong demand for native, easy-to-use accessibility tools within XR platforms. 

Analysis Summary

Tensions between XR creators and accessibility specialists often stemmed from differing expectations—creators favored built-in tools and ready-made solutions that could help them solve accessibility challenges swiftly, whereas accessibility specialists wanted clear, testable criteria that could make it easier to evaluate and audit XR experiences.

Both groups agreed that current tools are lacking, guidelines are insufficient, and that testing with real users is essential. There was a shared recognition that accessibility needs to be better communicated and embedded across workflows. Business priorities and tight timelines frequently push accessibility to the background. Overall, participants supported having clearer responsibilities, more intuitive resources, and built-in infrastructure support.

Guidelines Interface Prototype

Purpose & Context

The guidelines prototype was designed to help designers, developers, and testers explore XR accessibility guidelines more easily. It addresses key challenges surfaced in stakeholder interviews, including the lack of a central resource, confusion around responsibilities, and the complexity of existing standards like WCAG.

Design References & Benchmarks

As part of the early research and benchmarking process, I looked closely at existing accessibility resources to understand how guidance is currently structured and delivered. The Web Content Accessibility Guidelines (WCAG) offered a comprehensive but often overwhelming model. Its sidebar-based structure (Figure 3) was helpful for organizing large volumes of information, but its technical depth and web-specific framing made it difficult to translate into XR contexts.

The Game Accessibility Guidelines (GAG), in contrast, adopt a more approachable tone, presenting recommendations as clear, actionable statements (Figure 4). While GAG loosely categorizes guidelines by ability (e.g., visual, motor, cognitive), it lacks a structured way to search or filter through them, which limits discoverability when applied in practical contexts. This lack of navigability echoed feedback from participants, several of whom described the current state of accessibility guidance as “scattered” or “hard to interpret in context.”

References to resources for existing platforms like Unity’s accessibility package and Meta’s accessibility principles were also reviewed, but fragmented structures and lack of detailed resources in those sources validated the need for something more cohesive and informative.

Interface Prototype

To address the gaps surfaced through interviews and benchmarking, I designed a guidelines interface prototype that reframes guidelines in a more structured, approachable, and role-aware format. The goal was to make accessibility guidance easier to find, understand, and apply within real XR development workflows.

Structure & Categorization

The interface offers two primary ways of navigating guidelines:

By Principle – Grouped according to stages or functions within an XR experience (e.g., Setup, Understand, Navigate).
By Ability – Grouped by disability categories such as Vision, Hearing, Motor, Cognitive, and Cross-modal.

Guidelines were intentionally allowed to appear in multiple groups to support flexible discovery. Additional filters include Role (e.g., designer, developer, tester) and Platform, acknowledging gaps in responsibility awareness and platform-specific implementation issues raised during interviews.

Navigation & Interaction

Users can toggle between Ability and Principle tabs, which restructure the list of guidelines accordingly. They can also use the universal search bar to find guidelines by keyword. Filters are positioned above the content area, making them contextually visible and directly connected to the guideline list. Clicking a guideline opens a detailed view, with title, description, success criteria, accessibility relevance, and examples.

A future-facing feature includes a chat-based AI assistant, envisioned to help users ask questions and interpret guidelines more easily—especially when unsure how to apply them.

Design Iteration

The initial layout followed a three-panel grid with filters on the left, a list of guidelines in the center, and detailed content on the right (see Figure 5). However, during informal reviews and walkthroughs, it became clear that the placement of filters in a side panel made it less obvious that they were directly connected to the list of guidelines. Users didn’t intuitively associate the filters with the content they were viewing, which affected usability and discoverability.

To address this, the layout was restructured with filters positioned above the guideline list, making their function more contextually visible and clearly tied to the content. Tabs were also introduced to switch between categorization types (by Ability and by Principle), keeping the interaction simple and reducing visual clutter.

The final prototype (Figure 6) presents a cleaner, wiki-style interface that enables XR creators to browse, filter, and understand accessibility guidelines more effectively. A dedicated section “How it helps different disabilities” was included to help creators understand the impact of each guideline, encouraging more empathetic and informed decision-making.

Known Limitations

Some users may want to select multiple abilities, which points to Ability potentially being better as a filter than a categorization.
Edge case handling (e.g., filtering out a currently visible guideline) needs further definition.
The prototype has not been user tested, and feedback from actual users is essential before making decisions about implementation.

Next Steps

This research uncovered clear gaps in how accessibility guidelines are understood, accessed, and implemented in XR workflows. The guidelines interface prototype is a foundational step toward creating a more usable, structured, and role-aware guideline system — but additional layers of exploration are needed.

Moving forward, we could:

Validate the IA and prototype through user testing with XR creators and accessibility specialists to ensure real-world relevance.
Explore development of a shared checklist or reporting tool, enabling teams to track, assign, and document accessibility considerations collaboratively.
Refine how guidelines are presented, potentially shifting from static content to more interactive formats (e.g., customizable views, decision trees, AI-supported interpretation).
 Build a platform-level strategy for how guidelines, infrastructure, and tooling can be better aligned — moving from reactive documentation to embedded support.
Have a dedicated examples section to help creators find specific examples of what has been done before and how they can approach a particular accessibility issue.
Continue shaping a unified, XR-specific standard, informed by lived practitioner experiences, that balances technical depth with practical usability.

This work opens a pathway not just for organizing accessibility guidelines more effectively, but for helping teams interpret and apply them with greater clarity and confidence. As the MSF continues its work on developing standardized accessibility guidelines for XR, this research offers valuable insight into how different stakeholder groups navigate, understand, and act on accessibility guidance. The prototype provides a foundation for structuring and presenting guidelines in ways that are actionable across roles.

Conclusion

This research highlights the real-world gap between the intent to build accessible XR experiences and the barriers that make it difficult in practice. While many XR creators value inclusion, challenges like unclear guidelines, time constraints, and limited collaboration with accessibility experts often get in the way.

The prototype developed as part of this work offers a starting point to address some of these gaps. By organizing existing guidelines in a clearer, more navigable format and explicitly highlighting the roles and responsibilities, it supports creators in making accessibility decisions earlier and more confidently in their workflows. While still exploratory, it lays the groundwork for future iterations and conversations, acting as both a baseline and a provocation for rethinking how accessibility guidance is delivered and used in XR. There’s still much to be done but building shared understanding and tools like these can help push the industry toward more inclusive and sustainable design practices.

Appendix A: Interview Script

Interview Script: Understanding the current state of accessibility in XR

Stakeholders: XR Creators & A11y testers

Greetings and introduction

Hi , How are you doing today?

Thank you for taking the time to talk to us today!

My name is Mrunmai and I’m a UX researcher at XR Access. My team is working with the Accessibility Working Group of the Metaverse Standards Forum on a project to improve accessibility in XR (virtual and augmented reality) and would love to learn about the challenges you face when creating or testing XR experiences or otherwise evaluating for accessibility. Your insights will help make XR more inclusive for all users.

Please share your honest thoughts as we go along. Do remember, there are no right or wrong answers!

Do you have any questions for me before we get started?

Before we begin, could I just confirm that you’re still okay with this session being recorded? [Wait for reply]

Awesome! I will start the recording now.

Thank you!

Questions

XR Creators

Can you tell me a little about your background and experience in XR?
What are the types of XR applications you have worked on? (e.g., VR, AR, MR, gaming, training, simulations)
What software or tools do you use to design or develop XR experiences?
When designing XR experiences, what are the key factors you prioritize?
At what stage in the development process do you consider accessibility?

[For Sr Devs] Has that changed over time?

When designing/developing XR experiences, have you ever needed to consider accessibility? Was there any incident which prompted that?

Which disabilities have you considered in your designs?
How do you ensure users of different abilities can interact with your applications?

Who in your organization is responsible for accessibility? OR Who determines the priority of accessibility-related tasks, and who is responsible for approving accessibility changes?
Do you have any internal accessibility guidelines or best practices specific to XR?
Are there any people with visible disabilities on your team/in your organization? OR Have you ever worked with users with disabilities when designing an XR experience? What was that process like?
Have you ever had to adapt an existing XR experience to make it more accessible? If so, how did you approach it?
Can you share a time when making an XR experience accessible was challenging? OR Are there specific technical or design limitations that make accessibility harder to implement in XR?
Are there accessibility requirements from clients, stakeholders, or regulations that you have to meet?
Are there any accessibility-related design patterns or frameworks you follow?

Have you used any existing accessibility guidelines when designing XR experiences? How helpful or challenging was it?

Have you found these guidelines helpful, or do they present any challenges in practical implementation?
What would make accessibility easier to integrate into your workflow?
How do you typically learn about new best practices or industry standards in XR development?
Is accessibility also a part of your QA tests?

Accessibility Testers

Can you tell me about your experience with accessibility testing?
Have you tested XR applications for accessibility? If yes, which types? (e.g., VR, AR, MR)

What software and hardware do you use for accessibility testing in XR?
Can you describe a recent experience testing an XR product?

How did you determine if it is accessible?
Do you follow any specific accessibility testing guidelines for XR? If yes, which ones?
What are some of the most common accessibility issues you’ve identified in XR applications?
Have you come across any accessibility features in XR that were well-executed?
How do you typically document or report accessibility issues in XR?
Are there any specific disabilities that XR applications often fail to accommodate?

What guidelines do you apply regarding accessibility besides WCAG?

What would make your job as an accessibility tester easier when evaluating interfaces and experiences beyond WCAG?

Do you use any specific checklist tools for different interfaces (eg: web, mobile, XR, etc)?

Are there any features you really like about those tools?

Is there any tool/feature that you find difficult to use?

What do you do when existing accessibility guidelines don’t directly apply to the application you’re testing?
Is accessibility also a part of your QA tests?
If you could change one thing about the way accessibility is handled today, what would it be?

Closing/Thank you

These are all my questions for today!

Thank you so much for participating in this screening session. Your opinions and suggestions are important and will help us improve the accessibility in XR interfaces.

Ask if they want to join mailing list:

https://docs.google.com/forms/d/e/1FAIpQLSdZxYGXzfZumj_1xRu0J1V7gG3PLmCDj2GC8pB8SMAQB9rDRA/viewform

Is there anything else you’d like to add or any questions you have for us at this point?

Awesome! Thank you again for your participation and sharing your opinions. Have a great day!

Appendix B: Full Quotes and Insights

Approach to Accessibility

Participant
Sentiment
Insight

X2
Negative
Commercial projects: ‘I think it really kicks in in the later stages.’

X2
Positive
Research projects have more liberty and feasibility to accommodate accessibility in XR

X5
Neutral
Highly dependent on client requirement – does not proactively implement any accessibility features or follow any guidelines

X9
Neutral
As a consultant, clients are not super receptive of the feedback on accessibility and look for quick fixes and improvements

X4
Negative
Know your audience and cater the solution accordingly: User Centric but not accessibility oriented

X8
Negative
Focus more on MVP then iterate to make it more comfortable and accessible

X8
Negative
‘I think Industry projects are not always making the decision to spend time and money for accessibility.’

X3
Positive
The definition of accessibility changes when in context of XR

X8
Neutral
Created user persona after alpha launch and incorporated accessibility according to the persona

X9
Positive
‘You really want to think about accessibility before you start design because accessibility is pretty much impossible to retrofit’

X10
Positive
‘I think that accessibility is for everyone’

X4
Negative
‘I’m more focused on being a developer than a designer. So that wasn’t my first go to thing always’

X5
Negative
‘I am a tech person. A healthcare person is required when designing in the healthcare domain’

X6
Positive
Don’t have a dedicated accessibility engineer but included accessibility at all steps

X6
Positive
In a11y first orgs: Accessibility is considered pretty early in the process – embedded in the design phase

X8
Negative
‘But if we don’t have these kinds of needs, our user feedback is not asking for any of those features. We might not do that.’

X5
Negative
Despite the client being into healthcare, nobody worked on the accessibility aspect

X3, X7
Positive
‘I think accessibility is not something that you can incorporate towards the end. It’s something you start working with from the very beginning.’

X9
Negative
‘It’s not that they’re not doing it because they don’t like disabled people, right? It’s that they just didn’t think about it.’

A1
Positive
Considering multiple disabilities and having alternative controls

A1
Positive
If a studio has a dedicated accessibility team/ people are passionate => good accessibility features

A9
Positive
Accessibility guidelines are more about player experience and their comfort and usability

A6
Negative
‘A lot of the time something’s accessible but still might not be usable’

A1
Positive
Other considerations include environmental factors like movement of text, acceleration of objects/environment

A2
Positive
The approach was more ‘how do we do this’ than ‘we don’t want to do this’

A1
Positive
‘I think there’s a misconception out there that VR just is completely unusable if you can’t see, and it’s not necessarily the case.’

A4
Positive
Information architecture played a major role in revamping the website’s design to make it more accessible

A9
Positive
‘If it’s not accessible, it’s a bug’

A4
Positive
Focuses more on shapes and symbols over color to convey certain things like avoiding red for negative and green for positive

Challenges Faced

Participant
Sentiment
Insight

X8
Negative
Current prototyping tools for XR lack customization wrt accessibility

X1
Negative
Technical difficulties like file size for audio support

X7
Positive
Accessibility issues sometimes get addressed unknowingly

X4
Neutral
Consider UX but don’t consider accessibility explicitly

X1
Negative
Less interest from XR Dev teams worked with or a dedicated team

X4
Neutral
Haven’t had anyone in the org responsible for a11y – worked with clients and their requirements

X4, X5
Neutral
Made a few features/changes to make the experience accessible unintentionally

X1
Negative
Lack of information/data about users – difficult to focus on any disability

X8
Neutral
Conflicting guidelines like Meta and Apple can be difficult to resolve for cross-platform compatible experiences

X6
Neutral
Adding an accessibility feature in a more user-intuitive way

X7
Positive
Important to know how to have conversations about accessibility features and requirements

X1, X3
Negative
Difficult to pitch accessibility features/changes in commercial applications

A9
Negative
There are some current solutions that aren’t necessarily the definitive solutions

A2
Neutral
‘The roles and responsibilities are not clarified when it comes to accessibilities between, like, all the different roles’

A8
Negative
A lot of conversations and back and forth with design and dev teams to fix issues based on the testing performed

A3
Negative
Determining success criteria for cognitive disabilities is challenging

A5
Negative
‘I really don’t know who to communicate with on it (accessibility issues)’

A4
Neutral
Difficult to accommodate a large number of different stakeholders with different requirements

A8
Negative
‘How the webpage is going to look for people that use enlarged texts – often overlooked’

A9
Negative
Hand tracking enables natural interaction without having to hold a controller, but comes with requirements for e.g. gestures

A9
Positive
Game will ship one way or the other – want to get as much into it to let people play as possible

Guidelines and Standards

Participant
Sentiment
Insight

X1
Neutral
Did have a few considerations while designing for certain disabilities – But not aware of accessibility compliance and existing guidelines

X2
Neutral
Existing standards & guidelines: Focused on traditional interfaces and don’t really apply to XR

X1, X3
Negative
Did not use any specific guidelines – Brainstormed potential issues with the team

X6
Neutral
Don’t have any specific internal guidelines – making things accessible and intuitive testing within the team

X6
Positive
‘It’s usually a lot of internal and play testing that really kind of shape what that is but at least currently we don’t necessarily have like a specific set of standards for everything we do’

X7
Neutral
Also used video game accessibility guidelines – don’t feel as official

X4
Negative
Have referred to Oculus guidelines – but after completion of the development

X9
Neutral
Did not really refer to any other guidelines and referred to the internal doc created since it felt sufficient

X7
Positive
‘There needs to be testing. There’s no substitute.’

X8
Negative
Have referred to Meta’s XR Design guidelines as well as Apple’s guidelines

X9
Neutral
Used spreadsheets to document issues and prioritize into buckets

X9
Positive
Own set of guidelines – XR interaction style guide that includes general best practices

X2
Positive
Tried to reference WCAG to meet minimum font sizing requirements

X7
Positive
Have tried skimming through other guidelines like WCAG but they seem more web-oriented and don’t always apply to XR

X6
Positive
Refer to WCAG when looking for more “fleshed out” guidelines

A1
Positive
Multiple formats of reporting including full reports, slide decks or conversational walkthrough

A2, A8
Positive
Use project management tool to log accessibility issues

A5
Positive
Document feedback in the form of notes/observations

A2, A5, A7
Positive
Have internal set of guidelines

A1, A3
Positive
Also use client internal guidelines if any for evaluating accessibility

A9
Positive
Have internal guide documented using multiple resources like GAG, W3C, APX, etc

A1
Neutral
‘No amount of evaluation will ever replace testing with players with disabilities’

A1
Positive
Have internal guidelines/ design patterns called APX – work in conjunction with guidelines

A6
Positive
Internal rating system (Google Accessibility Rating)

A9
Positive
Use vision simulation tools and also test for spoken audio and auditory processing issues

A1, A9
Positive
Things fall under multiple guidelines and design patterns often overlap

A3
Negative
Referring to WCAG or other guidelines could be difficult for beginners/layman to understand

A9
Positive
‘I like the idea of WCAG guidelines categories over GAG’

A9
Neutral
Not a lot of standards about VR-specific accessibility right now

A7
Negative
WCAG is very complex

A8
Negative
Sometimes it is difficult to understand the WCAG success criterion and difficult to meet it because of user system settings that might lead to the website or app failing WCAG compliance

A5
Positive
Have noticed a high-level similarity between guidelines for web/mobile and XR interfaces

Perceived Need for XR-specific Accessibility Guidelines

Participant
Sentiment
Insight

X3
Neutral
Toolkit – something like a plugin that can help implement/take care of a11y

X3
Positive
A well documented resource on non-2D platform – An interactive VR based approach to understand and test the guidelines

X7
Positive
Need for real guidelines that would be simple to interpret and use

X1
Positive
Would be helpful but also could change with context

X3
Neutral
Design system – Pick assets on the go, catering to the XR a11y

X8
Positive
Customizable XR interaction toolkit

X2
Positive
Helpful to have standardized tools/packages according to guidelines

X2
Positive
Would love to have a11y plugins

X2
Positive
Easier to make the code more accessible using AI tools

X2
Positive
Examples of a11y issues in code for XR experiences and how to fix – like WCAG

X6
Positive
Focus more on platform level or native accessibility that applications could more rely on

X9
Positive
Accessibility should be built into the toolkit/infrastructure

X2
Negative
Customization leads to ambiguity in terms of putting everything in the same basket

A9
Positive
Hitting the minimum level of requirements/standardization/measurements would be useful

A3
Positive
‘I definitely think it would be easier, you know, if there was just kind of one universal set of criteria that everyone was in agreement on’

A7
Positive
Use own code examples in internal guidelines for better understanding of guidelines

A1
Neutral
‘Unreal and Unity have accessibility guidelines and templates and so on and so forth that you can kind of read through, but nothing that pulls everything together’

A1
Neutral
Having a holistic set of guidelines could help understanding the problem

A9
Positive
Having a cheat sheet / more approachable would be beneficial

A3
Negative
Having good examples in documentation is really important

A9
Positive
‘There should be a TLDR’

A5
Positive
Interactive tutorials/guide including a11y features for users to understand and adapt

A4
Positive
‘Having a more standardized way of labeling things for non developers would be really helpful’

A4
Positive
Helpful to include an alt text in the metadata of images and videos – will make it easier for developers and designers