- [Mike] All right, good morning, everyone and good afternoon. My name is Mike Mooney. I'm the Digital Marketing Manager at TPGi and we're excited to offer this presentation on enabling an accessible SDLC for people, process and technologies today. A few housekeeping items, we are recording this session and we will make it available to everyone after the event. We'll send you out an email. For today, we have the live captions available as well. So feel free to use those as needed. And lastly, if time permits, we will have a live Q and A, so feel free to use the Q and A box to submit your questions. And our hosts, if time permits, like I said, will answer those questions at the end. And without further ado, today's presenters are Chase Aucoin and Mark Miller and I will let them introduce themselves, so thank you. - Awesome, thank you everyone for joining today. Today, we are gonna be talking about enabling an accessible SDLC and I am very excited to be here with Mark Miller. My name is Chase Q. Aucoin. I've been in enterprise development for over 15 years, passionate about system-level design. So whenever it comes to systems and systems, huge, an important part of the work that I do, if you'd like to interact with me, please feel free to reach out to me on GitHub, LinkedIn or Twitter at Chase Aucoin, that's A-U-C-O-I-N. - Thank you for that Chase, I am Mark Miller. I'm very excited to be here with all of you and presenting this with Chase. I am Director of Emerging Accounts and Platform for TPGi. I've been working in accessibility for eight years. I host the TPGi's "Real People, Real Stories" podcasts, which you can find on TBGi.com in the blog section. You can also find it on iTunes and Podbean, I believe and I'm real passionate about overall organizational strategy when it comes to accessibility. - Awesome, so we got a few different things that we want to talk about today when it comes to SDLC and enabling accessibility within your software development life cycle. We're gonna talk first about what digital accessibility is. I think for many of the people here, this is gonna be maybe the first introduction that you've had to what that is. So we'll dive into that pretty deeply and we'll get into how continuous accessibility works within an organization. Some organizational challenges, tooling that's available, how automation can play a big part in this as well as some best practices. So just jumping right into it, the first thing that we got to ask is what even is digital accessibility? So I'm gonna leave that question to you, Mark. Mark, what is digital accessibility? - Yeah, thanks Chase. That's a fantastic question and obviously super important to what we're talking about today. So digital accessibility really refers to the way that everyone would consume digital content, whether that be a website, an application, even a document like a PDF and people with disabilities might access that information, interact with the content or the functionality of those things in a way that's different than a person without a disability. So for example, somebody who's blind or low vision, they rely on something called a screen reader, which reads aloud the content that a person with vision would just read through the site and also provides them with a lot of different ways to sift through that content. We don't all read pages from top left to the bottom right especially on the web, we skim and find what we want and click links to the next thing and the technology, if that page is programmatically correct, allows them to do the same thing, the screen reader user. Individuals with limited mobility, they may not be able to use a mouse. I worked with a woman who due to a disease did not have a gross motor control over her hands. She really only had good control over her head. So she used what's called a head wand and the keyboard and could not use a mouse. So a head wand, if you think about kind of a bandana with a pencil on the end of it, that allowed her to, with her head, tap the keys that's what she used. So of course you can't use a mouse for that. So being able to navigate with the keyboard only was important for her and then people with cognitive disabilities. And this is a tough one because there's a huge spectrum of what somebody with a cognitive disability might need for accommodation. I, myself, am on the spectrum. I have ADD and dyslexia both, my dyslexia is relatively mild. I don't really accommodate a whole lot when I use the web, but I had a friend of mine whose son was on the autistic spectrum. And he needed his information to be chucked down into specific pieces and all sorts of things for him to be able to appropriately consume that content. And of course, a person who, we were talking about our captioner earlier today, Chase, and a person who can't hear obviously anything that's spoken, any content that's auditory needs to be re represented through text so that that person can benefit from that context as well. - So really whenever we think about digital accessibility, then it sounds like it's just acknowledging the fact that not everybody uses technology the same way and while many people use it in a traditional, here's a screen, here's a mouse, here's a keyboard, there's a fairly large segment of the population that just can't interact with technology in that same way. So with that in mind, like what exactly makes a website and or documents accessible for those users who are not interacting in a traditional way? - Yeah, so that's a really important thing to understand. And I think for me, the one, I like to make things simple, and the one simple way for me to understand this is equivalency. If a person with a disability can consume content or interact with a website in a way that is equivalent to somebody who doesn't have a disability or need the same accommodations, then that's really a good measure of success. So an accessible website, that would enable people with disabilities, whether it's any one of the four that we've already talked about, cognitive, motor, visual, auditory to have a comparable experience to a person without a disability. So think about booking a plane ticket, if a person can successfully book that plane ticket in roughly the same amount of time, you've got an equivalent experience. And really this can be boiled down, the first place to look out on your sites, your key tasks, what are you really there? What is somebody really coming there to do? And can they accomplish that? So maybe the blog is secondary, but in that case of booking of a plane ticket, that's a primary function of showing up to your air carrier's website. And if users are unable to complete these tasks, due to not their assistive technology, the technology they use to perform all this, not properly being able to interact with the site, then that's where we get something that's considered to be not accessible. - So it sounds like, then just to recap, making websites and documents accessible is really just about making sure that if somebody is not interacting with it in a traditional manner via mouse and keyboard and screen, they can still do the key activities that you're trying to help users perform the same as anybody else. Is that a fair statement? - That's more than fair. That's exactly right. - Awesome, so seems like there'd be a lot of implications with this and the one that sticks out to me is obviously the moral implication, because we all wanna be good stewards of our community. We all want to be good tenants to our employees, our clients, and make the world as open and inclusive as possible. But what are some of these moral implications whenever it comes to accessibility with the products and features that companies develop? - Yeah, I think no matter who you are out there, you never wanna exclude somebody. And the problem is that there could be things going on with your technology where you don't realize it's occurring and that's where the separate comes in. So of course, from a social standpoint, looking at it corporate wide, just that sort of statement or inclusion principle is super important and what it does beyond just making it so that everyone can use your digital products, is it also really breeds a very good feeling amongst the community. People with disabilities are very loyal. The people who have people with disabilities in their lives are very loyal, especially when they understand that an organization is trying. And then if you turn around and look at that inward as well, employees, whether or not they have disabilities, really appreciate a corporation who's focused on that kind of standard and it can breed real positive feelings towards the employer and increase loyalty, increase productivity, increase all of those things, just like anything in this space could. - So doing the right thing is great, but it sounds like there's a lot of benefits there from within your organization and the way that you interact with your clients and the way that you interact even with your own employees. But I imagine there are some additional business implications from there and why being accessible and why taking accessibility seriously within your organization can be beneficial from a business perspective. - Yeah, I mean, there's several ways really that you can look at the ROI when it comes to having accessible content. There's some statistics that we have here, the first one showing that a substantial segment of the work population, 15%, according to the World Bank and the US population, which is 61 million, identify with having a disability. And if you think about this, oftentimes when that word disability comes up, we imagine somebody in a wheelchair or a person who's blind at birth or something like that but there really is a spectrum. There's a spectrum of vision disability, there's a spectrum of all different types of disabilities and our aging population who has been participating in these things sort of unfortunately, we collect disabilities as we get older. So it really can have an impact to your overall customer base, if you're not accommodating to that. Total after tax disposable income for working age people with disabilities is estimated at about 490 billion. - Wow! Billion with a B. - With a B, yeah, and that's according to the American Institutes for Research, and by the way, these statistics are a little bit old too. These haven't even been brought up to current. So you're probably looking at the things that are even higher. Inaccessible job application portals and organizational internets, prevent companies from employing a truly diverse workforce. So the diverse workforce is a fantastic workforce. It's very loyal. There's a lot of unbelievable skillsets. More and more organizations today are focused on making sure that they have a diverse workforce, but if your potential candidates can't even use the tools that they need to to properly apply, then that's what we would call a significant barrier to being able to complete that task and doing what they need to. People with disabilities tend to be the most loyal, as I had mentioned before, from a customer and from an employee standpoint. Basically once they find a product or service that they can use, well, they continue to use it, not just because of the convenience factor, but because of the goodwill that just focusing on their needs really promotes. - That makes sense, yeah. So that sounds like the benefits here really are having access to a much larger customer base, having access to a much larger talent pool to hire from and also just creating really good relationships with people who, if you take the time to care and you take the time to listen and create solutions that work well for them, are probably gonna stick around for a very long time. So that's awesome and I think that that makes a ton of good business sense. And I know that we probably, the way that most people are hearing about accessibility, especially as it comes to the corporate workplace is around lawsuits. We see more and more of these in the news of companies not having products or services that were able to be used by a fairly large segment of the population. And then saw that going into court. So, Mark, it seems like being inaccessible and not having accessibility be a first-class citizen within your organization can create some risk. - Absolutely, yeah and this is what we see a lot, this is really sort of, unfortunately, I guess what lights the fire underneath a lot of organizations, and it's not the way that you want to approach accessibility because you're typically you're sort of in a panic and there's a timeframe around it and all of that. So if you can, before something legal comes knocking on the door, if you can manage accessibility, you're gonna be much, much happier, but there's absolutely risk associated with it. A lot of organizations are looking to mitigate that risk. You can't completely get rid of it and create what we call defensibility, making sure that you can sort of tell your story around the efforts that you're making to create digital products very well and with objective data, backing it up so that they can manage sort of the unfortunate, legal things that might come across their internal counsel's desk. So the lawsuits are very real. They've been going on for a while. They continue to increase. The Department of Justice who has consistently stated that websites fall under what's called the public accommodation language. So if you look at Title III of the ADA, it says that places of public accommodation need to be accessible to people with disabilities. The ADA was put into place in 1990 and that was long before, Chase, you or I ever got that AOL disc in the mail. So they weren't thinking about websites at that time. But of course, now we bank on the web, we shop on the web, we register our cars on the web, you name it, something that would have been a public accommodation physically in the 1990s is now accommodating that public through some sort of digital means. So that's what they're referring to there. And the ADA has come out and said, hey, wait a minute. We know that wasn't in there, but we consider it to be a place of public accomodation. And the lawsuits have tripled, that's the bottom line, just from 2017 to 2018. - Wow! That's a lot. And I imagine that that was just in 2017 to '18. I don't think that we have the current statistics, but I can only imagine that trend is continuing upwards. - And it goes to the yes . - There's got to be some methodology available for understanding where you stand from an accessibility perspective to help organizations really get a handle on like what are they doing from their perspective? Can you talk about that a little bit? - Yeah, so there's several different ways when we talk about mitigating risk and creating a defensible situation, and I'm not legal counsel. So we tend to, when we're doing this, we tend to do this in conjunction with legal counsel that can really probably make sure that all those considerations are in place, but essentially this area is very gray. There's no certification. I call it the car inspection sticker, you get your car inspected, you meet the set of criteria and you know you're all set for a year and that's what everybody wants is something like that. And unfortunately it doesn't exist for several reasons. One, we have a set of guidelines and the ARC guidelines, two, everybody's doing something different. Like there's not a consistent experience out there when it comes to websites and applications and things like that. So the ability to conform to all of these guidelines varies. So we look at really, what does it mean? Like, what does it mean to satisfy Title III of the ADA and typically speaking, it's a unique definition and it goes a little something like this. And that is that the first thing you do is really identify the critical user journey. We go back to that example of if you're an air carrier, your business is plane travel. One of the critical functions in your website is somebody being able to book a plane ticket with you. So what are those? Why are people really showing up? What are those critical things? And then making sure there's no significant barriers in those. Accessibility can run deep. When you start to think about it from a usability standpoint, it can run even deeper. So the first sort of focus you want to think about reducing risk is how do we make sure people with disabilities using assistive technologies or that need a different way to accommodate can actually get through those tasks. And then you can start to look at other issues that may not be complete showstoppers, but are pretty darn inconvenient. So you're reaching towards that equivalent experience type of thing. And then, oh, go ahead. - If I'm understanding you then, it sounds like really the crux of this is kind of going back to what we were talking about earlier in that understanding how people interact with your applications, your programs, et cetera, and making sure that folks, regardless of how they're interacting with it can interact with it in a fairly equivalent way from a time and energy perspective. - And particularly without being just flat out excluded, it's that flat out excluded that is the first focus. And then from an organizational standpoint, you start to think about, okay, well, how do I demonstrate that's actually what I'm doing? So when somebody comes knocking and claims, otherwise I can say, no, no, no, no, no, we are doing this and here's my script. - So documentation winds up being an important factor in that, that makes sense. And so, I think this is the crux of understanding how accessibility fits into a organization all up. Accessibility is a systemic problem, it's not any one person's problem. It's not any one segment of the system's problem. It is the system as a whole that can create inaccessible environments. So whenever we think about solving for accessibility within organizations, we likewise have to think about it from a systemic solutions perspective. And I think, for me anyways, that's why it fits nicely into how we think about SDLC and that's where we've coined this phrase, continuous accessibility. So when we think about continuous accessibility, it's really how do we fit accessibility into all parts of the application development process from business idea to delivery and feedback? And really we can take all of these pieces of software delivery and break them down into four main segments, idea, development, testing, and delivery. And the thing we'll talk about first is the idea phase, where really, you can think about it as a strategy phase. So this is where the business gets involved. This is where the business says we wanna take this seriously, we care about our customers. We care about our internal employees. We want to do the right thing and or we've got some legal risk whatever the motivating factors are for your organization. It starts with that strategic look, what do we want to do? How do we get there? And then we start flushing out those business ideas, how we want to move forward from an accessibility perspective, when it comes to requirements gathering and then creating UX and mock-ups and features that have that notion of accessibility baked in. And that requires a lot of knowledge and a lot of expertise, which some organizations have and have hired for specifically, but some organizations don't. And that's where sometimes leaning on a third-party vendor like TPGi can be helpful. Now we've taken that as an approach to try and servicize everything that we do as a consulting organization. But again, that's not a requirement for you and your business to have to do, but this can be a very overwhelming process especially if you're new to it and you've never gone down the path of understanding accessibility and what that means to your organization, but what are some ways that people can kinda get their heads around that and think of accessibility from a strategic point of view, Mark. - Yeah, So that's a good question, Chase. And the answer can really vary according to the organization, what their current capabilities around accessibility are and what the specific needs are. But typically speaking, out of the gates, sort of the traditional approach has been these accessibility reviews or audits where you are uncovering the variances to the guidelines, helping the client, in our case, understand how to address those issues and then maybe coming back in and checking it. But to your point, talking about the whole SDLC, accessibility is really ongoing. So doing that activity on an ongoing basis and that could mean anything from an annual review to actually integrating that kind of activity into your sprints, where you're not looking at the whole site all at once and fixing the whole site all at once, but you're actually breaking it down into chunks and working within your sprint cycles to do that level of review and check and then really having someone either internally or an expert, a consultant outside that just look at your overall program and direction so that you can make sure that you're integrating accessibility across all different process areas in the organization, that you have things like prioritization in place and that you're creating something that's sustainable. You don't wanna be in this situation where once a year you think about accessibility, you call somebody like us up, we do a review, you fix everything and then forget about it for the next whatever, six months, only to kind of be back in that same position a year later. It's really about in our approach to this is a really one of a managed service approach instead of individual services, to give you an idea, but it's really about looking at your organization and figuring out how all these things can fit day to day and over time. - And anecdotally, I have seen over the last couple of years, a rise on job boards, whether that's LinkedIn or Monster, wherever people typically go to look for new jobs. I'm seeing more and more accessibility program managers, more and more accessibility-focused roles within organizations, so it seems like the strategic element is really gaining a lot of traction and in corporate environments at large or at least that's been my experience. Have you had similar experience over the last couple of years? - Yeah, absolutely, I mean, I think that the need for accessibility largely has grown and then the overall desire to do it in a way that's more efficient and effective for the organizations, absolutely. - That makes sense. So after we get to a point as an organization, that we've decided that from a strategic perspective, because of all of the various implications that we want to take accessibility seriously within our organization, then we get into kind of the nuts and bolts of this. How do we fit this? And as a part of our development processes, when we think about development processes, we generally think of it in three phases, code, review, commit. What's great is there is a lot of tooling available in all three of those phases that can help create more accessibility within organizations. And that's where dev ops engineers, you folks that have joined us today, can play a huge and meaningful role within helping to create accessibility within your organization. Because there is a lot of automation that can happen and while automation won't solve all of the problems, it can at least create some intelligence and some awareness of where your organization stands on the things that an automated system can understand. What's difficult from an automation perspective, there's always gonna be things that automation just can't glean because when we think about what makes things accessible, it's can I do a task? Do I have any barriers to doing that task? And so automation can look at those individual components of doing a task, but the whole process of it, that's really where humans have to get involved and create the kind of meaningful information. But what we have found is where there tends to be gaps in the things that are discoverable via automation. They tend to reside hand in hand with issues and barriers that can only really be discovered manually. And that's where we get into testing. So part of good accessibility within an accessible SDLC pipeline is baking accessibility into your testing, both from a functional testing perspective, as well as your automated unit testing and integration testing. So not just does this work via some parsing tool that will give you some insight, but does this actually work against my real live environment, against real live browsers? Because the difference between what you are inspecting in your IDE versus what is going to happen with a real browser in a real environment is gonna be very different. And so baking tools in technology and that's gonna help you with that would be hugely valuable towards simplifying and automating that process to get those kinds of insights, as well as from, as Mark was talking about, that documentation perspective, much of this type of technology that's available out in the world will give you tools in order for you to track and document that accessibility through its lifetime. So that way should litigation become a factor for your organization, you've got a trail and you can say, look, here are the things that we're doing. Here's where we're trying to embed accessibility deeply into our products because we care because we wanna do the right thing. But if you could speak a little bit to some of the other technologies available. - Yeah, so of course we use, at TPGi, we use quite a bit of technology and make that available to our customers and so to everything you're talking about, Chase, the ARC platform is really where we centralize all of that. And that would be doing automated testing or monitoring. So monitoring is really automated testing on a cadence so that you can be collecting, like you said, that you're only gonna catch maybe depending on the nature of the asset, 30 to 40% of the accessibility issues through automation, but that can inform so much. So one, it can inform the overall level of accessibility. So you have a good idea of baseline of how accessible something is and tracking that over time can start to demonstrate progress. So maybe we've done a manual review for you and you're fixing all those issues. Based on what can then be detected through automation and scanning. You can watch your number of automated issues drop and that supports your statement to anybody who might need to make it to that you're making progress with third-party objective data and documents that to your point. And then that same sort of practice can continue on so that if accessibility issues are injected, you see that right away, you're not waiting for an arduous, manual review or something, you see it earlier on and can react to it earlier on. And then you can use those analytics to really understand why and where those things are happening and where you might need to step in and extend that look more manually to your point. So it's not just about tracking that data, but it's also about using that data to really be very intelligent about your other efforts and using that data to prioritize those efforts, to understand what's going on. The beautiful thing is that it's learning or knowledge transfer is a huge component in properly doing all these things that you're talking about, Chase. So for instance, we do live training. We do these kinds of webinars, but we also have an entire library of e-learning content that sits in the ARC platform and best practices documentation and through our knowledge base on the guidelines, all that kind of thing. And it contextually ties in to the information you're getting about the issues that you have. So you have an issue failing to a guideline, that's an assertion meaning that there's something wrong or something that needs to change in the code. And then that goes back to the content that shows you how to change it. So the whole thing becomes very, very manageable. We also have, and this is something out there, if you're listening right now, you can actually type ARC, A-R-C, toolkit into the Chrome store. And there's a free Chrome extension, very, very powerful tool. And you can start playing with this right now. So you don't need to even spend money to start using technology. And what this will do is you can scan a single page as many times as you would like and it uses the same rule sets as our platform to come up with issues. It has contextual remediation advice on kind of a light level in there. And this is really the tool that a developer themselves, Chase, would use. So if you're thinking like a Shift + Left, we wanna include accessibility into our code before it even reaches production, then this is the kind of thing that a developer would really need to be able to initiate at least these automated checks, kind of the low hanging fruit you can think of it initially. And then of course, on the other side of it, in QA, it's a perfect tool for QA. So that's something that you guys should run out and check out right now, if you can and all these things sort of come together to create that ongoing experience and to give real data that you can collect as one part of that data collection that you were talking about. - And just, again, to be clear, there's a lot of products and vendors and services out there that make accessibility tooling to help you with this process. And to us, that is the most important thing, is that you are creating accessibility within your organizations. Obviously we'd love it if you lean on us for some help, but the fact that you do it is more important than anything else for us. - True, that's a great point. - And the last thing you know in this SDLC process is the delivery, because you've had your strategic plan, you've created it, you've tested it, you've gotten out in the world and then uh-oh, you find that it didn't go quite as planned. So that's where having that type of monitoring in place, that's where having feedback systems that bake in into your SDLC process and to your ticket management process for how you receive bugs, feedback, et cetera, from your users, getting all of that, where accessibility is at the forefront, is going to really be what makes or breaks your accessibility program within your organization, because it's great if you start strong, but then if three months, six months, eight months down the line, once things are starting to deliver, that enthusiasm wanes, and there is not processes and procedures built in that help keep accessibility at the forefront then in another year from there, you're just gonna wind up in the same position that you started with where you're unintentionally excluding people from using your services and features and offerings. And so it really has to be that holistic solve, where at the end of it, we're thinking about what we've done retrospectively and ensuring that we're continuing to get better and better. There is no best, there is only better. You never reach the precipice, you only go towards the precipice. So whenever we think about that kind of post and whenever people need additional guidance, additional help, et cetera, what are some of the things that we do to help our customers from that perspective, Mark? - I think we've kind of talked around some of these things just in the presentation so far, but to boil them down to kind of the specifics HelpDesk support issue, just having access to an expert, no matter how much self-help you have, no matter how good you are, the developer out there, even the best developers when it comes to accessibility, they can be very, very good at it. But at the end of the day, they're a developer creating web products. So accessibility, they're not focusing on it as a core function like an expert consultant would. So there's gonna be times when even that person needs somebody to reach out to. So having that level of support, having access to training, like everything else, even though you may observe that the guidelines don't change real rapidly, they do change. We went from 2.0, to 2.1 back in the summer of 2018. I believe it was, if I'm remembering that right. And we're looking at 2.2 soon and they're talking about 3.0, but it takes a while. To churn through that, the techniques, however, Chase, they change rapidly, as soon as we start to do something different on the web, that changes so having access to training so that you can continue to learn is super important. - And with emerging technology and technology ever shifting, I imagine that plays a huge factor in that in all of those standards. - Of course, absolutely, it does, it does, yeah and then just the last thing that I'll say is having access to accessible UX services, somebody who really understands how to create experiences and do things like evaluate your site and help you design and maybe audit your designs before they go in and all those types of things. The earlier on you think about accessibility, the more you bake it into something like design, the much easier time you're gonna have, when it comes to coding and continuing to include it throughout that process. So a lot of people don't think of that. You hear from them right after something like design has occurred. And they're like, oh, it's too late. And it's not the end of the world, but certainly much easier. - And then from a technical perspective, what I would recommend to all the folks here, is if you are using any some of these modern toolings like React or Vue or any component or Blazer or any kind of component-based system, component-based systems have really changed how we can think about accessibility as a whole. And that itself will be just a whole talk on its own. But so, having help from that UX perspective and how you can think about component design can have huge meaningful impacts on creating accessibility from the ground up and making it easy to maintain. It doesn't have to be something that's difficult or rigid or this thing tacked on top. It can be just part of what you do. And from our own internal practice, we find this to be the case and to be hugely helpful and beneficial. But just as a reminder, there's a ton of tooling out there that can help you guys get more meaningful insights about the accessibility of your products. Make sure you've got some tooling to check accessibility while you're developing. If you start going down the automation path, depending on how strict you want to be, more and more organizations are starting to gauge accessibility as a part of their check-in and deployment procedures as a part of that automated deployment and testing as we talked about using real browsers and using real test harnesses against your actual production environments or lower level production environments, perhaps your dev stage and QA, whatever your lower environments are. Deeply integrating the results of that output with your ticketing system, however you manage and track needs, tasks, bugs, et cetera, start thinking about accessibility problems as just UX bugs and bake it into that process and prioritize them. And then having some type of access to knowledge, Stack Overflow is a thing, but it'll only get you so far. So make sure that you're making some kind of investment into your organization around knowledge and how everyone within the organization can be baking accessibility into what they do. And then on some type of cadence, whether that's quarterly, biannual, annual, make sure that you're getting some type of qualitative review with an expert that's outside of your own organization, to make sure that you're staying on track and that the strategies that you're employing are working as you expect them to. If we think about continuous accessibility from an automation perspective, and from a CACD perspective, we can think of a couple of different parts. So the development phase, that's where we can use tools like ARC toolkit free on the Chrome Store or the ARC API for doing automated unit testing. And then as we start to deliver that, as we get into building it and delivering it into staging environments and running tests, we can use things like the ARC test initiatives, which help us know whether we are improving accessibility, staying the same or meeting some criteria that your accessibility program manager set up that help to define goals and outcomes for your organization from an accessibility perspective. And then if those pass moving forward into that continuous scanning of your production environments at whatever clip makes sense for you, maybe that's daily, weekly, monthly, you name it, that's entirely up to you and your organization as to what kind of cadence makes sense for making sure that your production environments are continuing to see improvements over time for their accessibility. Now, granted, any of these things can be done via other methodologies. Heck even if you're keeping an Excel sheet, what's important is that you are keeping track of that data, that you are keeping track of where you have been, where you're going and how you got there. So some best practices, I'm just gonna rip through these real quick, so that we've got time for Q and A, make sure you're making an investment for success and investing doesn't just mean dollars. Investing means training, resources and the commitment at all levels of the business to say, yes, we want to care about our employees and our clients. And we want to bake accessibility into what we do. And so striving for inclusivity in those business processes and decisions, then leaning on experts, both internally and externally, you're gonna have employees within your organization who do care deeply about accessibility, who are experts. You're going to have individuals who have a disability and so listening and understanding what they go through and what they need on a day-to-day basis. And using them as an expert resource to help build better projects and features within your tools and programs, et cetera. And then where possible automate as much as you can because it just simplifies the life of everyone involved. It takes a little bit to set up, but once it's set up, it's set it and forget it. So just real quick, Mark, if you want to kind of recap everything we've talked about from an accessibility lifecycle perspective and then we'll get into some questions and answers. - Yeah, for sure. So if we kind of take a look at what we've talked about throughout this discussion, obviously manual reviews and audits are a big part of this, whether you're reviewing the entire asset all at once, fixing it and kind of having us come back in and make sure it's done correctly or you're doing it in pieces within your sprint cycles or maybe you just had a lot. And it makes more sense to look at a specific flow and address it and then check it and move on to the next. It's a very important piece of all this in understanding the value of actually testing it manually. I think somebody put a comment up there saying that you could bring people with disabilities in and they made the point that you would do that after the experts. So that's typically absolutely right. Once the experts have looked at it and you know you're conforming to the guidelines, if you wanna improve user experience, you can extend that to people with disabilities. Once you know what's going on, addressing those issues is important. And then using automation to track, to analyze what's going on over time as an early warning system, to measure progress, all those things, it's very, very important. And thinking about all areas like the final code base, the design reviews, all aspects, including accessibility and all those things from a UX perspective is important and one thing can lead to success in the next thing and then of course having a good process in place to really QA and verify that all of these efforts are equaling an accessible experience on the production end of things. - Awesome, so continuous accessibility is really, again, it's about inclusivity. It's about making sure that people aren't excluded from your products, from your services and from what you do on a day-to-day basis. And so baking in accessibility within your organization, isn't just about legal risk. It isn't just about mitigating those types of legal issues. It's about people, people first, it's about making sure that we're creating an environment where people can do what they want to do and the way that that works for them. And so as you continue down that pipeline, try not to lose sight of that, that at the end of the day, you're working with people and they're what matters. With that, thank you very much for listening. We're gonna take a look at some of these questions that we've had. Check us out at TPGi.com, we've got a blog. We've got the great broadcast that Mark mentioned earlier, as well as a lot of helpful information and free tools, et cetera, on our website, TPGi.com. Make sure you check that out. I'm gonna take a look at the questions and answers here. - While you do that, Chase, I just wanted to address one thing that's popping up in the comments right now, which I think is a really, really good point and one we probably should have made better along the way. And that is that this is a lot and there's no light switch. You're not gonna turn around one day and have all this in place, it's not gonna happen. So the important thing, and typically that's with a manual review, the important thing is to start somewhere, start making progress. If a manual review is out of scope for what you can manage, maybe an automated scan and starting to address some of those issues is a place to start. Maybe even just with the ARC toolkit is a place to start. But the point is, is that you're absolutely right if you think about the whole thing, it can be overwhelming. So really identifying some low-hanging fruit, a great place to start, but keep in the back of your mind that you're on a journey. So you've got to keep making forward progress. You can't do any of these things and then sit back and say, well, I did something I'm all set. - Yeah, exactly, I've got a great question in the question and answer section. - Hear it. - We got access to a contractor that comes in once a week to help us with compliancy. When it's not convenient, they're not being utilized and so it sounds like they're having a problem with buy-in from upper management, who should be leveraging the resource, but they're just not. So how can they, as an organization, get more buy in from management whenever it comes to accessibility? And I'll take a quick stab at part of it and then I'd like to turn it over to you, Mark, if it's alright. From my perspective, it's about, one, understanding who the right person in management is to talk to. So you've got to kinda have both segments. You gotta have the sales and business side of the conversation, as well as the engineering side of the conversation. And if you want, buy-in the question ultimately has to come down to what's in it for me? And that's sad, but it's how business works. And so if you can paint from that perspective, what is it that the leaders in those two segments want to get out of the business and then frame accessibility in those. Because as we discussed earlier, accessibility, doesn't just make sense because it's the right thing to do it. It can make dollars and cents for your organization. I'll leave it to Mark to finish up on that. - Yeah, it's a super interesting question. And one that comes up a lot, in fact, so much so that I used to, pre-pandemic, give a talk live on this very subject and it comes down to a few things. One is evangelization. That's the overall category of what you have to do. You really have to figure out a methodology to do the things that Chase is saying in terms of getting people to understand all aspects of accessibility, the reason why it's important to other human beings, the reason why it's important to the business, the risk to the business, a lot of these things that we talked about today, and that can be done through training, that can be done through integration, if you're a champion within your organization, making sure that you're championing. Bringing accessibility into things and bringing it up whenever it's appropriate is important. And if you look at the model for behavioral change, I think it's a really good one for this. And it sort of goes something like this, like, there's nothing going on. You decide that you want to make a change, which is really where this question's coming from. Then you try and implement that, so you do your evangelization and then that happens and there's some degree of success because with evangelization, you know can get people rah-rah behind you, you know you can get people to start to change, but then sometimes they fall off. They get busy, life gets in the way. So being able to go back to the top of that, recognizing when that's happening, going back to the top of the model and starting over again and continuing to cycle through that and as you do learn from the lessons of the previous cycle, you'll eventually get there. It's my sort of long winded way of saying don't get frustrated, keep trying, keep saying the things and some of it's timing, you might say this one day and there may be litigation showing up. That would be an unfortunate way for it to happen but I've had that. We've been thinking about this, now we have a demand letter. Now we're gonna do something about it but you just want to sort of be that appropriate constant champion. There's no better answer. - And when we talk about evangelism, I think that segues into this next question pretty well, how do you enforce developers to comply with your SDLC? And I'll pick that one up, you don't. Let's start there. Like you can't force anyone to do anything. So evangelizing accessibility within your organization is step one, treat people like they're adults. You've got smart engineers, they want to do what's right, I guarantee you, they do. And so, whoa, where's this ? So treating them as competent intelligent individuals, that's a huge part of it. But then beyond that, as a part of that evangelism process, bringing them in and saying, okay, together, let's create a solution that we can all agree on for how we wanna get from point A to point B. And that might be things like automated testing. That might be things like peer reviews as a part of your check-ins. Maybe if you're not doing a pull strategy for how you get new features in, you are moving to that model. And as a part of those code reviews, accessibility is always one of the first questions asked as a part of that but ultimately it can't be forced. It can't come from one person within the development group. Everybody kind of has to agree with it, but I promise you, if you evangelize it and you go down that path, people do want to do the right thing and you can create that good environment for that, great question. - Chase, I just wanna say, as you've been talking, the participants have been adding some great insight to some of the things that we're saying. So if you're not paying attention to the chat, take a look at the chat. There's some great additional information and advice with these things that we're answering here. - Awesome, I will take a look through that. Are ARC and aXe similar tools? Good question, so ARC toolkit, what's available on the Chrome store, and aXe are similar tools in that they are both automated accessibility checks for looking for accessibility problems on pages. ARC, as a full suite, has a lot of additional features and enhancements available to how you can create accessibility program management within your organization at large, great question. Got another question here. Should UX designers be more trained on guidelines, your views on it? Mark, I'll leave that one to you. Should UX designers be more trained on accessibility? - Absolutely. We've been talking about evangelization and integration and all that kind of stuff and of course, you need to not only be trained, but have access to resources. And if we go back to our ARC platform just for a second, e-learning modules and knowledge-based articles. Even if you know what you're doing, you need a place to look up stuff and all that's very important. And going back to our statement that the earlier you integrate accessibility. So if accessibility is showing up in the design phase, the easier time everybody will have, including it down the road as well. So more training is always a yes answer. - Always. - Or knowledge, good. - And I think it's not just UX, I think to what you were saying earlier, I think making sure that management is trained, making sure that everybody who's a part of the SDLC process is trained and has the tools available to them. And when I say tools, we don't just mean technology. We mean like the cognitive tools to be successful. 'Cause really we want to set people up for success. - And to understand how their role contributes to accessibility. - Absolutely. - It's a huge part of that training. - So I'm gonna get one more question here, and then I think we'll be done. On the coding web development side of things, is there a specific language TPGi specializes in? Is it primarily JavaScript, HTML, CSS, Swift, Java? So this is what's great. So at the end of the day, if you're dealing with web technologies, specifically, all web technologies ultimately generate HTML and CSS. So whether you're using C#.net to generate your html CSS, whether you're using Angular, React, Swift, Java, Ruby, Python, et cetera, et cetera, et cetera, et cetera. At the end of the day, ultimately what gets generated is HTML and CSS. The tools that we offer work regardless of what language that you're in or what kind of platform you're on, whether you're in Linux, Windows, Mac, et cetera. But there are countless, countless ways to make a website. And so we try to take that into mind and create generic solutions that it doesn't really matter what your organization does and how that makes sense for you from how you program, we can help make sure that the output that you're creating ultimately is accessible, great question. I think that's it on the question side, Mark, anything you want to close with? - Yeah, I would just reiterate, start somewhere, get your toes wet. Start thinking about accessibility, great resources with the W3C. Some of you guys are asking about resources, check out the W3C, check out our blog. There's a lot of information out there on accessibility. And if you're really trying to encourage this in your organization, keep towing the line and keep trying different techniques and it'll happen for you. - Real quick, I wanna respond to Elizabeth Dunn's comment about it's hard to be an evangelist because you're perceived as a squeaky wheel, but with all the eye rolling, I find they're responding to developer designer accessibility questions, like why should I have to underline questions and things like that. So ultimately you don't have to be the squeaky wheel. That's what's great. And that's where like the beauty of evangelism comes in. Understand like trying to find that middle ground and understand like where you've missed somebody on the point of the thing 'cause I guarantee you, somewhere along the line, if somebody is perceiving you as a squeaky wheel, they've missed the point. And so helping to really listen to them and understand what's painful to them about the process of trying to be more accessible and then tailoring to a certain degree the feedback life cycle so that everybody's on board. It's not easy, but it can be done. And that's really where where like listening, understanding, and empathy comes in because like when you're dealing with engineers in many organization, most engineering groups are understaffed, overworked, they've already got half the organization yelling at them every day. They're like, you gotta get this done, you gotta get this done, you gotta get this done and so trying to be empathetic towards that and trying to help understand how you can bring accessibility into what they're doing in a way that they get excited about in a way that isn't just another person brow beating them is hugely beneficial from that perspective. - Thank you, thank you, Chase and I just wanna say thanks to everyone who participated and thanks to the great comments and additional advice that showed up in the chat. I really appreciate that level of participation and the thoughtful advice. That's it. - That's it, thank you everybody. Thank you for joining. - [Mark] Thanks a lot, everyone.