Re: Summary of Bugzilla comments on checkpoint/guideline 3.3

On Tue, 20 Jan 2004, Joe Clark wrote:

>>August 2003, Harvey Bingham: suggests explicitly including synthetic
>>speech (with variations of pitch, rate, etc.) as well as
>>announcement of events.
>>
>>Not yet addressed; might be incorporated in strategies and examples,
>>references to CSS 2.1 speech properties.
>
>We really shouldn't be encouraging people to cause their Web sites to
>read themselves out loud. The settings you the developer like will
>never or very rarely match what the visitor wants, plus there is much
>less control, *plus* we can flunk it under WCAG 1 as an unannounced
>change of state (plus don't you need to caption it?).

Essentially I agree with Joe here. Audio styling would be nice, but in the
absence of particular programs taking it up there seems some doubt about
whether it will remain in CSS 2.1 or be deferred until some time in the
future.

>>#430 Proposal 3, Checkpoint 3.3
>>
>>
>>August 2003, Lisa Seaman, on behalf of a group.
>>
>>This proposal, sent to the list and available at
>>[15]http://lists.w3.org/Archives/Public/w3c-wai-gl/2003JulSep/0244.html
>><[16]http://lists.w3.org/Archives/Public/w3c-wai-gl/2003JulSep/0244.html>
>>, forms the substance of Checkpoint 3.3 as it appears in the
>>September WD, though portions of the proposal were altered as they
>>migrated into the WD. Perhaps the most important concept that does
>>not appear in the WD is the one that calls for "markup of key
>>information that the user typically requires." Lisa notes that this
>>requirement is "similar to 1.3" but differs in the important respect
>>that it first calls for identifying important information and
>>including it in structural markup, whereas 1.3 calls for using
>>structural markup and making structure manifest:
>>
>>In my judgment, the proposal is clearer and perhaps more nearly
>>testable than Checkpoint 3.3 as it appears in the September WD; the
>>first plain language proposal (#648) took the WD as starting-point
>>rather than this proposal, so does not include the item about
>>identifying key information and incorporating it into structural
>>markup.
>
>I really need this one explained better. Various WCAG drafts have
>gone off into this fantasyland tangent that it is possible to use
>custom markup to emphasize different page components for different
>audiences. Yeah, like what-- <blink> and <marquee>?
>
>If you're writing semantic, valid HTML, *there is no more you can
>do*. It becomes a user-agent issue.

You can annotate pages to identify a particular type of skeleton. User Agents
do some versions of this (lists of links, lists of headings) but the sort of
thing that SWAP does allows you a lot more flexibility - think of how
accesskey (and even more a better version of accesskey/tabindex) allows for
improvements on navigating link-rich sites in ways that offer more than
simply tabbing through links.

You can annotate content to provide a "simpler" or "more multimedia" version.

>>3.3 [E8] Use the clearest wording that is consistent with the
>>purpose of the content. Provide summaries or paraphrases of complex
>>material, and provide visual or auditory illustrations as
>>appropriate.
>>
>>The proposed rewording eliminates the controversial phrase "no more
>>complex than is necessary," but replaces it with one about
>>consistency which may be equally difficult to test.
>
>Let's say "appropriate for," "compatible with," "consonant with".

I'd go for "compatible with". Some people seem to think that high falutin'
and complicated language is more appropriate for rich ideas, and that
sesquipedalian expression and excessive jargon are appropriate for explaining
technical content.

And "consonant with" strikes me as great for literature, but not the easiest
way to help people who are just trying to understand the guidelines in a
hurry.

>>1. The original wording of "A. familiarity of terms and language
>>structure" would be replaced by "A. The resource uses vocabulary
>>which is widely used by members of the intended audience." This
>>replaces the vague "familiarity" with language that suggests a test.
>>Note that Lisa Seaman's proposal would go even farther by calling
>>for links to a specific lexicon or glossary.
>
>few of which are even available. A lot of terms I know and use don't
>even come up with hits in the Google Glossary, for example. It would
>be imaginable that if a glossary didn't exist on a certain topic, a
>pedant could come along and forbid people from claiming conformance
>with this guideline for their pages. There would be, after all, no
>way for the author to link to a glossary that doesn't exist.

This may be true. It is clearly important to come up with ways for authors to
define terms. I'd encourage you, for example, to look at the work
on thesauri done in the SWAD-Europe project -
http://www.w3c.rl.ac.uk/SWAD/rdfthes.html - or the report at -
http://www.w3c.rl.ac.uk/SWAD/deliverables/8.2.html - although it's pretty dry
and technical as yet. Butit isn't the only work of its kind, and it is
feasible to link to a glossary constructed in the way it lays out...

>>2. The original "B. reasonableness of length and complexity of
>>sentences" would be replaced by language that suggests possible
>>tests: sentence length and complexity should be consistent with
>>practices recommended by widely used textbooks about writing in the
>>relevant discipline
>
>Let's have a full bibliography of all such books published in the
>last ten years in the English language. You mean there *isn't* a
>textbook published about how to write in, say, automotive mechanics,
>organic chemistry, needlepoint, homemade tofu, or even...
>accessibility? Shock.

Agreed. There are books about many disciplines, there are books about how to
write clearly. But of the handful of books written on Web accessibility in
english (I think the language where the most books on the topic are written
at the moment), none of them seem to be about how to write about
accessibility. (Although one, by a certain "Clark, J." does touch briefly on
the topic it is more about style than technical requirements of the writing).

>>4. The call for "clarity of headings and link text when read out of
>>context" is modified to include specific situations where headings
>>and link text must be understandable, e.g., in lists of links and
>>headings reported by screen readers
>
>This continues to be an extremely serious mistake the Working Group
>cannot stop itself from making. I have explained over and over
>again-- including face to face at the Toronto meeting-- that our task
>is not to custom-craft guidelines that suit the peccadilloes of
>whatever adaptive technology the Working Group politburo happens to
>like. (This always means Jaws and Internet Explorer for Windows.) You
>can*not* expect authors to write valid, semantic HTML pages that
>*also* make sense when someone comes along and removes all their
>bones.

I think the metaphor is inside out here. One can expect to have an
understanding of the body of a page if one looks at the bones.

The qualifier "e.g., in lists of..." is important here. These lists are views
of the bones, which assorted browsers make available to increase the
efficiency of understanding the nature of the body. This is particularly
helpful when people have difficulty scanning the entire page. I suspect we
are in agreement on the required result here - that people can sensibly
navigate semantically valid pages. Although it is hard to tell - is this a
disagreement on wording, or on the idea we are trying to be expressed.

(As it happens, WCAG called for a heading-based structure of the page some
years before JAWS or Internet Explorer managed to make it available to users
- long after some of their competitors.  Perhaps they actually did it because
users of their competitors were happy about the improved accessibility it
provided).

>I want a straight answer why this one hasn't been deleted forever. It *is
>not an accessibility aid* in Web content development. At best it's
>something a revised User Agent Accessibility Guidelines could handle.

If there isn't a basis in content for user agents to work from, it's hard for
them to provide the assistance. Although Lisa's work on using RDF to describe
structures shows there are different ways to create the content they might
require.

In any event, it seems that lots of users disagree, making extensive use of
lists of links. People also use lists of headers, but they have not been
available very long in some very widespread systems. That seems a reasonable
basis for keeping this issue somewhere other than the cutting floor of
history - despite the fact that I agree there is scope for some corrective
surgery.

>>5. The item about accuracy of page titles is now written in sentence
>>form and calls for page titles to be unique and informative
>>(consistent with Seaman proposal)
>
>I have strong reservations about the possibility of doing this across
>the entire Web. Unique compared to what? Every other page you've ever
>seen on that site? Every other page ever served by that site?
>
>The *page content* matters. Unique <title> elements are less
>important than *meaningful* <title> elements. Unless of course your
>computer platform is Microsoft Windows, in which the stacking of
>multiple seemingly-identical buttons in the Taskbar might lead you to
>demand unique titles. (What if they're the same all the way down to
>the 50th character? Are they still "unique"? What if I serve up a
>300-character <title> element just to comply with this guideline? Do
>you really want to listen to that in Jaws?)

Right. I think meaningful is the important one, and helping to distinguish
multiple pages is something to try and have. I'm not sure how to write clear
criteria for that, which means I'm not ready to make a particular proposal.

cheers

Chaals

Received on Tuesday, 27 January 2004 14:40:11 UTC