Benchmarking Usability and the Cognitive Accessibility Frontier

My name is Abid Virani, one of the co-founders at Fable. My name is Alwar Pillai, co-founder and CEO at Fable. All right. So we are genuinely thrilled to be here.

We decided to come all the way down here for this. Like, this is why we're in New York. Is to hang out with you all. So please do take us up on the offer.

We would love to grab a drink afterwards and hear what you think about what we're gonna share with you. As co-founders, we don't often get a chance to... It's been a while since we both got together, talked together. And part of why we're doing that right now and starting to do that more is because...

Fable is hitting a new milestone. And part of that milestone is because we're doing what we wanted to do 7 years ago, but we didn't think the industry was ready for it. And a lot of this stems out of Alwar's experience as a UX-er and an inclusive designer. So maybe just a little bit of an intro on your background and why did we wait 7 years before giving a talk on cognitive accessibility?

Yeah. So I started my career as a UX designer. And I then got introduced to the Masters of Inclusive Design program at OCAD in Toronto. And when I went through that program, as a designer, I kind of realized my own biases as a designer.

Some of the design decisions I made, and how that was causing a barrier to people with disabilities. And for my Masters thesis, I actually specialized in designing technology for aging adults. Specifically people who experience mild cognitive impairment. So stages before Alzheimer's.

And I would go into retirement homes and spend time evaluating social applications, applications that we used to just keep in touch with friends and family, like chat applications. And put that application in front of adults who were over 70 years old. And it was so evident that the designs that we created are by people who are able bodied and young. Because it was so obvious that none of our designs were intuitive.

The participants I engaged with were always confused about the UI. So when we started Fable, our goal was always to help companies practice inclusive product development. And the way you practice inclusive product development is by engaging with the very people who are excluded. So engaging people with disabilities throughout the product development process, and getting insights at the research stage, design stage, development, QA, and once your product is out.

And we wanted to do this at scale. We didn't think it was good enough just to get one piece of insight. I got an insight, and I can go act on that. We wanted companies to do this on a continuous basis.

And so we had to focus on some of the audiences that we felt confident that we can build a community around. And also build scalable methods, so that companies can start practicing it. Cognitive accessibility, 8 years ago, at least with enterprises that we were engaging with, very few companies had that on the radar. A lot of companies hadn't even engaged with people with disabilities in the first place.

Companies were just doing audits, remediation, that constant cycle. So to have some organizations go from not engaging with anyone and then all the way engaging with cognitive audience, we saw that as a big learning curve. And it was more that we wanted to make sure that the engagement was safe even for the participant. Right?

When you're engaging with a diverse audience, you need to make sure you're creating a safe space, that it's easy for you to give feedback. And we just didn't think the audience was -- and our customers were ready for that. But over the last two years, I would say, we're seeing companies increase their maturity, we have a lot of our customers who also practice in product development, and we've also built multiple communities and scaled it.

So we thought this was the right time for us to invest in this space. It's personally been my passion. We have a great team at Fable. And we're big believers of trying and iterating.

And so what we're sharing with you is our learning so far. And it's gonna continue to improve as we take this offering to the wider audience. So I put in this deck over the next hour we will go through... But we'll keep it tighter than that.

We promise. But over the next little while. We're gonna talk to you about the accessibility usability scale, which is a method that we developed to evaluate usability amongst assistive technology users. We'll talk about what we're learning, as we have more and more companies adopt the AUS, and then we'll dive into cognitive and the work we're doing of how do we start to take what we've learned from the engagements we've facilitated at Fable so far.

And go beyond that. For context, I think we crossed the number. I think we crossed 50,000 hours of engaging people with disabilities, at Fable, over the last seven years. [applause] Yeah, I'll take that.

Yeah.

And I'm a big Malcolm Gladwell fan. So when we hit 10,000 hours, I was super excited to brag about all our learnings. But the reality is that... It really was a glimpse at 10,000 hours.

At 50,000 hours, we're starting to really have stronger conviction about what we can gain and how we can incorporate people with disabilities best in a product development life cycle. But we know that there's a huge frontier that we haven't cracked through, which is cognitive accessibility. So we're excited to talk to you about it, and we're eager to hear your ideas.

Ultimately, we're building upon the same conviction that we gained by doing a Masters in Inclusive Design, this foundational belief that to solve problems, people who face the problems have to be at the core of it. Alwar talks about being a UX-er. I came from a background in international development. And my first attempt at implementing or leveraging inclusive design was in a completely different context, around young people, severely underemployed, in a small country called Lesotho.

