- Good morning, good afternoon, good evening, everyone. Welcome to this webinar from Vispero and TPGi, Building a Complete Accessibility Program: From Audit to Long-Term Inclusion. First of all, some housekeeping information. Captions are available for this webinar. Use the Zoom Show Captions feature to enable captions if you need them. Please use the Q&A feature of Zoom to ask any questions of the presenters. We'll be monitoring that during the webinar, and we'll make sure there's time at the end of the webinar to answer any questions submitted via the Q&A feature. We will be sending a link to the recording after the webinar to everyone who registered. We'll also share a copy of the slide deck with everyone who registered immediately after the webinar. So welcome to today's webinar, Building a Complete Accessibility Program: From Audit to Long-Term Inclusion. My name's David Sloan. I am Vispero's Chief Accessibility Officer, and I'll be co-presenting this webinar along with my colleague Amy Major, who I will now hand over to introduce herself.

- Yeah, hi everybody. Thanks, Dave. My name's Amy Major. I'm a practice manager here at Vispero, and I've been in accessibility for about eight years now. So finally not a newbie anymore, so I'm really excited to talk with everyone this afternoon and see how we can help.

- I don't know if we ever stop being newbies, Amy. The more we spend time in this field, the more we discover we don't know.

- True.

- So today, we are going to focus on accessibility program development, and we'll start setting the scene by talking a little bit about accessibility maturity as a framework for understanding where you are in terms of accessibility efforts and how to move forward. Then we'll look at how to get started with accessibility program development, and in particular, looking at accessibility audits as the activity that many organizations will start with in terms of their accessibility efforts. Then we'll pivot to thinking about using the audit, the accessibility audit as a way to introduce an accessibility program. And finish off with a brief overview of how Vispero can help with accessibility program development and end with questions and answers. So again, please use the Q&A feature to ask any questions that you might have during the webinar, and we'll answer them at the end. So setting the scene, let's think about, well, first of all, what motivates accessibility efforts? And we find that accessibility usually starts in an organization through a number of different trigger factors, and one of them is lawsuits. And that might be anticipating the potential of receiving a lawsuit, thinking about a risk management strategy to avoid getting into a trouble, perhaps because competitor organizations or other organizations with similar profiles have experienced lawsuits and an organization thinks, "We don't want to go down that road. Let's start thinking about accessibility as a way to avoid this risk." Or the risk may be real. It may be the case that the organization is dealing with a legal complaint or has agreed a resolution, and that includes implementing some form of accessibility program as a way to move forward. Then we can think about more progressively towards meeting demands for accessible products. Maybe it's a business to business relationship where an organization supplies digital products and services to public entities or other regulated industries. Those organizations, those customers have accessibility obligations and you, as a supplier, think, "Okay, if I'm going to maintain relationship with this customer, then then we need to be thinking about accessibility as well." Or you may be seeing it as a way to keep up with competitors. You realize looking at the business landscape, looking at what other peers are doing, they're thinking about accessibility. This is a motivation for an organization to start thinking about accessibility as well. And then there's the realization that accessibility, investing in improving accessibility for people with disabilities really means designing a better product for a growing proportion of its target audience. It's a quality factor. It's a way to drive improving how something is built and improving how well it serves its target audience and potentially increasing the size of that target audience. So when we look at these motivators, we start with risk, risk avoidance in terms of avoiding a lawsuit, through to identifying an opportunity to improve product quality. So depending on that motivation, the nature and impact and structure of an accessibility program may vary. Now, organizations are all at different stages in their accessibility journey. Some organizations know exactly where they are and where they want to go and what they need to do to get there. But others may need some guidance in figuring out where they are and identifying what makes sense to invest in to move forward to advance accessibility. So establishing a sense of organizational accessibility maturity helps an organization identify current state, where are they now, and how to advance to some better future state in a sustainable way. And that sustainable way is something we're gonna come back to throughout this presentation, because it's all very well investing in a project to improve accessibility, but if there's no capacity to sustain that effort, then the chances are that you'll regress to that earlier state of having products with significant accessibility issues and that risk remains of potential trouble or loss of business. So advancing to a better future state of accessibility maturity is always the focus of an accessibility program. What does organizational accessibility maturity look like? Well, there are a number of different ways that we can use existing maturity models to measure accessibility maturity, and to identify what organizations look like at different maturity levels. At Vispero, we like using the W3C's accessibility maturity model at w3.org/tr/maturity-model, if you want to go and investigate that further. And based on the maturity models, definitions of level, or different levels of maturity, we've kind of summarized and paraphrased them in the table I'm showing on this slide. And at a level zero, an inactive level, key characteristics of an organization at this state of maturity are there's no organized accessibility efforts. If anything happens, it's ad hoc, it's at a grassroots level, and it's limited in scope and visibility. There's nothing intentionally done to think about accessibility. And as a result, digital products that are produced by that organization, whether they're websites, documents, software, whatever, have a very limited level of accessibility. At the launch level, there is now an awareness of accessibility is something important, and that might be, as we've mentioned previously, because it's considered a legal risk. Or maybe it's something a little more progressive, a little more opportunistic. And some activities are starting to happen. Maybe one or two accessibility specialists have been identified or have identified themselves within the organization and have started doing some work. But knowledge is still very limited, not well distributed across the organization, and there's no real definition of accessibility as a process in anything that implement or affects the digital landscape. And as a result, digital products likely still have pretty limited accessibility. Maybe there's one or two exceptions where somebody's had positive influence, but that's not consistent across the organization. And then as we move to a more mature level where accessibility is considered managed or integrated into processes, some models may separate this level into two models. For simplicity, we keep this as a single level for this slide. An accessibility program has been established and there's staff and leadership support, maybe some sponsorship, maybe some budget. Accessibility has begun to be integrated into policy and processes that influence digital resources, knowledge and skills developments underway and tools are widely available to support accessibility efforts. And there's a demonstrable and measurable impact on digital product accessibility. It's improving, but there's still a level of reactivity that accessibility follows after other decisions have been made. So at the highest level of maturity, at the optimized level, accessibility is there as a core value of an organization that influences culture and it influences digital strategy. Decisions to move forward, innovation is made with accessibility as a driver, as an influence. Accessibility is embedded as a core professional skill of all employees who are involved in digital resources. And accessibility progress is captured and used to enhance and adjust strategy, data's measured or collected, and decisions are made based in data. And ultimately, the biggest indicator of all, digital products achieve and maintain high levels of accessibility over time. Now, that third maturity level is really very aspirational. Most organizations are working toward that, may have achieved it in some areas, but not others. But it's certainly there as an ideal future state that we consider as the ultimate success indicator of an accessibility program. What does accessibility maturity look like in terms of what it covers across an organization? Often, we look specifically at the process for building digital resources like websites, software applications, mobile apps, documents, all those things. But there's more to organizational accessibility maturity than process of building digital resources. There's the accessibility of how information is communicated internally and publicly. There's the focus on knowledge and skills development, the goal of trying to distribute role-based knowledge across the organization rather than relying on one or two subject matter experts. There's the oversight and culture dimension, the extent to which accessibility is integrated into policy and process and decision-making, and part of an organization's identity. There's the focus and personnel, that the extent to which an organization actively seeks to grow its proportion of employees with disabilities and ensuring that the workplace is inclusive and accessible to people with disabilities. There's a focus in procurement of how well accessibility is integrated into processes for acquiring third-party information and communication technologies. And then a support dimension that focuses on how well support is provided to customers or users of digital resources with disabilities, including when accessibility barriers are present and people who are affected those barriers still need to be supported. And again, we draw from the W3C accessibility maturity when we think about these seven dimensions. And these dimensions all interrelate, they all support each other. Ultimately, if our goal is to provide and maintain accessible digital resources, then the process of building those resources is critical to that. But all of these other components of accessibility maturity help build that momentum and build that sustainable goal of creating and maintaining accessible resources. Now, clearly advancing organizational maturity requires deliberate planning and requires intentional support. And organizations might realize that they need to identify the scope of a program if they're going to implement an accessibility program based on those maturity dimensions. Some organizations might feel, well, we're gonna start just by focusing one or two dimensions, and then we may broaden efforts depending on the support that we have. Organizations will need to establish goals in order to en ensure that the program has a target, has a purpose, has a success metric. Then there's the challenge of securing budget, staffing and leadership support to implement the program, which, again, the success of that will affect the scope of the program, what's achievable. So some big questions there. So how do you get started, especially when accessibility at the moment is a grassroots effort and hasn't yet been identified as a key business strategy? Well, one way to do that is to think about the potential that an accessibility audit provides as a ignition for accessibility program development. Now, when we think about accessibility, as I say, we earlier looked at seven dimensions of accessibility. Right now I'm gonna focus just on the development lifecycle, the process of building a digital resource like a website. And often at early levels of maturity, accessibility happens right at the end of the development process, if it happens at all. The slide I'm showing just now shows a process diagram starting with Specify, specifying what a digital resource, what kind of functionality it should have, what content should have, what purpose it should serve, what goals it should help users achieve if it's successfully implemented. Then there's a design stage, the development stage, and the testing stage at a very high level, that's how the development cycle is broken down. And at early stages of maturity, accessibility, if it happens, often is only gonna happen at the test stage. Once the specification has been written, once the designs have been confirmed, once everything has been developed in code, then we start thinking about accessibility. And that's generally when it's most difficult and expensive to find and fixed issues. So it's not a great way to focus on ensuring that a product has accessibility, but it is, in reality, where many organizations start. And that's okay, the focus is on trying to improve that situation over time by what we has come to be a fairly recognizable term in the accessibility field of shifting left, moving accessibility earlier in that design lifecycle or design and development lifecycle. So accessibility is considered right at the start in specifying what's to be created, in designing what's to be created to meet those specifications or requirements, in development and implementing those designs and code, and in testing. So testing is still a place where accessibility is involved, but ideally the number of issues found during testing is far lower because accessibility has been thought about throughout the design and development life cycle. So our challenge is implementing an accessibility program to successfully achieve this goal. And accessibility audits can be a great starting point and are often the first place that an organization starts when thinking about accessibility. They may conduct an audit themselves or engage a third party to conduct an audit of a product. Often, this is reactive and very specific. It might well be responding to or anticipating a legal complaint. "We better find out how accessible our web application is before we get into trouble." The audit may be confined to very specific digital resource based on very specific characteristics, for example, at the request of a customer, or a product leader or because it's considered an organizational priority, or because it's the most often used or highest traffic resource, let's focus on this single resource. And it's all great. Audits are there to help identify accessibility issues and give a sense of the level and complication of work needed to address them. So it really helps you focusing efforts on fixing issues. But effectively and sustainably acting on audit results requires resourcing, it requires some level of expertise, and it requires a level of strategic management if those audit results are going to have positive impact and not be left on unaddressed and decaying over time because after a while the resources changed such that the audit results no longer make sense because functionality has changed. So there are some limitations with the reality of how accessibility audits often become the first as part of an organization's accessibility strategy. Looking at how they should be used more strategically as the start of a program, the ideal context would be, first of all, that an organization deliberately inventories all its digital resources, its websites, its mobile apps, its documents, its software, whether they're public facing or employee facing, so that, first of all, there's a sense of what have we got and what do we need to find out is the level of accessibility. Then prioritize that list, that inventory, based on accessibility, risk and opportunity, which may include some of those factors we talked about earlier, business needs, internal or external, frequency of use, function of the resource, compliance needs, regulatory risk and exposure. And then audit each resource in prioritized order so that you can establish an accessibility baseline for each resource. And this is all especially helpful for an organization that's either directly or indirectly facing regulatory challenges, excuse me, such as Title II of the Americans with Disabilities Act or the European Accessibility Act. So audits should be seen as something that tell you where you are, but also are a way to start providing insights to how you can build an accessibility program and what that should look like. And at this point I'm gonna hand over to Amy to help us go from audit to program.

