Whether you are managing a project, product, service, or a technology team, you have responsibility for ensuring the technologies that are ultimately delivered are accessible to all users. There are many ways to approach this responsibility, including the following:
- Communicating the value of accessibility to your team
- Building your team’s accessibility knowledge
- Including accessibility in job descriptions to ensure you’re hiring talent that already brings accessibility awareness to their position
- Incorporating accessibility into all stages of a project
- Helping to make the case for accessibility
More details about each of these approaches are provided below.
Communicating the value of accessibility to your team
Many technical people have been trained and have pursued their careers without encountering accessibility. Convincing them of the value of accessibility can be achieved with steps like the following:
- Strategic goal: Identify accessibility as one of the strategic goals of your project and include your technical team in discussions of what that goal means and why it is important.
- Risks and costs: Provide examples of the risks of poor accessibility, including lost customers, bad publicity, lawsuits, and other legal actions.
- Your peers are doing it: Point out that their peers are creating well-designed, usable sites meeting accessibility criteria (technical people are often competitive) and point them to specific examples.
- DIY evaluations: Demonstrate simple methods technical people can use for evaluating the accessibility of a product, including interacting with it using the keyboard only, or performing automated tests using the wide variety of tools listed on our Tools and Resources page.
Building your team’s accessibility knowledge
- Learn: Many resources exist that can help your team develop an understanding of accessibility principals and techniques. Our Training Opportunities page is a great place to start. Support your team by allowing them time to learn about accessibility, just as they devote time to learning new design or development tools or coding languages. Accessibility is an integral part of any designer or developer’s skill set.
- Engage: Encourage members of your team to get involved in the IT accessibility community at the UW. Consult our Events page for opportunities to engage. In particular, encourage web designers and developers to attend the monthly Web Accessibility and Usability Meetup, an informal opportunity for peers to review each others’ sites in development, and to learn together with deep dives into current accessible coding challenges. Also, if any of your team members are especially interested in accessibility, encourage them to join the IT Accessibility Liaisons network.
- Apply: When designing or developing new interfaces, or when selecting components from pre-built code libraries, frameworks, packages, plug-ins, or modules, encourage team members to apply their accessibility knowledge. If questions arise, circle back to the accessibility community to get their input, or get help from the UW’s IT Accessibility Team.
Including accessibility in job descriptions
Hiring staff knowledgeable in accessible design can bring new insights and skills to any team. When advertising an open position, clearly state that such knowledge is an essential criterion for qualifying for the position. UW-IT, the central IT unit at the University of Washington, encourages supervisors to include the following required or desirable qualifications:
Knowledge of IT accessibility issues for users with disabilities; familiarity with accessibility standards and best practices; experience testing for accessibility; and demonstrated ability to design content/applications with accessibility considerations.
This is a good start, but more detail is recommended, particularly in positions that involve technology purchasing, development, deployment, or support. Also, rather than referring generally to “accessibility standards and best practices”, consider referencing specific standards from the W3C. See the UW’s IT Accessibility Standards for specific standards the UW is currently striving to meet.
Of course, it is common for candidates to assert they have experience in areas where they actually do not. During an interview, be sure to ask open-ended questions that required demonstration of accessibility skills and experience. For example:
- If candidates are asked to provide examples of their work, ask them to include one or more examples that demonstrate good accessibility. Regardless of whether they have accessible examples, as them to comment on the accessibility of their chosen examples. What are the most noteworthy accessibility features in these examples? What features could be improved upon, and why?
- If candidates are providing a demo of an interface they’ve created, ask them to set aside their mouse and demonstrate how the application can be used with keyboard only.
- If candidates are provided with design scenarios such as functional problems in need of technology solutions, be sure to include accessibility as a requirement in the scenario (e.g., the solution must be fully operable without a mouse, must be accessible to blind users, and must be operable using speech input for people with no use of their hands).
- When candidates discuss their accessibility knowledge, listen for keywords such as WCAG, ARIA, and semantics. (If these terms are unfamiliar, see the section above on Building your team’s accessibility knowledge for educational opportunities).
Incorporating accessibility into all stages of a project
Building accessibility into a product from the beginning is much less work, and more cost-effective, than trying to add it after the product has been built. A project life cycle should define and tests for accessibility criteria at each stage of the project:
- Plan: In your strategic project planning, clearly state that accessibility is a primary goal.
- Design: In the design stage of your project, explicitly plan how you will implement accessible design in your product and the specific procedures for evaluating accessibility
- Implement: In the implementation state, repeatedly evaluate whether the product, as parts of it are developed and assembled, complies with the planned design.
- User tests: Have the product repeatedly evaluated by outside people using a variety of access methods (keyboard only, screen reader, color blind person, etc.) as soon as there are functioning drafts or mockups.
- Evaluate: As the product nears completion, have a systematic accessibility evaluation as a key part of quality assurance.
- Bug fixes: After the product is in production, track any fixes that are done and evaluate each for any effect it might have on accessibility. If it has negative impacts, find a better fix.
Helping to make the case for accessibility
Management, from the team leader all the way up to the director and beyond, may be skeptical about the need for investing in accessibility. Here are some points you could share with them:
- Everyone benefits: There are many examples of solutions that were created specifically to address an accessibility need and now benefit everyone: Automatic door openers were created for wheelchair users but benefit anyone whose hands are full; Captions were created for people who are deaf or hard of hearing but benefit anyone who needs to watch a video with the sound down, help second-language users to understand what’s being spoken, and make the content of video searchable. It is highly likely that your product, if created with accessibility in mind, will be a better product for everyone as a result.
- Building competence: Building team accessibility skills and including accessibility throughout the development processes leads to better products in the long run and greater efficiency and flexibility in creating and updating them.
- Avoiding costs and embarrassment: Lawsuits and judgments can be expensive to respond to and result in considerable negative publicity.
- Teamwork: It is likely that your product is part of a set of products or services your organization provides for the people it serves. Putting out one inaccessible product reflects on the whole set of products and may prove to be the broken link in a sequence of products people need to follow.
- Creating an inclusive community: The purpose of your product is to meet a specific need for your users, who are likely to have that need in the context of other things they are doing. When your product works for everyone, then everyone can participate in that context.