And I was working on: How do you engage those young people in economic planning? And the reason I bring that up is because inclusive design is not just a framework for solving problems in the world of accessibility. Inclusive design is at the heart of how we also manage and run our company. It's how we build road maps.

It is foundational to just the way we do our work. And we'll touch back on that as we go.

So... I know we've got folks from W3C here. And probably everyone in the room has touched or experienced some element of a WCAG audit or report. As they've delved into the world of accessibility.

For a lot of people, it's how you get introduced to accessibility, and I was no different in that.

We really wanted to bring something to market that was different than WCAG. We felt like... Audits are tremendous from an evaluative tool, and framework, but in a two-week sprint cycle with 500 developers and product managers and designers and companies trying to really build product at a real pace, to keep up with consumer needs and competition, that WCAG wasn't gonna be the thing that made accessibility a priority. Yeah.

I think also we were trying to see: How can we make it... We think that everyone in the product development process has a role to play in accessibility. But we don't think everyone needs to be WCAG experts. And so we wanted to find a way that we can make accessibility more digestible and relatable.

You know, WCAG has several criteria. But not every developer needs to know that. Every developer needs to know: Why do I need to code this way? How is that gonna impact the end user?

And so we wanted to really take a usability approach to accessibility. And we thought that's one of the great ways of decentralizing accessibility within an organization.

So... What we found was we evaluated a lot of different ways that folks measure usability and user experience. And the system usability scale was the one that rose to the top of our list. As the most widely adopted.

And there are some parameters to it that are really great. The System Usability Scale was developed in the mid-1980s. It uses ten questions on a Likert scale. They alternate in terms of a positive and a negative.

And this is really effective at handling acceptance bias when someone is filling out a survey.

It's been so widely adopted in UX and HCI, and it's also genuinely used by so many global companies that it felt exciting to build on something that already existed. I was taken aback by this number. But having come from the academic realm of inclusive design, seeing something that was being leveraged in thousands of academic papers also gave some confidence that there's a robustness to this metric. And how can we use what they've built, but adapt it?

And I wasn't totally convinced, until I found this quote by John Brooke, who built the System Usability Scale. I don't know why that got blurred out there. But if there isn't a relevant questionnaire for your situation, you can devise one. Well, that was exciting.

I felt like it was a little cyberwink of permission to try to play with what he had built and designed. Even though it hadn't really been... We haven't seen many edits of it since the '80s. But there's a real reason to do it.

So a System Usability Scale -- one of the questions you respond to on a Likert scale is: I think that I would need the support of a technical person to be able to use this system. So we used the System Usability Scale with members of our community at Fable. When we started, our community was heavily focused on folks who rely on screen readers and are blind. So what was really interesting was, when we asked someone the question: I think I would need the support of a technical person, well, sometimes we were putting that question in front of...

It started with a colleague of ours. Sam Proulx. Who is blind since birth. An absolute wizard behind a computer.

The house runs on servers. Codes. He's an absolute technical person. And yet... This question was saying: I think I need the support of a technical person.

No. I need the support of someone who can see. Because I'm doing something that just requires sight. And so we realized that many of the questions in the System Usability Scale needed to be updated, in terms of language.

That made it more appropriate to folks who were relying on assistive technology. And we're at an age where we don't call things systems. So we adapted that question into our Accessible Usability Scale. I would need the support of another person to use all the features of this website.

It's a minor change. But when you remix ten different questions... We ended up at a place where we had a completely different questionnaire. And now we can put it in front of folks who are completely underrepresented in having their experience of usability measured.

And pulled into the focus for product teams.

So... We started developing this in 2020. We did it alongside a couple customers. We collaborated with our community a ton.

And it was led by Elana Chapman, our accessibility research manager at Fable, leading a team of researchers that support our customers. And since 2020, we've now had the Accessible Usability Scale used 11,000 -- more than 11,000 times. Across three major categories of assistive technology. So there's a bias towards screen readers there.

But 7,000 data points from folks leveraging screen readers. We've created this category that helps us organize a big group of assistive technologies called alternative navigation. These are technologies that emulate a keyboard or a mouse. So... It could be switch systems, eye gaze, we include voice navigation in there.

So... It's quite a mix of technologies in there. And then screen magnification tech. And what we're actually seeing now is: Our customers -- but not only our customers -- are using the Accessible Usability Scale as a way to set benchmarks, to compare different products against each other.

