Adapting Technology and Building an Accessibility Community at the University of California

It's a given. We all support accessibility for people with disabilities, right? After all, we're higher ed. We care. Why, then, is web accessibility still such a challenge for colleges and universities? Well, for starters, accessibility

• seems daunting to launch, and it's resource intensive;
• requires behavior change, yet there's no easy checklist; and
• feels like us against the world because governmental agencies insist that we implement accessibility (but don't issue regulations), while suppliers act as though they've never heard of accessibility at all.

At the University of California (UC), we have been working at accessibility a long time, and we can even point to some accomplishments:

• We have a policy!
• We include accessibility compliance in our contracts!

But, like other institutions, we don't have unlimited resources to pour into accessibility given so many other pressing demands. We still have a ways to go and, actually, we'll never be done—accessibility is an evolving target as content, standards, and technology continually change.

We have to keep making progress anyway. I believe we're doing this at UC because we started with a grassroots movement—even though we didn't consciously set out to do so. And, while we sometimes have to seek funding or find power in executive commitment, we discovered that the key is not to wait for those things; if you do, you will never get started.

Here's our story.

Establishing the Community

When I started in the IT department at the UC Office of the President well over fifteen years ago, some UC campus staff members reached out to ask if the president's office could "do something" about accessibility. I think they meant: issue some kind of order (although mandates from the top don't go over very well in our decentralized UC environment).

My job was to listen. A group of us had a few phone calls and then held a meeting at UC Berkeley. People came from almost every UC campus, mostly from IT departments but also from Americans with Disabilities Act (ADA) offices. That meeting marked the beginning of a community that thrives today.

We knew we didn't have the clout to create mandates. Instead, we just started doing things that were within our power, including

• creating an email list within UC,
• holding monthly calls,
• creating a website for UC web developers, and
• curating resources and developing guidelines.

Today, the core of our community has been formally recognized as the UC Electronic Accessibility Committee, which is about twenty-five members strong. Our committee is charged with leading initiatives to advance accessibility across UC. We also have a larger community that participates on the email list, other initiatives, and campus-based groups. We began as colleagues and collaborators, and so we continue.

Hiring the Evangelists

By sheer luck, we had a critical ingredient for success at the outset. Our original community included two blind employees; one continues to work at UC Berkeley and is active in the national accessibility community. Other colleagues with disabilities have since joined; they serve as internal consultants, readily available to explain accessibility from the perspective of those who live with inaccessibility on a daily basis.

Throughout, these members of our community have been—and continue to be—pragmatists, valuing incremental progress rather than expecting perfection. They are our colleagues and friends, and we want to minimize their frustration in accessing the often-inaccessible online world. They keep us grounded in why we're doing this.

I believe every institution should create a role for an accessibility evangelist and actively reach out to people with disabilities when recruiting. The role doesn't have to be full-time; it can be a component of another position, such as one in the disabled students' office or on the web development team.

Qualified people with disabilities may find the job very appealing because, in addition to professional skills, they have life experience that enhances their effectiveness as evangelist experts. Supporting such a function isn't resource intensive, especially if it's part of another job. Heck, sister institutions can even share; our evangelists, for example, offer insights to colleagues on all UC campuses.

The point is we need to hire the world we want to create.

Training the Foot Soldiers

As we began building a community across the UC system, I realized my own IT department needed to prioritize web accessibility. Because I'm in communications and policy and don't supervise a technical team, I had to persuade others to help me in the cause. I asked the web applications manager to send an employee to training—if I could find funding.

The chief information officer (CIO), my boss, agreed to pay for two people. So, the web applications manager and an employee set off for Knowbility training in Austin, Texas. They returned wide-eyed and converted. We joke about "getting religion" when it comes to accessibility, but it's a real thing. After training, developers find new meaning in their work, with every bit of code now a step for social justice.

Accessibility is also a fantastic avenue for professional development, especially since it's so closely tied to user experience skills. One of my colleagues who went to Knowbility has become an accessibility expert for the UC system. Now a web development manager, she requires her entire team to learn and practice accessibility.

Most IT organizations support professional development. If you want to jumpstart accessibility, the most important thing to do is to get people trained. Start by earmarking some professional development funds for accessibility, or at least requiring staff to take advantage of free training and resources on the web. You can't fix your sites if your people don't know what to do. You also need people who really understand the technology of accessibility to help you with policy, standards, third-party products, and so on.

Even if it's one by one, get your foot soldiers trained.

It is also important to begin formally incorporating accessibility work into all web and applications job descriptions. This is crucial because when budget cuts hit, positions focused solely on accessibility are vulnerable. If accessibility is a standard component of relevant IT job descriptions, however, accessibility itself cannot be cut.

Developing Champions

Having executive champions for any project is obviously valuable. The challenge with accessibility, though, is that most executives

• don't understand it,
• don't have resources for something they don't understand, and
• don't feel pressure to implement it from their own bosses, who don't understand it either.

That's why it can be helpful to ask for only small things at first, like sending two employees to the first conference.

In our experience, CIOs become more supportive of accessibility initiatives when a trusted staff member is engaged with accessibility and talks to them about it. So, it's important to keep finding ways to talk to the boss about accessibility.

We also went through our CIO leadership forum to get approval for important initiatives, such as developing a policy. At the same time, we didn't ask these leaders to prioritize accessibility over other key initiatives. We just asked for support, and we got it—their staff's time to work on committees, their recognition of the initiative, and the permission to refer to them as our sponsors. They are powerful champions.

None of this is to say that every college or university shouldn't prioritize accessibility and devote massive resources to it. Indeed, there are at least three good reasons to do so:

