Host Mike Paciello and guests Becky Gibson and Leonie Watson discuss winning approaches to deploying accessibility across businesses and why it's a good business and financial decision.
This is the third and final event in a three-part series on Design, Develop, and Deploy for Accessibility.
The first event, Design for Accessibility, can be viewed on demand by clicking this link.
Second in the line-up is Develop for Accessibility, which can be viewed on demand by clicking this link.
Mike Paciello of WebABLE hosts each session and brings old and new friends to the conversations. Travel further into the world of accessibility with subject-matter experts with outstanding professional and personal backgrounds in accessibility.
Mike Paciello is the Founder of WebABLE.
Becky Gibson is the Lead Accessibility Specialist of UKG (Ultimate Kronos Group).
Leonie Watson is the Founder of TetraLogical.
Event sponsored by the Bureau of Internet Accessibility, QualityLogic, AccessibilityWorks, Clusiv, and WEBAble.
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.
If you already have Event-Sessions login credentials, please login now
or Reset your password (opens new window) if you have forgotten it.
NOTE: A single login provides access to all of our Event Sessions.
Deploying for Accessibility Panel Discussion
Transcript for Deploying for Accessibility Panel Discussion
Hi everyone. Welcome to day three of Accessibility.com’s DDD Series, our three part series on Design, Develop, and Deploy for Accessibility. Tuesday we had Design which is now available on demand on our event page, if you'd like to catch up with that. Develop is also available for viewing on demand at our event page. And today we have Deploy.
We are bringing back our friend and host Mike Paciello of WebABLE. And along with him is Becky Gibson and Leonie Watson. Feel free to use the chat to have a discussion amongst yourself. Any questions you want them to answer as they go through, go ahead and type in the Q&A. The event is recorded and will be available on demand sometime this evening.
You'll receive an email from me with a link to the event. And on that page you'll have the transcript, the video and any other supporting documentation the panelists have provided us or something that we felt that you need. So here we are, the final part of our three part series on Design, Develop, and Deploy for Accessibility with Deploy for Accessibility featuring Mike Paciello, Becky Gibson, and Leonie Watson.
Hi, this is Mike Paciello with WEBAble and Accessibility.com. We are in the third part of our segment on accessibility: design, development and deployment. Today, I'm happy to be with a couple of close friends and colleagues that I’ve worked with over a number of years, Becky Gibson and Leonie Watson. Why don’t I have them introduce themselves. Becky, could you introduce yourself?
And where are you from and what are you doing?
Great. Thanks, Mike. Yeah. My name's Becky Gibson. I'm currently at a company called UKG. It stands for United Kronos Group. You may have heard of them as Kronos or Ultimate Software. They merged recently. I'm an accessibility specialist there. I've been working basically trying to help them update their accessibility plan and their strategy. I've been in the industry 20 years.
I spent a major part of my career at IBM as a developer. Then I focused mostly, all, on accessibility. I worked on the Web Content Accessibility Guidelines. I call them WCAG 2.0 as well as the ARIA spec. I also spent some time as a accessibility consultant with Knowbility. So I worked with different clients that way.
Excellent. Yeah. A long, storied and yeah, storied career. Becky So it's it's great to have you with us today. Thank you so much for joining us. Leonie. I imagine that you and I have known each other for at least a dozen or more years, probably closer to 20. But you want to tell us what you're at, what you're doing, and and give a little background to to to our audience.
I will do. Thanks, Mike. So my name is Leonie Watson. I'm founder and one of the directors at TetraLogical, a UK based, accessible consultancy. My Life on the interwebs began a horrible number of years ago. I started off as a web designer back in the mid nineties. Lost my sight around the turn of the century and got bitten by the accessibility bug not long after that.
So I spent 20 mumble something years working in accessibility, as Mike just mentioned, a good number of them with him and the team at the Paciello Group before I set up TetraLogical. And I've worked with a lot of organizations through that time to help them find really practical ways to implement accessibility and deploy it. Because often, as I'm sure everyone here will agree, it seems like a huge and unachievable task and breaking it down to make it practical and achievable is something that interests me.
Yeah. Thanks, Leonie. Yeah, there's... There's an awful lot that goes into building a mature strategy within an organization. But as I mentioned at the at the outset, our focus today, the third part of our segments is to talk about deployment of accessibility. And so I thought with having the two of you on, you both have been very experienced, have worked in in organizations where deployment has been a critical attribute of what you do and the work that you've contributed to other organizations.
Let me start off with the first question, which is what strategies have you found that work best when deploying accessibility across an organization? And when I say organization, you may want to size a small or large organization or even a private versus a public or government institution. So maybe I'll start with Leonie first.
Well, it definitely gets harder the larger the organization. I think that's probably the first thing I would say, backing off of, you know, when you've got a relatively small team, you know, by that I mean perhaps, you know, fewer than 150-100 people. The chances are you've got fairly well-defined roles, fairly well designed teams. Probably just the one sort of cost and accounting center.
You scale that up to organizations that have got thousands, tens of thousands of people and you know, you're coming to all sorts of problems with, you know, who's responsible for paying the budget and know which team the people come into on which particular day when they're fulfilling which particular task. And I think really the most important thing at that level to do is to try and do what you can to understand how the organization fits together structurally.
And if you're not part of that organization yourself to begin with, if you're like me coming in from a consultancy point of view, find somebody or some bodies who've got that information and start working together as soon as you can. Once you know how the organization works, you can start to work out the logical places to fit accessibility into it.
Yeah, very good. Becky, Kronos is is a large company and you've been there for what, two, three, four years now?
Yeah, two years.
Yeah. And so I imagine that what we're talking about right out of the box is something that's very close to your heart. How are you making it work there?
Well, it's a slow process, I think. You know, it's learning. We had two organizations. One was a little bit more mature with accessibility than the other. So a lot of it is education. I mean, I like to I really always stress that you have to start at the the executive level. You really need that support. So people say, yes, this is important.
People need to be given the time to, you know, incorporate accessibility. Some people, it's a whole new thing. They have to learn it. So we're we're kind of approaching it with we the company has got our okay, our objective key results. And we actually have a few teams that have been accessibility listed within that OKR. And they have to make a certain amount of improvements.
So we have a small, dedicated accessibility team. So we kind of split ourselves up to work with those teams and get them to slowly integrate into the process. We're working on adding automated tools, but some of it the biggest part we're undergoing now, and that's is the education. So we are in the beginning stages and how do we do that?
It's like finding your champions within the different groups and, you know, getting them to work forward and then providing the the education that people need and training. But it's it's different. I mean, when I was at IBM, there was everything was in place, right? We had a very large organized accessibility organization. We had a very firm structure. Here's what you have to do before you can ship.
If you're shipping something inaccessible, you have to sign off on it. Then BP has to sign off on it. So, again, it's a it's a small step to get to that place. Having that OKR, that objective key result is, is important, as well as saying, you know, new features have to be accessible and that's getting drilled down. Product managers are hearing that and they're you know, we're in building that into the whole system of, okay, here's your new story.
And what's the exception criteria? Yes, here's what here's what they are. So it's a it's just gathering a lot of data and finding your champions and having that a little trying to add that structure in to each of the groups. Keyway, development, design.
Right. All the way across all across the engineering lifecycle. And I just realized we have a perfect storm here with the two of you because, Becky, you can speak from what it's like trying to communicate this strategy within a large organization. And Leonie, TetraLogical has the other side of coming in as the outside experts and consultancy to to, you know, to communicate those those same strategies.
So let's take it from that standpoint. How do you communicate, you know, a strategy and the importance, you know, raising the bar and raising the level of priority where accessibility lies in an organization today. So Leonie, how do you do that as an external consultancy?
I think Becky said actually is really relevant to this. You've got to get the buy in from the top, but then you've got to hit it from all angles. So you've got to get everybody from the top to give everybody underneath them permission, times, basic knowledge ,capability to implement that commitment to accessibility. That's got to filter all the way down through the company.
And to do that from our point of view, you've got to be able to talk to people in the relevant ways. There's absolutely no point in going in and talking to a C-level executive and giving them chapter and verse on every success criteria in WCAG. It’s just going to be asleep in 6 seconds out the door, you know, 2 minutes after that.
So you've got to understand how to package things up and talk to people in the right ways. From a sort of the other end, you know, talking to the practitioners and teams, the messaging that we found most successful it seems to be oddly not talking about guidelines all that much. Absolutely making sure people are aware of them, that they exist, the importance, you know, the relevance of conformance.
But actually people seem to much profer solutions. You know, I'm a designer. I have to do this and I have to do it in ways that are accessible. What are the practical techniques that I can learn how to do that? And then, oh, great, those maps, those success criteria and I've got that conformance while I was at it.
Same for development and all of those things. So yeah, a big part for us is getting the messaging right, the communication right in different ways that are relevant to different people.
Yeah, that's interesting. Now, Becky, you're more likely to be in a position where you bringing in outside consultants now and then. But again, how are you communicating those OKRs, this notion of of getting things done without... and, I think Leonie makes a great point. You know, developers, they don't want to have to go through an encyclopedia to try to figure out how they're going to make something usable and accessible.
They just want give me the straight scoop. What do I need to do? If I could code and I will. If it's a UI thing, I can do it. So, you know, that's that's part of the challenge that you have in communicating that.
Part of the challenge is training as well, and I think we'll probably discuss some of that. But you know, people don't know what they don't know, right? If you haven't had to do this before and somebody just shows you this design. So part of it is we do have the you know, we're working with design to have a process.
And, you know, when I first came in because I had the development background, I can go and look at the designs and we have a spec that says that I can say, you know, go look at the, the best practices for tab panels, right? You need to follow those rules for ARIA. You need to understand. You know, I can't tell them, just go read the spec.
So it's like, here look at this section and this is where, you know, if you're using and you know, I'll find things in the code and point them out. So a lot of it is having someone, either a consultant or someone internally that has kind of that background that can help. And we have other people on the accessibility team that can do that level as well. And I get sidetracked from the question when I start talking about
So, yeah, and you know, a lot of it is just having those OKRs. And it wasn't for everybody. It wasn’t like everybody has to make, you know, and it was like you have to make significant progress. Well, we had to figure out how do you... what's significant progress?
How do we score that? How do we figure out how to tell if those teams are making progress? And it wasn't all teams at once. It was like, let's focus on our main teams. So they we have an express accessibility specialist working directly with each of those teams to help them understand where they can make progress. And we have gone in and prioritized, made our own priorities.
Not necessarily all Level A, all Level AA. It's like where can they make progress and feel good and start learning? Maybe that's a AA text contrast, right? Because that's one that people can understand. They can make that usually easily through the CSS. So we start in that those pieces and give, oh, look, you made progress. And then we have a we've developed a very rudimentary at this point we're working scoring to figure out, okay, how do you how did your accessibility conformance report? What things or does not support?
You know, you get so many points for you know, get no points for that. You get partially supports and then we can categorize them and say here you changed your your ACR has gone up. Which is a hard thing because, you know, if you have a big progress, you might not see a lot of change in the ACR... you’re not going to necessarily go to all supports. You may go from does not support to partially, but that's at least improvement.
So it's just finding a way to measure that and focusing on certain teams to start educating people.
Just heard from our audience using the acronym ACR and you mean?
Accessibility Conformance Report. Sorry, I'm sorry. I usually preference on my ACRs at least once.
That's a 508 outcome. The ACR says that level. But now you you've been talking about OKRs. And so this kind of goes into the next section that I want to do. I want to talk to you both about you. We often talk about in terms of more common acronym are KPIs, right? Key Performance Indicators. Yeah. It sounds like am I am I right that the OKRs are analogous to it?
They are made up of key performance indicators. Yes.
So so, okay, so talk about those a little bit more then. I want to come back to Leonie because it'll be interesting to see how WCAG actually even plays into this or if it does, you know, at all.
I mean, we know it's very you know, it's one small piece. I mean, that was a big, big win for us to get accessibility into these OKRs. It's, you know, one of the one of the and I don't know, the top... With one of the main OKRs this is a small KPI inside of it. Key Performance Indicator inside of that was that, you know, and I don't, I don't want to say the teams, I don't want to give it away any, any company secrets.
I don't think it's that secret. But you know, these teams specifically will work on that and make significant improvements. Like okay, it's a starting point and and that it was sort of up to us to remind the teams knock on them and say, you have this in your... it's a key performance indicators for your group.
So and so that that made people aware. We actually have someone that helps us that's on that particular group just to help to follow up on the OKRs.
They come to some of the meetings that we have with the teams. So they get the feedback from the team and the team sees that it is a real thing coming from management.
Does that kind of address that?
Leonie.. Leonie, Are you seeing things ike this in your engages with your clients? OKRs? KPIs? And what's the foundation stone for or even developing these?
Yes, we are. There's a definite move in the past few years, you know, usually most sort of substantial sized organizations to start thinking in these terms and So there is one exactly. What there is more is a need to make sure that they're all interconnected. It's no good just giving your designers or your developers or your user researchers is a bunch of KPIs and thinking it will work. Their KPIs, or OKRs, have got to fit in, excuse me, fit into those of, you know, the product owners, the project managers, and you've got to make sure it retrofits or would back up the kind of food chain, if you like, because if you don't, ultimately you will hit somebody who hasn't got accessibility as part of their responsibilities and they're going to start blocking things because they've got other priorities they've been told they need to to focus on. So you've got a sort of chicken and egg situation, really. You've got to try and figure out the whole chain of responsibilities and metrics for measuring it. Otherwise you'll kind of, yeah, sound the brakes on at some point. And then, you know, you asked where WCAG fits in. For example, you know, at the at the product level.
Sure. Yeah, absolutely. Conformance would probably be a pretty important KPI or OKR, depending how you work, you know, to put in at the product level, depending on how much time and energy and, you know, the organization's KPIs look like anyway. You might want to get more specific about how WCAG fits in when you get down to, you know, practitioners and different specific roles, if you see what I mean.
So WCAG needs to be a thread through there. We've got too many countries in the world now where conformance with those guidelines is a requirement and obligation, so we can't ignore them entirely. That would be foolish. But it's framing the KPIs in the ways that are relevant to the individual roles and groups and ways that are consistent with what they're already doing in that organization.
You don't suddenly want to have, you know, really simple KPIs for, you know, your responsibilities towards privacy, data protection, security, and then nine miles of responsibilities when it comes to accessibility, because again, that just stops it, makes it feel burdensome, it’s too much for anybody to achieve in a practical way. So you've got to keep it real, as they say.
Yeah, yeah. Very good. Very interesting. Do you have or do you recommend any notion of a feedback loops? I mean, when you're tracking progress? Becky, at you're level, which is... I'm just going to assume is kind of like a director management level. You're overseeing what's going on with the company, what kind of feedback mechanisms does a company or do you rely on in order to ensure that, okay, we've got a goal, we've got a strategy, is there follow through?
I mean, I think it's we we don't we're still working that out, right? I don't think we have a big feedback... Or feedback is just, you know, okay, you know, we're going to we do redo the ACR, the accessibility conformance, right? VPAT. Other people that people have heard of it mostly as a VPAT. I'm trying to retrain my brain.
Well, how do you know? How do you know where accessibility is kind of your your, your area, right. And you're kind of tracking and watching where the company is going and what progress they're making based on those KPIs are. The KPIs are OKRs. OKRs. How do you understand, you know, how do you communicate with those teams?
Do you have email sessions? Do you talk with people in the halls? Do you have meetings? You know, is there a social networking in, you know, environment there where you’re looking at it? How do you know teams are making progress once you know what you let go, once you walk away from the training sessions, for example.
I mean, we are very involved. You know, like I said, where there's a you know, we're assigned to different teams and we kind of keep track of them. We're checking in regularly with the product manager. How's it going? Where are you going? Are you making progress? Are you committing to? Have you created an epic or a story for this?
What are you going to commit to in your next release? When is your next release? And then we will follow up. And our goal is to eventually not be the ones that are doing the testing. I mean, the overall testing, obviously we don't do testing for the whole product, but to to complete the the VPAT or the the Voluntary Product Accessibility Template, you know, to create the ACR, We're you know, we're also working with QA to add training for them and say, okay, now you can do this, have you seen this?
Have you added this? And a lot of it is just getting it all into the process so that, you know, we'll say, Oh, you have this new epic, where's that? Where's the acceptance criteria? What did you put in? Do you need help writing those? So we're it's mostly right now, it's still a follow up as we're building that skill into the teams.
Okay, that makes sense. Got it. Leonie, how about on your end, again, as an outside consultant, you're trying to work the relationship with with your client. What's the feedback, what feedback mechanisms you use to ensure that there's, you know, there's progress is being tracked and then you're helping your client make that progress.
So typically, I think it comes down to two forms of data reporting and then the human connection. Yeah. Getting teams to get into the regular cadence of audits and updating their ACR is, yeah, it's a useful thing for them to do. But it also gives, you know, if you have an accessibility team, a way to benchmark progress. You know, is there noticeable improvements in each ACR that the product team is is producing or having produced and if you start monitoring that data you can very easily put together a dashboard across all your products and services that starts to give you some trend information. And if you all the person on the team reporting back up to you'll see level, who’s got responsibility for it. You know you can again distill that down and you show them some hopefully clear progress signs across the different products or, you know, perhaps a little less happily you can identify the patterns and look at the causes. Why are some teams not managing to to make improvements? Why why are they perhaps taking steps backwards? And you can start to analyze the reasons why. And that then kind of gives you ways to move forward again with more training needed, more internal processes needed. The other part I mentioned is the human connection.
Becky mentioned accessibility champions, having a network of those or even, you know, guilds, different organizations calling different things and do them in slightly different ways, but having people who kind of go out into the company from sort of core accessibility team and represent, you know, accessibility best practices within their disciplines, within their particular role, but also making that a two-way process so it's not just about them going out there and supporting teams in altitude design, more accessibility or user research, but it's also listening. So what are other people in their guild or their team or their discipline finding difficult? Where are the challenges? And again, on a kind of macro, a micro level, sorry, where are the problems, where the gaps that keep consistently appearing?
Then again is that all gets reported back up again, you've got a lot of information you can feed into, work out how to close any gaps that you recognize are happening.
Yeah, I love I love that very agile kind of approach to ensuring continuous improvement in the checks and minuses and, and things that that, that you're engaging with, with your... with your with your clients. I'm a very strong proponent of, of agile development and, and the feedback mechanisms that that come along with it just makes, just makes development I think all the way across the board and it makes achieving accessibility actually easier. For me, at least from my perspective, my, my experience with it.
So along those lines and when you know that you're dealing with a number of disciplines. Right? Becky. So you've got QA. You may even have documentation involved there, you've got [inaudible], you've got requirements. You know, all of these disciplines that are involved. Again, what are you doing there in terms of kind of promoting that notion of continuous improvement and agile development where accessibility is concerned?
Yeah, well, I mean we're like, again, we're still building up our processes. We're working with each group. I mean, you know, it's like we know it's not going to happen overnight. So it's like there's deadlines. Okay, We have there have been developing take design. We have a process for design, right? They have and we need to incorporate accessibility into the design.
So there is you know, there's an accessibility checklist. You need to create an accessibility document that, you know, not only the standard design thing, but it specifically points out, you know, make sure that this is noted as a heading, right? Don't just can't be visibly as the heading. This has to be noted. You know you need the designer needs to know it's a heading level two or one or whatever, that it fits into the hierarchy.
So you can say this is this plus one and then there's the the documentation tab index. What's, you know, is this arrow key navigation? Is it tab key? So it's getting all that documented. So that that is also given to the developer. So not only they know what color and what the padding is, but they also have that. We're also have a design language system that we're getting everyone to work to the same system.
So we also work with that team. They've done a pretty good job already with accessibility, but then we discovered some gaps. So it's like just working with them. And and so again, is that finding the champions and getting the people educated. And then as we get more people in the design team, yes, we have, you know, someone that has very good design skills and he is helping to move that forward to other teams.
The management has embraced it. So I think a lot of it is just repetition going back. We have a whole... we built a whole SharePoint site. We’re a Microsoft shop. That has accessibility by role. Here's your and here's the training classes you take. Oh, you need help? You don't understand this? Here's this resource that you can go to.
And we've done a good job of just following up on all that. But it's, you know, like I said, there's no I can't say, oh, here's what exactly what we do. It's kind of depends on the the maturity of the team.
Right. Right. But I but I do appreciate, Becky, is it you've been saying this all the way through consistently. How important training is within your organization to ensure that there is continuous improvement moving forward. Right? So you're as you're going through, Leonie mentioned the notion of using dashboards. You've got the SharePoint site. Looking for those gaps, you're finding those and then filling them in with maybe increased or enhanced training, right?
Based on based on your finding finding there, is that correct?
Oh, yeah. And definitely and we you know, we have those what I call the canned training, the prerecorded training, and we assign that to people. But we find if you're not using it and it doesn't relate to your product, it doesn't make as much sense. Right? And I know I've given the training. You give concrete, simple examples that people can understand.
Well, once you get a little bit more forward, the simple examples aren't enough, right? You need to see it. So we are working to either give training ourselves some of that but or build it in-house that is specific to the product. And some people don't like to do that. They’re like, oh, we don't want people to feel bad that we're showing bad things they did in their product.
And I said, I think it's how you present that. And they, you know, but also you have to do it in bite sized chunks. Like I'm always like, okay, here's how ARIA labels work, because they're always using labels. And I'm like, You don't need a label here. You can use this other ARIA accessible rich Internet applications specification. You could do it this way.
You need to have code or, you know, so it's I think those examples and we try to work with the third party to bring in specific training, training specific to our module. Like show them how to use the keyboard with our product. If you're giving screen reader training, for example, or keyboard training.
Yeah, Excellent. Leonie. I mean, I know both of us know having worked together for so many years, how critical training is to a, as, as a feedback mechanism to, to ensure that, you know, TetraLogical’s clients are making progress and it's measurable. So I imagine that you you there in the team there have a fairly strong footprint where where training is concerned.
We do yes. Although last year we pivoted away from classic instructor led training. And the reason we did that was because we did a whole lot of research with our customers. We talked to people from all sorts of organizations that had had accessibility training over a long number of years. And the one really clear message that came out of that was instructor led training is great. Everybody piles into a workshop for a few hours one day. They learn tons of stuff. They get really excited, really inspired, and then they go back to work two days later and they're thinking, oh, well, I remember we covered this, but I don't know how to close the gap between that and what I'm looking at today on my screen.
And so we've moved more towards instructor led training programs, which is kind of based on the idea of more continuous feedback. You do a bit of self led training. You go, you know, implement it in your job. If you come unstuck, people and the instructor have a permanent channel, you can come and chat to the team to ask your questions.
You get an instructor led session next week. So it sort of mixes it up. But because it's slower and steadier and smaller chunks of information. Go away. Do some. Learn some. Ask some. It has a lot more sustainability behind it because the sort of feedback happens over a number of weeks. So that's one interesting sort of way we've been approaching it that seems to be getting a lot of interest and having some success.
The other interesting thing about feedback loops there is one of the strongest actually is not really a feedback loop at all, kind of pay it forward loop if you like. And that's encouraging people in project teams to talk to each other before they do stuff. So if you are about to work on some user interaction or some creative design or any prototype. Go and talk to the people who are going to implement it, develop it, code it, QA test it... Run your ideas past them and head stuff off at the pass so you get the feedback in one way back up the way back up the lifecycle. Because you'd be surprised actually how much you can you can prevent at that point just by having a conversation with someone. Going let's, I'd love to do this design or this interaction, and can we actually do that accessibly in our code base? And having a conversation about it that that's one of the best preemptive feedback loops, if you like.
That's awesome. And I'm sure the folks in our audience really appreciate that. That very notion. Because it's real. It's it's dealing with what what's in front of you right then and really be learning how to make progress and move forward with with what you're with, what you're addressing and developing in the development environment. I want to just switch gears just a little bit. Gonna talk a little bit about a topic that, again, all of us are very, very familiar with.
And it is auditing. So what processes do you find work best for you when it comes to doing the the deep level? You know, type of auditing to ensure that whether it's a product web based or otherwise is usable and accessible. Leonie, you want to try tackling that first?
Sure. So our preferred way of doing it is as likely as possible at a point when it becomes confirmation of everything the team has been doing up to that point. Not the first time that anybody discovers what's wrong with it. Yeah, I mentioned before, you know, the legal expectations around conformance and using an audit right at the end to say, actually, yes, we confirm, you know, that all the kind of exhaustive testing, feedback loops, all the training, everything that's happened up to this point has done what it was supposed to do.
It doesn't always work out that way, of course. Often teams don't have the knowledge, skills, time, all of those things. And so an audit ends up being the first point at which they're really starting to understand that they have got issues and how to fix them. And so the sort of the wherewithal of how we do it, we follow a fairly classic methodology for doing it.
We’ll we'll use a representative sample of screens or pages or features, or whatever it may be. We do still come across some organizations that are very, very determined to have us test every single page, every single screen in an application. And so the first thing we do is actually explain to them why they don't need to spend that budget, you know, doing that because of duplication, repetition. We could be a lot more efficient and they can keep their budgets down.
And from there it's a reasonably straightforward technical conformance checking all the different success criteria, the mostly WCAG 2.1. But of course we're gearing up for 2.2 now. And then, you know, I think it's important we include assistive technology verification. We're expert users, we're not real members of the general public that use assistive technologies, although some like myself do, of course.
But we do check to make sure that the features interactions actually do work with speech recognition, magnification, screen readers and things like that. As I say, it's not usability testing, but it does at least let people know that stuff works in practice because I'm pretty sure we've all counted examples where you've met every success criteria, conform to all the guidelines and somebody will come along as a human and try and do something, and it still doesn't necessarily work with their technology.
Yeah, there's a... I'm glad you actually highlighted that, Leonie, because I think that sometimes organizations do mistake using usability testing or even user experience testing, and AT testing or interoperability between the assistive technologies, applications or other ways that users with disabilities use, interact with, you know, a software or an interface. It's it's not the same. It's why on the 508 committee, we separate it out.
We call it interoperability. Well, how does mainstream technology work with AT for example? Right. That's a that's a different beast. It may include some of the area, you know, some of the disciplines like user testing and UX. But in fact, it's it's it's more robust in terms of of of actual testing to to ensure compatibility with assisstive technology.
Yeah, absolutely. And you know, when it comes to usability testing, you really need that not only to be people who have different disabilities, access needs or use different assistive techs, but there really needs to be people from your target audience. You know, if you're an organization that's targeting its content at I don't know, you know, teenage transgender people, for example, there's almost no point in asking a bunch of people who are over 75 to help you test that.
You know, it is just because they use assistive technologies, you know, because their attitudes to everything probably, you know, gender, politics, the use of technology, everything will be very, very different as human beings or is likely to be very, very different. So, yeah, if you don't focus usability testing around people with your target audience, you know, you're missing a really important trick, though.
Right, Becky. Inside inside of Kronos, I'm sure that you've already kind of laid out a very disciplined approach towards testing and auditing. But I want to get a little bit more out of you. How do you how are you approaching that with with your teams and how are you making sure that it's implemented?
Right. I mean, again, it's a beginning of the journey, but and how we kind of do that is we really have the teams start with, you know, the product managers. What are your top ten user journeys? User stories? Whatever you want to call them. Use cases for your employee and for your manager. And then sometimes admin generally, you know, if your further administration that gets left till later, because often those interfaces are not as accessible and it's a smaller user group.
So we we focus on those. Like, okay, what are the top things you can do? And then we can go through and you know, we're, I don't know, every single product that's part of UKG. Right? So if I'm going to help a team, I have to sort of learn a little bit about it. And then I have to say, okay, what are the main things we have to do?
And then I can help with the page, you know, figuring out which pages we want to do because I know where things are repeated. Right? Okay. I know this page is the same whether in if I go in from this direction or this direction, I'm still going to end up at a certain page. So we focused mostly on on the user journeys.
And one of the other things is, is we're much more stringent on new product, new products or new features. And most of those things are using our design language system. So that gives us a little bit of a head up on the fact that they are going to be likely, there's still ways you can use the design system wrong, but they're more likely to, you know, and then we can again narrow down, oh, they're using the the DLS design language system.
So I know. Okay, once I get that that's used on this page and you know it's probably accessible if I did it right in one place, chances are they did it. So I can narrow down the focus. And that's, I mean, the same thing that we would do when I worked for Knowbility doing consulting and a similar to what you know, Leonie said. You you find the representative pages, you find the representative tasks that people use and then mix it up with the different assistive technologies.
And, you know, one of the things that came to mind as people were talking is that I think there's much more awareness of neuro neurological [inaudible]. I can't I can't speak today! The diversity, neurodiverse people in the audience and we can point those things out. And that actually often thinking about that leads to a more straightforward approach.
And I'm sort of getting back to design. But again, we do try to include that as we're going through. Is there something that's really confusing here? Did I need more instruction, especially as someone coming in to do the the auditing without having that in-depth knowledge of of the product?
Yeah. Excellent. Really good. Thank you very much for for bringing that point, especially around neurodiversity because that is a that's a hot topic. That's a that's a big button right now for a lot of organizations. And so the fact that you're giving attention to that, considering that in your design, you're testing and deployment is really is really important, I hope those that are listening to this pick up on that because it is a critical it's a critical KPI if you want .
So here's the $6 million question, because it's the one area that I struggle really... well, wanting to fight against it sometimes is some of the answers that I hear back on. But where's the business value proposition of accessibility today? How do you drive that home to customers and clients? How do you get them to see it? What.
What methods do you use to to not only to, to tell them the business value proposition, but what do they have to measure it on their own, on their end? How do they show? Well, all of these efforts that Becky or Leonie, you've I've taken, I've followed your your direction. We we've instituted the complete lifecycle and we're not seeing any we're not seeing any revenue generation, increased revenue because of all of these changes.
All we got is more people suing us. So what do we do with that? What do you how do you feel about that? Go ahead Leonie.
I'm never entirely sure on the best answer to that question.
[laughter] That’s why I asked it.
Because I think part of me genuinely wants to push back on the idea of there needing to be any financial return on investment. There actually isn't. With an awful lot of the reasons, you know, all the things that we do as part of website production, app production. You don't see an increase in revenue because you made your systems secure.
You don't see an increase in revenue because you met your obligations under GDPR data protection. So part of me is a little bit, you know, why are we putting accessibility on a peculiar kind of pedestal? And suddenly expecting it to be revenue generating when actually an awful lot of what we do astounded doesn't have that direct in a correlation with a return on investment.
However, then the kind of nicer part of me kicks in and starts to think about, yeah, there are benefits. They're not necessarily easily measured ones in the same way that you know conventional advertising if you like. You know, you might see an advert for a particular TV brand and very rarely makes you jump up and go out and buy the TV.
When it does date, though, is the next time you want to buy a TV, you remember that advert, thinking, okay, maybe that's the brand I want to go for. And I think the return on investment for accessibility is a little bit like that. We know there are lots of people with disabilities out who want to be doing more, spending more, you know, engaging more online.
And if you make that possible, you know, we know they will be doing that and telling other people about it. And the problem is, is unless you have a very good idea, you know, what your audience looks like, your audience demographic is currently, it's very hard to know how it's changed or improved with regard to that one particular, you know, angle of it.
We do know that if you get accessibility built in, if you put in place the processes, the deployment practices that we've been talking about today, you can massively reduce your time to production. You can reduce your time to remediation if you need it, but you minimize the need for remediation in the first place when you get it right.
And if you're talking about large organizations, you know, especially one that has many, many websites, products and services, every little bit counts. A long, long time ago now, I worked for a very big organization at a customer services helpdesk, and we helped them make one small usability change to the interfaces that their customer service personnel were using, and it only saved each interaction a few seconds.
But if you mounted that up over all the customer services calls and every single interaction, suddenly it was saving them months. You know, in the space of any given year. And accessibility again, is like that. I think every little thing you do to put in place the processes, saves you a bit of time later on and that saves you cost.
Because when your teams are spending time fixing stuff that should never have been gotten wrong in the first place, that's time they could have been spending on something else. And you know, that's a hit to your company and, your budgets and all the rest of it.
Yeah. Excellent. Thank you, Leonie. You gave us a lot of good insight. Becky, how about you? What do you think?
Yeah, No, no, I definitely agree with so much of what Leonie already said. But I mean, I think and I kind of I always try to put accessibility... I'm like, you know, when people are like, oh, accessibility is too much, work is whatever. And I'm like, you don't say that about security, right? And security is another thing. I mean, security you don't make money on making your product more secure, but people are more comfortable buying it when they see that you have X, Y, Z certification.
And I think accessibility is similar. It's like you're not going to suddenly make more money. You may. You may have more customers that, as you know, customers talk to each other. You know, and that's where a lot of our pushback comes because, you know, we provide for many customers. I know that. Oh, we will provide them a a example, a tenant, and we'll give them an instance of the product to use and try.
And there are many that will do an accessibility audit and come back to us and say, we found this, this and this. And that’s and that's great because that gives our team more ability to say, hey, you know, there's this a customer that needs this and is pushing back. And the less we have that and the less that we have to address those because we don't have that customer pushback.
That's, you know, we're suddenly that's saving time, saving energy. We're selling to those customers. They can see and we provide our ACRs online, our the conformance reports for people to see if we're still in the process of getting them all. But yes, so I think a lot of it is just, you know, you have to just say once you get this and part of your process, just what Leonie says, it's going to save you time going forward because now you have less development time, you have less remediation time because your developers are more trained and they're going to pick up.
It's like, hey, wait a minute, you didn't give me the alt text for this image. You want me to put this image on the page? You don't want. I I was a developer so I say this. You don't want the developers writing your all text, right? Yeah. So, you know, you get them and they know to go, you know, to go back like, hey, you need to give me.
And that's not a simple example, but there's other ones like, okay, what's the what do you think the keyboard order should be here? You need to tell me that you can't just say this is, you know, X, Y, Z. It's like, okay, or maybe they do. Once they know it's a tab panel and then somebody identifies it as a tab panel, then they know, oh, I'm going to implement arrow key.
So it's a time saving. I don't think you can say, yes, there are less support calls because those get highest priority, anything from a customer. So if you don't have those accessibility support requests coming in, you're making money. But yeah, it's I don't think there's a way to say, oh, you're going to make this much. I think it's got to be you're going to get more customers and you're going to have happy customers.
And that's going to save you money. Make you money and save you money in the long run.
It’s that last statement. I'm sorry, Leonie. It's that last statement that you just said that I'm going to fixate on and that if you make your customers happy. You know, the reality is that what accessibility does is, as I'm listening to both of you and I really do appreciate your input, is it's really about the quality and the appeal of the application, right?
People buy certain apps because they already know that they're secure. Because their privacy is protected. That's the appeal factor, right? The same thing is true about accessibility. People buy it or invest in it or use it because they know it's accessible and usable. So that's got to be one of these things that I think we need to start to talk a little bit more.
It makes it more appealing. We've got more. I mean, we're talking about a billion people or more literally on the earth right now who who are in some way, shape or manner affected by disability. Right? And so we're just appealing to the masses at that level. And how can that not be a good business value proposition. To build something that is got quality and is useful and is just appealing to to to users.
So so really, I got to think about that a little bit more as a as a go here in some of the things that I do in talking to talking to others. Well, Leonie and Becky, I want to thank you both so much for being with us today. Again, this is part of our our GAAD presentation here at Accessibility.com.
We're going to be focusing on focusing on... Today we focused on deployment. We also did our first two modules on design and development. So we've got a holistic approach here that we've taken to share that with the universe. And we we expect that it'll make a great splash on on this year 2023 GAAD. So again, thank you. Becky.
Thank you,. Leonie. And have a great a great week.
Great, thanks. This was fun.
Thank you so much, Leonie, Becky, and Mike for that wonderful conversation you had on a deployment for accessibility. It is quite a process, bringing everything together. When you think about starting from design, passing it over to development, and then deploying it and all the steps involved and how to measure your results and check to see if it's working and taking your organization further.
As I stated at the beginning, this event is recorded and will be available on demand along with the transcript and any other supporting documentation. This evening you'll receive an email from me with instructions on how to access that. Thank you so much for being a part of this wonderful three day series. Our Design, Develop, and Deploy for Accessibility series leading up to GAAD, Global Accessibility Awareness Day, which is next Thursday, May 18th.
It's always the third Thursday in May, and this year it's next week. So this is our way to celebrate accessibility by spreading awareness globally and what you can do and talking through... Bringing in some experts to talk through their experiences and what's worked best for them to hopefully shed some light and give you advice on how to best design, develop, and deploy for accessibility.
We'll be back in August with Accessible Mobile Apps and Kiosks. My name is Lori. I'm the Director of Conferences at Accessibility.com. Please don't hesitate to reach out to me with any questions and feel free to register for Accessible Mobile Apps and Kiosks on our event page. And you can reach me at Lori L-O-R-I at accessibility dot com.
Thank you so much for spending some time with us today. Or if you spent all week with us, we really appreciate it and we look forward to having you join us at our next event. Enjoy the rest of your day.
Click on any of the file-links below to open or download.
You could also Right-Click and "Save As".