Yes, Virginia, PMs Are Responsible for Accessibility

[amazonv]

Yes, Virginia, PMs Are Responsible for Accessibility

Type: Breakout

Track: Wildcard

Ho-ho-ho, Virginia! For too long, we’ve relied on developers to be the accessibility champion for tech projects. But if you put the sole responsibility on them, you’re setting your project up for problems–big, costly problems that can cause delays. I’d like to show how you–as the PM–can make sure your digital media projects are accessible because it really does start with you. You’ll learn the why, what, and how to do it. You’ve got this, Virginia! Love, Santa’s Helper.

 

>> Super excited to be here to moderate this session. Brought to you by Angela M. Hooker. Just before we get going I'll take care of a few housekeeping issues. 

Sorry. For people who need live captions, there is a captioning below the session here. I know that it looks like there may be a slight technical difficulty with that right now. But there is it is, it's starting now. So very exciting. So anyway, if you need live captions, those are below the video streaming service. If you'd like an accessible version of Angela's presentation, there's a button below the caption service that says download documentation here. This will give you an accessible version of the presentation to download for your own use. Next to the video streaming player is a chat and Q&A area. So if you have questions you'd like to ask the speaker, please put them in the Q&A area. I was advised by a screen reader user that it's actually a Q&A link. So you'll want to hit that and put your questions in there. I will be passing the questions into the group area which you can vote on if you think questions are interesting. You can thumb up those questions and we'll have the more popular ones float to the top. 

With that housekeeping done we'll save the last five or ten minutes of the session for Q&A. With that I'll love to hand it off to Angela and thank you very much. 

>> All right Noah, thank you. I've got a bit of an echo here, but I think it just resolved itself. All right everyone. Thank you for joining me this morning. It's bright and sunny in the Seattle area, and I'm really glad to be with you all. 

Let's talk about Virginia. You all might be familiar with Virginia O'Hanlin, who wrote an infamous letter to the New York Sun newspaper back in 1897. Back when I was a little girl... but we're not talking about that Virginia. We're talking about another Virginia. So meet Virginia, this cute little bear, this Christmas bear. She is a PM, and I don't know if that means that she's a project manager, a product manager, or a program manager. 

But she has a fair amount of experience, and she hasn't made accessibility a priority in her work. And she wants some help now. So she wrote me a letter. It says, dear Angela, I'm a PM, and some of my friends say that engineers are responsible for accessibility. My manager says it's also designers too. Please tell me who is it? Am I responsible as the PM? Sincerely, Virginia. 

Well yes Virginia, you do carry some of the responsibility, and I would say the bulk of the responsibility for making sure that your projects, your products for your programs are accessible. And I am going to answer her questions today. 

So I would say that when it comes to being a PM, the ability to produce a project that is accessible actually reflects your skill level and your capabilities, and effectiveness as a PM. So along with delivering a product or a project on time, within budget, within scope -- no scope creep -- and minimal friction among your coworkers. The knowledge of building in accessibility is going to set you apart from other PMs and leaders. And this is a skill that I see people seeking desperately. Because not everyone who says that they have accessibility knowledge and experience is able to translate that experience into accessible works. 

So let's talk more about some other questions that she has. Why do you build in accessibility from the start? When it comes to IT projects, the biggest mistake I've seen is when a PM or another team member thinks about accessibility when the project is almost done. And you effectively are setting your project up to fail if you wait to think about accessibility until the end. If not, it's just like building a house where you've got the frame, you've got drywall, you've got brick on the outside, you've laid that foundation, and it's almost finished. And then somebody says, did we forget to put in pipes? Are you kidding me? We forgot to put in the pipes. And then you have to go and tear up the foundation of the house and lay pipes. That's what it's like when you wait until later to build in accessibility or to consider accessibility. 

So as the PM, it's up to you to manage expectations. You'll have to set the expectation that you're going to deliver an accessible project with your team. Since accessibility affects everyone, every role in a project team, the person who is actually overseeing that project must ensure that every team member produces accessible work. This is going to lower the cost significantly to support accessibility if you consider it -- before you even start on the project rather than trying to retrofit it. 

And the first thing you're going to want to do is to get your leadership support. When you make your big pitch to leadership, you want to convince them. And there are a few ways to motivate them. Now, we all know that money is a motivator when it comes to companies that are actually producing a product. So you want to talk to them about the return on investment, and let them know that they would be missing out on the $8 plus trillion in disposable income that people with disabilities have. 