And it's part of a product health score for a lot of companies. And it's a lot more approachable for a researcher, a designer, a product manager, to understand whether or not they're moving the needle on accessibility with all the various things they're trying. So what's really exciting here is just to share that we now have something to compare to. So when we ask a user to go through a product or a flow, we now are able to give them a survey afterwards and compare to a large body of data.

Now, whether choosing to compare to your own data points, whether choosing to compare to Fable's benchmarks -- this allows for a different interpretation of... Is something working for someone? We tend to think of this after completion. We tend to think of this as: A measure of usability.

So it doesn't capture: Were they able to complete the task? We think this is a unit of measurement to use after you have compatibility at a basic level. But what we've observed is companies start in a world of "can a user do the thing we're putting in front of them?" And they evolve and mature to start to say... "how usable is our product for assistive technology users?"

And then what was interesting with the AUS, what we saw, was... Now there was another metric that product teams can use to measure accessibility. So it was no longer just: Are we WCAG 1.0 or 2.0 compliant? It was: Product teams setting a base level.

We've had some of our customers where they've set a base level for all product teams. Every product team needs to have an AUS of a certain number. And it's not striving for what Fable's average is. It's more just striving for where you were before.

And just coming up a few points. And what this made product managers, as well -- it made it easy for them to measure, like, what is the impact of all of our accessibility efforts? Which is harder for them to dissect, just from a pure WCAG compliance perspective. I think the other thing that's been fun about this is: The relatability to another part of what product teams are looking at.

So if a product team's got a research team that's feeding them data on a regular basis, there's a high likelihood the System Usability Scale is being adopted there. And now they have something to compare. And what's really neat is that our 50th percentile and the 50th percentile for the System Usability Scale is within a 1 point differential. So they're directly comparable, and now we can actually say: How are the experiences of our assistive technology users, compared to those not leveraging assistive technology?

Everything is an iteration at Fable. And when we set out to build the AUS, we wanted to version it. We expected to version it. And we haven't actually updated the language of the questions, because every time we do a benchmark study and we analyze in depth, what we're realizing is that the questionnaire is meaningfully capturing different components of the experience.

Whether that is the level of confidence, the perceived level of ease, the perceived learnability. Like, how hard is it for me to get familiar and comfortable with this product? It really seems to be representing appropriately how assistive technology users are feeling when they're navigating products. But I keep using the term "assistive technology users".

So I'll get to the fun stuff. Which is: What about those who don't depend on assistive tech? And that is a question that has been on our minds for many years. And it has been intimidating to open up kind of the can of worms that that might be.

Because there's a literal element to assistive technology that's more measurable and observable. But let's dive into what this means, as we delve away from just focusing on assistive technology users. And so this is where we get into cognitive accessibility. Because so far, our community of testers is also categorized by assistive technology.

But we knew when we were entering the cognitive space we can't have that as a requirement. Because there are gonna be individuals who rely on assistive technology. But there are also gonna be individuals who don't. And so what would be the way to categorize cognitive accessibility in a way that, one, makes it easy to recruit, get feedback, and also action on it?

But more importantly, why are we excited about cognitive accessibility right now? And in the US, we know that cognitive accessibility is actually the most prevalent form of disability. We know that this is a growing number as well, just based on the number of people that we have aging. So we know that the number of people who are gonna rely on cognitive accessibility accommodations is only going to increase.

So on the screen, we have a chart of the US population in 1960s to 2060. And you can see how the number of people -- the age groups are gonna increase. And we also have just a population who are gonna rely on accessibility accommodation -- is gonna increase. So we think that this is a market that is going unserved.

We have a pretty large user base that needs to be accommodated for. And we haven't done a good job of accommodating for them so far. And we also know that this group is gonna continue to grow. I think one thing that really jumps out to me, when we see data like this, where, like, the population pyramid is almost flipping, it's bulging amongst seniors, is there are stats out there, and depending on the sources -- one in five or one in six people generally live with a disability.

But as you get into the over 65, over 70 range, you start to hear numbers like one in three. One in two. I think as we get into cognitive accessibility, as we get into aging, it's also important for us to start to be a little bit more flexible with that definition of: Do you identify as having a disability? Do you have a diagnosis for a disability?

Or do you experience cognitive accessibility needs? Do you want to just talk a bit about that, as we... Do you want me to jump forward? Sorry.

Did I get ahead? Yeah. I think you did. But we will come to it.

But I think it's a good point to keep in mind. How we categorize needs. And just the medical model of diagnosis. The social model.

