Spanning the Product Development Spectrum: A Conversation with Oracle’s Peter Wallack

Peter Wallack, Oracle Corporation

Peter Wallack photoPeter Wallack is the director of the accessibility program at Oracle Corporation. His team defines the accessibility guidelines for all Oracle products to follow, and he works with UX Designers, Developers, Documentation Writers, Sales, Consultants, Education and Support groups to incorporate those standards into their processes. Peter has been with Oracle since 1989, picking up accessibility responsibilities in the Applications Division starting in 2000 when Section 508 was being written, and taking over the role for the entire corporation in 2007. He is a member of the US Technical Advisory Group to the JTC-1 Special Working Group on Accessibility, and has contributed to numerous working groups including TEITAC and WCAG. Peter also authored ‘Designing Accessible Forms’ for the book Web Form Design: Filling in the Blanks by Luke Wroblewski.

Headquartered in Redwood City, California, Oracle is a multinational information technology (IT) corporation that develops computer hardware and enterprise software products widely used in workplaces by hundreds of thousands of customers around the world. The company approaches accessibility from an external and internal perspective—both as a producer of workplace technology products (including online talent management systems), and also as an employer of more than 120,000 people.

Oracle's Peter Wallack recently spoke with PEAT about his company's expressed commitment to developing and promoting accessible technology, particularly as it relates to employment.

PEAT: Tell us about your role at Oracle. Where does accessibility fit into your organization, and how are accessibility-related resources allocated?

WALLACK: I'm the senior director of our accessibility program office. This office falls under our corporate architecture group, which in turn reports to our chief corporate architect. Basically, it's my job to determine which accessibility standards our products should follow, and to manage resources and testing tools that serve to educate Oracle's approximately 30,000 designers, developers, and quality assurance staff on how to incorporate those standards. And I would add that awareness is a major part of my job—ensuring that every Oracle employee is aware of the need for accessibility.

My group is a centralized one that determines corporate accessibility standards, has subject matter experts, develops and delivers training, and provides other related services. But it is the responsibility of each of our product lines to design, code, and test their own products for accessibility. Since accessibility impacts so many aspects of a product, we believe it does not work well if this knowledge and skill does not reside directly in the organization responsible for delivering the product to the customer.

PEAT: What is Oracle's general approach to accessibility?

WALLACK: As I just mentioned, we believe that it affects nearly every aspect of a product, from research to support. In fact, we have a graphic that we use in our accessibility trainings that depicts the entire technology product lifecycle—user interface design, development, documentation, testing, and conformance statements. And that graphic is a perfect way to illustrate that accessibility impacts every aspect of product development—all the way to the Voluntary Product Accessibility Template (VPAT), which describes how our products meet core accessibility standards.

Graphic depicting the technology life cycle (design, develop, test, accompanied by documentation, VPAT)

PEAT: Are all of Oracle's products accessible? How do you ensure the accessibility of what you develop and sell?

WALLACK: Oracle has thousands of products. With some, accessibility is a work in progress; others have been coded right from the beginning. We work hard to infuse accessibility into the products we sell, and as the graphic I shared indicates, we ultimately promote their accessibility features through VPATs, which we post online as a way to describe to our customers how well our products meet core accessibility standards. And we maintain several thousand VPATs that cover all kinds of product lines.

But we also acquire a lot of companies, and Oracle believes it is crucial to ensure the accessibility of the new products we inherit through these acquisitions. We've acquired more than 100 companies over the years, and often, the products that we gain are not accessible. So it is common for us to remediate and add accessibility, or to start with that requirement for the next version.

PEAT: What do these acquired developers think when you tell them they need to start over and build for accessibility? Do you train them on accessibility?

WALLACK: They are often shocked, because it usually means lots of work for them. But we believe accessibility is an intrinsic thing that simply needs to be there. So when we insist on the redevelopment of a product, we support the developers with a comprehensive suite of accessibility training offerings. These include online and pre-recorded training, moderated forums, monthly meetings, monthly newsletters, and more.

PEAT: Tell us more about your accessibility training.

WALLACK: We offer multiple classes to our employees, ranging from high-level "Introduction to Accessibility" to very detailed classes such as "How to Code Using WAI-ARIA." We hold these classes live at multiple locations around the world. But since it's impossible for absolutely everyone to attend live training, we also support remote connection to each class, and we record them so employees can watch at any time. Oracle has built the content of these classes ourselves. Most is lecture-style, with significant time left for Q&A, while classes on assistive technology are hands-on.

PEAT: Why and how did Oracle's accessibility program begin?

WALLACK: Our program started because of Section 508 [of the Rehabilitation Act of 1973]. Oracle is the largest provider of IT to the federal government, so we knew it would be a risk to business if we didn't address accessibility. So when we heard Section 508 was coming in 1999, we formed our accessibility office so that we would be ready. And when Section 508 actually went into effect in 2001, all Oracle products at the time met the standards already.

