- From: Geoff Deering <gdeering@acslink.net.au>
- Date: Mon, 8 Mar 2004 14:42:34 +1100
- To: "W3C WAI AU" <w3c-wai-au@w3.org>
Hi, Regrets for being off list for a bit over a month. But I have still be thinking about matters I have raised before. I did begin work on writing a long technical article covering items I have raised, but I don't think that is a good approach, unless those here want to engage in a technical discussion. This is the crux of my point, that in spirit ATAG is heading in the right direction, but I feel it is seriously flawed by it's naivety at addressing technical issues and clarifications. And I feel these issues of technical inadequacies are so serious as to have the effect to alienate and loss the developer community, specifically ones that are building web based authoring tools. I will just briefly make these points, and if anyone wants to discuss them, then I am willing to expand on them and clarify these issues. As I have said before, there is a problem with grouping all these guidelines together and applying them generically to all the Authoring Tool categories (http://www.w3.org/TR/2004/WD-ATAG20-20040224/#what-auth-tool). First point, "Software Accessibility Guidelines" and WCAG share the same focus and aims, but they are aimed at technically different types of application that run under different programming environments and are therefore subject only to the rules governing those environments, one is aimed at software that operates on APIs, and the other is based on markup render via a user agent. I believe ATAG has to be very clear which is which and technically correct, otherwise the effort put into these guidelines will be wasted on the developer community they are aimed at. To see some of my initial points, please refer to; http://lists.w3.org/Archives/Public/wai-xtech/2003Dec/0002.html I feel there is need clarify this document so that the right guidelines are applied to the correct type of authoring tool. I am also afraid to say that I feel there is a need for a third type of category (1. Software Accessibility 2. Web Content Accessibility Guidelines 3. Web Application Accessibility), the problem is that *every" "Web Based Application Tool/ CMS Interface" I have seen does not comply with WCAG1 Priority 1. All of them rely on scripts (Java, JavaScript), many rely on popups for certain functions of the user interface, etc. I just cannot see any of them seeing the benefits of transferring all scripting to the server side and trying to become ATAG compliant. They are all script dependant. I did 2 days of Interwoven Teamsite training a few weeks back, and I just could not see any reason why they would try and comply to the letter of these guidelines. What is the benefit to any of the CMS developers to follow ATAG, because it will surely kill their product in the general market, it will put them so far behind their competitors. Can anyone else see these issues, or am I a lone voice on this list in this regard? Geoff Deering
Received on Sunday, 7 March 2004 22:41:55 UTC