- From: Al Gilman <al.gilman@comcast.net>
- Date: Thu, 05 Feb 2004 12:41:27 -0500
- To: w3c-wai-gl@w3.org
At 03:37 AM 2004-02-05, Jens Meiert wrote: >- Is this really an important issue in WAI terms [1]? >[1] 'The aim of the WAI is to level the playing field for people > with disabilities. If people with disabilities have the same > problems as people without disabilities, the goal is reached.' > > http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JanMar/0118.html >- What wording has to be explained, where ain't an explanation needed? >- What way(s) of semantic highlighting should be recommended? > >If these questions (of course and above all, the first) are answered, there >should be a general discussion on it, not yet. [I speak as a fool, or at least as an individual. Your assertion is out of order, the chairs of the group set those rules. But I, as one voice, do wish to a) meet some of your concerns and b) diagree with some of the more severe strictures.] There has always been a tension in the WAI between seeking to guarantee *any* access and striving to attain *equal* access. You are reading John's opinion in a particularly strong-one-way manner: You are claiming that if some TABs, some people-without-disabilities, encounter the same modality of functional degradation as do people with disabilities, then that modality of functional degradation is out of scope for the WAI and the WCAG. The other way to read John's dictum applies the equal-access standard: If people with disabilities experience a disproportionate degradation in usability, it is an access issue. I believe that your reading is too strong. I do believe that we should give priority to things that are readily fixable, but I do not believe we should rule out-of-scope things that are incremental, but disproportionate, degradations in usability. I think that this is one of the lessons learned from trying to deploy WCAG1. One of the things that we learned, in my opinion, is that the distinction we drew between Priority 1 and Priority 2 is academic to the people who have to adopt or implement the guidelines. It is too 'nice' a distinction to have been used to cut the pie of exhortations. Let me remind you: P1 means there is technically *no way* a function of the web can be accessed for someone with some condition. P2 is applied if the function becomes effectively useless because the degradation in usability is so severe. In the real world, this distinction doesn't carry any weight. It only entered our considerations because we are a caucus of technophiles, on the whole. So let me turn from process generalities to "on the product" the standing of - the interest of dyslexics in simple language - as a WAI concern. While overly-complex language does degrade the usability of resources for the general public, There are people with reading-related difficulties who are "thrown off the bus" by this degradation. It pushes them beyond their ability to cope, to maintain lock on the story line in prose. I claim that you could by usability-structured experiments document that there is a relationship between - reading level, or any metric of language difficulty you chose to use .and. - probability of task failure for dyslexic subjects So on the 'demand' or 'mission' side, the issue clearly has standing to be a WAI and WCAG concern, and I believe that this has consistently been the conclusion of past discussions in the WCAG. But, on the 'supply' or 'technology' side, is there anything that we can do about this? Sniffing code pages is enough of a language-change hint so that its use in prompting authors for translations should be considered. And in checking documents. That is a technological intervention that one should regard as likely to prove effective until proven otherwise. This issue not only passes the PF test for "is this a WAI concern" to wit: - does this failure mode disproportionately and substantially degrade the usability of the Web for a recognizable class of PWDs? It also passes the more severe test: - is this a make-or-break issue for a recognizable class of PWDs? It also passes the pragmatism test of "can anything really be done about it?" So there is no excuse for claiming it is out of scope. I believe that addresses your first "prior question." The other two questions are _what should be discussed_ in a general discussion or task-team assignment. But here are some provisional, personal answers. >- What wording has to be explained, where ain't an explanation needed? There is no one answer to this. There are various ways of assessing prognostic language difficulty. And the results are points on a continuum of difficulty. One unifying parameter is the negative of the logarithm of the probability that the user will recognize the sense intended. It is not possible to set a uniform standard for language level across all documents, but documents internally should police a leveling standard and apply remedies according to their proper sliding scale. >- What way(s) of semantic highlighting should be recommended? Embedding a content model in the markup, and interpretation of this content model in different ways in the User Agent. The ways of embedding the content model in the markup include - RDF in a separate file, available for any and all assertions today - RDF in the same file, available in SSML, SRGS, and some other contexts today. - <abbr> markup in HTML4, and its replacement under discussion in HTML WG. - relationship records in a lexicon referenced from an SSML or SRGS document, .. available today. The methods used to convey the content model will vary with the format employed. Again, there is no one answer here. There are general trends: - put things that are most likely to confuse in the 'push' default presentation .. example: expand abbreviations (including acronyms) on first use. .. example: for 'context help' for a form control, we are looking for the right technique that will make the help text be a selection from the normally displayed text, in preference to relegating this to a normally-hidden text fragment. - put things next most likely to confuse in places where there are "a click away" such as 'notes' if the medium is a standard digital talking book, labels for form controls, and similar opportunities built into the markup vocabulary specification. .. example: index the defining occurrences of jargon terms, support a lookup function in the User Agent that will return the definitive text when any instance of the buzzword is queried (as in the Atomica product). - use more indirect linking mechanisms to make connections that are less likely to be needed, but will be needed by some. The best ways to do this linking are still a matter of differing opinions in the W3C at large. Watch this space for clarification. But examples are: .. a lexicon referenced from your SSML document. .. metadata in your SVG document liking terms to WordNet nodes >Best regards, > Jens. Hoping I have suspended your disbelief, I remain Your colleague, Al >[1] 'The aim of the WAI is to level the playing field for people > with disabilities. If people with disabilities have the same > problems as people without disabilities, the goal is reached.' > > http://lists.w3.org/Archives/Public/w3c-wai-gl/2004JanMar/0118.html > > >-- >Jens Meiert >Interface Architect > >http://meiert.com/
Received on Thursday, 5 February 2004 12:42:26 UTC