Obviously, our program has had to evolve as accessibility standards have changed. All the regulations have expanded, and today, many states, cities, and counties have their own requirements. There are global considerations, too, and we take that all into account, since we are multinational.

PEAT: Does Oracle's leadership support the mission of your office?

WALLACK: Yes. Internal champions are key, and at Oracle, we have support from the highest levels of the company. In fact, our President and Chief Financial Officer Safra Catz has penned a statement about accessibility that is shared widely. It states that, "Oracle is committed to creating accessible technologies and products that enhance the overall workplace environment and contribute to the productivity of our employees, our customers, and our customers' customers."

That statement appears on our corporate website, and it's reflected in our internal corporate social responsibility documents, as well. And, more importantly, it's been transferred into a mandate for making all of Oracle's products accessible.

PEAT: Why is Oracle so committed to accessibility? Have you developed a so-called "business case" for building accessible products?

WALLACK: We never went through a formal business case exercise, mainly because the benefits of building accessibly are so self-evident. The statement from President and CFO Safra Catz that I shared earlier was the real marching order. But our commitment boils down to four key reasons.

The first is regulatory in nature. Obviously, it would impact Oracle's business if we couldn't sell to the government. So we have a fiscal incentive to promote accessibility.

Similarly, the second reason is that it's good for business. We make money by selling user licenses, and we know that many users either have disabilities, or that they will acquire them someday. So why wouldn't we want as many people as possible to be able to access our products?

The third reason relates to our own employees. We want to attract and employ the best talent, and they should be able to use our internal products. It just makes sense.

The fourth reason is the ethical one. Selling accessible products is simply the right thing to do. We're a Fortune 100 company, and we know that we need to be setting an example of inclusion.

PEAT: What are some of the challenges you face relative to accessibility? Do you ever get pushback from developers or product managers?

WALLACK: Yes, of course we get pushback. Complex enterprise class products are under incredible pressure to support a myriad of things such as new functionality, responding to changes in regulation, an extreme focus on security, new platforms, customization, translation, localization, and more. And of course they have neither infinite resources nor time to deliver all of this. This is where our executive management support becomes so vital.

Another challenge in what I call "the accessibility puzzle" relates to user proficiency with assistive technology (AT). Even though we at Oracle believe many of our products are coded correctly to meet accessibility standards, we still see failures because certain users are not actually familiar enough with their AT devices to optimize all of our accessibility features. Some people who use screen readers, for example, only know how to use the Tab key. But that doesn't necessarily cut it anymore. Furthermore, there are many users who fail to turn on the accessibility features we have built into our products and that we promote online in our VPATs.

Unfortunately, Oracle's helpdesk is not equipped to train AT users one-on-one, and it's really not our place to train users at that level anyway. So we try to encourage customers to obtain AT training from third parties. That said, when we hear from a customer with a disability who is really stuck, we may train them on an individual basis. But that solution doesn't scale very well with hundreds of thousands of customers. So users failing to receive sufficient AT training is one of the greatest pitfalls to accessibility working well. And it's something that the industry needs to address collectively.

PEAT: Do your customers inquire about the accessibility of your products either before or after purchase?

WALLACK: Many but not all of our customers inquire about accessibility. It's typically listed in public sector request for proposals—but not always adequately, I might add. And we're seeing more accessibility requirements from private sector customers, as well. For instance, many Fortune 500 companies are tuned into it from a discrimination standpoint. They’re increasingly recognizing it’s part of an inclusive workplace.

PEAT: Tell us about Oracle's accessibility testing practices.

WALLACK: Oracle employs six types of testing: 1) automated; 2) tool assisted (where a human helps judge what an automated tool uncovers); 3) visual inspection; 4) manual inspection; 5) inspection by sighted individuals using AT; and 6) inspection by users with disabilities (typically users who are blind) using AT.

PEAT: What advice would you give to technology providers interested in developing an accessibility initiative?

WALLACK: First, there has to be executive management buy-in. In our experience, no one does anything unless their manager tells them to do it. Any successful accessibility program simply has to have support from the top.

My second piece of advice is "training, training, training." We provide two or three days of training to our developers at minimum. We know they'll never find the time to read up on accessibility practices on their own, so dedicated training is a must. And it constantly has to be revised as accessibility standards change.

Third, you must staff people who are very focused on attention to detail. Most of what we do from an accessibility standpoint is hidden deep in the code. So it's easy to overlook it and fall into a trap where it's "out of sight, out of mind" after you tackle it the first time around. To avoid such a pattern, we continually task someone with a detailed eye to stay on top of accessibility for each product.

Earlier we discussed testing, and that's my next piece of advice. Those who set out to only use an automated tool in their accessibility testing will not have an accessible product in the end. At Oracle, we conduct six types of testing. This is key.

Finally, I recommend that technology companies invest in a core set of experts who are dedicated to accessibility. I don't have expectations that all of our approximately 30,000 developers will become experts on accessibility. It's just not realistic. Instead, I have a core set of experts who are there to train others and become a resource company-wide.