- Thanks Dave, and I apologize in advance. I have an overzealous tabby who has decided that he needs my attention immediately. So if you see a tail swishing around, you don't manage cats, cats manage you. So I apologize for that distraction. So Dave's been talking a lot about how, ideally, accessibility programs should be created and planned through. And honestly working in accessibility for the amount of time I have, most people come to us first with, "I need an audit, I need to test this site. We wanna see what issues we have and where our risk is." And that's a great place to start and actually can give you a lot of insights into what you need to focus on for the rest of your accessibility program. So using an audit, you can help kind of establish your accessibility baseline and figure out how to deal with issues and then at more of an organic level, and then take steps to reduce the chances that those issues will reoccur. So in terms of you can do a deep dive on audit results and see where and when did issues occur. Do you have processes in any of those stages of your lifecycle, design, development, content creation, where you can adjust processes to help shift that accessibility effort left and integrate it into the process earlier? Additionally, audits can also be really good at spotlighting training needs, both in terms of what types of issues and development teams need additional training on, as well as if you have multiple teams working on development and design, which teams have a better understanding of accessibility and which may need some additional training and support as you move forward. You can also look at your issue patterns to determine are there things in your templates that are inaccessible that are then occurring in multiple locations or on multiple sites within your overall web presence and your applications. If you can figure those out and then fix them in your template or your code library, that gets you a lot of bang for your buck in terms of doing remediation without having to go through every single issue on every single page. Another one that's not always thought of right away is procurement. We see a lot of sites where people have third party or vendor content in a widget or a header or a footer or some part of their site, and that's something that we need to address with the vendors themselves. So you can look at where those issues exist and figure out what your procurement strategy is gonna be and how you're gonna work with your vendors to help push them to be more accessible in what they're providing to you. We also wanna look at UX needs. Are there issues that indicate that your overall user experience is not ideal and could be enhanced for people with disabilities? As many people who are in accessibility or aware, testing the code definitely shows you where issues are, but having an actual person with a disability using assistive technology to go through a site or an application will show you those blockers very quickly and tell you if your site is actually usable or not. And finally, we want to pay attention, identifying issues is fantastic, but we wanna be sure that we are not only documenting those issues so that people who may encounter them and can't use a site or can't use parts of a site or an application are aware of the issues and are aware that you're aware of the issues, but also what workarounds can be done in the meantime to help provide support to people that those accessibility issues will be blocking so that they can still be and efficient in their work while issues are being remediated and addressed. So there's a lot of different things that can come out of an audit that can help you kind of identify where you wanna go with your overall accessibility strategy. And as Dave mentioned earlier, there were key components to your accessibility program. And the key thing with any accessibility program is that it's very easy to get overwhelmed early because you look at, "I have all these things to do in all these different areas," but you can really break it down into a few key components. The first one is obviously training, and that's not just general training for everybody to be aware of accessibility and what it is and why it's important, but also having role-based accessibility training for both technical and non-technical people. So you wanna make sure that your dev and design teams obviously have accessibility training, but you also want people in procurement and in leadership to understand what accessibility is and why it's important, so they can not only help with buy-in but help understand how it relates to their day-to-day job. You also wanna be sure to integrate accessibility into your design and development lifecycle, including your QA testing. And that's something that we encourage, as we work with clients, we encourage, the earlier you can integrate that, usually the better off you will be down the road because this is definitely, accessibility is definitely something where the more focus you take early on, the less remediation you have to do down the line. As I was mentioning previously, including people with disabilities in your user experience, not only in your testing but also in your research and design as you are creating sites and creating products, include people with disabilities who are using assistive technology to access your products into that research and design experience so they can tell you, "No, that's not gonna fly, we need to think of something else," early in the process so that it's not just being tested and then being reflected as an issue. Including in your procurement process, this we'll get into in a deeper dive a little bit, but just how are you gonna work with vendors? How are you gonna emphasize that accessibility is a key goal of your organization and they will be expected to provide accessible digital assets. And finally, with any program, you need to not only know where your goals are and what your policy is to help you achieve those goals, but you also have to figure out how you're going to report out progress on those goals and figure out what your success criteria are. And the biggest thing to remember with governance is you wanna have that policy in place, but you also wanna make sure that your reporting is scalable. So it may be something where you look at a certain key like group of goals for your first year of your program and then you expand those goals as you go on, and your reporting can help build with that. So I'll dive into each of these a little bit further. In terms of training, I mentioned both your role-based training and general training. In general training, you're focusing on just usually, this is what our accessibility policy is, here's why it's important, here's where the organization's goals are in making sure that we are providing accessible content for everyone. So you wanna ensure that everyone knows what the policy is, knows how that affects their day-to-day work, and what tools and resources you're providing in order to help them meet that responsibility. A lot of times when we speak of accessibility, we think of the technical people on the team, the designers, the developers, the UX specialists. But you also wanna think of how does accessibility affect your product and project managers, your content team, your marketing and communications team, your writers, and especially your leadership. Because leadership is involved in so many things, you have to kind of give them the high-level overview so that they can help drive your buy-in from the top down. And it's one of the key things in establishing a program is making sure that you're getting that buy-in at all levels and then identifying where you may need a little more support and you can pull in your leadership to help there. And while you're doing all of that training, you also wanna make sure that there are tools and resources available so that, as people are taking the training and getting more familiar with accessibility, they have a place to go, share a repository of knowledge-based articles and additional trainings they can take and links out to key industry resources like W3C where they can just go get more information on specific things that they're looking for. You also want to ensure that you have access to tools, both things like scanning tools so you can see how accessible your products are. And continue evaluating that as you're doing remediation and validation, as well as you're building new content and new products. Sorry. In integrating it into your development process, you want to be sure this is one of the key places where we talk about bringing accessibility and shifting left early on. You want to look at those design and get design reviews done so you can spot where accessibility can be integrated early on before when you're in the wireframe phase rather than at the end of testing you've got something you're ready to test it. In development, you can do manual checks and automated testing at the end of sprint cycles to see where you're at and what things need to be addressed before you get deeper in and you have a lot more issues to address. And as part of those testing, you also wanna make sure that your QA is incorporating accessibility into its process. One of the things we see a lot with accessibility bugs are they get documented in some organizations where they're still ramping up their accessibility capacity. Sometimes accessibility bugs are prioritized much lower than other types of, like security bugs are usually very highly prioritized for obvious reasons. But it's very helpful to have your leadership emphasize that accessibility bugs should be taken just as seriously as other types of bugs so that they can be managed and prioritized in an equivalent way because accessibility issues can expose you to a significant amount of risk as well. So you wanna be treating them equally, and you just want your user experience to be solid. And in production of reusable resources, you want to ensure that, as you're creating and editing your design systems, style guides, code libraries, things of that nature, that you're not only testing them for accessibility, but that you're building inaccessibility from the ground up so that you have resources across your organization that are already accessible that people can pull from. Including people with disabilities in your user experience, anytime there's activities that involve representative users, you want to be sure that you can include people not only in the testing, as I mentioned before, but in exploratory research, like how could we make this idea for this product more accessible? What are some requirements we should consider as we're thinking of what we want this to look like or we want this to do? They can also be involved at the co-design, the design phase to help troubleshoot design issues and figure out, or again, early on, before you're actually building something, where accessibility can be integrated for a smoother and more efficient user experience. And we also wanna make sure not just for integrating users with disabilities into the experience, but also in representations of your users and customers of the product. It's helpful to show that you have a focus on accessibility if you are showing users with disabilities in interacting with your product, using assistive technology and just saying, "Yes, we have looked at this ahead of time and we wanna make sure that our product is accessible to everybody." Engaging product teams to use people with disabilities and user research, again, going back to that idea of getting actual users to test your product and go beyond that code testing to say, "This workflow is accessible," or, "we've got a blocker here and this person can't even log on to a retail site," which would increase the likelihood that they would go elsewhere. And also hiring people with disabilities in positions that help influence your digital resource creation. So just getting that user perspective and getting some different perspectives across the board so that you can make sure that accessibility is a key consideration rather than an afterthought as you are going through your development life cycle. Procurement, as I mentioned before, is one that sometimes is an afterthought to a lot of organizations, but it's actually one that you can really help your strategy for accessibility in your program evolve by addressing procurement early on. This can be something as simple as socializing your accessibility policy to your vendors and then letting them know that they're going to have to comply with the policy by whatever timeline your organization has decided. And it may be a staged phase in, but you can start that by then adding terms to your contracts that say we expect vendors to have accessible products. And if you have those terms in RFPs and other specifications, letting clients, or letting your vendors know, "Here's what we're expecting in terms of accessibility." If you have a roadmap for that, it's good to include that just so they know what their expectations will be now and where you're expecting them to go, how quickly you're expecting them to resolve accessibility issues that are identified, that kind of thing. You can also use it as a basis for evaluating vendors. It is not only something that is helpful for your overall program, but it signals to your organization and everybody in your organization who is working on integrating accessibility that you are also making sure that your vendors are providing accessible products and that accessibility is a key feature on which you decide who's getting your money and your business. It can be a key consideration in that selection process, as I mentioned in the contract language. You also may wanna include some terms about how you're going to go about working with a vendor to address accessibility issues and what the expectations will be for that. Will it be something where they have X number of time to remediate it, and if they don't, you're going to go to another vendor. I've been in organizations where we use that strategy, and it really wakes people up, especially some of the big vendors when you say, "Look, we've been working with you to address the accessibility issue that we identified and we've been doing it for a year, and if you don't have this fixed within the next half, we're going to put out an RFP, or whatever procurement process you use, to consider other vendors that do the exact same thing that you do." This can hinge somewhat on purchasing power, but it's definitely something to consider just to help push vendors towards accessibility in all of their dealings as well. And then for governance and culture, I think this, a lot of times, is what people key in on when they're thinking about developing an accessibility program. And you know, the first thing you wanna have is just some kind of policy that communicates what the organization's commitment is to accessibility and what the expectations are for everybody in their individual roles within the organization. Usually it's very helpful to include what specific technical accessibility standard will be, the standard for the policy, so WCAG 2.1, 2.2, if there are legal or regulatory things that you have to comply with, you'll probably wanna include that in your policy just so that people understand what they're trying to achieve. And one of the key things with policy and governance is it's so helpful early on if you have leadership buy-in at the very top or at least have an accessibility champion high up in your organization who can not only show that the organization is behind the policy and wants to push for accessibility being integrated across the organization, but it can also communicate that this is a very real goal, and it's something that's very important for the organization. If you have that champion, you can pull them in not only to get the rest of your leadership involved, but also when you have difficult test cases where people are saying, "I've already got a million things to do and I'm not sure how I'm gonna work this into the rest of my duties," leadership can help set those priorities and show where the focus is going to be. You want to have disability present in representation of customers and product users. So both in your internal and public communications, you want to make sure that you're representing users with disabilities in your product use and your marketing so that they understand that accessibility is a key focus for your organization. And it's also, with all these things and baking accessibility in from an early part of your life cycle, having more employees with disabilities to help improve the accessibility of the workforce is a key standard of that, because you can't get that perspective if you don't have someone who is directly using the technology and understanding how it impacts their day-to-day life. I frequently, I have an awesome team of amazing engineers, and we'll take certain trainings, as all organizations have mandatory HR trainings and that kind of stuff, and they will come to me and say, "I couldn't get past this slide or this video kept repeating." That's the kind of stuff that, when I get that feedback, I take that up to leadership and say, "Hey, we need to talk to this vendor and make sure that this is accessible for our employees," because we're an accessibility organization and we're modeling for everyone that accessibility is important to us. So it's really helpful to have employees who are familiar, not only with accessibility, but how they use technology to help inform your standard with vendors and other types of communications in your own culture. And then reporting and monitoring, so I think most people in the accessibility field are familiar with VPATs, or accessibility conformance reports. That's kind of the gold standard for reporting on what accessibility issues any product has, as well as what level of compliance generally that it has at a given state and time when it has been tested. For organizations, we found that it's also really great to have an accessibility scorecard of some kind. This can be really simple or really complex. You can break it down into those key areas of training, development, procurement, reporting and just see where various teams, business units. It's kind of up to you how you organize it, but organizing that scorecard in a way where you can collect meaningful data on accessibility performance and performance towards those goals. This is especially key when you're considering that accessibility is something that you can scale to so you don't want to... People need to realize that the metrics for the first year may be very different than the metrics for years 2, 3, 4, 5 in your program. Showing progress year over year not only helps you identify what your strategy needs to be and where there's areas of opportunity, but it's also a really great way to help celebrate your successes and show where your teams have made great strides in accessibility and where they're really implementing things across the board. And then feedback loops, making sure that there is a central place for people to provide feedback on accessibility issues with products and a way for them to get support is key because, while you're doing all of this accessibility implementation, you still have users actively working on your sites, using your products, and you want them to be able to get quick support. And you also wanna have a process that's very well known and socialized for how your organization is going to handle demand letters and complaints. Is that something that will be reported up to managers? Is it gonna go straight to legal? Having everyone in the organization understand how those are handled when they come in is really key on something that is usually very time sensitive and that you wanna be responding to quickly. So you want to make sure that those feedback loops are in place and that they're very well socialized throughout the organization for everyone who needs to be aware of them. The biggest thing in overall program progress that I have seen, and that is, again, something where people get overwhelmed easily is building an accessibility program from the ground up, or from, you know, "We did an audit and we have a lot of issues," is remembering that it is impossible to boil the ocean. So you need to figure out what you're going to address and establish priorities for your efforts based on your resources. This may involve some kind of risk management calculus where you're looking at what are our highest risk sites or products, where do we want to get by the end of this year, by the end of this quarter, by the end of this month? And kind of establishing that roadmap. It's really important to set achievable goals and timelines. They can be assertive, but you don't want to set goals and timelines that people will look at and say, "That's not realistic," because that will dampen the enthusiasm for doing this from a very early stage. It's also helpful, if you find a community, to identify with either grassroots or enthusiasts from people in the accessibility community to help show not only their success stories, but how they have implemented these programs within their own organization. When I was helping Ohio State establish their accessibility program and implement their policy, at this point almost 10 years ago, one of the first things we did was go talk to other schools, both large and small about how they were doing it so we could get an idea of what worked well and what we could easily transition to our own program. Because you don't need to reinvent the wheel in any of these situations. It's usually a case of more tweaking what you're using. And then finally, celebrating and sharing successes. You want to really celebrate when people are doing things right and when people have made great strides in implementing your accessibility program. And that's where building into this scalable idea is really helpful because it shows where you've come from, where you're going and just celebrating everyone's help and contribution along the path. So I'm gonna go through this next section kind of quickly just because we wanted to highlight how we can help you with your program maturity. So I will run through this pretty quickly, but we can answer more in questions. I wanna make sure we have plenty of time for questions. So early on, Dave showed you this slide. And you may have looked at that slide and said, "Where's my organization in maturity?" We can help you at any stage of maturity, whether you know where that is or not. And if you don't know, we can help you figure out where you are with some kind of assessment. So we have a variety of services for all phases and maturity levels. We spoke before about training, we not only have ARC Tutor, which is our training library of prerecorded trainings, pre-curated trainings, but we also have a training division that does standard and custom training on a variety of subjects. And those deliveries are both virtual and in person. On top of regular training, we also do strategic consulting both for technical guidance and for programmatic guidance. So if you literally want Vispero to come in and help you and say, "Here's where we are, we wanna get here," we can help you build that roadmap to your accessibility program in a way that works in your organization's goals and needs. In terms of auditing, we do auditing across web, PDF, mobile. And that always comes with remediation and validation support as well as access to things like help desk and office hours and that kind of thing so that you're getting subject matter expert-level guidance on the issues that you're seeing within your own sites and people who understand the context of the environment that you're working in. For governance and compliance, as I mentioned, this goes back to program management. We can help you with policy and standards development as well as your reporting. Any sites that we have audited recently, we are happy to create VPATs and accessibility statements for those. And we can also help you with some of that internal strategy in terms of accessibility scorecards and benchmarking and figuring out where you are in terms of maturity and where you wanna go. In terms of UX and design, we do design reviews to help identify those accessibility issues early and how you can help integrate accessibility in at the beginning of your process rather than the end. We also do user flow testing with assistive technology as well as user research and usability testing to get that feedback from individuals who are working with assistive technology and have disabilities. And then program management and support, Expert Services happens to be the department that I manage. This is targeted support for your organization. But my team of engineers blow me away every single day. They are really like having an in-house subject matter expert for your organization. And they do everything from planning strategy to auditing to remediation. So, or remediation guidance, I should say. We don't touch other people's websites. But it's really like, what is your need? What do you need day to day? They're kind of dedicated support. They embed, they can embed, or they can work for you 20, 25 hours a week, whatever makes the most sense for your organization. Strategic consulting is also another great aspect here where we will help you come in for more defined periods of time to help you along the journey and then kind of step out, let you run with it and step in as you need us. We also support accessibility of kiosks, self-service terminals, payment devices, that kind of thing where users can't install their own AT. So that's a big initiative that we've been working on. And we do JAWs scripting for anyone who uses JAWS and our clients. We can help their employees successfully use workplace software when you can't remediate the software right away, we can do some scripting there. So I've run through those really quickly, but I wanna make sure we give time for questions.

