This chapter looks at the role of your team or company in a web accessibility initiative and discusses how to get them engaged and trained on their new responsibilities.
Involving the Team
Like many things, the best time to start considering accessibility is from the beginning. It is always better to integrate accessibility into the workflow from the beginning rather than retrofitting at the end. This will produce a better end result with less impact to your product timeline. By incorporating accessibility while designing the application, usability is greatly improved and as a bonus will provide the practice your team needs to become really familiar with accessibility concerns.
Whether you are starting a brand new project or making an existing project accessible, getting the entire team and stakeholders involved and on board is important to the success of any accessibility initiative.
Motivation
When you incent, people optimize for reward. When you inspire, people optimize for purpose.
—Michael Norton1
Depending on their role on the team or in the organization, each individual may be motivated by different factors to accept accessibility as part of the requirement and process for a project. These can be ethical, legal, economic, or personal.
Ethical: Accessibility is the right thing to do because it helps provide all users equal access to information and services. Individuals choosing to support an accessibility initiative because it is the right thing to do will generally yield the best results.
Legal: Several countries have laws regarding accessibility standards. Depending on the project and situation, it may be legally required for the project to meet certain accessibility standards and failing to meet that requirement may result in legal action being taken against the company. Examples include Australia’s “Disability Discrimination Act 1992,” the United Kingdom’s “Equality Act 2010,” and the United State’s “Section 508 of the US Rehabilitation Act of 1973.”2
Economic: Lost market share and revenue due to users’ lack of ability to use the application and competitive advantages gained for being accessible. In the United States there are 49 million Americans with disability who control an estimated $175 billion in discretionary income. For many businesses, skipping accessibility is potentially excluding 20% of their total market.3
Personal: Whether they are personally affected by accessibility in some way, or perhaps have friends or family members that experience handicap, they have a personal motive driving them to support accessibility initiatives. They tend to understand the importance and the impact it can have on others. In the United States it is estimated that 30% of all families have at least one disabled member.
Short of personal motivation, many people are simply not informed enough to be swayed by ethical, legal, or economic reasons. One of your most important tasks in getting a team committed to accessibility is to educate them about these factors and find the one that will motivate them to get more involved.
It is important to use positive motivators such as encouragement and rewards rather than negative motivators such as guilt or punishment.
Team Roles
It is easy to say that adding accessibility to your products is the responsibility of the developers, but developers cannot do it alone. Outside factors such as designs being provided having inaccessible colors, time allotted to complete tasks being too short to deliver accessible features, and accessibility not being tested for, may even render the task impossible. Getting everyone involved and on the same page removes these barriers. Even though accessibility is the responsibility of the entire team, each role brings a different set of concerns.4,5,6
Business Leadership
Leadership is responsible for supporting accessibility efforts and making sure that accessibility is a business goal. This includes budgeting for training and software to allow the teams to meet their accessibility objective.
Managers, product owners, and project managers are responsible for determining the accessibility level projects must meet--and therefore standards to follow--and for making sure that time is allotted to accessibility development, testing, and resolving of any issues found.
Business stakeholders are in a great position to advocate for accessibility as they often are the decision makers in timelines, requirements, and budgets but also have the opportunity to lead by example.
Marketing/Branding/Design
As they are responsible for dictating brand colors, typefaces, and language used, it is imperative that those standards be accessible. Often the brand team will produce a style guide to allow for consistency across company communications and artifacts. These standards should be reviewed for accessibility so that “staying on brand” does not negatively affect accessibility.
Web Designers
Designers generally concern themselves with user experience, look and feel, layout, interactions, content organization, and much more.
Understanding the accessibility standards that the application will adhere to is important in this role so that the web site can be designed to support them from the very beginning. Things to keep in mind as a designer are color contrasts, using more than just color to convey meaning, font sizes, alternate navigation options, and content organization. Collaborating with users, developers, and quality assurance (QA) when creating designs will help ensure that implementation ends up accessible.
Making sure the persona is not just a disability: Focus on abilities rather than the disability itself
Nature of the limitations (blind, is in a noisy environment, easily distracted, etc.)
Tools and strategies used (screen reader, keyboard user, trackball, etc.)
Content Creators
Content creators are often responsible for adding text, links, and images to sites. To maintain accessibility it’s important that they ensure that the content and templates follow accessibility guidelines by minding heading structures, alternate text for images, reading level, and that link and button text is present and descriptive.
Content itself is often overlooked in accessibility testing. Including regular content review for accessibility will help ensure that the content itself stays accessible. Worth noting is that not all content management systems are capable of generating an accessible output, and therefore this needs to be considered during procurement.
Developers
They are the ones building the web sites and applications. They should be familiar with accessibility standards, ARIA, and semantic markup. Adding automated accessibility testing as part of unit and integration testing will help maintain component quality. They may need access to training in order to get familiarized with coding for accessibility.
Access to the technologies they need to support is important to test while developing and to understand how they work.
Testing/QA
Testers should include a combination of automated, manual, and usability testing. Automated testing can cover some basics including the presence of alternate text on images, but cannot assess whether the text was meaningful or descriptive. Manual testing fills that gap and should include a variety of devices and techniques such as screen readers, keyboard-only, screen magnifiers, etc. Usability testing allows actual users to determine if the application fulfills their needs. It is invaluable in catching issues that might be missed because of the intimate knowledge held by the business and development team about the application and its inner workings. More details about accessibility testing will be provided in the next chapter.
Legal/Compliance/HR
They are responsible for making sure everyone in the organization knows any policies the company may have toward accessibility as well as if there are any legal requirements attached to them and the consequences for nonconformance.
They may also be responsible for producing accessibility statements and conformance documentation. An accessibility statement provides information about the accessibility of the content and shows commitment to producing accessible content. These include a commitment to provide accessibility, inclusion of people with disabilities, specific standards and levels that are being followed, and contact information to report issues. They can also have extra information including supported technologies, measures taken to ensure accessibility, or known limitations.
Education
Education is the most powerful weapon which you can use to change the world.
—Nelson Mandela7
Statistics and descriptions such as those provided in Chapter 1 can provide an overview of what some of the disabilities are and how the user is affected, but education must go beyond numbers.
Education about disabilities, what they are, and their impact on the users allows the team to understand the obstacles they are trying to remove. This can involve learning more about specific disabilities and handicaps, and using assistive technology.
However, there are many other important topics related to web accessibility. Developers must understand the technical details of implementing WCAG and ARIA. Designers and testers need to be able to use assistive devices to ensure a good web experience.
Simulators
To get a glimpse into the experience that a disabled user might have while using an application, simulations can be used. Simulators can be used to imitate what it is like to have a certain handicap by altering the view in order to mimic the disadvantage. There are simulators available which can be used to understand what it is like to use a website or web application with cognitive disability, low-vision conditions, dyslexia, or motor impairment.
Cognition
Distractibility simulation8
Motor Control
Motor Handicap Simulations include making the cursor tremble in order to replicate the tremors caused by Parkinson or removing the user’s ability to use a mouse or trackpad in order to force the use of an alternate form of navigation. Asking team members to go without a mouse or trackpad for an afternoon can be a very revealing experience, exposing some of the struggles shared by users who cannot use a mouse.
Visual
Visual Handicap Simulations can cover a wide variety of conditions including the following.
Funkify Disability Simulator9 with persona “Tunnel Toby” enabled
Funkify Disability Simulator10 with persona “Peripheral Pierre” enabled
Funkify Disability Simulator11 with persona “Sunshine Sue” enabled
Funkify Disability Simulator12 with persona “Blurry Bianca” enabled
Normal vision
Grayscale (achromatopsia)
Blue/yellow (tritanopia)
Red/green (protanopia)
Also valuable when simulating loss of vision is experiencing what it is like to use a screen reader. Screen readers are interfaces that communicate content rendered on the screen via speech synthesizer or braille display. Interacting with a screen reader not only exposes a vastly different interaction than what abled users are used to but also provides insights into a tool developers will need to support.
Testing and Feedback
Simulations can be useful when trying to judge how accessible a button is (can it be clicked easily, is the target area large enough to do this, is its purpose of being a clickable button obvious), or whether color contrast needs to be adjusted. However, simulations are not a holistic view into what it is like to be a disabled user. They fail to account for coping mechanisms acquired and frustrations experienced by users who live with disability every day and should be used as an aid and not as a substitute for interacting with disabled individuals.13
The best way to understand how users are impaired by a web site’s inner workings is by regularly interacting with your users and soliciting their feedback. Be sure to include users with a wide range of abilities when performing user testing and building focus groups. Include assistive technology alongside mobile devices and web browsers when performing usability and compatibility testing. Keep in mind that many users of your web sites or web applications who experience either permanent or situational handicap likely do not think of themselves as disabled. They are simply aware that your application is hard for them to use.
One of the most important things to remember is to practice empathy. It is your responsibility to provide the best web experience you can across all ability levels, but nobody is obligated to explain what it is like to live with a disability.
Summary
Each team member may have a different motivational factor.
It is important to use positive, inspirational motivators.
Your team should get hands-on with simulators and assistive technology.
Everyone has a role to play in successful web accessibility.
In the next chapter we will cover how to get started testing your application, highlighting areas requiring special attention.