- From: Al Gilman <asgilman@iamdigex.net>
- Date: Tue, 12 Nov 2002 08:26:03 -0500
- To: Jukka Korpela <jukka.korpela@tieke.fi>, WAI IG <w3c-wai-ig@w3.org>
Interesting ideas. Exceptions as follows: >Well, I wouldn't quite agree. All this priority thing confuses me. >For example, what are the clear and well demonstrated accessibility >issues for the checkpoint "4.1 Clearly identify changes in the natural >language of a document's text and any text equivalents (e.g., captions)."? The reasoning is that you can't do text-to-speech without knowing the natural language. One can fake it between different European languages, but try that with a French TTS and Thai text. >The guideline for using valid markup (in the sense of checkpoint 3.2, >which is actually much more than validity, since it requires the use >of a "published DTD", effectively referring to the small set of DTDs >published by the W3C) might, in rare cases, even conflict with >accessibility. You are reading the requirement a little stricter than it is. While the WAI would like you to prefer markup that conforms to W3C recommendations, the requirement to stick to a published grammar has IIRC always been understood to include the case Charles describes where you tailor your own DTD and publish it on your site. The standard on the Web of what is 'published' is that it is available on the Web. The matter of not breaking negative numbers is an interesting microcosm. Instead of going straight to the 'nobr' formatting directive in the content markup, there is the possible option of classing this token as a number and enforcing the non-breaking directive in a style rule applied to numbers. But in general the handling of word-breaking in texts is not yet fully covered, and it is on tap to be on the table in the timed-text work. Al At 02:31 AM 2002-11-12, Jukka Korpela wrote: >Jon Hanna wrote: > > > From a perspective of accessibility only many examples of > > invalid markup are pretty harmless, > >Indeed, especially since common markup errors are things like >attempts to put block level elements inside <font> elements, >where the real problem is not formal validity. > > > so it seems reasonable that it is of less priority than > > cases with clear and well demonstrated accessibility issues > >Well, I wouldn't quite agree. All this priority thing confuses me. >For example, what are the clear and well demonstrated accessibility >issues for the checkpoint "4.1 Clearly identify changes in the natural >language of a document's text and any text equivalents (e.g., captions)."? > >It's fairly easy to list down issues involved _in principle_. But then >again, the same applies to invalid markup. Invalid markup means that >the document syntax does not comply with a published "grammar", and >this in turn implies that any software, such as assistive technology >or special browser, may get thoroughly confused. But on the practical side? > >The guideline for using valid markup (in the sense of checkpoint 3.2, >which is actually much more than validity, since it requires the use >of a "published DTD", effectively referring to the small set of DTDs >published by the W3C) might, in rare cases, even conflict with >accessibility. > >The WCAG 1.0 text says: >"Content developers may be tempted to use (or misuse) constructs that >achieve a desired formatting effect on older browsers. They must be aware >that these practices cause accessibility problems and must consider whether >the formatting effect is so critical as to warrant making the document >inaccessible to some users." >Fair point, but consider the possibility of using constructs that >achieve _accessibility improvements_ on _newer_ browsers but haven't >been canonicalized into a W3C-approved DTD. > >Browser vendors haven't been that eager to implement accessibility >enhancements that are not present in published DTDs, but they just might. At >least some "minority" browser vendors. > >Or to take a specialized, yet real, example: Suppose your document contains >the string "-42". It is known that the most widely used browser treats this >as splittable*), in the sense that it may put "-" at the end of a line and >"42" at the start of the next one. This may confuse any user, and especially >users with cognitive disabilities. As far as I know, the only effective >weapon against that (in the general case) is to use <nobr>-42</nobr>. This >invalid markup, when used in cases like this, causes no known problem, to >accessibility or otherwise. I'm not saying it _should_ be used; just that >there are good arguments in favor of using it - for accessibility too. >*) For the boring details, consult >http://www.cs.tut.fi/~jkorpela/html/nobr.html > >In most cases, of course, there's no good excuse for using invalid markup, >unless you count relative lack of time and other resources to fix past >errors. ("Relative lack" refers to the possibility that there might be >other, more urgent problems to fix.) > >There's a particular reason to avoid emphasizing the importance of validity >too much in the accessibility context. It seems that surprisingly often >validity is presented as something that somehow guarantees interoperability >and even accessibility. Does the following sound familiar? >"To show your readers that you have taken the care to create an >interoperable Web page, you may display this icon on any page that >validates." > >-- >Jukka Korpela, senior adviser >TIEKE Finnish Information Society Development Centre >http://www.tieke.fi/ >Diffuse Business Guide to Web Accessibility and Design for All: >http://www.diffuse.org/accessibility.html
Received on Tuesday, 12 November 2002 08:26:12 UTC