Ashley Coffey: Hello, my name is Ashley Coffey, and I’m the Director of Technology and Integration XALTER, as well as a member of the XR Access Business Case XR working group, and I’m delighted to moderate this XR access panel on building for all. We have a wonderful combination of perspectives to share from our panelists today. I’ll ask each of them briefly to introduce themselves and share what they focus on in regards to building XR experiences for all. We will start with Mari Kyle of Facebook Oculus. Mari Kyle: Hey everyone, my name is Mari Kyle, I’m a game producer at Facebook Oculus, I work with a team of producers to create many of our first priority games, as well as build resources and solutions for all of our developers. At Oculus I led an initiative to create a set of virtual reality recommendations, standards across Rift and Quest platforms for accessibility features and also built a series of educational resources for our developers. These resources include a video walk through of accessible design in VR and a thorough set of developer documentations that provides detailed tips and best practices for accessible VR. Ashley Coffey: Excellent, thank you, Andrew, would you briefly introduce yourself. Andrew Eiche: Hi, yes, thank you, I’m Andrew Eiche, the COOwl and cable slinger at Owlchemy Labs, we a XR studio are building innovative, and exciting all ages experiences. Well known for the games Job Simulator, Vacation Simulator, including our recent add on Back to Jobs, and Rick and Morty Virtual Rick-ality. One of the things we do, our kind of mission statement is VR for everyone or XR for everyone because we've now pushed forward, and you know, we believe in kind of all aspects of XR for everyone. This talk today is going to touch on a lot of that, and kind of our philosophies behind that, and accessibility is a big part of that philosophy. Ashley Coffey: Thank you, Andrew. Next we'll hear from Roland Dubois. Roland? Roland Dubois: Thank you so much for having me. My name is Roland Dubois, and adjunct faulty teacher for Immersive Design at the School of Visual Arts in New York City. I'm also the creator of a journal about what's out there in the industry. I am hosting web XR New York City and workshops and meet ups, allowing people to play around with the immersive tech. And I also am working on accessible projects and prototypes and diverse hack-a-thons wherever I can in collaboration with Thomas Logan from Equal Entry. Ashley Coffey: Thank you. And our fourth panelist is Sophia Moshasha, VP of the VR/AR Association, D.C. Chapter. Sophia, would you tell us a little bit more about you and your work. Sophia Moshasha: Absolutely. Thank you again for having me, Ashley, and it's very nice to be on the panel with everyone that has focused goals on XR accessibility. That's precisely what we need in our industry. As you said, Ashley, I am the VP of the VR/AR association, and I also co-founded a group called XR women which is how I delightfully met you, Ashley, and coproduce events surrounding web XR, including the web XR awards, and the web XR developer summit, so all of these initiatives and efforts are focused around education, awareness, and accessibility for XR and the industry at large, and getting people to understand what we can do with technology, and how to deploy it to the masses. Ashley Coffey: Wonderful. Thank you all for being here today and being part of this important discussion, and important work. We have a lot of exciting topics to dive in to today. So with all of your fascinating blends of backgrounds here, I would like for each of you to share a perspective on how important it is to build XR experiences for all. Especially at the beginning of content development and design. Not just along the lines of designing for disabilities but in the broader sense of being inclusive of all under represented or marginalized groups. Unless we do this, we will not have equity in XR design, usage, experiences and opportunity. Mari Kyle: Mari would your share your thoughts first? Sure. We see far too often that developers think of designing for accessibility or building more inclusive games and applications as an afterthought rather than a central part of their application, but given how immersive and personal VR experiences can be where you're actually living and experiencing these applications firsthand, we have an immense responsibility to make sure that these applications implement inclusive considerations at the start and integrate them into all aspects of development, from mechanics to UI, to sound, art and more. Often, when building for a broader inclusion, you end up making the application more comfortable for all audiences. The phenomena of the curb cut effect feels even more real in VR where so many people are still learning how to locomote, and interact, and simply live within these worlds. Thank you, Mari. I would love to hear thoughts from the other panelists as well. Sophia Moshasha: I’ll just step in and say something really quick. In terms of building for all, diversity, and inclusion, I think it's generally very important to get the perspective of people from a very diverse background because if we don't, we're missing out on a lot of great content that could apply both to these niche groups and under represented groups as well as to the masses and when I mean diversity, I also mean diversity in subject matter expertise because you can be a great designer and developer but without partnering with people that have this deep industry knowledge, we're not going to be able to execute XR at its greatest capacity. So I definitely think that it's important to include people from a variety of backgrounds when developing XR experiences. Andrew Eiche: Sophia that was the perfect tee up for something that I was about to say which is one of the things that we do at Owlchemy because we're focused on our specific thing, not the broader organizational stuff. We work really hard to make sure that our products are, back to the VR for all, are all kind of under that banner. One of the things I want to point out as an example for folks, we built this character creator at Owlchemy, and it's for the Vacation Simulator game, and we really wanted to make sure that everyone could be their truest selves, so we contracted with the group, Pretty, Brown and Nerdy, to make sure that we represented Black hair styles properly, brought in Google's diversity and inclusion group to do testing and give us feedback. We brought in other folks who are part of different religious communities that have religious headwear to make sure we represented all of that correctly, and it was a massive amount of work, but in the end, I feel like we have one of the -- it's a very select group of games that have this broad spectrum representation, where you can really make yourself, and that has meant a lot to folks. And some of the other things, too, like there's a lot of subtle things you could do. A lot of things that you can think about, right, so something that very few people have noticed but it exists is in our game all the characters are genderless, and we use the non-gender they. They're robots, that's what we decided, we did it, we committed to it, and we have never heard anyone say anything, which is kind of cool, everybody accepted that as the base, and all of that kind of knowledge carries into our work on accessibility. So, you know, it's really important that we brought these folks in at the very beginning, and then had them reviewing our content throughout, right, we were sending mock ups of different hair styles like fades out to Pretty, Brown, and Nerdy, and they were sending comments back to us to make sure that even if - you might not necessarily have the diverse set of talent in your company, it's worth going out and hiring, you know, contract groups, and bringing those folks in to make sure that you can increase that diversity of access too. Ashley Coffey: I was going to say, Andrew, I noticed whenever Owlchemy came out with that, I realized that you did put a lot of ground work into that, and I attributed that back to 2019 XR Access, when you were setting up a table trying to pull the resources together, and bring them forward at Owlchemy Labs to actually implement in your designs. Bravo to you and your team for doing the ground work. It truly doesn't go unnoticed. Andrew Eiche: Well, thank you. Roland Dubois: I wanted to speak about the actual content that we're always touching on because we have to think about XR as a medium of delivery of content, and the diversity aspect and the equity aspect is how do I consume that content. How do I make the content usable and useful for the people that you are actually targeting, and how do we make it more inclusive. Right? So what Andrew did, what was really interesting in the gaming space, to actually have representation of the same user groups, and so they have the reflection of themselves, the content, and when it comes down to content usability, and productivity, we have to think about how do people consume, and navigate that content, based on their abilities, their cognitive, like, patterns that they're used to, the cultural references, and all of this other stuff, so when I teach at SVA, my students, always start very basic at what is the actual content to deliver, and how do you actually make that work in that medium, and what kind of parallel worlds can you create that provide the same kind of quality of experience in all of the different kind of layers of XR, so that's a really important focus, and centers always content first, and then the technology and the limitations around it. Ashley Coffey: Sophia, I would love to hear your thoughts? Sophia Moshasha: I completely agree with what everybody else is saying. I think it's super important to get all perspectives on board, and because you can't create for a demographic or a culture or anybody really, without getting the perspectives of the people that you're creating for. So I think in terms of diversity, and inclusion, and accessibility, I would say you both have to think about the creation and development side of things, as well as the audience, and deployment, and how you're going to get your content out to your target audience, and you also have to think about how you're going to deploy it as well because one solution may not be the one size fits all solution for all audiences. So you have to understand who you're trying to target and how they're going to be able to access XR content, and understand what media might be the best fit for that audience, which is why I love the upcoming developments of web XR, and the capabilities of that bring to accessibility. Ashley Coffey: Absolutely. Great perspectives here, and one key thing that I think is a great take away, especially for our audience is awareness matters, so talk about these things at the companies that you work for or work with. Kind of spread that word because the more that we're working with one another and spreading the awareness of the importance of this access, then the more that it can take spread and take flight, and actually be implemented from the ground up and not as an after thought. As we have discussed this imperative for building XR experiences for all, I would like to discuss about how we would go about doing it. It strikes me as key to have to approaches, resources, as well as people who can learn about and practice building XR experiences for all. In terms of resources and processes, what are your thoughts here. Mari Kyle: I can jump in here. My biggest tip for the developers and people who are trying to build accessible experiences is really to try going through your experience or your game with different settings. If you're an able bodied developer, it's really hard for you to understand what it's like for people to go through your VR application without certain abilities, and get a grasp for your blind spot without experiencing your application from a different perspective yourself. I usually recommend going through your game or application with certain settings like disabling all the audio, and playing exclusively from a seated position or desaturating your visuals and seeing if you can navigate your VR application with these settings. For example, if a puzzle that was previously solvable by matching certain colors is not unsolvable when everything is in gray scale, you have a learning to bring in contrast, or bring in some sort of pattern. For another example if you can't anything that happened in your narrative without audio, that's another learning to add in better captioning systems or provide some visual context cues to help users understand. But to Sophia's point, although this works sometimes for people who are able bodied developers who are going through the experience of developing on their own, you should always get in the perspective of someone from the community to come in and play these experiences. They're always going to have the most authentic, lived experience that they can share with you, and be able to provide feedback? Andrew Eiche: If I can add on to that, that's all amazing, the perfect advice, I’ll tell you tricks we use at Owlchemy to help that process, right, because it's easy to remember or it's easy to turn those things on and off, but you have to remember to do it. Some of the things that we do to kind of push that along is we built a few simple tools to help us, right, and they are kind of silly but really effective tools, one is the word scrambler and the other is the audio scrambler, those are tools that go in and purposely scramble all the voice over, and then another tool that purposely goes in and finds any instance of text and scrambles up the words, and the point of the testing is exactly what we have been talking about is make sure that you can play the game. We do all of that until we run out of, you know, kind of head room when we stop finding things, and then we bring in folks from the community. You can build tools to make it easy for your developers. If you integrate that into your testing process as one of the tests, you must do, you must turn on the word scrambler and pass it. That is part of the definition of done. Then you will be designing things more accessible out of the gate and probably more universally accessible. Because you're going to have to learn how you to not to rely on the features. In terms of tools and resources, first of all, XR Woman, we meet every Wednesday. We have a whole slew of perspectives of women community and immersive technology. That is a good resource there in itself. There is in terms of accessibility for on the creator side, there is a lot of low code and no code tools and platforms out there for the non-technical creator. From a creator side, accessibility is important as well. So, I know metaVRse is one tool that's out there. There are a few others out there that are great for those learning how to develop. I'lll also say web XR is a great new up-and-coming medium where you can access 3D content on the web. Check out what the W3C is doing with the immersive web working group and the webXR device API that they are coming out with soon. Those are resources to check out. I can talk about that XR space. I wanted to point out that it is very important what Andrew said about building accessibility testing into the QA pipeline. Internationalization for text is nothing else than scrambling words, so it's not too much of a leap in order to bring in accessibility and those tests into already established pipelines when you create international software. For my workshops which are in a-frame which is a framework that builds on top of 3DS, a javascript library that uses that XR API. My students are not tech students. At SVA, they are mostly artists, mostly creatives. Some have JavaScript, knowledge. Not many. Some people use Unity to build VR right away, from the get-go. I stay away from that. I want to have people think about it in the context structure way like the way we are used to in the world wide web. There is so much that the W3C has done toward that with the accessibility guidelines, WCAG 2.0, 2.1, AA and AAA certifications. There is so much that the browser software already provides, with already established guidelines and tests and resources, that it's a natural transition to go from a two dimensional web site to a three dimensional web site and eventually wrapping it around yourself. For that reason, I think that prototyping, especially in a-frame, understanding space, designing for space, proprioception, space that you take yourself on inside of the virtual environment - does do things like encroach on you, or do you have enough space to breathe? Are people in your space or are they too far away? So you have to feel like you cannot really interact with them? All of this learning experience of spatial design is much more closer to an architecture project than a game or a 2D project. Tools that are free, like A-frame is an open source project that is started by Mozilla a few years back. And there are tons of JavaScript frameworks that take advantage of that device API to deliver content through the browser. You can prototype with that. That gives you a lot of opportunity to test in place without being an engineer. It lets you craft things really quickly and fast. Ashley Coffey: Thank you, Roland. Thank you all for sharing great ideas about useful approaches and resources and tools. Next, I would like to ask each of you about the most important part of building XR for all. How can we get more people with disabilities and intersectional identities involved in XR technology platform and content design, ensuring people with a lived experience of disability are driving design and improving access and experiences available to all? What is the broader value of that? Sophia, I would love to hear from you. Sophia Moshasha: I would say the broad value of developing for disabilities is, you know, we have new opportunities to deliver content to people -- to the masses. If we think of XR as a new medium of communication, then, you know, this is like the new TV, the new radio of the 21st century. You know, this really is in that sense, it belongs to the masses and to the global economy. This is an opportunity to deliver content, meaningful content to those who wouldn't be able to access these lived experiences. 3D, XR, VR, AR is the closest that you can get to having those lived experiences. I think in that sense it is super valuable and important to be able to develop for the people that are currently missing out on these day-to-day activities in life and learning experiences offered to everyone else in traditional classroom environments. It is a new opportunity for everyone, but specifically for people with disabilities. We offer them a lot of value that they currently do not get from traditional mediums. Mari Kyle: I like to give a huge plus one to Sophia's point. That's the thing that's most exciting about it to me, is that we have a real opportunity here to tear out the roots and restructure the standards for accessibility in this new medium that we couldn't for TV and for other media that's existed for decades and developing for decades. We're at the start now, where we can take all of these learnings and really create a solid language for us all to move forward with, with accessible design. As part of what we did at Oculus, we created a set of VRCs, virtual reality checks, that every single application has to pass or is recommended to pass before they get published. Those were things like you have to have captioning, you have to have locomotion options, you have to have certain things within your game. And building this standard so early on is something that I think is really, really exciting and just really a good course to move forward with in the VR industry. In terms of developers, and broadening diversity with our developers, it is what Roland mentions in his last answer. Which is breaking down those barriers and making it more for people who don't have coding backgrounds or years of gaming experience to come in and build these applications and get their perspective into the content that they want to consume and create. I feel like there is also a huge responsibility on us, the platforms to create solutions as well. People aren't going to want to create diverse content for a platform that they can't use. So it's on us to create accessible hardware, accessible solutions, and it's also on the developers to create and breakdown these barriers to make it easier for other folks to get others into the industry and start contributing. Andrew Eiche: To push that a little bit further, to talk to some of the developers that are existing. You know, there's definitely a lot of these barriers broken. You can look at things like Rec Room and Dreams as examples of platforms that exist that have literally no coding experience. But I think some of the things that our developers that are already doing the work have to do is, go out and find these people. You have to not be afraid to playtest your games, and you have to not be afraid to playtest your games with an incredibly diverse set of people. And you have to do it early, right? At Owlchemy, we start playtesting our games incredibly early. We get the smallest chunk of it we can get playtestable, and we work from there, and we continually do it throughout. And do it with incredibly diverse playtesters. We've even figured out how to do it during the pandemic. You an do this. This is possible. There are things like NDAs. They work. You don't need to have things leak out. You need to find your target population. Even if you are doing client work, go to you client. Figure out the target population. Get them to start doing play tests. As Mari said, I love the VRCs, and I think our one thing at Owlchemy is, if I can push it here, make them required. They are only optional. We want to be required. Mari Kyle: It is a rule, so at Facebook Reality Labs We have the guideline that is never surprise users, and we consider developers to be a part of that. If we just suddenly launched these nine VRCs that everybody had to develop these features in a day and it had to be required, it would be a mess and get a ton of pushback. We decided to use them as a runway. We are making them required for now and listening to the community and seeing which ones, you know, people are having difficulty with, building resources around those ones. We built those developer documentation, the video tutorials and then getting that feedback to understand, what things can we as Oculus develop on our side. Captioning solutions is something that Oculus can take on. Other things are things that Oculus can to take on to take that load off developers. And what things can we create education, so developers can learn to use this before we just - banhammer. Make it required for them. Otherwise they don't get to ship. So we are really trying to be contentious of how developers are growing with us and how we can take the load off of developers while also creating some sort of consistency for our users as well, who are going to be needing these accessibility features. So I totally hear you. I am trying to get them required. It will take time to listen to the community and get an idea of what's easy and what's not. Andrew Eiche: I don't mean to put you on the spot. I think it is a fantastic answer. As a developer, I’m really excited to hear about all of those things you just talked about. So that's awesome. Yeah. There are some solutions coming. So it will hopefully be a lot easier. Roland Dubois: I need to point that that Andrew's work has been spearheading this entire space. So I am really excited about what I have seen and published. I want to talk about the engineers and developers that are building VR experiences. The problem I’m seeing and the reason why it is slow in adoptation, is exposure. A lot of academies that train engineers and developers, they don't spend enough time on accessibility. They focus on the ever changing landscape of frameworks, when you think about development and the JavaScript frameworks. It's like a moving target. You are basically hustling to get into one of those ecosystems and blocked from learning the basics about accessibility and ADA compliance. The way that something that isn't ADA compliant can sometimes not be solved. Educational software has to be ADA compliant, has to be accessible. If VR software is not ADA compliant, aka does not commit to the WCAG 2.0 standards then you cannot actually sell the product. You can't sell the software. It is not only an exposure and a knowledge and a good faith thing, or an inclusion or a moral thing, it's also a legal thing, build this stuff into your software in order to make sure you cater to everyone. Ashley Coffey: Absolutely I know we can talk hours about all this. I could spend days talking about this. We'll have to continue our critical conversations in our work streams. Andrew, Mari, Roland, Sophia, thank you for taking time to be a part of this discussion and to share your valuable perspectives. I’m thrilled you are part of this conversation. Thank you all for this fantastic panel. Jessie Taft: Thank you so much to all of our fantastic panelists. Ashley, Mari, Andrew, Roland and Sophia. Our first question actually builds on something that Sophia mentioned. Low code and no code methods for development. I would love to hear responses from all of you. I know Sophia is not able to make it for the Q&A. So I'll had this on to Ashley first. The question comes from Krishna on Slack. A lot of times accessibility that's built into XR technology relies on pretty advanced hardware. What are the challenging with bringing accessibility to cheaper hardware with fewer features that can be leveraged? Ashley Coffey: Hardware and where we are in the technological society. I do think there are a lot of challenges that can be approached to help fix that in the long run. With the low code and no code options available, and I know Roland can really talk more about this. With a-frame and Webxr, there is a lot of opportunity for individuals to get involved in those development processes from the ground level. I think that opens up opportunities for more insight into that development. I know it is not an in-depth answer, but Roland might have a better answer for that. Roland Dubois: Yeah. This is Roland. Thanks for leading me into the discussion. Like no code, low code environments. We have seen so much development in the web space. If you think about the very beginning. The software used to create web sites, from dreamweaver up to now like the platforms like Wordpress. A lot of the way content is being created on those platforms, has been standardized, with accessibility compliance built in. We are in the very early beginnings of those frameworks right now. Like there's webXR engine, There's a bunch of software out there to create webXR experiences with very little or almost no code, just plug and play. And Unity is also an example. You can export webXR from unity. We are definitely going to see more and more structured content that is basically set up for accessibility and hopefully with getting standards normalized, we can actually help people to make content structured and accessible from the get-go without having to rely on the hardware to be able to read it, just the content is the first part that needs to be accessible and the hardware can be developed. Jessie Taft: Great, thank you. I’m going to send the second question to Mari. Let's see. James asks do you have any thoughts on what should be the responsibility of individual developers versus platforms regarding accessibility options within applications? Mari Kyle: That's a really great question and one I think about quite a bit. This is Mari. In my past, I used to be a Unity developer. That was before I came to Oculus. I have a lot of experience with searching through the tools and plugins that platforms offer and trying to put them into my games. The way that I've been thinking of it is, if you have needs for your game or your application which are very specific to what you are trying to accomplish with your game, maybe that is something where it's your responsibility to go through and research and try to find resources and try to solve the problem that you are trying to solve within your experience in the way you only you can uniquely solve. But there are things like captions or perhaps locomotion techniques, or height measuring. Things like that, that could apply across all applications. I think those are things that platforms should take on. That is something I'm really advocating for internally. So, things that apply to all applications, that are are kind of universal. I think should be platforms' responsibilities. I’m sorry. Things that are key to your game are things you should focus on. Jessie Taft: The next question is from - From Deb. Actually I’ll ask all of you to comment on this one. What guidelines do you follow for developing accessible content and do you have a favorite code snippet or course you recommend for people looking to do more accessible development? Ashley Coffey: I’ll take that one first. For developers I work with I reference chapter six, accessibility guidelines, that was actually put together by the XR Association. This is a comprehensive document that is available if you go to the XR Access web site under resources. This document has been put together by a lot of amazing people working on this since 2017 and 2018. I use that. That is the most thorough document I have found that actually demonstrates how you build accessible experiences. Not only from a mobility perspective, but cognitive perspective as well. That is all something we all need to remember whenever we're developing those experiences. When I started diving into where are these guidelines for accessibility, I looked at, what are the accessibility standards already existing for the web and how they are paralleling to the XR. For that, chapter six on the developer guide, available on the XR Access website, is my bible that I share with my developers. I would be interested to hear what Mari and Roland use as well. Mari Kyle: I can hop in. For Oculus, we built a set of guidelines on accessibility, and a set of documents that talk about how to design accessible VR experiences as well as a video tutorial. I can provide the link in the Slack, but if you go to the link on Oculus developer dashboard, there is a set of developer documents that talk about how you can design inclusive locomotion techniques and inclusive captioning systems as well as a video tutorial that walks you through the concepts visually. We use those and we, of course, are referred to so many of the colleagues internally on our accessibility task force as experts on this topic. Roland Dubois: Yeah, plus one on all those, for me. This is Roland. Definitely I’m very much looking into the WCAG 2.0 guidelines from the web. Understanding that web accessibility guidelines are focused around the content itself, not actually about immersion. There is a little bit of a disconnect of accessibility guidelines on the web are focused around consuming content, versus the in the VR space, or spatial experiences, there's a whole big component that is immersion. You lose that immersion if you strip that content out of the experience. There's the AbleGamers, a non-profit organization that came up with a bunch of really good game guidelines for accessibility. They are very good to, you know, review. They are referenced in the XR Access resources. I think everything that is out there is basically in accumulated on XR Access. For any kind of edge cases, where I feel like I want to play more and build something, I usually explore the lowest common denominators of what's currently defined as accessible and then build prototypes and experiences to push the edge. I encourage everyone to see what is out there and test that and also then go beyond that and actually validate. In a lot of cases, the theory is different from the reality and it is really important to always keep a check on what's being provided as the standard. That's my take on that. Jessie Taft: Thank you very much. So, I think we have time for one more question. This one comes from a couple of people. Do you have any tips for thoughts on making -- what's most important in making content creation and platforms like Unity more accessible to people with disabilities and do you have any tips for making that happen? Yeah. Mari Kyle: My top tip at the top of my list is get a test user group that has lived experience. You cannot get valid feedback on what you are developing unless you put the right people in the situation to give you that feedback. Definitely reach out to those in the community that are willing to offer that feedback. You are in a great spot as an audience member. XR Access is here for that. First and foremost, test with individuals with lived experience. You can get the best form of feedback that helps promote that content and immersion as Roland was saying. I would like to add to that. Definitely creating educational resources as well. For me, when I was a young developer, I lived off Youtube videos and walkthroughs from other developers who were trying to figure out difficult problems and having those kinds of resources available for me and really accessible online was something that I think is super helpful. If you do include features to make your game engine more accessible, create resources around it, teach people how to use it, and be in a dialogue with the community about how to use those things. Roland Dubois: Yeah. This is Roland. One of the big parts of the XR space and everything surrounding the platform the webXR device API, everything is living on GitHub, everything is open source. There are tons of projects and experiments out there. There are a lot of like projects that people can contribute to and build in accessibility features. This is an open source kind of shared experience. Unity itself has plug-ins. Everything at the moment which is focused on accessibility are plug-ins. They are not built into the systems quite yet. But I think that the best way to approach this is to see what's out there and test with people that have actually those disabilities and those needs. Not only try to do the color filters and see if you can still walk through the experience. Obviously this is important. You need to validate yourself if you understand the content based on those filters or muting or whatever. You have to understand that you as an able-bodied person, you cannot simulate how a person with a certain disability can interact with the software because the senses that are missing in that person are the other senses of picking up over 150% to 200% of the capabilities and make up for that missing part. Therefore, it is good to double check yourself. You have to double check with the person that has those needs and understands how they are used to interacting with content. Then you can make a really truly inclusive and focused experience for everyone. Ashley Coffey: One last thing I would like to add to that. Look at the researchers in the community as well. A lot of researchers are building plug-ins. For example, Yuhang Zhao is a researcher at researcher at Microsoft and Cornell Tech. In 2019 at the XR Access Symposium, she delivered her research on contrast shaders which is a plug-in you can add into your experience. It blew my mind that this plug-in was accessible. I put it into some of our experiences and it was beautiful. The fact we are here having this conversation is a great step in the right direction to continue to collaborate and continue to look at the work coming out of the research and work coming from groups like these. I think these are all great tips. Don't forget, we always have to build with accessibility at the forefront and not as an afterthought. If you take away anything from this, when you go back to your teams and your work, make sure to cultivate that same attitude of building for all. Whenever we build features, that benefits all, everyone wins. Jessie Taft: Wonderful. Thank you so much, Ashley, Andrew and Mari and Roland and Sophia. That's all the time we have for questions. We will move into the next plenary panel. Realizing inclusive value moderated by Liz Hyman.