Interview with Judy Brewer on WCAG 2.0
Following a conversation with Judy Brewer from the W3C back in February, Jared Smith had the chance to interview her and submit some probing questions about what’s happening with WCAG 2.0.
Update: Judy clarified that, although she did check with the co-chairs of the WCAG Working Group and some other W3C staff, the answers are primarily her take on things…so I’ve amended the entry accordingly.
- What is the future of WCAG 2.0?
-
I think that WCAG 2.0 will be a substantial step forward for Web accessibility. Developers will be able to create accessible Web content without having as many constraints on the technologies that they use. They’re going to find a much better range of implementation support materials than were available for WCAG 1.0, so it will be easier to work from. People who evaluate and monitor Web accessibility are going to have clear criteria against which to test accessibility. And people with disabilities are going to benefit because WCAG 2.0 provides guidance on how to make a much broader range of Web technologies accessible to them.
- Can you explain the W3C process as it relates to WCAG 2.0?
-
As with all potential W3C Web standards, WCAG 2.0 is going through a series of stages to ensure broad review. These stages include Public Working Drafts, then Last Call Working Draft, Candidate Recommendation, Proposed Recommendation, and finally the completed W3C Recommendation, which is essentially a Web standard.
WCAG 2.0 went through several Public Working Drafts in recent years, and a Last Call Working Draft in 2006. Each Working Draft was sent out for public review — altogether to hundreds of individuals, organizations, and lists around the world where people had expressed interest. You’ll see the results of these comments in an updated Public Working Draft in the next month.
Everybody who submitted comments on last year’s Last Call Working Draft will get individual replies to their comments, and we’ll ask them to look at how their comments have been addressed in the updated Working Draft. There will also be an opportunity for public review.
Based on feedback from this upcoming Working Draft, we’ll make new changes as needed, then publish a second Last Call Working Draft. Integrating comments should take less time during the upcoming document stages since so many issues will have already been addressed.
During Candidate Recommendation, we’ll ask for feedback from people using WCAG 2.0 on a trial basis. But we can also use implementation feedback as early as this upcoming Working Draft.
There’s more information about W3C Process — what the stages are, when & how to comment, and what to expect from your comments — in How WAI Develops Accessibility Guidelines through the W3C Process: Milestones and Opportunities to Contribute.
- Many in the development community believe that it is too late for effective changes to be made to WCAG 2.0. Is the process so far along, or is WCAG 2.0 so formalized, that we cannot expect to see significant changes?
-
Not at all; you’ll be seeing significant changes in the upcoming Working Draft. We want people to take a good look at this one when it comes out, and let us know what you think.
All the comments that we get are considered seriously by the Working Group; many result in significant improvements. The quality and usefulness of W3C standards is dependent on community dialog, and the W3C Process is designed to support that. I appreciate all the people who’ve taken the time to read previous drafts carefully and make constructive comments.
- Many have expressed concerns over the complexity of the language of the guidelines and are concerned with the amount of support documentation required for developers to grasp, understand, and implement WCAG 2.0. Are these concerns being addressed? Can we expect a simplification of the guideline language?
-
Yes, it’s going to be more understandable. That was definitely a problem with the Last Call Working Draft last year. The Working Group has already done a lot to improve the understandability of the guidelines since then. WCAG 2.0 addresses accessibility of complex Web technologies, so it needs to use some technical language. But we want it to be useful for diverse audiences, so we’re aiming for something more understandable. It’s an issue that we’re interested in getting more feedback on in the upcoming draft.
With WCAG 1.0 we didn’t have enough support material available. With WCAG 2.0, there will be different kinds of support materials for different purposes. Most developers will probably use the WCAG 2.0 “Quick Reference” — which we’ll update with the upcoming draft — most of the time, and go to other material only occasionally. One of the things that we’ll be working on in subsequent drafts will be ways to help people quickly find the right supporting information.
- There have been other concerns raised about how WCAG 2.0 addresses cognitive disabilities; that the guidelines themselves are not accessible to many with cognitive disabilities; and that the W3C process for contributing to the guidelines is not accessible to many with cognitive disabilities. How are these concerns being addressed?
-
The guidelines should address as much as possible of the needs of users with different kinds of cognitive disabilities, so we’ve asked for additional feedback on proposed resolutions for comments relating to cognitive disabilities. We’ve had a series of discussions with people with different interests and expertise in cognitive, language, and learning disabilities.
We’ve added success criteria and advisory techniques, and changed the level of success criteria. We’ve added clarifications that WCAG 2.0 does not cover all possible solutions for cognitive disability issues, since some approaches don’t fit within the testability framework of WCAG 2.0, and some other approaches would require more research and development before they could be added to the guidelines.
The guidelines themselves will need to remain technical, though we are making them more understandable. Some of the support materials should be more accessible to people with cognitive disabilities.
The WCAG Working Group has made a few changes to its process, such as clearer labeling of issues under discussion. We’ve heard that this has already helped.
We’ll be holding some additional discussions on how to better address accessibility for people with cognitive disabilities throughout WAI groups, and we will look more at accessibility of working group processes within those discussions.
- Some have proposed that instead of continuing with a “broken” WCAG 2.0, that the W3C should instead focus on updating WCAG 1.0 with technology-specific language that is easy to understand and implement. Is this a viable option? Why or why not?
-
I think most people will be encouraged enough with the progress they’ll see in the upcoming draft of WCAG 2.0 to realize that it’s not broken. WCAG 2.0 lays out principles and guidelines for making the Web of today and of the future accessible for people with disabilities, which is what we need. The technology of the Web continues to advance; WAI guidelines need to as well. People with disabilities want access to more than just yesterday’s technologies.
WAI looked at the possibility of developing a “WCAG 1.1″ several times over a period of years, but the largely HTML focus of WCAG 1.0 would not have covered newer technologies that are an increasingly important part of the Web. Guidelines were needed that could also provide guidance for these other technologies.
A “WCAG 1.1″ would likely have led to an increasing number of different versions of accessibility guidelines. This fragmentation of guidelines tends to slow improvements in authoring tools, which could otherwise better support production of accessible Web content.
- How can a developer become involved in WCAG 2.0 development?
-
There are a lot of ways to contribute. You can review the upcoming draft carefully and send us your comments. Try using it in your Web development projects; send us any problems that you run into, and suggestions for changes. Contribute implementation techniques that could help other developers.
Talk about it with other developers and colleagues, or discuss it on the WAI Interest Group mailing list.
Consider participating in the WCAG Working Group. The participants in the WCAG Working Group represent different viewpoints and have contributed a huge amount of work. Participating in the Working Group takes a commitment to principled dialog, hard work, and persistence in seeking solutions that meet the needs of diverse stakeholders.
- What other changes are likely to happen?
-
The Working Group has been working on the baseline concept from the Last Call Working Draft — another issue on which we received a lot of comments. You can expect a number of changes in that area, including dropping the term “baseline,” and a more effective replacement concept.
One of the most interesting aspects, from my perspective, is how WCAG 2.0 relates to other key Web accessibility documents. A quantum leap in accessibility of the Web will come when support for production of accessible content is built into mainstream authoring tools. Towards that end WAI is also updating the Authoring Tool Accessibility Guidelines to parallel WCAG 2.0, and ATAG 2.0 should provide much stronger support for implementation of WCAG 2.0 than was available for WCAG 1.0.
You can sign up for RSS feeds from the WAI home page that will give you updates on these as well as other areas that we’re working in, such as Accessible Rich Internet Applications (WAI-ARIA), Evaluation and Report Language (EARL), updates on WCAG 2.0 status, and WAI‘s educational resources.
Thanks for the chance to talk with you about this. I’ll be interested to hear what your readers think about our upcoming WCAG 2.0 draft when it comes out.
The Web Standards Project is a grassroots coalition fighting for standards which ensure simple, affordable access to web technologies for all.