Re: WAI status (Q issue)

Please Martin and whoever is going to follow-up, include both
w3c-html-wg and w3c-wai-hc in the thread.

Thanks.


------- Forwarded Message

Date: Mon, 3 Nov 1997 15:19:13 +0100 (MET)
From: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= <mduerst@ifi.unizh.ch>
To: dd@w3.org
cc: w3c-html-wg@w3.org
Subject: Re: WAI status

On Fri, 31 Oct 1997, Daniel Dardailler wrote:

> Hello all, here's an update after a week or so of discussion in WAI
> land.

> On Q.
> ----
> 
> The discussion started last Tuesday (28 Oct) with a message from Dave
> Raggett,
> 
> http://lists.w3.org/Archives/Public/w3c-wai-hc/1997OctDec/0203.html
> 
> stating that Dan Connolly, chair of the HTML working group has ruled
> that the 4.0 spec should strictly adhere to RFC2070 for the required
> treatment of the Q element.
> 
> We then went on discussing the issue (please follow thread for details).
> 
> 
> Here's our conclusion.
> 
> 
> 1. It is possible to read RFC2070 to mean that user agents must
> _ensure the presence_ of quotation marks separating the contents
> of a Q element from its context.  It is not necessary to read
> RFC2070 to mean that user agents _must insert_ quotation marks
> around the Q contents in all cases if the Q contents is already
> terminated on both end by matching quotation mark characters.

This is rather on the edge. RFC 2070 clearly says that the Q
element does not include quotation marks.


> RFC2070 does not anticipate the development of audio browsing and
> quotation characters are clearly not the best styling method to
> set quotes off if other prosodic devices can be used (e.g.
> changing characteristics of the speaking voice).

RFC 2070 uses the term quotation mark, but is explicitly designed
so that the quotation mark can take all kinds of forms. If this
is the form of some prosodic change, I think that would easily
qualify as "adding quotation marks" in the intent of RFC 2070.


> 2. It can be made clear in the HTML 4 specification that the
> normal mode of operation with HTML 4 compliant documents and HTML
> 4 compliant browser is that the Q content is not delimited by
> quotation marks and that the browser applies media- and
> language-appropriate styles to distinguish the quoted text from
> its context.

Ok.


> 3.  Because of the transition from a situation where quotation
> marks are mostly not supplied by the browser to a situation where
> they mostly are, there is room for positive contribution from
> heuristic approaches to handling exceptional cases such as when a
> Q element in HTML 4 has content which is started and ended by
> quotation marks.

There is a specific note on page 11 of RFC 2070 that makes it
clear that there was no intet to have this problem being solved
with heuristics, but with a very quick but easy bottom-line
implementation of Q.


> 4.  In these exceptional cases, the browser may wish to strip the
> pre-existing punctuation in the application of some styles or
> adapt what it inserts based on the terminal characters of the Q
> content.  This is a styling matter on which it is reasonable for
> the HTML specification to remain silent.

It is probably good for the HTML spec to remain silent on this
issue because:
- - Removing some punctuation may lead to removing too much;
	the document author might have relied on RFC 2070
	and might have intended to have two kinds of punctuation
	combined.
- - Requesting any kind of behaviour in this direction would
	lead to the question of "what exactly", which would
	mean that we have to go into the really nasty details.
- - Officially suggesting such behaviour may lead to the situation
	where all browser have to use complicated heuristics.
	This is definitely not in the intent of RFC 2070.


> 5.  The WAI believes that there is an accessibility interest in
> minimizing the transitional difficulties in this area and making
> the Q element as attractive to authors during the transition as
> we can.

I agree. But it doesn't get more attractive if different kinds of
browsers start to use different heuristics for quote removal and
authors start to rely on them.


> 6.  The WAI plans to prepare a browser guidelines document
> discussing browser behavior in more depth.  We would like to have
> room to recommend approaches to smoothing the trasition in Q
> behavior in this document.  We believe that if the HTML
> specification takes pains to emphasize a hard "MUST" for the
> insertion of quotation mark characters, our ability to mitigate
> the transition problems will be impaired.

Please don't put language in your document that may result in
the removal of what is seen by some authors as relevant content.

If you want to say: On audio media, "quotation marks" can mean
so-and-so, that's fine. If you want to say "in case of display
for pepople with limited eyesight, please make sure the quotation
marks are large and thick enough", that's again fine.


> 7.  None of the above is a major make-or-break access issue.  If
> the HTML 4.0 specification becomes a W3C Recommendation with the
> Q element behavior as it now stands (must insert quote
> characters) there is very little likelihood that any specific
> pages will be rendered totally inaccessible as a result.  On the
> other hand, there is a plausible belief that the Web will serve
> persons with disabilities less well in an articulable and utterly
> unnecessary way.

The best thing is to have Q implemented everywhere as quickly as
possible, at least in the base version (one single kind of quotes).
As RFC 2070 or its drafts are around for quite some time, that
should already have happened.


> 8.  We suspect that this is the kind of wording change that could
> be accomodated in the trasition from Proposed Recommendation to
> Recommendation.  The issue does not necessitate immediate
> reconsideration if the HTML WG Chair concurs that the range of
> changes discussed above is compatible with consideration after
> the Proposed Recommendation goes out.  Immediate, fast-track
> reconsideration is not thought to be necessary.

Okay for minor stuff, but not if complex heuristics should be
introduced.


Regards,	Martin.


------- End of Forwarded Message

Received on Monday, 3 November 1997 09:25:44 UTC