- Yeah, so opening up, I don't see any questions in the Q&A panel. But if anyone has any questions, feel free to share them now. Or we'd be happy to answer them afterwards by email or through other channels. I think just one thing, Amy, I was going to go back to note, we've talked a fair bit about procurement and some people listening might think that that's a kind of very formal process of spending big money on enterprise software. When we're talking about procurement, we're talking about any activity where you are using somebody else's content or technology or tools or software to help you with your efforts. So it might be a really an open source JavaScript library, anytime it's somebody else's, it's really important to think about whether that tool helps you with managing your accessibility goals or whether it might well hinder them. So it's all, you know, it's important. We all do procurement in our own little way that doesn't have to be something that's considered a sort of formal process. So we have a few questions coming in, one from Mara Waldrof, thank you. "After you perform an audit, what's a good way to transition the conversation to more sustainable practice?" That's an excellent one. Amy, do you wanna give a start and I can can add it, add in some thoughts afterwards?

- Yeah, I mean, honestly it depends on the client and depends on both what your goals are for accessibility as well as what resources you have available or you can make available, like I mentioned through like Expert Services or having someone kind of in-house to help assist that. Really, using an audit as that pivot for what are your most important areas that you want to prioritize first and then kind of tiering how you want to scale that up from... You know, I mentioned at Ohio State, like we had very reasonable goals for the first year, and then we built on those every year of... We had a five-year plan for accessibility program, and for those not familiar with Ohio State, it's a campus of like 100,000 users. And it's highly decentralized, so everybody could implement the policy in their own way, but we were trying to guide them on what we recommended was the best ways to do it. So really understanding what resources you have available, what your goals are, and then making however long of a plan to get to a sustainable continuous level of accessibility and kind of building that out according to whether you use KPIs, whether you use a risk management strategy, but just kind of figuring out what order you wanna go in. You may not tackle procurement in the first year, but maybe in the first year you wanna look at auditing some of your primary sites and then getting people trained up both on accessibility and on how to address the issues that you're seeing in your templates and your components so that you can remediate those and then hopefully have sites that have fewer issues down the road. So it's really something that you can do a deep dive and kind of tier those goals.