We're very much big believers of a needs-based model. And so as we get into the space, we wanted to kick off a cognitive accessibility Working Group. Because it's gonna be the first time we're gonna be doing this. And we thought it was... Practice inclusive design, even internally, is how we go about any new initiative.

So we decided we're gonna have practitioners in the industry. So a lot of researchers that do inclusive research. We're gonna have individuals with lived experience of cognitive disability. We're gonna have subject matter experts as invited guests to live in the space of neurodiversity, clinical diagnosis.

Just to intentionally make sure that we're always having different perspectives. Because if we got into this just as Fable researchers, we're gonna have our own bias in how we build it out. And so we intentionally created a Working Group where we brought in different perspectives, and sometimes also conflicting perspectives. Because we wanted to make sure we debate out how do we want to define cognitive accessibility.

And what we did was: We have nine participants. Nine individuals who are part of our Working Group. It's a voluntary Working Group. And we divided ourselves up into multiple different Task Forces.

And the goal of the Working Group was threefold. The first one was: We wanted to really identify: What is the best way for us to recruit for the cognitive audience? What would be the categories that we would recruit? And then the second was: How do we do this in a scalable manner?

How do we collect insights from people, individuals, who experience cognitive disabilities? And collect insights in a way that is easily digestible for product teams to action on? And the third part was: How are we collecting those insights? What methods are we using to collect those insights?

Because the reason we introduced the AUS instead of just using the SUS was because the SUS was not working for this audience. We tweaked it to make it work for this audience, but after including cognitive, we need to make sure that our methods are also getting tweaked to support this audience, instead of just using general research methods. So those were the three goals that we had with the cognitive accessibility Working Group.

And we set ourselves a couple of milestones. We wanted to be able to... Just through our own research and process, we wanted to be able to share guidelines for the larger community, to be able to start thinking about cognitive accessibility. We also went through the process of updating our AUS to accommodate for individuals that have cognitive accessibility needs.

We're gonna be publishing our approach. And it's gonna be a perspective. And it's gonna be our way of approaching it -- obviously we're looking for feedback. And we're looking to see how we can improve this.

But for Fable, the goal is always: How do we do this at scale, so we can help many organizations truly build inclusive products. And the best way we know something is working is we give it a period of time where we put it out on the market. So we will include this in our Engage product where our customers will have access to this and they'll get to try it out and we'll observe how those insights are impacting the insights they're collecting and ultimately impacting the products that they're building.

And so we went through a lot of debate with especially I think this was -- Task Force one and two. Where we looked at a lot of literature, research papers, that existed in the market right now. And we looked at the medical model of cognitive disability. You have intellectual disabilities.

You have learning disabilities. You have traumatic brain injuries. You have dementia and Alzheimer's. You have neurodiversity.

There are various different ways individuals identify themselves within this group. And what we wanted to focus on was very much a needs-based approach. So someone doesn't need to be medically diagnosed. We wanted to make sure: Can we just have people self-identify specific needs they have?

And then based on that, we can recruit for them. So... And even within the Task Force, we were like... Okay.

How many groups can we create? So we had a lot of different groups. We decided we just need to start somewhere. And starting somewhere means we're not gonna capture every individual's needs.

But we're gonna capture the needs that we feel most confident about. And that's where we came across the three categories of... We're gonna work on individuals that have challenges with memory, challenges with recall, and processing information. We're gonna have individuals who have challenges with reading and writing.

So supporting users with text, comprehension, and communication. And we're also gonna focus on individuals that struggle with attention and focus. So how can we help design products that don't have you get distracted, but help you focus on the task that you're trying to do? And we thought this would be easy for an individual if they do... Whether they do identify as having a cognitive disability or being neurodiverse, we thought this would be easy for an individual to self-identify and communicate.

Yeah. I do have challenges with memory. I do have challenges with reading and writing. Or attention and focus.

And so this will be the three categories of cognitive accessibility that we would be rolling out. And then designing our methods based on that.

And I want to come back to... We kind of talked about the aging population and the number of people who experienced disability as they age. One in two, as mentioned. And we actually see a huge overlap between cognitive disability and needs and aging disabilities and needs.

Whether that's memory, attention, reading, and other difficulties, or just like navigating really overwhelming UX experiences. So there is an overlap, and we want to make sure that we're capturing that, as we enter this audience. And that's also what gets us excited. Because we have a rapidly aging population.

