Managing for Accessibility

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 criteria 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 qualification:

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.

Here are a few examples of additional job requirements that might be included in a position announcement:

Accessible user interfaces: Experience designing and creating user interfaces that work well for a wide range of users, including people with vision, dexterity, and other limitations who use assistive technologies.
Evaluations: Experience conducting accessibility evaluations of websites and web applications.
Semantics and ARIA: Understanding of the concepts of semantic mark-up (HTML elements that state the type of content they contain, such as paragraphs, headings, lists and list items, and forms).
Continuous accessibility evaluation: Experience at evaluating accessibility of their product at each stage of its development.

Unfortunately, it is common for candidates to assert they have such experience when they actually do not. In evaluating an application, watch for the following indications of demonstrated skill:

Evaluate the samples: When they provide sample sites, conduct an accessibility evaluation on the site.
Show me: When they are demonstrating a site, ask them to set aside their mouse and not touch the screen or touchpad and demonstrate how the site can be used from the keyboard only.
Semantics and ARIA: Ask the candidate to explain their understanding of semantic element types and ARIA and their relevance to accessible design.
Accessibility throughout development: Discuss with them how they might ensure the consideration of accessibility in their projects from initial planning to final release.

Communicating the Value of Accessibility to Your Technical Team

Many technical people have been trained and have pursued their careers without encountering accessibility as a design goal. 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 through the keyboard only, using a screen reader program such as VoiceOver (available on all Apple products), and tabbing through a page to see its sequence and whether the cursor location can be determined.

Building Knowledge of Accessibility on Your Team

Substantial resources exist that can help your team develop an understanding of how to build accessibility into their products as a normal part of the development process.

Inclusivity mantra: Develop a team or project mantra and repeat at the beginning of each team meeting. For example: Our team values: Design that works for everyone People over features Ease of use over ease of development Discovery within the interface over explanations in documentation Just chant the mantra at the beginning of each meeting. It will bring up ideas and insights that otherwise might never surface.
Learn: Explore the WebAIM site (http://webaim.org/) as a team, walking through selected sections and discussing how they apply to your project. Good sections might be Introduction to Web Accessibility, Designing for Screen Reader Compatibility, or Using VoiceOver to Evaluate Web Accessibility. One approach would be for one member of the team to read an article before a meeting and then have time in the meeting to explain what they learned.
Apply: In selecting components from pre-built code libraries, frameworks, and packages, including content management systems, apply your accessible design knowledge to evaluate each component you are considering using.

Accessibility Testing at Each Stage in the Project

Building accessibility into a product from the beginning is much less work than trying to add it after the product has been built. Develop a project management process that defines 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.

Talking Points for Your Management

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:

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 (magnified in these times of social media).
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.