Yes, Virginia, PMs Are Responsible for Accessibility
•Download as PPTX, PDF•
1 like•140 views
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
Recommended
Recommended
More Related Content
Similar to Yes, Virginia, PMs Are Responsible for Accessibility
Similar to Yes, Virginia, PMs Are Responsible for Accessibility (20)
More from Angela M. Hooker
More from Angela M. Hooker (10)
Recently uploaded
Recently uploaded (20)
Yes, Virginia, PMs Are Responsible for Accessibility
- 1. Yes, Virginia, PMs Are Responsible for Accessibility Angela M. Hooker axe-con | March 2021
- 3. Your ability to produce accessible projects reflects your skill level as a PM.
- 4. Why do you build in accessibility from the start?
- 7. Budget. Timeline. People. Resources.
- 8. Include multiple accessibility reviews in your timeline.
- 9. Choose the standards and level of compliance you’ll achieve.
- 10. Put accessibility requirements in your contracts.
- 13. Get training for your team.
- 15. How do you coach your team and oversee their work?
- 16. Written content comes first.
- 18. Engineers and developers: Collaborate!
- 19. Have your team start with user personas.
- 20. Invest in usability testing.
- 21. Did I mention documentation?
- 22. What if you’re updating a legacy project?
- 23. Let’s review.
- 24. Thanks for coming! @AccessForAll linkedin.com/in/angelahooker angela.m.hooker @ gmail.com Credits: This presentation template was adapted from Slidesgo's "Cute Winter Animals" template, including icons by Flaticon, and infographics and images by Freepik. slides: https://noti.st/accessforall
- 25. Resources (1 of 2) • Integrating Accessibility in the Organization’s Web Development Life Cycle, Denis Boudreau • Accessibility for Project Managers, Ben Logan • Just Ask: Integrating Accessibility Throughout Design, Shawn Lawton Henry • Managing Accessibility Compliance in the Enterprise, Karl Groves • Personas: Understanding Disabilities and Impairments: User Profiles, GOV.UK • Do Your D&I Efforts Include People with Disabilities, Harvard Business Review • Motivating Accessibility Change, WebAIM
- 26. Resources (2 of 2) • Constructing a POUR Website, WebAIM • Accessibility laws and standards from around the world, Level Access • World Wide Web Consortium Web Accessibility Initiative’s Accessibility Curricula • About the real Virginia O’Hanlon
- 27. Top tasks for PMs (1 of 2) • Do the technologies you’ve chosen support accessibility? • Investigate compliance statements. • Check well-known implementations of those technologies. • Review these technologies, if needed. • Is there enough time for accessibility reviews throughout the project timeline? • Have you factored in budget for accessibility consultations (if you need outside help)? • Have you considered the specific access needs of people with each disability type and people in situational limitations?
- 28. Top tasks for PMs (2 of 2) • Choose the accessibility standards you’ll follow for the project. • Use the Accessibility Roles and Responsibilities Mapping Project. • Ask potential vendors for proof that they are experienced in accessibility. • Include accessibility requirements in requests for proposals, contracts, statements of work, etc. • When you select a supplier, state in your contract that they must give proof that their work conforms to your chosen accessibility standards when the project is complete. • State in the contract that your team—and not the supplier—will have the final say on whether the supplier has met the standards. • Let them know you’ll measure accessibility against the POUR principles (perceivable, operable, understandable, robust).
- 29. Top tasks for content writers (1 of 2) • Write simply and clearly. • Write simple, short sentences. • Write for the web rather than writing as you would for print. • Use common words and terms that your readers know. • Use plain language principles. • Put the most important info first in headings, sentences, lists, paragraphs, links, etc. • Break long documents into separate topics. • Use bullets and lists, when possible. • Make call to action (CTA) buttons and links specific and descriptive.
- 30. Top tasks for content writers (2 of 2) • Aim for a sixth-grade reading level. • Consider people with cognitive impairments, low-language proficiency, mental health concerns, plus non-native language speakers, and neurodiverse people. Learn about their needs at Clear Helper, and WebAIM’s Cognitive Disabilities info. • Test your content with people with disabilities; ask if they can complete a task based on the content. • Read Accessibility for Web Writers, from 4Syllables. • See “A web of anxiety: accessibility for people with anxiety and panic disorders,” The Paciello Group
- 31. Top tasks for designers (1 of 2) • Consult user personas before you design. • After you’ve designed each component, page, etc., work with your accessibility consultant to map out how people with each type of access need (and people without access needs) will use each part of your project’s interface and complete tasks. • Choose fonts that support the best readability (avoid fonts that are too thin or ambiguous; avoid too many fonts per page; remember that font use/repetition conveys structure/hierarchy). • Watch out for flat design issues. Sometimes the lack of depth makes it hard to perceive parts of an interface. • Don’t follow the crowd—innovate!
- 32. Top tasks for designers (2 of 2) • Use motion with caution, as it can make some people ill or, worse, induce seizures. • Mark up your design for developers. Walk them through each component/page. See Aaron Pearlman’s Top Five Most Common Accessibility Annotations. • See WebAIM’s Accessibility for Designers infographic.
- 33. Top tasks for engineers/developers (1 of 2) • Work with the designers and the accessibility consultant to plan for all content states, interactions, etc. • Use checklists to help you remember accessibility principles, but know that using a checklist doesn’t make your work accessible. • Write user stories, related to each accessibility standard in the Microsoft Accessibility Standards, so that you meet each user need that each standard addresses. • Build out the design. • Use semantic code. • Code for device and platform independence. • Support keyboard accessibility.
- 34. Top tasks for engineers/developers (2 of 2) • Use HTML before relying on other technologies, such as ARIA, to create compliant works. • Validate your code to find common errors, or be sure your development environment checks your code for errors. Don’t worry about issues that the W3C recommends but validators mark as errors (including ARIA, CSS, etc.). • Test your code with accessibility tools throughout your development process—not just at the end. • Use Accessibility Insights to help you find access issues throughout your development process. Its FastPass mode is good, but you’ll get more in-depth help from Assessment mode.
Editor's Notes
- You might be familiar with Virginia O’Hanlon who wrote an infamous letter to the New York Sun newspaper, in 1897. But I’m talking about another Virginia. She’s a PM (project manager, product manager, or a program manager) with a fair amount of experience, but she hasn’t made accessibility a priority in her work, and she wants some help now. She wrote me a note that said: Dear Angela, I'm a PM, and some of my friends say that engineers are responsible for accessibility. My manager says that it's designers, too. Please tell me—who is it? Am I responsible as the PM? Sincerely, Virginia: Yes, Virginia, you do carry the responsibility for making sure your projects, products, or programs are accessible.
- It demonstrates your skills, capability, and effectiveness as a PM—program, product, project. Along with delivering a project on time, within budget, without increasing scope, with minimal friction among colleagues…the knowledge of building in accessibility will set you apart from other PMs and job candidates. This is a skill that people seek desperately because not everyone who says they have accessibility knowledge and experience truly does. So, let’s talk about Virginia’s questions starting with how to build accessibility into projects.
- In IT projects, the biggest mistake I’ve seen is when a PM or other team member thinks about accessibility when the project is almost complete; you effectively cause your project to fail if you wait until the end. If not, it’s like building a house where it’s almost finished and having to tear up the foundation to put in pipes. As the PM, you manage expectations—you must set the expectation that you'll deliver an accessible product. Accessibility affects everyone on a project team; the person overseeing the project must ensure everyone produces accessible work. Lowers cost to support accessibility significantly if you consider ahead rather than having to retrofit it in a project. Photo https://commons.wikimedia.org/wiki/File:Pacific,_WA_%E2%80%94_New_house_under_construction_%E2%80%94_01.jpg https://creativecommons.org/licenses/by-sa/3.0/
- Get your leadership's support for accessibility. When you make your big pitch, here’s how you convince them: We know money is a motivator; tell them about the return on investment; they’d miss out on the $8+ trillion dollars in disposable income that people with disabilities have. Helps your organization to be competitive. It makes *you* as a leader look good, and it makes your organization look good. It’s the law in many countries. It's the right thing to do; inspire them to work with purpose and intentionality: in my resources, I’ve included WebAIM’s hierarchy for motivating change—this work requires a culture change, and it can take a while to accomplish that. Demo inaccessible content to your stakeholders, whether you need to make them believers; have them try to navigate without their mouse, using a free screen reader, etc. This exercise will show them how inaccessibility hurts: It hurts your site’s audience, since inaccessibility causing mistrust; it hurts your company’s reputation; and it hurts the bottom line. As the PM, you’ll need to guide leadership, so they won’t undermine your efforts. It’s important for you to talk with them about requests or directives that will hinder your team’s work; you’ll need to learn the art of speaking to them to manage their expectations. This is especially true if they ask you to produce work that Emphasizes being cool over usability Requires the team to use a specific technology or framework, BECAUSE … Inaccessible design direction Prioritizes deadlines over having an accessible product Doesn’t allow you to work with an accessibility consultant and/or people with disabilities as you create your project. If accessibility isn’t a priority for leaders, they won’t prioritize it for your team.
- Work with an experienced accessibility consultant. If you don’t have accessibility knowledge and experience, it’s not something that you can learn overnight with a checklist. It’s far more in-depth than that. Someone with a fair amount of experience has seen how technology and accessibility has evolved and can advise you accordingly. They will guide you through the lifecycle process. They understand what people with disabilities need for access and can translate that into results in your product.
- Some people say that you start considering accessibility when designers come onboard your project—start thinking about accessibility ahead of that. You’ll want to factor it in your budget and timeline, and consider the people on your project team and the resources you need to carry out the work, whether internal or external.
- Include accessibility checkpoints throughout your project timeline. You’ll need to have your accessibility consultant and team check more than once.
- Choose the standards, laws, and level of compliance with your accessibility consultant. Your consultant will know what you must do to comply with the law and what will make your project accessible—two different things. If your project will be used globally, make sure your consultant helps you comply with worldwide laws, since some countries require certain documentation. Save yourself some pain! Use the W3C’s Accessibility Roles and Responsibilities Mapping Project., which is based on the Web Content Accessibility Guidelines (WCAG 2.0). I’ve got a link in the top tasks resource for PMs in this deck. This Photo by Unknown Author is licensed under CC BY: https://www.biblioblog.si/2015/09/pravo-v-dobi-velikega-podatkovja-ali.html https://creativecommons.org/licenses/by/3.0/
- Will you work with vendor agencies? Put accessibility requirements in your requests for proposals (RFP), statements of work (SOW), and overall contracts. Also ask, in your contracts, that the vendor agency proves that they’re capable of producing accessible work. Be sure you stipulate that your organization—and not the vendor agency that you hire—will determine if a project, product, or any type of work for hire is accessible. In those vendor contracts, RFPs, SOWs, ask for proof of accessibility/documentation for any work they produce for you. Let them know what you’ll measure against to determine accessibility: the specific accessibility standards you’ll use, and I recommend that you give them the Perceivable, Operable, Understandable, Robust principles of accessibility that the World Wide Web Consortium focused on when they created the 2.0 version of the Web Content Accessibility Guidelines (otherwise known as WCAG).
- Read the label! “Shop” for the technologies, platforms, libraries, frameworks, plug-ins, etc. carefully. Make sure they support accessibility and won't hinder it in any way. If the technology has accessibility issues, can you get the technology's creator to solve the issue? If not, must you use it? If you must use it, can your team fix the issue—within scope, cost, and deadline?
- Document everything your team does to make its work accessible for each project, product, program. Do this for every new project and every update. Work on this with your accessibility consultant. This is especially important in case someone tries to bring legal action against your organization. You'll be able to show that you made a good faith effort to be accessible.
- Your consultant may be able to help. Be careful of resources—misinformation abounds; choose trusted sources. Start with this info from the World Wide Web Consortium’s Web Accessibility Initiative’s accessibility curricula: https://www.w3.org/WAI/curricula/ Also start with these trusted organizations (there are many I can list here, but these are a good start): Deque University WebAIM Knowbility IAAP: International Association of Accessibility Professionals Make sure the training covers people with disabilities, people in situational limitations, and other access needs, and teaches what makes a great user experience for them. Include leadership when you train your team. Also, train new team members when they come on board. Accessibility learning is ongoing since technology changes. Keep your team current.
- Don’t follow the leader! People tend to look at the competition and imitate what they’re doing. So many people have compounded bad design and inaccessibility with this practice. This doesn’t lead to accessible experiences—it leads to acceptance of poor, inaccessible design as the norm common design pattern. Do something different—but accessible! You can distinguish yourself, your team, and your company by creating something that’s innovative and solves problems for people in a distinct way. Many of the accessibility problems we have across the web and in software exist because people follow others. Solving problems isn’t a quick or easy task—work is work! Make time to research, test, and solve problems for the long term.
- How do you make sure each team member is creating accessible work? People will try to make this about a cult of personality: “If it’s not accessible, Angela won’t be happy…” It’s not about making Angela happy, it’s about your audience and giving them a good, engaging user experience. If your team makes it about you, then your legacy won’t outlast you since they’re only working to please you instead of doing the right thing. Sometimes, this work can feel demoralizing; people take it as criticism about their skills—you’re great, now also consider X. Keep them motivated through the tough times. As a PM, advocate for accessibility. Praise your team members for their progress. Share these wins with leadership. This helps to build a good rapport with your team and earn their trust.
- Write content first. Use plain language (resources in the appendix). Write with your designers, so they can design the content instead of pouring content into a pre-made design. I know this is a framework and templatized world, but as much as possible, do this. Test their writing with people who have cognitive impairments—ask if they’re able to understand what they’re supposed to do; have them describe it; if they can understand the task or interaction or subject, then it’s good. Have your accessibility consultant review all written content.
- Prompt designers to design with accessibility in mind—not inclusive design: accessible design. Designers have an important task: to annotate their completed designs that show interactions, states, functionality, etc. so developers can translate that into an accessible work. Include accessibility reviews with each mockup, wireframe, annotated designs, etc. See the resources for designers later in the deck.
- People usually make accessibility the responsibility of only developers and engineers—big mistake. Make sure your developers know how to produce accessible code. Check that they don't "over-engineer" solutions to any problems—a simple approach is best. Have them work closely with designers. Make sure the project works with a keyboard. They should check their work for accessibility throughout their development process. Encourage them to use an accessible pattern library or a framework as a foundation, so they won’t re-create problem code. Also have your accessibility consultant review their work, so they can make sure it works with any assistive technologies that people with disabilities use.
- You can work with personas available from some great sources—I’ve included them in the resources. Or you can tailor them to the typical people who would use your project, program, or product. Either way, include personas of people with a variety of disabilities. Write user stories based on personas to help each of your team members to consider and fulfill the users’ needs. As you create your work, start with thoughts of each user story and persona you create. I’ve assigned each persona to a team member and had them advocate for that person, whenever we did any updates, redesigns, completely new sites, etc.
- Gather all those sticky notes, chalkboard drawings, notes on napkins—and the documentation you’ve kept. Prepare a general statement about the product or project's accessibility status. If you uncovered problems, document them and make a roadmap to address those issues. I see teams fail in this area at a high rate: They neither store this info nor share it as institutional knowledge. This is how you stop your team from making the same mistakes over and over—especially when you have people come and go. Setting your organization up for success with this institutional knowledge is another differentiator and sets you apart from other candidates.
- What if you're not building something new and need to bring a legacy site or project up to conformance? Start small: Have an experienced auditor review your project for accessibility. In the meantime, talk with the team responsible for the project. Find out what they need to know, if they have concerns and questions. Get them training, if they need it. Talk with your stakeholders about budget, time, and scope. What resources do they have? What concerns do they have? When you have the report from your auditor: Create a plan to give them some quick wins for accessibility. Create a roadmap for conformance, so they understand what it will take. Also, explore whether you're able to go beyond mere compliance with the standards--remember, the goal is for great user experiences, so how can you improve on that? Is it possible to address more than the minimum when the team has to remediate their work? If so, do it then--don't put it off.