Now I would hope that people would support accessibility for more altruistic reasons, but sometimes the bottom line is what gets them. And you'll also want to let them know that it helps the organization be more competitive. Look at the accessible works that you can do. It's going to set you apart from the competition. So that's a plus there for your company. And it actually makes leadership and it makes you look good. So therefore, it makes the organization look good and trustworthy. Of course we hear most of all usually it's the law in many countries. So there is that aspect. But ultimately, it is the right thing to do. And you want to inspire leadership to work with purpose and intentionality. So in my resources in the deck, I've included a link to webaim's hierarchy for motivating change. And I would say it's really important to consider that because most people don't realize what a culture change it is when you start building in accessibility. And it can take awhile to really make that change happen in the organization. 

Now one other way that I've learned how to inspire leadership is to actually show them how inaccessible content hurts. I would encourage you to demonstrate something that your organization produces or perhaps something that a competitor produces, and show them if it's inaccessible how it doesn't function well for its users, and what an impact that has on the people using it. So whether you do something like walking them through with a screen reader or perhaps having them try to navigate a project without their mouse, that often is a good way to show them, oh, there are people who don't use a mouse. And we need to make sure that they're actually able to interact with this content. 

I would also say that this is a great time to think about asking a person with access needs to demonstrate their ability to use or not use existing content. And let them see this. Because in the end, it hurts your audience. They don't feel like they can see you as a trustworthy source if you can't engage with them. So it hurts the audience and we know when people lose trust they'll go to another source to get the same information that you're presenting. The other thing is that it hurts your company's reputation. It will create that mistrust. And it hurts the bottom line, because like I mentioned before you're leaving dollars on the table that you could be bringing in if you were producing something accessible. So as a PM, it's up to you to guide leadership so they will realize the importance of accessibility, and they won't undermine your efforts. I would say that you should talk with them about requests or directives that hinder your team's work. And you'll need to learn the fine art of managing their expectations and telling them, okay, I understand that you want to do X, but if we do this, it's going to impact us this way. And it's especially true if they ask you to produce a project that emphasizes being cool over usability and accessibility if it requires your team to use a specific technology or framework just because or if they are pointing you in an inaccessible design direction; if it prioritizes deadlines over having an accessible project, and if they don't allow you -- if you're just learning about accessibility, if they don't allow you to work with an accessibility consultant, or also work with people with disabilities as you create your project. So if it's not a priority for leadership, they won't prioritize it for your team. And it's a great opportunity for you to demonstrate your leadership skills and allow them to see how it's going to impact your project and your team to produce a great work. 

So I mentioned working with an accessibility consultant. If you're newer to accessibility, and you don't have that depth of knowledge, it's not really something that you can learn overnight with a checklist. Sometimes if you're thrown into a project and you just didn't have an opportunity to get people to help you on board, a checklist is going to help you to know what to look for, but it's just not going to tell you everything. So you would want to work with someone who has a fair amount of experience and has seen how technology has evolved over the years. They can advise you accordingly, because they'll know what works, what hasn't worked, what can work, and they can walk you through the life cycle process. 

They will understand specifically what people with disabilities have a need for when it comes to access, and they can translate that into results for your project. 

So the other thing is I often hear people say that you should start considering accessibility when design comes into the room. I say that it's already too late, because when you're putting together a project, you want to make sure that you've considered budget, timeline, people on your team, and the resources that you'll use to produce the project. So you don't even want to start thinking about accessibility when you're in the design phase. Go way back before that, and plan for accessibility when you're actually getting stakeholders together, and determining your project plan. And factor in accessibility in these areas. 

So while we're talking about your timeline, I want you to include multiple accessibility reviews within that timeline. Sometimes people have the mindset that, okay, we're going to build in accessibility, but we're going to check it at the end. Actually, you want your team to check their work as they go along. So include those reviews there for each team member, and in their role. And make sure that you have adequate time to actually check work. It's going to take more than a day to check a site, and many times I've had people come to me the day before a project was due to launch and say, can your team help us check this site and make sure it's accessible? And that's when I want to run screaming from the room. Don't be that person. (Laughing). 

So include multiple reviews in your timeline. The next thing you're going to want to do is think about the standards and the level of compliance that you need to achieve. And your consultant will help you know what you must do to comply with the law where you are, and also make your project accessible. And those are two different things. 