- Yeah, I think just to go back to the phrasing of the question, the fact that the question includes the word conversation, I love that, because an audit is often not seen as a conversation. It's more of a directive from an organization that's performed this review of a website. "And here are all the things you've done wrong and here's our right instructions for fixing it," and then walk away. But the audit is exactly that. It's the start of a conversation, firstly to figure out, "Okay, what do we need to do to fix things as best we can? What can we do to reduce the chances of those things happening again in this resource and in the other ones that our team looks after?" So we very much see the audit as serving both of those goals. So it's definitely a great conversation starter for accessibility efforts. Another question, "Do your auditors use automated software as well as performing manual audits?" And yes, we do, and we have a couple of tools. We have our ARC tool, which does automated scanning at a larger scale of multiple sites. But we also have a browser extension ARC toolkit, which does a more a page by page. So it's a kind of guided process where it will do some automated checks and then it will highlight certain areas of the page which require manual inspection. And we certainly see automation as a way to speed up the process of doing accessibility testing and also improve quality where automation can improve quality. We'd certainly see automation as an essential part of doing a job quickly and to a high level of quality, but we know the limitations of automation. We know that they're changing with generative AI and computer vision and all sorts of other innovations. So we make appropriate use where automation helps us improve efficiency. Next question from Rah-ma Ra-hi-di. "Do you provide expertise for making 100% fully inclusive, digitally accessible mobile app?" And the answer is yes. Won't necessarily guarantee 100% accessible. It's definitely a target, or an aspiration rather than an measure, something that's always going to be maintainable. But yes, we have, amongst our engineering team, we have some leading mobile accessibility specialists who've built tools to help with code inspection, particularly in the Android platform. So we'd definitely be happy to talk more about how our work focuses on mobile accessibility. And some of what we've covered today very much covers all digital resources, but mobile accessibility brings its own constraints and opportunities that influence accessibility strategy. Sarah Hamilton, "Just a note to say this was great and helpful with lots of great points to action." Sarah, thanks so much for your feedback. If there's anything more that we can do, then please just to let us know. Nicole Shoemaker, "I'm having a hard time convincing my organization's leadership that digital accessibility is more than a one-time quick text fix. I love the quote you stated earlier about how efforts will be lost if you don't build a sustainable program. My leadership doesn't watch webinars like this. Do you have a white paper or other concise source I could point them to that discusses the criticality of developing an ongoing digital accessibility program?" I think that problem that that question outlines is one that I think will be familiar to many of us that this challenge of convincing somebody that accessibility isn't something like, that's fixed and then we can move on. This is where bringing up the security analogy is really important. Companies generally recognize that security isn't project that can be done and then we move on, we don't have to worry about security. There are always new ways that hackers, that cyber criminals will find to create security breaches. So organizations recognize that risk and recognize the need for ongoing investment. Accessibility is exactly the same, even if the risks are slightly different and the opportunities are slightly different. So the question around a white paper, other concise source, we'll confer offline, Amy, I think, and figure out what we can point people to. But we'll certainly we'll answer that and follow up with everyone who attended, unless you can think of something right now. Then the next, I guess it's more an observation from Brig-i-ta Vix-nev. "The concept of involving people with disabilities and designing of services is not an easy one, as at least in EU, the one only benchmark of conformity is EN through 1549." I think in general terms, yes, involving people with disabilities throughout the design and development lifecycle is the ultimate gold standard in ensuring that what's built is usable and useful by people with disabilities. While accessibility is focused on standards conformance, there's always a limitation that it stays an abstract rather than a real world human-focused endeavor. I think it's not a straightforward challenge. Certainly looking at actively increasing the number of people with disabilities in a product team is important. It's easier than ever to find smart people out there who have design, development, UX, management, leadership skills who also happen to be disabled. And this is exactly the time where that leadership and talent is needed to build out product teams. And that's one way to help. When the people making decisions are people with disabilities, then it's help. Involvement becomes much more real. We've got maybe time for one more question, I think. We're almost at time. And I know Sophia has raised a hand. So Sophia, if you can follow up with an email with your point, then we'll handle that offline. But I'm just gonna answer one more question from Robert Fen-o-kov-sky. "How do you handle audit and remediation for companies dealing with non-English content staff and customers?" This is a great question. And we are a multilingual workforce, but we know there's more that we can do. So to some extent, accessibility issues are language agnostic, but certainly, there are content areas where we'll need to address that on a case-by-case basis based on the language that's spoken and the language capability that we have in-house and where we might have to work with third parties to assess those areas of accessibility that require fluency in a particular language. But it's a great question and one that's an important part of accessibility as it becomes an international challenge. So at this point, I really appreciate all the questions. I know that we didn't get to answer all of them. We will send out answers to each question as a follow-up communication to all attendees. Thank you for joining us. Good luck with your accessibility efforts. And if you have any further questions for either Amy or myself, our email addresses are on the screen right now, dsloan@vispero.com or amajor@vispero.com. Thank you for your attendance. And have a great day, and all the best with your accessibility efforts.