Skip to content Skip to navigation

Roles and Responsibilities

Introduction

When considering accessibility, it is critical to integrate it throughout the design, content creation, development, and quality control phases of each project's lifecycle, as well as to consider accessibility when maintaining and updating web sites and web applications. Since each school/department operates fairly independently, the Stanford Online Accessibility Program cannot be prescriptive here. But you will find pointers to help each of you who visits this page begin to think about what contributions you can make and how those of you who are managers can guide members of your team to take responsibility for accessibility as everyone continues to complete their typical assignments.

Even after training, it often happens that implementing accessibility in a project, from the beginning, may take some extra time, but that amount of time will gradually diminish as thinking about accessibility becomes second nature.

When accessibility is framed as a shared responsibility so that each team member is accountable for thinking about and checking for issues that dovetail with current activities, over time, the need to invest resources to remediate sites decreases. And this is clearly the goal -- to shift accessibility from a quality check after a project is launched to a concept that is considered in every decision made by a team. As AccessIQ suggests, Web Accessibility is a Mindset Not a Checklist.

Accessibility Responsibilities in the Stanford Community

So, how do members of the Stanford community take steps to make accessibility a regular part of the decision-making process? By visiting this site, you've taken the first step on your accessibility journey. Thank you!

The SOAP site offers some guidance based on general notions of roles on campus. Check out the links below to choose the role that most aligns with yours, and see what pages have been tagged with you in mind. The current roles are:

Roles, Responsibilities, and WCAG 2.0

While the SOAP site is a fine place to start, what is more helpful is to map roles and responsibilities specifically to WCAG 2.0 and the How to Meet WCAG 2.0 (Quick Reference). Aligning guidelines and success criteria with roles and responsibilities allows each team member to focus on and develop expertise in the areas that directly relate to the work at hand for each person. Two sites, discussed below, have created models but each group at Stanford will want to adapt a model to its workflow. When reviewing these two sites, note that, at this time, Stanford's focus is on WCAG 2.0 AA.

One effort to map WCAG to different groups is the Accessibility Responsibility Breakdown on the WAI Engage Community Group Wiki. The list of possible groups is quite extensive.

In addition, there is Interactive WCAG 2.0 posted to Git by Viget. This blog post explains how you can filter and share results and/or fork the project on Git.

As you use these tools to tailor your accessibility journey, and that of your team, you are encouraged to maximize everyone's strengths. Keep in mind that implementing accessibility best practices, just like improving anything on the web, is never a "done deal." But that is a good thing, isn't it? Aren't we all in the business of innovating and improving access to information for all?

Target Audience: 
Administrator
Content Creator
Designer
Developer
Last modified: 
May 18, 2015