I'm sure you've heard other people saying that you can have something that conforms to the standards, but it's not the greatest user experience. It's not accessible. And your consultant will help you with that because sometimes you may need to do a little bit more work for certain disability types. So you want to make sure that you are choosing the right requirements, the right laws, and level of compliance so that your project can succeed. And if your project is used globally, make sure that your consultant has thought about worldwide laws since some countries require specific documentation. Now save yourself some pain, please. I was so heartened yesterday to hear Denevudro talking about the accessibility needs and mapping project. Because that has been a real project saver for me. That project is based on the web content accessibility guidelines. And I have a link to that in the resources. So you want to take a look at that, because it actually breaks down the responsibilities for your digital projects by role. Everyone will know what they're responsible for, and there won't be any question about what they have to achieve. It's safe to use the web content accessibility guidelines or WCAG because you know that you are going to meet the standards that most countries have if they have those laws. 

 

 

 

So see that resource in the deck. Now you also want to think about accessibility if you work with vendor agencies. You want to put that -- those accessibility requirements in your contracts. So you want to consider it when you're putting together your requests for proposals, statements of work, and any overall contract for your project. This is where there can be a lot of confusion because if you don't do this, then you can't hold agencies that produce work for you. You can't hold them responsible for the end result of their work, and making sure that it's accessible. So put that in your contract, and be sure that you stipulate that your organization and not the vendor agency that you hire will determine if your project is accessible. Any work for hire. You want to make sure that they're meeting your needs, and they may say something is okay but it may not meet the needs of your audience. So you also want when you're putting together your requests for proposal, make sure that you ask those vendor agencies for proof that they can produce accessible work. If they don't know and they can't adequately explain how they do this work, then they're likely not the agency for you. Let them know, this is another place where I see an area for improvement, let's say. Let them know what you're going to measure them against when it comes to accessibility. Let them know the specific standards that you're going to use. And I also would recommend giving them the principles of accessibility that the worldwide web consortium put out when they put WCAG 2.0 out. You want to let them know that you're going to measure them against the ability for the project to be perceivable, operable, understandable, and robust. If people know what they have to measure against. It's going to be easier for them to produce work that meets your needs. And I have linked to a resource on those principles, the POUR Principles. 

 

 

Now you also want to be careful about the technologies that you decide to use to produce your project. Make sure you read the label for everything. And shop for the best technologies that you're going to use, whether we're talking about platforms, libraries, frameworks, plug-ins etc. What ever it is, make sure that they are able to actually produce an accessible work. And that they won't hinder accessibility in any way. So if the technology that you want to use has accessibility issues, and the creator of that technology solved that problem. If they can't, must you use it? And I know this is sometimes where get guidance from leadership that says you must use this. But if you must use it, can your team fix any accessibility issues that it has within the project scope and timeline and within budget? If not, you want to flag that as a risk. The next thing you want to do is to document all your team's work when it comes to accessibility. Make sure that you're keeping track of everything each team member does to make the project accessible. And you can work with your accessibility consultant. This is particularly important if any one ever publicly calls your company into question about their work. You will actually have documentation that shows you made a good faith effort to be accessible. So keep track of this because it will protect you, it will protect your team, and it will protect your organization. 

 

 

The next thing you want to do is to get training for your team. If your team is new to accessibility, they are probably going to need some guidance to help them know what to do when it comes to producing accessible work. And there's a lot of great free information out there on the web, but let me tell you, be careful with that. Because misinformation abounds. You want to make sure that you're choosing trusted resources that will guide you. I would say start with information from the worldwide web consortium's accessibility curricula. And I have a link to that in the resources, so don't worry about trying to find that on your own. Because there is great information that they have for everybody involved in producing a project. You also can go to Deque University WebAim, Note-ability. And the Association of Accessibility Professionals. They all have trustworthy information out there about how to produce accessible works. So make sure the training actually covers people with disability and their specific needs. And you also want to consider people in situational limitations. And people with access needs that really aren't based on a disability but that would prevent them from using a project. And this is training that sometimes people forget about. They usually look for the how-to's, but they don't get to the part of understanding the why's and the impact of what they're doing. So make sure that training covers that. And also be sure to include leadership when you train your team. Sometimes we think of them as the people over there and we don't have to worry about them. But the more they know and understand about ability, the more they're going to support you and your team. You also want to be sure that you train new team members when they come on board. Because they may have an understanding about accessibility, they may have checked that box when they applied for the job. They may have even talked briefly about it when they interviewed with people to come on board. But they may have a different understanding than you have. So make sure that you all are aligned on what accessibility means. The other thing is that since technology changes, learning and education about accessibility should be ongoing you want to keep your team current when it comes to latest trends and technologies. Things change. So don't expect it's something people learned a year ago even is going to be the same in truth for today. You also want to encourage your team to be innovative. Boy oh boy, I wish I could have this branded on a T-shirt. Encourage innovation. Because I see many people wanting to play follow the leader. People look at their competition and they want to imitate what they're doing because they think it might be cool or current, but let me tell you something. I would say that we have compounded so much bad design and inaccessibility by following what other people are doing out there. It doesn't lead to accessible experience. Doing what your competitors do just for the sake of doing it often leads to the acceptance and normalization of poor, inaccessible design, and that becomes the norm as far as design patterns. 