We have an aging population that also has been introduced to technology, and would want to continue relying on it. And we think that through addressing cognitive accessibility accommodations, we're actually gonna start catering to the needs of adults who are aging as well. So... One of the things of inclusive design is: Can you solve for one and have that impact be beneficial for a broader audience?

And we really think cognitive accessibility is well positioned to have a much broader impact on UX for everyone else. Those three categories -- are you distinguishing levels of severity? That's a great question. Do you want to just repeat the question?

Sorry. The question was: For those different categories, are you identifying levels of severity? We got asked similar questions when we started engaging assistive technology users of kind of like the skill level. Of using assistive technology.

And we haven't gotten to a point where we feel like we've needed to do that on the assistive technology side. There is variance of users. But if you're collecting feedback from a good enough group of users, on cognitive...

We're looking at it a little bit differently. We have to be a bit more intentional and aware of the full spectrum that exists across those different categorizations.

And I think it's important that... It's not just one person -- just belongs to one category. Right? They will belong to multiple.

But there will be one that they have more of a challenge with. So our goal would be to be able to capture... Okay. Which ones do you identify challenges with and which ones do you identify more challenges with as well.

For product teams, the thing that we learned is most important is the predictability of the insights. And so if you're working with someone with severe memory challenges, there are different types of insights you're gonna be able to collect, than somebody with... You know, maybe a light degree of memory challenges. So... Creating that predictability in our community for the product managers, designers, researchers, who use Fable, is where we're focused.

And it's a task at hand. And there's a curve ball here. That I think is exciting to talk about. And I want to show you about.

Which is: The intersectionality of barriers. And so... Here's an exciting little data point from an initial research we've been doing. So yeah.

We recruited -- I think about 25, 26 participants, as part of our pilot study. As part of the cognitive accessibility Working Group. And individuals in that pilot study -- 35% of them identified as using assistive technology on a daily basis. We talked earlier about how there can be a category of individuals that don't use assistive technology at all.

But we did still collect information on: Do you use assistive technology and what type of assistive technology do you use? And we did find that at least based on Fable's categorization of screen reader, screen mag, and alt nav, that there were individuals within the cognitive group that used those technologies. What was even more interesting was the next stat. Which is 84% of our pilot participants use AT accessibility settings, different types of cognitive tools, and assistive devices.

Folks have... What we realized -- when we were doing a test of our recruitment method, we engaged a group to see how they would respond to some of the questions we were asking. I remember when I asked one of the participants: Do you use assistive technologies? And their definition of assistive technology was different than what is typically understood.

We think about it as screen readers, screen mags. They were just referring to a couple of systems settings as accessibility. They were referring to some of the plugins that they had as assistive technology. So I think that also made us really reflect on... Just kind of broadening our perspective of assistive technology as well.

And part of investing in the cognitive audience would be for us to be able to capture: What do people just use for support? And that's kind of where we shifted our language to. And we got introduced to so many tools and devices that we also weren't aware of. And it was a really good learning experience for the cognitive Working Group.

And it's something that we're gonna take back to our community team to also look into. Yeah. I think the intersectionality of technology and needs is gonna be an area where we have to be a little bit more flexible in understanding the different ways that people choose to use their technology. And all of the adaptations that we use... And this really helps us come back to that foundational thesis around...

That the work we do here and how it expands beyond just those who maybe identify as having a cognitive accessibility need... Whereas now we can actually say... This overlap includes this notion that there is a reliance on some form of technology and tooling that's also baked into the experience. And that likely is coming in from not a thing that product teams control.

As a product designer, you don't get to control whether or not the users you're serving also have other things installed that are interacting with your product. And in the case of cognitive accessibility, we're finding that that's a lot more prominent than we expected it to be. What did you expect? What did we expect?

I think... I think it was more us just trying to find ways we could make this more... Make it easier to predict the type of tools and technology that people use. Because from a product team perspective, you know, as a designer, researcher, developer, you want to be able to have very clear guidelines of: Here are all the things I want you to consider, while building an application.

And I think it's opening us up into... There's a lot of other devices, plugins, that we have to consider. For teams to understand that this is a broader spectrum to kind of capture. So I think it's gonna be interesting for us as we take this to market, how individuals collect these insights and how they choose to action on it.

But I think for us personally it was... For Fable, it was a big moment. Because we started questioning a lot of our own internal processes. We looked at our community team -- did a deep dive of... Oh, actually, why don't we go look at our own recruitment process?

We realized... Our recruitment process had way too many steps. And this is not gonna be accessible for the cognitive audience. So we ourselves are going and changing a lot of what we built, because we're keeping cognitive load top of mind now.

