This Accessibility Advocate Checklist is a compass. A non-thorough and non-technical Accessibility checklist for the person taking the role of Accessibility Advocate in a development team. All steps in this checklist lead to knowledge discovery for the Advocate as well as for team members.
Identify
Critical user journeys.
Testing cases and QA scenarios for Accessibility
Verify
All User Interface components have Keyboard Accessible Patterns.
User journeys are doable using only the keyboard.
Keyboard traps do not interrupt or prevent user journeys from being successful.
User journeys vocalize properly using a Screen Reader with keyboard navigation.
If the project is for government employees in a regulated environment.
Reading Time: 3minutesTeam of 5 people seated at a conference table examining a User Interface on a monitor.
A Web Accessibility Advocate, in the context of Software Development, is the team member in charge of raising awareness and increasing the Web Accessibility literacy of the team. Also ensuring that knowledge stays in the team.
Among the responsibilities of a Web Accessibility Advocate are the following:
Raise awareness of potential consequences of non-compliance,
Point team members to an Accessibility Resource Center based on their roles.
Run the Accessibility Advocate Checklist for all team’s projects.
Provide accessibility questions for interviewing job candidates.
There are similar “advocacy” roles in software development teams. Such as the “UX Advocate” role, following along the lines of the User Advocacy principle. These advocacy roles become handy especially when the Designers’ ratio in development teams is very low. Also, when designers are temporary contractors. Once delivering wires and visuals, they leave. Hence, the need for a developer, who also has “that” UX awareness, to take on that role.
All that said, the same principle applies to Web Accessibility. Consequently, any team member can take on the role of Accessibility Advocate. However, coding practices covered in the topic are better communicated from one developer to another. It’s best if a developer takes on that role. Still, it could be anybody.
When taking on the Web Accessibility Advocate role, the huge body of knowledge should not be intimidating. There is no need to understand it deeply when starting, not even the empathy part. There are tools and tricks to learn how to empathize. However, the reasons for taking the role should be clear and convincing. Not just because it’s fancy-sounding or a trend.
Why it’s important
First of all, is important to understand why Web Accessibility is important in software? besides the fact that it’s the right thing to do. The web has the potential to bring an unprecedented level of independence to people with disabilities. For them Web Accessibility is freedom. As IT professionals, one has the great opportunity to enable this independence for people with disabilities and improve their lives.
People with disabilities can’t easily leave their houses They may encounter barriers outside their homes. But they can perform tasks from their computers like working, shopping, banking. Even have access to entertainment or playing games online. But that’s only if the websites or the software are built with accessibility in mind.
There’s a different approach to Accessibility, that also renders results. By not worrying about being “nice” for a moment, and just focusing on being “smart”. Then embracing Web Accessibility to “show-off”, protect or build a brand. Most likely competitors are also doing their part in complying with Web Accessibility.
Plus, a clear benefit of building inclusive software is that it often results in a larger user base. Yes, more clients, due to the positive impact on more people’s lives.
Now, if the previous “nice” or “smart” reasons aren’t good enough to convince. Then, the “litigation avoidance” reason should prevail. Lawsuits for non-compliance are very common these days. Litigation is the most expensive way to implement accessibility.
All the previous goes to show, that being a Web Accessibility Advocate is a way of being proactive. By anticipating and preventing lawsuits for software companies and their clients.
How to start
Every process is different, niches vary, teams have their own personalities. In my experience, I have found that answering the following questions helps in shaping up the Advocate role. Also, they help to outline an Accessibility Roadmap.
Who is the person that will take the role of Accessibility Advocate?
Is our product static and likely to have flawless and durable 100% Accessible status?
If our product evolves, when are regressions likely to happen?
How do we “painlessly” dive into Accessibility Requirements to anticipate and reduce legal problems?
How do we recognize the pitfalls to avoid?
Accessibility is a practice, not a one-time project. So how do we know where to start and where to end the cycle?
How do we know when we have arrived, or how much is left?
Do we start from scratch or retrofit?
Where will we build our Accessibility Resource Center? (Virtual space where we can pour in statistics, tips and tricks, references and painless approaches concerning Accessibility for our product).
