Transcript of the webinar PEAT Talks: Policy-Driven Adoption for Accessibility (PDAA). This webinar was originally held on September 17, 2015.
Welcome and Logistics
>> Hello, and welcome to PEAT Talks, the virtual speaker series from the Partnership on Employment & Accessible Technology. PEAT Talks will be showcasing various organizations and individuals whose work and innovations are advancing accessible technology in the workplace. My name is Christa Beal, I'm a member of the PEAT team, and I will be heading today's talk.
PEAT is pleased to welcome three distinguished speakers. Jeff Kline is the author of “Strategic IT Accessibility: Enabling the Organization.” He currently serves as Program Director, Statewide Electronic and Information Resources at the Texas Department of Information Resources. Prior to his current position in public service Mr. Kline managed IBM's worldwide accessibility consulting and business transformation initiative.
Jay Wyant is Minnesota's first Chief Information Accessibility Officer, or CIAO. His role is to work with Minnesota state agencies to develop policies and procedures and best practices so their operations and services can be accessible.
Sarah Bourne is the director of IT accessibility for the Commonwealth of Massachusetts where she works on accessibility policy, standards and guidance for development and procurement for internal and public systems. These efforts began with creating accessibility guidelines in 1998 as the Commonwealth's first webmaster. Sarah is the coordinator and organizer of the annual Boston accessibility conference.
All three of our speakers also volunteer their time and expertise in support of PEAT as members of the think tank we convene for advice. We're lucky to have both their time today and their continued involvement with PEAT. Our speakers today will be discussing policy driven adoption for accessbility, or PDAA.
PDAA is a new approach to help achieve higher levels of accessibility and vendor provided products and services over the long-term. The approach helps vendors drive themselves to produce accessible products and services as measured through a maturity model against the implementation of core criteria. The PEAT program is excited to be showcasing this topic and we believe a policy driven approach to the implementation of accessible technology is critical to supporting the employment, retention and career advancement of people with disabilities. And with that I will turn things over to Jeff Kline to kick off.
Presentation
>> Thank you, Christa. Hello everyone. To kind of frame this up a little bit if we go to the next slide there's a problem that everybody deals with both in public and private sector that I call the procurement dependency. Most organizations rely on procuring products and services from third parties as opposed to developing things themselves although some companies do have their own homegrown stuff, but the majority of products are procured.
When you start to look at accessibility and how you buy accessible products really most of the products and services out there in the world today don't meet the technical standards, which are known as US 508 and WCAG 2.0 AA which creates a real problem in trying to be inclusive for your whole populations. And is going to be a continued dependency on procuring IT. We don't really see that changing in the foreseeable future. Next slide, please.
When you go out and try to procure a product or service, there is a Standard Format out there that's available called the voluntary product accessibility template or VPATs which applies to commercial off-the-shelf products. Most people are familiar with these, probably in this audience a lot of vendors unfortunately still don't have their arms wrapped around that. And that's very evident by the accuracy in a lot of the VPATs that are out there today. Some are filled out by developers and some by sales reps and some by attorneys. It's really all over the map. And so you get a lot of information that may not be accurate in those.
The other issue is if you are shopping for something like a development service for a software or web or whatever it is, there is no such thing as a VPATs. There's nothing there that covers technical services and those kinds of things. So how do you know when a vendor signs up to be accessible to make an accessible website or an accessible application that they can in fact do it? And then how do you choose between these competing products? By using these inaccurate VPATs and lack of services documentation. And then how do you know whether a vendor is actually committed to accessibility and their products or in the long-term? Or whether they are not? So if we move to slide, the next slide.
I would argue even though there is a large body of knowledge in the technical arena in terms of making things accessible, it's still very challenging work. I won't argue that. But the knowledge is there, the technologies are there to make things accessible. I would argue that governance is a bigger problem today than the technical challenges. We've seen, ever since the year 2000, US 508 has been around since that time. We are not releasing the ball moving forward as we should. What we see really is pushing these technical specifications has not been an adequate driver for adoption to accessibility. And one of the reasons is the technical standards are not governance criteria, they are execution criteria. So there's nothing that tells an organization that this actually needs to be done or to put all the pieces in place to enable themselves to create accessible products. And there's no silver bullet on the horizon for something that's going to magically make these products accessible. Next slide.
If you look at kind of what's happening out there with regard to convergence models. On the slide I show four different areas in the realms of directives and statutes and litigation that some of us are familiar with. The DOJ and deal E litigation settlement. But if you look across all these four different areas there are some constant things that have been pronounced or mandated as part of these. And those are having policy requirements on accessibility, making sure that there's skills and training within the organizations in order to make accessible products and services, tracking and reporting requirements and making sure that there is some organizational pieces in place, that somebody has accessibility stamped on therefore had within the organization and there's some kind of a structure that helps guide that especially in larger organizations.
So while we're seeing this kind of happening in an informal or ad hoc way, or by coincidence I don't know the best way to term that. These common elements are there and they're all there for a reason. What we've tried to do with PDAA is formalize that and make those drivers for adoption and in PDAA's case we are focused on the procurement process right now. I will turn it over to Jay now and he will talk about PDAA.
>> Thank you, Jeff. So as Jeff pointed out, we have got the technology to make things accessible. We've got to know how to make things accessible. Now you can look at governing to make it happen. IT governance is the key we believe to driving an organization to use the technology, knowledge and training that's out there to improve accessibility adoption. So the idea is if you can build governance through policy at the executive level and the corporate level then it's no longer IT accessibility and no longer relegated to one person here or one person there. It's a companywide, systemwide approach.
The other thing is the idea behind PDAA is that we're not telling people how to build accessibility in the organization. We're not asking or telling people a certain process or certain procedure they have to follow. You develop a policy and the language that works best for your organization and then use governance means to drive it to the organization and the organization themselves applies the processes that make it meaningful to them, the procedures that are meaningful to them and ideally develop innovation and ways to make it happen that are meaningful and more successful to them. and in that way build an effective approach for accessibility. Next slide, please.
In addition to the path that we know how to make things accessible and we promote governance and all that. We also believe that there is a very strong business case for accessibility and because of that, vendors can use that to again argue for the value of the policy and the value of making it work appropriately. We believe that a fully accessible organization that builds accessibile technology will have more beneficial technologies such as better search engine optimization. They will have increased customer base and increase market share by staking themselves as an organization that believes in and promotes accessibility they will increase their brand equity.
All of these are values, but also in addition to the business case there is a very strong argument that being forward thinking with accessibility and building accessibility and the policies at an operational level that you are mitigating risk because the Department of Justice, when they are investigating a complaint or investigating how a possible lawsuit, the first question they ask is do you have a policy? What are your processes that fall behind that policy? By developing the policy you are putting yourself in the forefront, ahead of the game so that when there is a complaint, and the odds are good if you are a large or medium organization you will get a complaint. By showing that you have meaningful, intentional approaches, you tend to mitigate any kind of risk that may come out of that complaint. Next slide, please.
What we did was, okay we had a great idea. We thought that PDAA was the way to go and needed to figure out the way to make it happen. The CIO for Texas at the time was Karen Robertson. She persuded NACSCIO the National Association of State Chief Information Officers to set up a workgroup to figure out how to make PDAA work. That workgroup had three objectives. To develop a common set of criteria, to develop deliverables and to package a model for adoption by the states.
There were 10 states that got involved and one federal agency. Those 10 states assigned the work of the organization to a subgroup consisting of myself, Jeff Kline and Sarah Bourne. The three of us put together the PDAA we are talking about today. It's not a descriptive or prescriptive concept. It's the concept that you must develop a policy in your language and then drive it there. And we will talk about how we put that concept into a language and developed a framework that will allow each organization to then develop PDAA. Sarah, please take it from here.
>> Good morning. The outcome of the workgroup was, the first thing that we came up with was the core criteria that vendors need to be addressing. They fall in the areas of policy creation, how you organize your business processes, your planning for how to become compliant. Training your staff in various parts of the organization and communication. This is very much in line with the ways that you would be addressing any other policy that is at an enterprise level.
The very first thing people need to do is to develop, implement and maintain ICT, information and communication technology, accessibility policy. This is your foundation. Everything else is going to grow out of your policy. The other things will not happen if you don't have policy in place to make sure that they do happen. You want to make sure that you want to establish and maintain an organizational structure that enables and facilitates progress in ICT accessibility. What you often see is that sometimes accessibility is relegated to a developer or somebody in QA. But if it's actually going to, that's not high enough in the organization, so you need to look at your organizational structure and make sure accessibility is being addressed where it needs to be.
You need to make sure that your ICT accessibility criteria is built-in to your key phases of development, procurement, acquisitions and other relevant business processes. You don't want to have to try to fix up a bad decision after the fact, so look at your processes and determine when is the earliest possible time you can make the right decision about accessibility. You need to have processes in place for addressing an accessible ICT that you may actually already be offering. Bug tracking, version release planning, so on and so forth. Varies from company to company. You want to ensure the availability of relevant ICT accessibility skills within or to the organization, whether you build your own training program or bring in experts from outside. That will be up to each company but you want to make sure that everybody who has responsibility for accessibility knows what that is, and training is essential for that.
And last but hardly least is communication. Make information regarding your ICT accessibility policy, plans, and progress available to your customers. So you need to let customers know what you're doing and how you're getting along and how you are doing to show your improvement. Next slide, please.
For each of the core criteria, the workgroup flushed out additional details. So for instance, on the first one for developing implementing and maintaining an ICT accessability policy, we built a business case for it. It creates the foundation on which your programs will be built and it will ensure accessibility efforts are not a one-off project, but that they keep happening. So that it is strategic and instead of tactical. And it allows people in different roles to understand what they're responsible for. And then for each criteria we also realized that this is a process. It's not an activity. It's not something you will check off on. It's going to be an ongoing process. At the very beginning you'll be in what we call the launch phase, which is in this case having a policy.
The next is actually integrating that policy into your organizational plans, and many organizations may actually be in that integrate phase for a fairly long time as they build this out. And then optimize is going to be where everybody spends the most time, hopefully. You will have created your policy and gotten people aware of what they need to do about it and at that point you'll be establishing your metrics so that you can track progress towards achieving compliance to the policy. At the end of the slide deck, we have the slides for each of the core criteria. So this is the first one. The other five are at the end of this deck. After this you can get the slide deck if you are interested in seeing the additional criteria that we developed. Next slide, please.
So we take the core criteria and the launch, integrate, and optimize. And what you end up with is a PDAA maturity model. It shows you how far are we? How mature are we in terms of establishing and integrating and adopting and living by our accessibility policy? And you will be at different phases for different criteria at different times as you go through this. This is not an accessibility maturity model. There's a lot more complexity that would be involved, but it certainly reflects and is very similar to what you would see for a full maturity model. Next slide, please.
Here we will hand it off to Jeff.
>> Thank you, Sarah. What this slide is trying to articulate is, we know that it takes a long time to make products accessible. But we feel like with regards to policy implementation, that there's a timeline that could be reasonably set up and this is just a generic timeline because it may not be precise for everyone. The idea here is by the time you throw the switch and decide that you want to have an accessibility policy, and by the time you get through all of the criteria to the integrate phase of having the policy, not making all your products accessible. I just want to make sure there's no confusion on that. You could probably do that in about 24 months. Some of those things happen simultaneously of course. The dark blue squares are the ones where, are the different points within each one of the core criteria areas and the green boxes are one that would be complete. But you can see a lot of things can happen very simultaneously and by the end of 24 months it is very reasonable to have all the elements in place to be fully executing against your policy and really starting to make a difference in the accessibility of your products and services.
As part of the deliverables, if we move down to the next slide. We developed using the maturity model, a self-assessment tool that can be provided to vendors or even any organization can use this tool to gauge where they are relative to policy maturity within their organization. The score is a very simplistic thing. There's a link here to go open the tool. I think it's out on the Minnesota website. Have a look at that in your spare time. It's a very simple Excel spreadsheet that as you go through the respondents to the questions, on this slide we show the last question. As you put your answers and their numbers for where you are, it automatically generates a bar graph of where you are at in your maturity model. So then you can look at that and get a good idea of where you are, and then where you need to go in order to get to the other places, to get to optimized for everything. The self-assessment tool also includes a set of FAQs for both vendors and the procurement organizations.
What do you do with the results? The results of this self-assessment can be used in two ways. For procurement organizations, it can help them assess the vendor's ability to produce accessible offerings. It's another data point that could be used in addition to looking at the VPATs. It could potentially give a procurement organization confidence, or lack thereof of the accuracy of their VPATs. But one of the important things is because we know that this is going to be new for a lot of vendors and a lot of organizations, that you can track over time the responses of a particular vendor, or anybody for that matter, and it would allow you to see if they are making progress towards fully implementing the product. The process with the idea is as you are more mature over the long-term, you're going to actually increased the accessibility of your products and services. And customers might even want to consider using the assessment as part of their own selection process.
Now for vendors, and this is almost even more important, is the maturity model and the self-assessment really are a guide that can help the organization develop and implement a corporate wide program and accessibility initiatives. And ultimately when they do that, that will achieve more accessibility of their products in the long-term, as I said. If you move to the next slide, I'll talk just for a minute or two about what we're doing in Texas with policy driven adoption for accessibility. We started including the vendor self-assessment in our cooperative contract solicitations, and cooperative contracts are like master contract that we put in place for various vendors, and then state agencies and other government bodies can then go and use those master contracts to purchase in a shortcut without doing a full RFO. Basically it simplifies the process.
We may have a solicitation for software and related services and we can get 100 or 200 responses back on that. So all those vendors in their response have to complete the PDAA self-assessment and we look at that. We don't actually score the PDAA assessment results as part of the selection process. But we do keep it on record and it is available, or will shortly be available on request. The other thing is, as the same vendor responds to multiple solicitations over time, we can look at that and see if they are making progress during these solicitations or contract renewals.
We've seen about 190 vendors have submitted assessments to date so we have a pretty good sample size on that. Most of the responses have been pretty honest, which is good. It's not always obvious. The hope is and we provide the instructions that this PDAA assessment form is sent to the right person, especially in a large organization. It's probably not the best idea for a sales representative to fill this thing out if they don't really have direct knowledge of all the processes and things that are going on within the organization. As I said, we are putting a mechanism in place to make the results available to customers upon request on a vendor by vendor basis. There's a link at the bottom to the Department of Information Resources information on PDAA. So Jay, I will turn it back to you now so you can talk about Minnesota.
>> Thanks Jeff. As you can see, the State of Texas has been using PDAA on a regular basis as part of the procurement process. In Minnesota we are kind of in a situation where we are piloting a program to bring us to better policy because when we, when the procurement people in the state of Minnesota talked about it they said: We like it. We think it's a great idea but how are we going to integrate it into our processes? How will it work? It's not a simple thing to require vendors to flow into a new mechanism. They also asked questions like, do we have to do this for every single solicitation, or do we want each vendor to do it once a year? Once a quarter? What's the best process to make it work so that it works best for the vendors as well as for us? So, what they asked us to do was to pilot it by by extending an invitation to vendors who all were already on contract to ask them to complete the PDAA worksheet which you can see in this link, the link that Jeff mentioned. The Minnesota link, the links with the worksheet as well FAQs and the other materials.
So we have requested a number of vendors to complete the worksheet and send it to us and give us their feedback as to the process. How does the process work for them? What's the best way that we can make it work as part of the procurement process? At this point while we are also talking with Minnesota vendors about that pilot that we offer, we are also talking with vendor organizations like ITIC, among others, to figure out how not only a few vendors, but all vendors can implement this.
It's the very same process from our perspective as to requesting how vendors can change and implement policy, but also what's the best practice for states and how to implement the PDAA process within the state's own procurement level. That is where we are at this point. It will be very interesting to see what happens in the near future. Next slide, please. I believe I hand it off to Sarah now. Sarah it's off to you.
>> Thank you Jay. How do you actually get started on this? We've put together some information resources that can help you figure out how to do all of these things and how to create a policy. How to do some analysis of your organization and other activities that are behind doing a PDAA program for your organization. The first is Techcheck. Many people on this call are familiar with PEAT's tool. The W3C is always a fantastic resource for accessibility information and they have a special section on planning and implementing Web accessibility. The British standard BS-8878, the standard itself you have to purchase but there's many pieces of information that of been made available by Jonathan Hassell on what that is. That's not a technical standard. It's talking about how to integrate accessibility into your organization. That's very valuable.
And Jeff's book, strategic IT accessibility: enabling the organization, goes into a lot of detail. I recommend that book very highly and it's going to be very helpful for you to do PDAA. SSB Bart Group has a full accessibility model. If you are pursuing a full maturity model for accessibility, you will find a lot of overlap and you'll get a lot more detail on what the capability maturity model looks like for accessibility overall. And the Texas Department of Information Resources has an accessibility implementation framework, which is a framework and project plan that can help get all these things rolling and keep these moving. Next slide. Thank you very much and we actually have a few minutes for questions at this point.
Audience Questions
>> Thank you to all of our speakers. Now we just will dive into a few of the questions that have come through. First off, are there examples you can share for those who are not sure how to get started?
>> This is Jeff. Really the first step is as we mentioned, you really have to formulate the policy. The policy can be done, there's some information on that in some of the subsequent slides in this presentation. But the idea is, is because it is policy if you have a process by which policy is created and implemented within your organization, you should probably use that with the people that are familiar with that and help you move that through. The important thing is when you do that the policy, you get the buy-in from the key organizations stakeholders who are going to have to live by that policy. And so a lot of times you'll want to write a policy and then have reviews by your development community and your legal community and a number of places so that they have the opportunity to look at it, comment on it and buy in, which is going to make it much easier to implement when the rubber meets the road on implementation.
>> Thank you. Our next question is, what is the first step states should take to implement PDAA?
>> This is Jay. I think I will answer that one. As Jeff said, you start with the policy process. There's no one way to do it. Every organization has their own way to approach how to how to develop policy and to make sure you tie in to whatever that approach is. Regarding states, as I said, the state of Minnesota is trying to figure out, well, how this will work. How it will take place. I would argue the first step is talk to people who are in charge of the procurement process. Here in Minnesota we have centralized our IT so it is all within one organization. Before it was between each agency and we're still transitioning that but hopefully it will all take place within one organization.
So it is a little easier for us, at this point, to identify who is in charge of procurement. But we got them all into a room, we got the people on the contract side, procurement side and the buy side to get together and say we want this to happen and how do we make it work with our current process? And then the next challenge is then, to make sure that people who are writing the RFP and the people doing the evaluation and getting them involved as well because most likely they are further down the food chain and haven't heard of it, unless you bring them into the room. So it's a very methodical process just like the policy side. You need the people involved to understand what this is and then ask them how do we make it work. There is a chain of events and processes and they start building it from there. It may take a while for it to actually be implementable because you have to figure out, ok we have it, what do we do with it? That's the next step in the process.
>> Thanks, Jay. The final question today is how do publish institutions leverage accessibility in their efforts to become model employers?
>> This is Sarah. I'll take that one. I think the same way that you are asking your vendors to do the PDAA, I think the one thing you can do it yourself, you can use your PDAA for your own organization, and in this case maybe it's not to improve the accessibility of a product but it's the improving the accessibility of your workplace and your ability to provide adequate support for employees whom may have disabilities. The other is to make sure you have a policy and make sure that you are purchasing and acquiring and addressing an assessable IT that's already in the workplace yourselves. And of course, the other is to adopt PDAA as part of your policy and to use PDAA in your own procurement.
>> This is Jay. I would like to chime in on that for one moment. Jeff at the very beginning of the whole process just talked about the procurement dependency and it's a real thing. Most states do not build stuff. We are almost completely reliant, I might say at the mercy of our vendors. If our vendors don't build accessible stuff, then the key, the states in many cases as in Minnesota, are required to provide accessibility, accessible technology to our employees. We are required to hire people with disabilities and we have a mandate to increase the employment of people with disabilities to match a certain percentage of our state population. If we can't buy accessible technology, our employees can't do their job. So it's a big issue here and that's one of the biggest reasons why we are trying to push that to the vendors, to say we need your help with this.
Conclusion
>> Thanks, Sarah and Jay. I think that's all we have for today. I'd like to invite you all to join us for next months PEAT talk on Thursday, October 15. It will feature Dana Marlowe of Accessibility Partners, who will be speaking about how embracing the concept of bring your own device can enable your employees to create offices that meet their personal needs through technology. You can find the registration link on Twitter on Peatworks, at PEATwork.og, or look for an email in the coming weeks. I'd like to give a special thanks to Sarah, Jay and Jeff. Enjoy the rest of your afternoon.
