When it comes to the accessibility of web pages, web applications and web tools, most people turn to the Web Content Accessibility Guidelines (WCAG), the internationally recognized standards developed and maintained by the World Wide Web Consortium’s (W3C) Web Accessibility Initiative (WAI). In order to help technology providers and employers understand the basics of WCAG and other related accessibility standards, PEAT spoke with the W3C's Shawn Henry, who leads their worldwide education and outreach promoting web accessibility.
Henry also leads the TAdER Project, which provides research and outreach to better understand users' needs to customize text for readability — specifically, people with low vision, dyslexia, and related conditions that impact reading, including older people. Her book Just Ask: Integrating Accessibility Throughout Design offers an approach for developing products that are more usable for everyone.
PEAT: Can you please give our readers some general background on W3C's accessibility guidelines?
HENRY: Basically, the guidelines and supporting resources provide guidance on web accessibility for developers, designers, content authors, project managers, procurement officers, and others—really anyone interested in making web products accessible.
The guidelines are developed through the W3C Process that is designed to encourage consensus and broad community input through public review. Like other W3C web standards, they are called "W3C Recommendations". The first accessibility standard from W3C was Web Content Accessibility Guidelines (WCAG) 1.0 back in 1999.
WCAG 2.0 is the current web content standard. WCAG applies to all web content, including plain web pages, dynamic web pages, multimedia, and mobile web applications. WCAG 2.0 is also an ISO (International Organization for Standardization) standard, ISO/IEC 40500:2012.
There are two other WAI guidelines that are important to workplace accessibility: Authoring Tool Accessibility Guidelines (ATAG) 2.0, which is a recently-completed standard, and User Agent Accessibility Guidelines (UAAG). ATAG applies to tools used to produce web content, such as content management systems (CMSs). ATAG covers two aspects of accessibility—the tools help authors create more accessible web content, and the tools themselves are accessible so that people with disabilities can use the tools. UAAG applies to web browsers, media players, and other tools called "user agents" that people use to interact with the web.
While the guidelines are primarily designed for those involved in developing web products, some technology users might want to understand the basics of web accessibility guidelines so they know what they can expect of websites and web tools.
PEAT: WCAG's relevance to public-facing websites is quite clear, but where does WCAG apply in the workplace?
HENRY: In many places. WCAG applies to all web content, and that includes intranets and web applications. Web-based applications are increasingly being used in today's workplace—for example, for employee vacation reporting, supply chain management, customer order tracking, and more. For those that are developed in-house, an employer's project team can follow WCAG to help ensure accessibility. For applications that are purchased from external vendors, employers can make WCAG conformance a requirement through procurement. WCAG can also be used to inform the accessibility of non-web documents and software.
As I mentioned earlier, ATAG and UAAG are particularly relevant in the workplace, as well, since they help ensure that the web tools that employers develop and procure are accessible to employees with disabilities.
PEAT: In your view, why should employers follow the voluntary accessibility guidelines?
HENRY: There are two aspects: why make your technology accessible and why follow these guidelines. There are legal accessibility requirements that apply to some employers, which I won't get into. [See PEAT's article Accessible Technology and the Law.] There are also business advantages. For positions where web use is an essential job function, providing accessible tools helps you retain employees—including people with age-related impairments—and enables you to hire from a wider pool of potential employees. Even for positions that use web applications less, many employees these days use web applications in some part of their position, such as for managing their employee benefits.
Following the guidelines helps employers realize the benefits of accessibility. Accessibility addresses the needs of people with a wide range of abilities who use many different assistive technologies and adaptive strategies to interact with web technology. The guidelines take all of these into consideration, so following them helps you cover the wide range of accessibility issues. Also, conformance to the guidelines makes a strong statement that you care about web accessibility.
PEAT: Why should technology providers follow W3C's accessibility guidelines? What's the business case?
HENRY: For most technology providers, the primary factors are potential increased revenue and decreased risk of legal action for having inaccessible web content and tools. Some governments, university systems, businesses, and other organizations have policies requiring that purchased technology is accessible—so meeting the accessibility standards can be a competitive advantage.
For many vendors who sell products internationally, W3C's accessibility standards are also applicable. They have been adopted by many countries and organizations around the world, such as the European Commission (Mandate 376 produced the standard EN 301 549).
If you want learn more about the business case, I suggest reading WAI's resource Developing a Web Accessibility Business Case for Your Organization. It presents the benefits and costs of web accessibility, and helps you figure out which aspects most relate to your organization.
PEAT: You've talked about motivations for web accessibility from an organization perspective. What about from developers' and designers' perspectives?
HENRY: There are several reasons why accessibility is getting more attention from people who are creating websites and online tools. For example, accessibility is increasingly recognized as a key aspect of high quality websites, so developers and designers with high standards are addressing accessibility more.
Many developers and designers are focusing on designing for mobile device users and are being tasked with meeting the needs of older users. There is huge overlap between mobile design and accessibility, and between design for older users and accessibility—and designers and developers can use W3C's accessibility guidelines to help address those design issues.
So those are some tangible reasons to follow the guidelines. Yet for some developers and designers, the primary motivation for accessibility is to do the right thing. Technology accessibility can have a huge impact on the quality of life of people with disabilities, and on society. And some designers and developers realize that their work can make a huge difference. They care about enabling people and not excluding people with disabilities—and they embrace their role in making the world a better place. This motivation is often strongest at the individual level, yet it can also exist at the organization level since some organizations place a high value on corporate social responsibility.
PEAT: That's always nice to hear. Now for some practical questions. Many companies need help understanding the differences between Section 508 and WCAG conformance. Can you help clarify?
HENRY: The web provisions in the Section 508 standard were largely based on WCAG 1.0. WCAG 2.0 has many benefits over WCAG 1.0—it applies to more advanced web technologies, it's adaptable and flexible for different situations and for new technologies and techniques, and it comes with extensive supporting materials and practical implementation guidance. The proposed updated 508 standards directly reference WCAG 2.0. While the US Access Board is still working on the Section 508 standard refresh, the Access Board has been recommending using WCAG 2.0 for some time.
PEAT: What advice do you have for companies seeking vendors who know and understand WCAG?
HENRY: Good question. One thing I suggest is to make it very clear in your RFP that WCAG conformance is a requirement for your project or product. This might weed out some vendors who are not prepared to meet that requirement.
When you're considering vendors, you can ask to see the WCAG conformance statements for their corporate website, relevant products, and other websites they've developed. (If they don't have any, that's a warning sign.)
You can also check the vendor's website yourself to see how well they've addressed web accessibility. Even if you don't have to have any knowledge of accessibility, you can follow the steps in WAI's Easy Checks - A First Review of Web Accessibility. Although it covers just some WCAG criteria and doesn't provide definitive results, it can give you an idea if they considered accessibility in developing the website. Certainly if you identify any potential accessibility problems after using Easy Checks, the vendor's ability to address those issues would give you some idea of their understanding of web accessibility and WCAG.
PEAT: WCAG outlines different levels of conformance. What level should website owners strive to attain?
HENRY: WAI recommends that you aim to meet all Level A and AA success criteria, and also consider the Level AAAs.
For those unfamiliar with WCAG, it is organized by principles and guidelines, and the specific WCAG requirements are called "success criteria." Each success criteria is Level A, AA, or AAA. The levels are based on impact on people with disabilities, feasibility, and other factors.
Most policies that reference WCAG require websites to conform at Level AA, which means meeting all Level A and Level AA success criteria. While Level AAA should not be required, we encourage web developers to consider Level AAA success criteria. Some of the Level AAA success criteria are very easy to do, for example, using text and background colors with enhanced contrast, limiting flashing, and providing section headings to organize the content. Also, depending on the target audience of the website, some Level AAAs might be more important.
PEAT: How hard is it to learn WCAG 2.0?
HENRY: It's much easier to learn WCAG once you understand the fundamentals of web accessibility. So for people new to accessibility, I suggest starting by understanding the basics of how people with disabilities use the web, and the general principles of web accessibility. At least skim the first four pages of How People with Disabilities Use the Web, and read through the last page: Accessibility Principles.
I think it's helpful to keep in mind that some aspects of accessibility are quite easy, and some are fairly difficult. I suggest that you learn the easy things first, and don't get too bogged down in the harder things early on. WAI's Tips for Getting Started with Web Accessibility provide practical starting points for web developers, designers, writers, and others.
Also, be aware that WCAG itself is a technical standard, which impacts its readability. There are several supporting documents that provide practical guidance on understanding and implementing WCAG. Before you read WCAG itself, I suggest starting with the WCAG Overview to understand the type of information provided in the different WCAG documents.
Next I'd print out WCAG 2.0 at a Glance—maybe a couple of copies to post next to your computer, read on the train, etc. Then, play with How to Meet WCAG 2.0: A Customizable Quick Reference to see how you can customize it and how the links work. We're in the process of redesigning the user interface and adding more filtering functionality, so you probably want to use the redesign prototype. This will probably be your main resource for learning and using WCAG because it includes all of the guidelines and success criteria from the WCAG standard, the techniques, the failures to avoid, and links to more detailed guidance.
Another useful resource is the Before After Demo (BAD) that provides a sample website with accessibility barriers, another version with the accessibility barriers fixed to meet WCAG, and annotations.
In addition to introductory material, WAI has more advanced and detailed resources, such as Techniques for WCAG 2.0, Understanding WCAG 2.0 , and Web Accessibility Tutorials.
PEAT: Many technology developers want to know whether WCAG knowledge will help their career. Your thoughts?
HENRY: I think so, definitely. Whenever I check popular job websites for keywords WCAG and 508, there are always many jobs listed. I've seen accessibility included in the required experience for positions like developer, designer, and project manager. There are also job openings for accessibility specialists, such as those listed at https://twitter.com/a11yjobs.
Experience designing and developing for accessibility and meeting WCAG can make you more valuable to your current employer and help qualify you for other positions.