Re: valid mark-up only priority 2!! WAS valid comments

I would also note that if I cannot know that the language has changed, I
may not be able to account for it.  Without at, this much more apparent
than with but it could also be argued that it aids in cognition.

----- Original Message -----
From: "Al Gilman" <asgilman@iamdigex.net>
To: "Jukka Korpela" <jukka.korpela@tieke.fi>; "WAI IG"
<w3c-wai-ig@w3.org>
Sent: Tuesday, November 12, 2002 8:26 AM
Subject: RE: valid mark-up only priority 2!! WAS valid comments



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:54:47 UTC