People will say, well, so and so is doing it -- it must be okay. No. You want to be able to do something that's different and innovative, but accessible at the same time. You can distinguish yourself, your team, and your company by creating something that innovates and solves real problems for your audience. It can be distinctive. That's fine. But just make sure it's accessible. 

Many of the accessibility problems happen because people are doing what others do. Solving those problems isn't a quick task, but it is well worth it because work is work and it takes as long as it's going to take. So don't look to what other people are doing to try to get on the fast track to produce your project. Make sure that you do research and solve problems for the long term. 

So Virginia also asks, how do you coach your team when it comes to accessibility and oversee their work and make sure that they're actually producing something that is accessible? This is really important because people, I would say when it comes to requirements for a project, they usually try to make it about the person who is responsible for the project, or the consultant that comes in and talks about accessibility. You do not want to make accessibility a cult of personality. People have said to me, well, I know that if you're not happy then we can't move forward. And I have to stop them. Really, it's not about making me happy. It's about what is going to produce the most accessible and usable product for our audience, and what is going to make our organization look good. So it's not about Angela. If your team makes it about you, then let me tell you all the great work you've done will not stand the test of time. You will not leave a legacy that will continue, because they're doing it to please you rather than doing it because it's the right thing to do. Now when you're coaching your team, I've seen how demoralizing this work can be sometimes. People when they learn about accessibility, they often take it as criticism. You have to coach them and let them know, no, this isn't about you doing a poor job necessarily. You're great. But have you considered this? We need to think about how we can expand our reach. And make it so that we can engage with more people. So keep them motivated during the tough times. And it's hard. Let me tell you that's probably one of the hardest things that I've encountered when it comes to working for a team that is trying to produce something accessible. 

You also want to make sure that you advocate for accessibility. And when you do that, when your team is doing a great thing, make sure you praise your team members. Share that feedback with leadership so they can see the difference and the progress that your team has made. This is going to help you build a great relationship with your team and it will help you earn their respect and their trust. And that is going to ultimately help your project. Now I would like you to remember that for each team member, when it comes to a project, there are some things that you're going to want to coach them on. In the interest of time, I have some resources in the deck for each role. I have tasks that you'll want to make sure that each team member is looking at when it comes to producing accessible work. But let's start with the content writers, and we can go briefly over a couple of points. You want to make sure that they're writing the content first. I know that we are living in a template-ized world. And I am a template-ized girl. But let me tell you, when you try to pour in content into a preexisting design, it often will not support the accessibility of the written content. You want to design the content and make sure that it is usable. You don't want to come with a template, a pre-designed template and then try to force something to go in a square peg in a round hole, let's say. 

You want your content writers to work with the designers to collaborate with them. And that's going to help them start thinking about how they can produce a design for the content. You want to encourage your content writers to test their writing with people who have disabilities, and particularly it's helpful if you talk with people who have cognitive impairments. Ask them if they're able to understand what they're supposed to do. And have them describe what they think the task is. And if they can, then that's great. Have your accessibility consultant review the content, and make sure that it is accessible. 

You also want to make sure that they're using plain language and not obscure or big words that are unnecessary. Now again, I have resources for each role so please see that in the deck. 

 

 

When it comes to designers, again, collaboration is the key. Prompt your designers to design with accessibility in mind, and that they are producing universal accessible design. They also have an important task when it comes to working with engineers. They need to annotate their designs so that they can show the engineers what the interactions, any changes in state, the functionality; they need to be able to mark that up so that the developers can actually take those designs and produce an accessible work. 

