- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Sun, 29 Jul 2007 12:22:06 -0400
- To: <public-html@w3.org>, <wai-xtech@w3.org>
Wow. I think we've made some real progress in this thread. I am sorry I haven't the time this morning to do a thorough summary. Let me just try to hit two points: one candidate agreements that we might manage to discuss less; and one perceived point of difference that we might manage to discuss more concretely: 1. [possible agreement] Baseline accessibility API information as 'to be explicitly supported.' Lachlan indicated support for the idea that "machine interpretable information" should be provided where reasonable and necessary. Others commented that Assistive Technology support has to be considered "reasonable and necessary" as that is how access to the Web works, when it works, today. In the spirit of the 'continuity' principle, this should be something that we don't change without a strong reason and a migration plan that eases the transition. It's also explicitly called for in UAAG 1.0 and is one of the four principles of WCAG 2.0. I think that we should consider putting this into a PFWG:HTML "working assumptions" agreement -- Information customarily used by Assistive Technology today to inform their management of the adapted user experience is presumably information that HTML5 should/must make available with machine-interpretable semantics. An initial benchmark for this information requirement is the information that is supported in the accessibility APIs of operating systems and programming language systems. 2. [possible disagreement] One of the major reasons for creating HTML5 is to clean up the mess of markup in use. Jason said something like this. I fear that if we took Jason's paragraph, or post, and put it up to an opinion poll in HTML WG there would be a majority of 'disagree' and 'strongly disagree' responses (on a five point scale including those two, 'don't care', 'agree', and 'strongly agree'). I think that accessibility proponents, to sell their proposals readily to the HTML WG and get them voluntarily accepted by consensus in that group (rather than sword-play over Director's decisions) will need to defend any 'consolidation' or 'rationalization' changes to the language on a case-by-case basis with appeal to the 'simple' principle in the HMTL WG Principles http://dev.w3.org/html5/html-design-principles/Overview.html#avoid-needless-complexity .. in balance with the 'continuity' principle. http://dev.w3.org/html5/html-design-principles/Overview.html#compatibility Partly this is an artifact of technology politics. One of the ideas that galvanized people to force the re-organization of HTML work in W3C was the idea that the then-existing HTML Working Group had placed too high a value on rationalizing the markup and too little emphasis on continuity of service to the incumbent user base. So if it sounds like we are arguing from a perspective of 'rationality for rationality's sake' we may run into an unexpected level of resistance. I would hazard a guess that the de_facto consensus in HTML WG would be something like the following: If, to achieve some highly desirable utility, where we have to migrate the user base anyway, we should take advantage of consolidation (increased simplicity, reduced 'footprint' in the sense of the PFWG charter) where it does not materially or unduly aggravate the migration pain. The point of the 'simple' guideline (avoid unnecessary complexity) as I read the tenor of the group is not so much to expunge existing complexity but rather to keep featuritis from driving HTML to explosive bloat, senility and obsolescence too fast. Al
Received on Sunday, 29 July 2007 16:22:29 UTC