- From: Kynn Bartlett <kynn-edapta@idyllmtn.com>
- Date: Thu, 07 Sep 2000 08:53:37 -0700
- To: Al Gilman <asgilman@iamdigex.net>
- Cc: "Web Content Accessibility Guidelines" <w3c-wai-gl@w3.org>
At 08:32 AM 9/7/2000 , Al Gilman wrote: >1. You have made a reasonable case that there is a problem. Do you have a >rough estimate of a solution? What audience(s) do you think the WCAG we >are developing should target, i.e. should serve or should focus on? Good question, sometimes it's important to call me on specifics or else I just prattle on. :) My concern is the following, as expressed in email sent by the WCAG co-chair on August 19: >One of the most difficult aspects of our current work can be described as >follows. > >The guidelines are heavily constrained and must meet many requirements >simultaneously: >- some content developers want immediate, practical and verifiable >requirements relative to today's technologies; >- others want to be able to apply the guidelines to emerging standards; >- technology designers want from them a set of criteria to provide guidance >as to what "accessible" design requires in the creation of new formats, >protocols etc.; >- policy advocates, likewise, want a definition of, and criteria for, >accessibility; >- and the W3C process imposes a fundamental demand for stability in the >document that is supposed to become a W3C Recommendation. >- Add to this the blurring of the distinction between the content developer >and the language designer which results from the "extensibility" of most of >the newer W3C formats, combined with the emergence of XML as the predominant >markup language, I feel that with these constraints and requirements, it will be -impossible- to meet these goals with a single or even two documents. I think that too much is required, to the point that no one core document (or one core document plus a derivative techniques document) can exist which meets the goals above, in any way that's accessible. I've spoken to people at <some big company, involved with WAI and W3C activities>, who said flat-out that WCAG 1.0 was too "everything for all audiences" to be useful within their company, so they had to basically start from scratch (from the same source material as WCAG) and make their own guidelines for internal use. My practical solution is to prioritize as follows: >- some content developers want immediate, practical and verifiable >requirements relative to today's technologies; This should be considered a core audience and goal. >- policy advocates, likewise, want a definition of, and criteria for, >accessibility; This should be considered a core audience and goal, with the caveat that we are defining _accessibility of web content_. I believe that a generic document describing accessibility itself -- a "principles" or "concept" document -- should be created by the W3C which covers not only WCAG but ATAG, UAAG, ERT, and others. _Defining accessibility itself_ is too large a project for _this working group_ if we are also tasked with creating a WCAG document, which I believe we are. >- others want to be able to apply the guidelines to emerging standards; >- technology designers want from them a set of criteria to provide guidance >as to what "accessible" design requires in the creation of new formats, >protocols etc.; >- Add to this the blurring of the distinction between the content developer >and the language designer which results from the "extensibility" of most of >the newer W3C formats, combined with the emergence of XML as the predominant >markup language, I think that XML accessibility is going to be fundamentally different from application accessibility (such as the application of XML as XHTML or SVG), because it is going to be one meta-level up and is going to be a different conceptual audience, working on an entirely different level. I feel that meta-accessibility _is_ important but may be best addressed by either a second core document from this group, or by another working group entirely. The issues related to meta-accessibility are -not- well understood, and are -still- items up for debate in the Protocols and Formats working group. I don't feel that the WCAG working group is equipped to deal with these issues at this time, without drawing the process out further and making it near impossible to complete the task of generating a new WCAG version. By tying this issue too closely with the issue of HTML/XHTML/CSS/SVG/SMIL accessibility, we will produce a workload that will be too difficult to meet in a timely manner with far too many factors in the mix. >- and the W3C process imposes a fundamental demand for stability in the >document that is supposed to become a W3C Recommendation. If the W3C process is truly a hindrance to our activities (and I do -not- feel that it needs to be), then we should address our concerns to the W3C advisory committee, staff, and director, and see if we can get this changed. The purpose of the W3C process is to facilitate and organize the process of creating standards in a responsible manner, not prevent us from accomplishing that task. However, in my opinion, the W3C process requirements have been overstated in discussions on this topic. Summary: I think the WCAG document should concentrate on the _WC_ itself -- on web content, on accessibility specifically of "languages which someone sets down in front of you, the designer" not of "languages which you the designer choose to create." The latter is a valid and good topic, but I think it is a topic for another day, another group, and another audience. -- Kynn Bartlett <kynn@idyllmtn.com> http://kynn.com/ Director of Accessibility, Edapta http://www.edapta.com/ Chief Technologist, Idyll Mountain Internet http://www.idyllmtn.com/ AWARE Center Director http://www.awarecenter.org/ Vote for Liz for N. Am. ICANN Nominee! http://www.khyri.com/icann/
Received on Thursday, 7 September 2000 12:10:38 UTC