Accessibility experts Lori Samuels from NBCUniversal, Abid Virani from Fable, and Lukas Simianer from Clusiv discuss the best strategies for ensuring accessibility as your journey matures.
Event sponsored by the Bureau of Internet Accessibility, Monsido, Verbit, AccessibilityWorks, Clusiv, and QualityLogic.
You need permission to access this content
You must have an Event-Sessions account to proceed.
Access to this area requires a sign-up & login that is separate from individual events registrations. You must use the following link Register for access now to receive a password-setup email from us.
NOTE: A single login provides access to all of our Event Sessions.
How Do You Know You're [Still] Accessible Panel Conversation
Transcript for How Do You Know You're [Still] Accessible Panel ConversationLori Samuels
Well. Hello, everyone. I'm Lori Samuels. I'm the Senior Director of Accessibility at NBCUniversal. And I'm excited for today's conversation about how to make sure that you you learn about how to stay accessible and maintain accessibility over time. So how do you know if you're still accessible is the topic we're going to be discussing today. So and I turn it over to our fellow panelists here.
Luke, do you want to introduce yourself?
Yeah, thank you. Thank you so much, Lori. So my name's Lukas Simianer. I am the CEO and Founder of Clusiv. We are the world's first e-learning platform built for and by people who are blind.
Abid. There it is. Hey, folks Abid Virani from Fable and COO and Co-Founder at Fable. And what we focus on is helping companies practice inclusive product development. And we do so primarily by connecting people with disabilities to the folks who are responsible for building the digital world inside of large companies. Excited to be here. So to have this conversation.
Fantastic. All right. So we're kicking it off. Maybe we could start by saying what does it actually mean to be accessible? We're talking about digital accessibility here. So websites, mobile apps, digital content. So what is what is accessibility really mean if we're trying to maintain, to achieve a certain state of accessibility, are we talking about compliance or are we talking about something else?
So just want your thoughts to start on that. What are we thinking about when we say “accessible?”
So I guess I'm happy to go first on that. Yeah. Um, to me, I like the way you put it. Are we talking about compliance or something else? And like within Clusiv, we even have a range, right? There's compliant, there's, you know, notionally usable and then there's actually fully usable, right? Like a wonderful user experience.. 12 out of 10.
And in America, our legislation only covers compliance, right? It doesn't cover usability. But I have like an analogy I really like to give with that when I'm explaining this to people who aren't in the accessibility space or just engineers. And I like to say that, you know, accessibility is like a store having a wheelchair ramp, right? And it may be at a 90 degree angle. Like only Arnold Schwarzenegger can wheel himself up
that thing, right? Usability is where that wheelchair ramps at a 3% grade, and everybody can actually use that to gain access to the store. But right now, only the fact that a wheelchair ramp exists or needs to exist is what's regulated. And that's that's where the gap falls.
Abid, what are your thoughts on that? That’s a great analogy.
Yeah, I do like that. What I do worry about, though, is about the framing of kind of achievement and maintenance. Like I do think... I think it's still relevant, but I wonder about how security matured as an industry and what does it mean to be SOC 2 compliant means to have, you know, a certain amount of policies in place, controls in place to ensure those policies are being followed, and a process of reporting on those with evidence.
And and I think that the spread of what happens in security is more like accessibility than we sometimes talk about. And what I mean by that is that no company can be 100% secure. It just doesn't exist. It's an impossibility. And and I do think that it's impossible to be 100% accessible. I think we are downplaying the the nuance of accessibility if we think that's achievable. It's changing too quickly.
And we're just not in a place where we can keep up with it. So in that case, I think I think being accessible as an organization has more to do with how do you approach building product? What processes and procedures do you have in place to ensure that? And then do you... do you have ways - do you have failsafes in place to to adhere to that?
Even when you do have 50 new people join your engineering team and maybe a handful of people leave your design team... Is there is there enough in motion so that as an organization you can still maintain your accessibility practice? At that point, I think there's different grades of whether you are trying to get the job done versus you're trying to use accessibility as an innovation strategy.
But broadly, I really do think it has more to do with the process than it does with the status.
Now I think that's a great point. And just for folks who might not be too familiar with with accessibility in the digital space - website accessibility, mobile apps, etc. The compliance we're referring to here refers to compliance to the established Web Content Accessibility Guidelines which have been evolving over time. As the Internet has evolved. We're going to see another evolution of of those standards which are used internationally and which tend to be the basis by which, you know, litigation or legal compliance is kind of looked at through that lens.
So so there is a set of standards out there. The standards, you know, are useful because they point out a lot of very basic, important things, you know. So there's a usefulness, in my opinion, to the to the WCAG or Web Content Accessibility Guidelines. We certainly don't want to throw them out when we focus on usability because they can help us get to that goal.
But in my experience, what I've seen is that organizations that chase compliance as a goal are endlessly chasing that goal and never actually achieving it. To your point, Abid, that it's similar to, you know, can you be 100% secure at any given moment in time? Frankly, probably not. Similarly, with accessibility, at any given point in time, some random day of the year, you may not be.
So if you're chasing compliance, it's almost like you're always trying to catch a train that's ahead of you. You can't quite get there. But if you're integrating accessibility practices and feedback into your development, into your design and development lifecycle and processes, then you can achieve a greater degree of usability. And usability, specifically for people with disabilities who might be interacting with that digital content in a different sort of way.
Right? They might be using a screen reader or they might need to magnify the screen, or they might not be using a mouse because that's not what they're, you know, they might be using voice to navigate or they might be using a standard keyboard or an adaptive keyboard. So there's a whole host of the way that people can interact with technology and digital content, which is what accessibility is really all about.
So just kind of think about this a little bit more. There has been an increased awareness of the importance of compliance, whether that's driven through, you know, litigation or other factors. So we do see an awareness of of accessibility and compliance growing year over year. But we're also seeing an increased desire to have that outcome of usability. So so how how do we as a company or an organization prioritize usability as a standard, as sort of the gold standard for accessibility?
How do we actually go about trying to do that? Thoughts on that?
Luke? Or Abid?
You want to go first on this one?
Yeah, sure. I mean, I think what's really exciting is, is that by focusing on usability, we can actually not separate accessibility from the rest of the product development lifecycle. I think that's probably the the best part about that shift. And I think it's it becomes about how do you ensure that your approach to designing new features and new components and shipping more products, just considers a broader and more diverse group of users.
And it depends how far you want to take the argument. You know, the extreme end of the argument to kind of make the point would be that if you actually only kind of focused on the requirements and the needs of folks who use assistive technology or who have a harder time navigating websites or folks who maybe have English as a second language, and yet it's an English language website.
You know, if you focus on this group, you end up with a product that is probably more personalized, more adaptable, and that ultimately has a huge impact on everyone's experience of using the product. But in terms of this, the more common first step to take, it's we already have research practices and design practices and and quality assurance practices.
It's about how do you integrate and consider some parameters and and use cases that maybe haven't yet fell into the requirement building process. And at Fable, like we firmly believe that the reason that that happens is because our product teams often look quite homogenous in comparison to the broad audience that the products are actually serving. And and it's hard in today's world for someone with a disability to get into a rapidly changing organization in the world of tech and get through the HR processes, get through the onboarding, and and actually be able to use the, you know, 200 subscription tools that we all have to run a digital team. And so it's... a voice is missing
at the table and it's due to a bigger, more systemic problem. But finding ways to get that voice involved at different stages of the product development lifecycle is, is what we think at Fable is kind of the key in the hack code to building an innovative, personalized, customized, adaptable product that meets the needs of everyone.
Yeah, I would I would sort of continue on that you know, I think that one of the advantage of, of an emphasis on usability or usability as kind of the end state that we're after is that as you're seeing product teams, digital product teams are typically already very aware of that as a goal. They understand that. Of course you want to build a product that people can use.
Everyone has that goal. So what we're trying to say is, yes, and accessibility, usability is a part of making sure that actually the one in four people with a disability out there that you may not have on your product team, you know, also need to be able to use this product and enjoy its content. So so that's it's a familiar goal, whereas compliance is an abstract goal, right?
It's an abstract one that many people might not be directly familiar with. What does it mean to be compliant and who tells you if you are? So there's other issues with that. Luke I just wanted to hear your thoughts on that.
No, I was I was beating the drums while Abid was talking through that because, you know, 65% of Clusiv’s employees are blind or low vision. Prior to a recent engineering sprint, it was 85%. Right. And we're one of the fastest growing startups, and that's like super exciting, right? We drink our own medicine, if you will. But I've been doing a lot of research in the space, and Abid, as you put it right, like it's a process, right?
It's a process that we have to look at. And I would say, like the research I've been doing recently is on the growth positions. Right? And how new that title is. Right. I mean, we're talking 2008 and on is when you first start to see like the word growth used in a title. And what's the why of that?
Well, it was a bunch of startups, got a bunch of money, and they put all that into marketing and they're like, we need this to tie to revenue. Oh, man. Okay, we need someone that knows marketing and kind of rev ops. Okay, what is this? Growth? Boom. And so they created a title and I think that in engineering companies, right, like where I got inspired to even start Clusiv... in my first engineering job, you know, people don't give usability and accessibility the credit it needs.
It's a person. Like you're not going to get around that. It's a person. If you want to strive for even 80%, 70%, as you said, I don't think 100% is necessarily feasible or necessary. It's a person. You should have, if you want to make sure your website is really or your app is is a great experience for someone who's blind.
You're not going to get around hiring someone who is blind to help be a part of your product team. And that is why at Clusiv, when we launched our product and it's taken off with great validation and great reviews from the community itself. That would not be possible were it not for the hands and and spirits of many, many hard working blind people at Clusiv.
Yeah, I love I love that framing. And I think it helps us move closer towards this acknowledgment of of why the compliance mindset can leave a lot of great opportunity on the table. And and it's because, you know, when let's say if you're, I don't know, like an outdoor, an outdoor associated shop. Right? And and yeah you can work to get your website from 90% to 100% on the compliance metrics.
Right? On the other hand, it might be more meaningful to start selling adaptive wheelchairs and making them available on your 90% accessible website. And that's, I think, a big part of this of or making it easier to find adaptive items in the shop that can work effectively with one hand. Like there's there's a there's a focus on the person that can really unlock opportunity.
And I and I don't think that sheer compliance mindset does unlock opportunity. And I think that's why we're seeing leaders like Spotify and Shopify and Microsoft, of course, investing in that full cycle of understanding who's on the other side and what are they trying to achieve and how do we make that easy to do and to get there?
And that it's sometimes okay to have in a minor issue that a user can work around 95% of the time. So that we can have the bigger, meaningful, impactful thing that that user actually needs as a service or as a product or otherwise. But yeah, I just think, I think the individual, the person, that's where the focus has to go back to.
Because that's such a good example. Like maybe it's not some crazy engineering investment? It's did you offer like, you know, an accommodation or an accessible device or an adaptive device? Like... what, what shows the most empathy and understanding towards your customer? And that's you know, that's a it makes me think of like I'm going to bridge here, but like the Patton quote, right?
He's like, you know, “the best plan executed next month is way worse than the worst plan executed tomorrow.” At 90%, do the thing that's empathetic and, you know, leads to better, better usage. But I like that a lot.
Yeah, go ahead.
I was going to ask you, you know, like you're in the size and scale, like you have to think about accessibility.
It’s... it must be a harder process of prioritizing the user because the scale naturally gives need to some formalization and standardization. And, and I imagine that using WCAG is probably an effective beginning point, but does it...
It's a really interesting question I was going to kind of touch on, you know, how do you do this at scale with really large organizations and lots and lots and lots of teams? You know, how how do you figure this out? And I do think this is actually where it becomes because I've worked in very large organizations at Microsoft, Intuit, now NBCUniversal. And and what's interesting is that it in some ways you do need simple goals when you're dealing with large numbers of people and you're trying to move the needle.
And one of those simple goals is, can a person with a disability use this website or not? And so I actually love kind of capturing it in simple terms, and I would much rather see the cultural and process shifts that you're talking about start to happen and teams begin to practice accessibility, albeit imperfectly, maybe at first, then to get then to get a, you know, a formal WCAG audit done of a large website and be handed, you know, 500 to 800 bugs.
That is a completely overwhelming and very negative experience for the product team. So I think there’s a... I think there’s a more rational and motivating way to to do this. To get teams to begin. Because really what you're trying to do is get teams to change behavior. Right? Ultimately, we're doing organizational change management. We're telling you, please do something differently than you've always done it.
And and by the way, you need to learn some new skills along the way. So yeah, so I think, I think a couple of things are really key. One, bring, you know, bring training to the table so that you're not asking people to do something that they don't have any idea how to do. Right? You have to give people some basic skills to begin practicing.
Also, I'm a big believer in shrinking the change, which is don't make it overwhelming. Figure out a place to start. And incorporating feedback from people with disabilities as we're doing with Fable is a great place to start. Learn how people use screen readers. Learn how people use keyboards and other kinds of switch devices to navigate a website. Understand that better. First, start that learning process for yourselves on the product team so that you can then take that into account as you're beginning to design or implement your next features.
Also, I think... So, I mean, so a lot of it is, is really making sure that our our North Star is usability. But I want to talk about the importance of not throwing the compliance standards out the door either because they actually are very useful. So I want to give the impression that all we're doing is going to get some feedback from people with use-, with disabilities or, you know, AT users.
We also need to pay attention to the standards. Because there's there's a ton of great information in there. There's a ton of great well developed guidance that also needs to be incorporated into our our processes. So I think that's an interesting question, is how do we incorporate both? I mean, I, I wouldn't say that necessarily any one organization has all the answers to that.
I do think that at times a a standard audit is a is a helpful place to start. So what I would suggest, though, what I found to be helpful is to take a small scope. Take a small representative scope. Just get some of the basics figured out. Like if your site can't be navigated at all with a keyboard, well, go fix that first.
You know, if you haven't labeled your your interactive elements or all your graphics are missing alternative text... Do some of the fundamental cleanup that is the sort of the hygiene of accessibility. Get some of those basic things done on at least a representative scope of your product, maybe some of the core flows into it, and then start to immediately and then start to get user feedback.
I think that's a good cycle is, you know, you don't necessarily want to put something that's completely broken in front of people, but you also don't have to chase that perfect compliance goal. So use the standards as a starting point. Do, and I would even say that there's a subset of standards that are particularly impactful on the user experience, which is somewhat of a radical thing to say.
But I still believe that. That there's a there's you have to have a starting point. So I always kind of start with my top three are color contrast, keyboard accessibility, and proper accessible naming of elements on the page. Once you get those three under your belt, there's a lot more that you can start to work with and work on and improve.
So thoughts on that?
I'll just tell you my favorite thing when I'm trying to introduce a notion of of these standards to folks. I find the buckets that the standards are in quite effective. And I especially find myself, if I'm with our product team at Fable, talking a lot about predictability. And as a as a UX principal and being able to explain how the work you're doing towards accessibility actually is improving the experience for everyone,
I really do find that predictability is just really effective poor construct. To have a conversation about directly ties to what a lot of the compliance standards are trying to achieve. And I find that to be... honestly even just I just think it's a great product practice to ask yourself whether your UX patterns are being reused in a way that folks could feel like it's intuitive, but it's not actually intuitive.
They've been trained on the UX patterns by using your product and and you're training them how to use your product effectively by using something consistently. So yeah, I just love that as a framing and I totally agree with you. They’re a good starting place and they have a lot to offer for different cultures and different teams. And you got to kind of choose how to navigate compliance into your own product organization.
Yeah. I second that. And I think the, you know, the foundational level can't be overlooked, right? You don't build a house on a swamp for that exact reason and you shouldn't build a software company without understanding the compliance, whether it's around security, data privacy or accessibility. Right? And they should be held that same regard. Um, and I think that, you know, we've seen, we've experienced some really interesting use cases at Clusiv, right?
Like, as I said, we're built for and by the blind. And we sell on to state agencies and train blind people to be accessibility analysts themselves. Right? So we're literally training people to go help solve the problem and deploy to companies, right? Get jobs at big tech companies and help, you know, make their usability much, much better. But we have a VOC rehab counselor enroll a student who is deaf and on the spectrum.
Right? Because they serve all sorts of clients within their state agencies. And, you know, obviously our coursework is not designed for that. But we ended up getting an email about three weeks later from someone. And this is our professional skills course. All the things you need to do to hold a remote job, right? Using assistive tech. And they’re like, “man, I loved the course. I learned how to use Zoom. By the way, what the hell's a screen reader?” [Laughs.] And that was all, that was all the email said. And I was like, Whoa. Our design worked to really communicate language and navigation and these pathways to someone who has just never really been able to grasp any learning platform before.
And we got a funny email out of it. We've now used our design to expand into a whole different area. We're not just serving the blind and the low vision population anymore. We're creating financial literacy and Internet safety courses for everybody in these systems. And that wouldn't be possible without the one, the foundational standards of 508 and WCAG and two, engineering with empathy.
So I think that, if that doesn't paint the dream picture for any company like whoa, that's a huge a whole other market I could tap into then it should.
So we're kind of talking about I mean, I love all of that. And, you know, designing for, you know, intentional design in general typically works better, right? Any time you're being intentionally inclusive in your design, I should say, you're going to end up having some unexpected benefits. We, you know, we refer to that as the curb cut effect in times of you know, products that were designed with with disability inclusion in mind end up having these unintended but but they're very beneficial usability for everyone as it turns out.
Just as, you know, wheelchair ramps have the benefit for people on bikes or pushing baby strollers or dragging luggage behind them, you know? So to that point, thinking again of kind of at an organizational level, how... One of the challenges in accessibility is what are the metrics? What's the data that really feeds into this system? Let's say you do get it to the point where you've prioritized accessibility.
You're you're integrating it into your design and development and quality processes. You know, how do you measure your results? What's the what's what are the benchmarks we're looking for? What are the metrics that we're looking for to help us along the way? Because you have to know, especially at scale, you know, how are you doing? How do you how do we assess how we're doing?
What are the mechanisms that we use for that?
Yeah, I think, I think we're going to have very different answers on this one, Abid. You want to go first?
Yeah, sure. Yeah. I mean, you know, we we've been building an opinion on this for a while. And and the first thing I'd say is, start with evaluating how far along this journey you are. Because it's the metric you should measure should be right size to what state you're at in approaching accessibility. I do think that the compliance component thing is great to evaluate every six months or every year.
I think that there's some stuff that we should evaluate much more frequently and it should have a low bar. Like can someone do the thing? So if it's sign up, if it's complete a purchase... These types of flows should be evaluated more consistently on the basis of can it be done? Not is it perfect. Even if there's ten issues along the way, but or did someone actually have to leave because they couldn't figure it out or couldn't complete the flow?
So completion is I think completion of critical flows is one of the most important things to measure. I do think if you're at a place where you're you're doing well on completion of all your critical flows, now we should start thinking about measuring the quality of the experience. And that's where we get into, you know, asking, asking questions about ease. Asking questions but confidence. Asking questions about time to learn or feel familiar.
And and I think that some of the work that Fable’s done in developing benchmarks, like the accessible usability scale, is for this purpose. It’s how do we measure the quality of the experience? But I do think that those are you have to right size what you're using to measure at the right time. And beyond that, I think how how engaged is your team in terms of their conversation and learning around accessibility?
So this is this is a light one, but I think it's really meaningful to know if if a lot of folks are on your Slack talking about accessibility. Or just how many folks are engaging with content that you've provided to them that is available for them to check in on if they're doing something right in in the framing of accessibility.
So some sort of metric on the on the team side is really important as well.
Luke, what are your thoughts on that?
Yeah, our answers honestly aren’t as different as I thought, Abid. You know, you've done a lot more of helping these big companies really integrate this stuff. But it's actually it's cool to hear that we're actually pretty closely aligned, you know. The only thing I would really add is, you know, one of the tests that we have at Clusiv that is my absolute favorite, we call it context free. And we'll change the name of a Testflight app to thing one. And you know, when you when the the the test group goes through this, which by the way, if anybody needs help recruiting test groups of blind, low vision individuals, I have the kind of the cheat code here right? So hit us up.
But you know, I want to know hey, you went on thing one, right? The app. And you know nothing about what's supposed to be on thing one. Could you navigate all the way through? And when you, when you do your recorded video response, how do how much do I like what you're saying about it? Right. I want this to be a learning app that teaches you critical skills X, Y and Z.
And you're like, Well, I learned how to cook. No, no, no, no. We missed the mark completely. Right? Because they didn't get the full context. Right? Whatever we did, whatever layout we used, it limited their their use of it to this was through... And so when someone comes back to us, you know, on version two of thing one, right? Then they're like, man, there's like three courses in there.
And I dove into each one. You could navigate between the panels. It's really cool. Then there's an ability to, you know, request this training and and follow here. And, you know, they give you like a full layout, almost like you're talking to your UXer right? And it's like, okay, we killed it. We knocked it out of the park.
And I know this too, because we've launched two products, one of which, you know, the contextual testing wasn't really... it was very, very narrow. People could understand one or two things. On the second launch of this thing, we had some great feedback. Like the second example I gave and the adoption was just, it was almost insane.
It blew what we were expecting out of the water. And so I think things like that for, you know... But the point is nothing replaces having actual people with that disability represented. Right? And don't be afraid to reach out looking specifically for those people. There's state agencies, there's companies like us and Fable. There's a million and one people who just want to help you build the best thing.
Now, that's the encouraging thing. I think about where we're at now with with you know, at least in the years I've been doing this, to really see this engagement and participation. And it's such a collaboration to have people with disabilities participate, you know, as it should be in the process, provide that feedback. I think, Abid, what you mentioned about the accessibility usability scale and there are quantifiable ways to to measure usability.
So I think that's that's something that might be a little bit misunderstood. Is that it is possible. ISO’s developed standards around usability, what we consider with ease completion, like you said. Difficulty of task. So we can measure this. So I think that's the good news is that we can measure usability. Interestingly, I think to some extent compliance is somewhat harder to measure.
It requires essentially an outside expert to tell you whether or not you're meeting these these particular standards, which are subject to interpretation. Let's let's be real. Right? And so there's nuance there. And again, I think back to chasing the compliance goal, which can be difficult. A 90% compliant experience could have huge usability barriers in it. You know? That 90% can sound good on paper, but it can actually mean that someone can't get through the most basic task on your website or get to the thing that matters the most, or pass the sign in or whatever it might be.
So wherever that 10% issue is might be really problematic, which is why I think that that compliance goal itself can be can be difficult. But I wanted to I wanted to ask another thing, which is some of what we're talking about here, integration into processes, making sure there's a steady feedback loop from from, you know, user base with people with disabilities.
We're talking about driving greater maturity into the organization ultimately. Right? Ultimately, we're after a mature systainable process that that will weather the you know, the fluctuation of who which experts are happened to be in the room at any given point in time. Right? Because we might lose. Oftentimes what happens in a company is you you've got a couple of people who know a lot about accessibility and then they leave, youre like “no, don't go!”
And and so how do we you know, how do we kind of build that maturity out, put a small plug in, not because I was on the working group, but that the W3C has published a draft of the accessibility maturity model. A lot of very smart people were involved in kind of building that out. And there are proof points there's the, you know, kind of what you look at holistically, not just in terms of like is this particular website accessible? But are you sustaining the practice of accessibility and usability in your organization?
So if you're not familiar with that, go check out the W3C maturity model for accessibility. It's a good, it's a good draft form.
And I wanted to add onto that, too, that there's, there's plenty of amazing examples out there that are shining stars of you can of how you can be 100% compliant with every regulation and everything out there and still have a completely unnavigable, unusable website. If you'd like an example of this, you could go to USA Jobs, right?
I mean, that was an expensive website that has been built and it's obviously 100% compliant because they wouldn't you know, the contractor who built it would not have gotten the release that if it wasn't. But if you ask anybody, you know, even a fully able bodied person to navigate that, it's it's a it's a journey. So there's... I think it's just so critical people think those silos... They're both important, but they're also separate pieces of the pie. You can't have that trust without feeling, right? And if if we're going with the pie analogy,.
Really. I think we've also all seen examples of where there's fundamentally a usability problem and then you try to make that fundamentally somewhat unusable experience accessible. And it's like, well technically we could do that. But it's like our friend Jared Smith over at WebAim says it's, like putting lipstick on a pig at that point, right? You've got something that isn't working well for people, anyone really.
And then you try to make that accessible. So, so that's an interesting one because the accessibility people in the room will be like, well, you know, I guess if you put some labels on it and you can navigate with the keyboard, that might sort of work. But, you know...
That spinning, spinning image that is a website. Like well we put an overlay on it. So it's good. Yeah.
Yeah. I think... I think one of the most important things Lori, when it comes to that longer term kind of approach and way of thinking. And I think part of the spirit of the W3C recommendations around not just the maturity model measurement, but even just the the role focused objectives. I really think the most critical thing we can see is just as this real buy in to this notion that this is a distributed responsibility.
And I think what's exceptionally tough about that and what we see as being really tough about that is where folks who have worked really hard to become knowledgeable in the space, the ones who are really achieving great success are the ones who are okay with the imperfection of the progress that gets made in accessibility. And and I do think that that is, again, like quite similar to the world of security and privacy, where I think the leaders in those spaces know what the best practices are.
But no organization starts by being in the best practices and, and being okay with the distribution of work and the imperfection of what's happening or recognizing that the spread is improving, the broader impact is increasing and the buy in is getting there, really does, I think, give an organization the best chance for success in the long term.
Oh, I agree. I've always felt that it's a combination of of grassroots work and the way that you get people excited about wanting to learn more about accessibility and wanting to do better in accessibility is to have that human connection that you mentioned earlier, is to recognize that you're you're talking about something that affects real people and can make the difference between someone being included and part of the experience that you're trying to share or excluded and on the outside of that and feeling that exclusion.
So, you know, nobody wants to exclude anyone. It's not it's not starting out with any intention to do that. Largely, and unfortunately, there's still too high a lack of awareness of what we need to do differently to make sure we are including people, everyone. So so that's where, you know, the learning curve is still there. I mean, obviously, we'd all love to sort of solve that problem further upstream. As to say you shouldn't actually come out with a degree from a university if you've never heard the word accessibility and you're about to build websites or mobile apps or do engineering, right?
You should learn that engineering with empathy or designing with empathy, way earlier in your career, you know, which is which is another big problem to solve at a systemic level. But yeah, so I mean, great discussion. I'm trying to think kind of wrapping up a little bit. What would what would sort of be your key takeaways or advice, key points you'd want to kind of close out with. Just thoughts to share with folks who are trying to drive, you know, further accessibility and usability in their organizations or perhaps sustain the momentum that they've already achieved.
Let's either one of you feel free to take that. A couple of takeaway points for folks.
Yeah, I, I would say, you know, the my biggest thing that I always try to hammer on wherever I go is that making your website, making your business accessible and usable is not just the social good, get a Boy Scout badge, do a thing. If you're a public company and you have, you know, an obligation to your shareholders.
I get it. Accessibility can sounds scary to implement. It's a big thing. But here's the truth. If we talk the blind population alone, you're 7.6 million Americans, right? 46.5 million people globally. And that's an underestimate by a good measure. Right? How much would you pay your marketers to get access to that size of demographic? Like, let's be real. This is an economic opportunity that you are robbing your shareholders of if you're not becoming accessible and usable.
And so let's you know, yes, you get a Boy Scout badge, too, because it's a good thing to do. You're being inclusive. But let's not forget what you're leaving on the table. My other my other piece here would be, you know, this has been an awesome conversation, honor to be a part of it. And a pleasure to meet you both.
You know, there are companies like Fable and Clusiv and many, many others that genuinely, whether you're buying our product or not, are happy to to spill some knowledge on how we've built what we've built, not to speak for you, Abid.
You know, we do, though, and we love talking about how we built our product. Yeah, yeah.
We're on the same page with this. We love what we do and we, you know, we're here to help, you know, and yeah, we productize that, but we can help with our brains too. So yeah. Thank you all.
Fantastic. Abid? What are your thoughts?
I think one of the one of the principles of inclusive design paraphrased is one size fits one. And I just think it's really important that we keep that in mind for organizations. And and so, you know, I think this is a very common approach to tackling accessibility has been to get caught up and then to start thinking about maintenance.
And I think it's a really meaningful thing to challenge that idea. And at some organizations, the code base is changing fast enough and frequently enough that it might actually be appropriate to start by figuring out what are we working on today that has business value? That means a lot to the company? And how do we make the next feature we release more accessible than the last feature we released?
And if if you start with just starting to ship new things that are accessible, you are going to make a tremendous amount of progress and it won't feel like a distraction to the team and to the company. And it's just something to have as an option. You don't always have to start with the backlog and sometimes depending on the pace of your code base update, it actually might be the fastest way to become closer to that full coverage just by focusing on what's new over the course of 18 to 24 months.
So I just think one size fits one. If if you heard about a strategy that worked on one organization, don't assume it's going to work for yours. Consider your culture, consider your team, and and take one step at a time.
Yeah. I literally love that so much. You know, this is software, people. It changes all the time. We aren't, we can't be, we can't be way back in the backlog. We've got to be out in front of this. And absolutely agree with that. Challenging those assumptions that you don't necessarily want to go to your big, you know, your biggest, you know, high profile things that are aren't even changing that fast.
Maybe maybe the better thing to do is to start practicing on something that's new, fresh. We always say that's the easiest time to do accessibility because, you know, just like, you know, I mean, if the analogy in in the built environment is that if we were all in the business of pouring concrete and we kept forgetting to, you know, put the wheelchair ramps, the curb cuts in, you know, it costs a lot of money to bring the cement truck back, to to bring the jackhammer crew out.
It probably isn't really the best result, actually. It's not as designed in. So it doesn't isn't as smooth a ramp as you know? But if we can, you know, pour every new sidewalk with those curb cuts, then then we're starting to do it right. We're learning how to do it better. And so, yeah, I mean, my takeaways are accessibility is not a project with an end date, it's a process.
It always is. And it's a it's a cultural change that's happening in terms of people's behavior, incorporating an awareness and an an intention towards towards a set of requirements for usability of people who interact with content a little differently than you might have known or imagined. It's a simple as that, but it's obviously there's a lot in that iceberg underneath. And that is progress over perfection, as our friend Meryl Evans likes to say. That it's it's really about continuing to keep that learning curve going, looking for those opportunities.
That's very aligned in my mind with the agile, you know, manifesto of, of, of, of continuous improvement, right? We're always just looking to improve. So where are those opportunities to do that with accessibility? So yeah, those are my little gems which are mostly borrowed from other people, but, but it's a lovely discussion. Thank you so much. I hope this is what everyone came for, but.
Thanks so much. This is great.
Awesome. Thanks, everyone.
Click on any of the file-links below to open or download.
You could also Right-Click and "Save As".