So you want to include accessibility reviews there when it comes to mockups, wire frames, and the annotated designs even. I have some resources for how to annotate designs for engineers. So when it comes to engineers and developers, collaboration is the key. And this is what we always hear that engineers are responsible for accessibility. No. If you're waiting -- like I said earlier, if you're waiting until this part of the project, then you're already behind. Make sure your developers know how to produce accessible code, and make sure they don't overengineer solutions. A simple approach is usually best. And have them work closely with the designers so that they can produce something simple when they review those annotations that the designers create. Make sure that your engineers are actually checking their work throughout the process to make sure that it's accessible. They shouldn't wait until the end of what they've developed to make sure that it is actually functioning properly. Have them use one -- several of the many accessibility checkers out there and tools out there that will help them make sure that their work is not producing something -- I'm sorry. That it won't produce an inaccessible experience. 

 

 

And encourage them to use an accessible pattern library or framework as the foundation, because I've seen that people will recreate the same problem over and over, but if they start with something that's actually accessible from the start and then build on that, it's going to make it so much easier for them. I also encourage you have your team work with personas of users. There are some wonderful examples out there, and I've linked to them in the resources. You can build personas based on typical people who would use your project. And you can build them up based on those examples. Either way, you want to make sure that you're including personas of people with disabilities. And then write user stories for your project based on personas. One of the things that will help your team consider and fulfill your users' needs is actually assigning personas to -- a persona to each team member. Have that team member represent that person. And advocate for that person and disability type throughout the project. That sort of makes it resinate with them. I've assigned them to each team member on certain projects, and that helps them understand, okay, not only do I need to represent this user, I need to understand what the other users that my team is advocating for. I need to consider their needs. So that usually makes it a bit more real to them. 

You also want to invest in usability testing for your project. And if you're able, do that throughout your project. And not just at the end when you've produced the project. Now I recommend a book by Steve Krood called Rocket Surgery Made Easy. An organization I used to work for created a usability testing program based on this work -- on this book, because we didn't have a lot of money. So we were able to take the information in that and transform it into a really thriving program. It helped us as we produced our work. So take a look at that book, and there's a link in the resources. Now did I mention documentation? Yes, I did. Let me tell you. Gather all the sticky notes you kept, any chalk board drawings, all the documentation that you've done to make things accessible. And prepare a general statement about your project's accessibility status. If you discovered accessibility issues, document them and make a roadmap to address those issues. It's particularly important to save this institutional knowledge so that people who come or go will always information about what worked, what didn't work in the past, and that will stop your team from making the same mistakes. If you're working on a legacy project or product, if you're not building something new, what do you have to do to bring something up to conformance? You want to start small. Have an experienced auditor review your project for accessibility. But in the meantime, talk with the team responsible for the project and find out what they need to know and if they have any concerns or questions about producing something accessible. Again, get them training if they need it, and talk with your stakeholders about what's in scope for the budget and time that you have. What resources do they have? When you do get the report from the person who audits your project, create a plan to give the team some quick wins for accessibility. And create a roadmap for conformance. 

So with all of that, thanks for coming. Thanks for listening. I know that I went a little bit long. And I apologize for that. But I'm happy to answer any questions. 

>> Unmute myself there. Angela, can you hear me okay? 

>> Yes, hey there, Noah. 

>> Thank you so much for the presentation. This has been tremendous. There's a lot of questions. And I apologize for everyone attending we don't have time to get to all of them. But one close to the top of the popularity is which certifications or study pads can you recommend for PMs interested for growing their professional skills within accessibility? 

>> I would say go to the International Association for Accessibility Professionals. And look at the different types of programs they have available. There are different types of certifications for people who test or people who actually are project managers, or other parts of it. And see what is really best suited for you and your interests. You don't want to get a certification for something that is dull to you. So make sure you choose something that works with your career goals. 

>> Uh-huh, yeah. Love that. The IAAP, the WACP, and WAS and the there's a new certification, the CAP, I think. They're pretty diverse in body of knowledge and applicability. So I agree that's awesome. We only have about one more minute left. So real quick... any tips for getting reluctant designers on board? 

 

>> Ah, okay... designers can be a challenge in some cases because they don't want their creativity hindered. So you can tell them that you're not trying to hinder their creativity. You're trying to give them an opportunity to do something that goes beyond the norm when it comes to good design. Because good design is accessible design. And they can really make a name for themselves if they do something that is innovative and accessible. 

>> Yeah, I love that. Well said. Thank you to Angela. Thank you to everybody for attending. This was a wonderful session. I -- we're wrapping up here. So please enjoy what may be a breakfast or lunch break. Depending on where you are in the world. And we'll see you at the next session here at axe-con Deque. Thank you again Angela so much. 

>> Thank you