• From a legal perspective, the federal government says that web accessibility is the law.
• From a business perspective, accessibility broadens and diversifies the audience for your websites (among students, employees, faculty, the public, and customers).
• From a human perspective, it's the right thing to do.

Reality looks different, though, with shrinking resources, competing demands, and the need for expensive new technologies for every aspect of the enterprise. Nevertheless, we must find small ways to make progress anyway. Doing so can add up to big changes over time.

Personnel in the risk-services group can be influential champions as well. They clearly understand the institutional risk. Over the years at UC, they have always responded favorably to our requests, funding small projects that helped build our community and expertise. Among these projects were in-person training for staff and piloting various web accessibility testing tools.

Risk services recently empowered us to leap beyond grassroots movement into a structured university-wide initiative visible to all CIOs and other executives. Further, the group is funding both online accessibility training for anyone at UC (from technologists to designers to buyers) and a website accessibility checking and reporting tool deployed at all UC locations.

Getting Formal

There came a point in our movement when we realized that we needed an accessibility policy. Although people at UC supported accessibility, they didn't feel they had the authority to "do the right thing" without force of mandate. For example, procurement said it needed policy to back a requirement for accessibility in RFPs. Likewise, technology staff wanted a codified explanation for budgeting accessibility in development projects.

We therefore started down the policy road. I had heard horror stories from other institutions, including stories about accessibility policy drafts that had languished for years. And, indeed, we had one failed attempt. A couple years later, we tried again.

This time, we asked our executive champions—the CIOs and, in particular, the university-wide CIO—to ask the heads of legal and compliance to support policy development, which they did. At UC, presidential policy requires review and input from all corners of the institution. Over the course of a year, staff in many different functions provided constructive feedback to policy drafts. In a final, critical phase, the Academic Senate offered its support. Although it was concerned about the difficulties of implementation, it wanted the university to do the right thing, especially for students.

In August 2013, a UC presidential policy on IT accessibility was established.

We kept the policy simple, allowing each UC location the flexibility to implement it in its environment. In essence, UC's brief accessibility policy does four things:

• Establishes the institution's commitment to accessibility.
• Requires each location to establish a program to implement the policy (and outlines program components).
• Prioritizes efforts to ensure the accessibility of new websites and new online environments, rather than retrofitting old ones.
• Codifies the web accessibility standards that UC organizations should follow.

The policy also enabled us to take another formal step: inserting a clause in our standard terms and conditions contract that requires suppliers to comply with the WCAG 2.0 AA standards for web accessibility.

Cultivating Coalitions

In IT, we can't make accessibility happen on our own. We need smart friends with expertise in legal, risk services, compliance, and so on who are sympathetic to our cause. In our case, we developed a critical coalition with staff members in procurement.

It began when a couple of us were asked to serve on an RFP committee to assess accessibility for a major enterprise software purchase. We didn't know what we were doing. As a result, the process was super complicated and didn't include the useful questions and testing needed to help us truly assess accessibility. That one bruising experience made us realize that we had to keep accessibility top of mind throughout the entire purchase process, not just in the formal RFP.

We started developing guidelines based on our experience. This effort gained traction when a procurement colleague helped rewrite the guidelines from procurement's perspective and helped socialize them among the procurement community.

The accessible procurement guidelines focus on five key phases:

1. RFP checklist. We include a checklist that presents the WCAG 2.0 AA guidelines in plain English, both to help our UC reviewers understand them and to explain accessibility to suppliers.
2. Supplier demo. We ask finalists to demonstrate accessibility in their presentations.
3. Testing. We schedule sufficient time to fully test finalists' products and services for accessibility.
4. Contract. We use standardized contract language about accessibility.
5. Supplier education. After the contract is signed, we work with the supplier, if necessary, to create a plan for ongoing testing and improvement.

Each of these phases is a step in building a relationship with the supplier that we will eventually select. As everyone in the field knows, suppliers rarely provide a 100-percent accessible product, yet requirements and contracts can seem like absolutes, pitting the goal of accessibility against the needs of the business. Accessibility can't be seen as a barrier to business. Instead, we must get the business what it needs and make progress with accessibility.

Our goal in the procurement process is therefore two-fold: for suppliers to understand that we're serious about accessibility, and for us to be aware of any deficiencies and choose a supplier that will partner with us to address them. This is still an experiment, but we're finding value in developing relationships with suppliers to work on accessibility together.

Learning Always

Like cybersecurity, accessibility requires key players to continually adapt as they figure out what is most needed at that moment. And the target always changes. Accessibility depends on the device or software version being used, and the user's particular abilities.

So, we must always revise and always seek the best approach for a given situation. After all, standards evolve, laws get rewritten, our understanding of accessibility grows, technology jumps ahead, and the players change. We need to keep our sights on continual progress.

One truth, however, is constant: Accessibility is about people. It is foremost about people with disabilities who want to use technology. But it is also about all the people who take up that charge: from IT staff who code accessible sites; to procurement staff who continually adapt their approach; to suppliers who partner with us; to executives who support noble causes; to colleagues in legal, risk, and compliance who back change; and down to every person across the institution who learns to make an accessible PDF.

I now understand that what we're doing at UC is focusing on people, not technology. We're building the army of believers who understand that it's a terrible thing when a person with disabilities has to use clunky workarounds or simply can't do something because the technology isn't accessible.

This, then, is our charge: Instead of making people adapt to technology, we believe technology must adapt to—and work for—people.

---

Yvonne Tevis is Chief of Staff in Information Technology Services at the University of California Office of the President.