But I think we're gonna go through this process and we're gonna help our customers. But... Yeah. It's gonna be a learning experience.

The thing I just wanted to say on this slide, as we kind of race to the end here, is that... It's absolutely critical that we work on cognitive accessibility needs. As part of the broader accessibility practice. At Fable, our goal is to get this into our product by April 1st in a beta stage.

And then more broadly. But we're gonna be publishing our learnings continuously. It's worth mentioning the AUS is Creative Commons. We'll be releasing a cognitive kind of version of it.

And ultimately, what we're trying to do is trust in a proven framework. Inclusive design has this foundational argument. Which is that if you pay attention to the unique elements of individuals, you develop processes, systems, to facilitate effective engagement of those individuals who are perhaps looked upon as being outliers. Those folks at the edges.

The impacts are gonna compound and be broader than the use case you're designing for. I think when it comes to cognitive accessibility, where is your feeling around how that is gonna ripple? Yeah. I think we're gonna see the most amount of broader impact with the cognitive audience.

And that's what gets me personally excited. When we completed our pilot study as part of the cognitive accessibility Working Group, a bunch of our researchers, we all came together to analyze the type of insights we got. And we kind of categorized them. Okay.

This seems like an accessibility issue. This seems like a usability issue. There were a lot of things that we categorized as usability. And one of the researchers was... But all these usability issues are general usability issues.

How are people gonna understand that this is also accessibility issues? And I was like... But that's the best part. For so long, we've tried to take a very segmented approach of like...

We do general... Gen pop research and then we go do accessibility research. And I think with the cognitive audience, we're gonna prove that by actually prioritizing research with marginalized communities, and prioritizing research with cognitive audience, we're actually gonna capture a lot of usability issues that are not even gonna be uncovered with gen pop research. So... Like, my personal goal that I'm kind of aiming for is that people actually start to put cognitive accessibility research as the first thing, before even gen pop, and just start to act on that feedback first.

We tried our best to keep that relatively short, folks. Thank you for your time and we'll pass it over. Also, Ben, Thomas, thank you. [applause] Thank you for the great work you're doing.

My name is Jose Garcia, Native New Yorker. I was just curious if you tried considering the organizations that advocate for disabled, either cognitively or physically. Because they often are very vocal about it.

Sorry. Just to clarify -- do you mean us engaging with specific organizations? Or end users for feedback? So... The government gives funds to non-profits that advocate for disabled communities.

So, for example, HRC in New York. Easter Seals and so on and so forth. Have you considered engaging -- because they're very vocal about these needs. Especially around employment.

Yes. So at Fable, we basically are constantly recruiting people with disabilities to join our panels. The way it works is they join us as contractors. They get paid for their time.

They get paid to get trained. Stuff like that. And generally speaking, our primary source of being able to do that recruitment is through partnerships with a bunch of non-profits, right across Canada and the US right now. And moving into Europe in the summer.

Yeah.

All right. I'm gonna pull one from online.

Let's see. What are the best practices for making tech documentation more cognitively accessible. That's a small question. Let's just tackle that in a minute.

Yeah.

That's a very specific one. Honestly, if you figure it out, let us know. Because we have a lot of that as well. By documentation, I mean manuals and so forth.

Yeah. Yeah. I think that's something that we have to get into testing it. We're actually going to get into it, as part of our cognitive audience onboards onto our community platform and recruitment platform.

Because... We have a lot of documentation. And onboarding courses that our testers do. So our team is actually actively looking at how to update our own documentation.

So... Yeah. We can follow up there. The stuff we're doing as we delve into it so far... Involves multiple modalities for everything.

So terms and conditions, there's an FAQ version, there's a video version, so... Multiple modalities is foundationally a good practice. Like a choose your own adventure to the mechanism that you best understand. And giving that agency to the users.

It's a piece we're working through right now, as we get ready to onboard a bunch of cognitive accessibility research participants. Awesome. I see other... Other great questions online.

That we're not gonna be able to get to this evening. But please do throw them. We've captured them here. But yeah.

Please throw them into the Meetup chat if you have more. We'll figure out a way to follow up with those. And I just wanted to add that we are gonna be sharing some of our learnings from the pilot. So that'll also be something that people can refer to as guidelines.

Yep. And thank you so much for Thomas and Ben for having us here. Really exciting to be back in New York. It's great that you have a community that comes together.

So... Also thank you for everyone who attended online.