Re: the Q element and WCAG2

this response to:
[http://lists.w3.org/Archives/Public/wai-xtech/2006Aug/0004.html]
was composed in august 2006, but due to circumstances beyond my 
controli i was unable to post it until today..

WCAG cannot be held responsible for nor captive by poor, shoddy, or 
incomplete implementations; it should NOT allow any work-arounds that 
encourage authors to deviate from using the semantically logical 
markup which, when valid AND validly parsed, fully support the 
standard DTDs addressed by WCAG (in this case, HTML 4.1 and XHTML 
1.x) - if the Q element is recognized by a user agents' parser, there 
MUST be a default style in the user agents' default style sheet for 
the Q element, just as there are default stylings for the EM and 
STRONG elements, all of which can trigger multi-modal, user-
controlled switches to indicate the presence of a semantically 
meaningful element...

instead of providing an quote out quote for user agents or DOM-aware 
adaptive technologies, WCAG should, in liason with the Authoring 
Tool, User Agent and EO groups to formally ask the WAI Co-Ordination 
group to discuss the incomplete implementation of Q and to approach 
those user agent and adaptive technology developers who are members 
of the W3C and formally request of those companies slash 
organizations' Advisory Committee member, who should, in turn, make 
it an internal matter of the utmost importance that the Q element, 
the LONGDESC element, the ABBR and ACRONYM elements are supported by 
that entity's user agent and slash or assisstive technology...  for 
those developers who are not members, EO should reach out to them 
with the same request...

why my insistence on using, parsing, and rendering Q is that i am a 
screen reader user who would like the Q element to trigger a change 
in the reading voice's characteristics, such as a change in pitch or 
a change of voice (from male to female, male to deep voiced male, or 
whatever the user prefers), just as it provides expansions when it 
encounters the ABBR and slash or ACRONYM element, and how some screen-
readers know to switch language libraries on the fly in response to 
the "lang" attrribute...  but all of this is dependent upon use of 
the Q element, rather than guessing whether content contained in 
" is semantically a quote, or an ironic or emphatic use of quotes 
(the written equivalent of quote air quotes quote or my own habit of 
using quote unquote inline)

i also wouldn't mind a list of quotes in a given document, something 
again that needs to be pulled from the DOM in order to work, as it 
would be of interest to some users to have the URI of the quotation 
displayed in the list of quotes' status line, so that they are aware 
to where activating the quote (as opposed to just moving to it) will 
lead them...

thus, the only advice WCAG should give authors is to require them to 
encase quotations in the Q element...  that is why it is in the DTD --
 to provide a means of logically signaling that a particular string 
of content is a quotation, which is semantically essential to a full 
understanding of the content being presented to the user...

the very purpose of the WAI domain is to ensure that published, 
standard (and thereby validatable) DTDs either enhance accessibility 
or prevent new barriers to accessibility from being erected - the 
grunt work in this effort is done by Protocols and Formats, and - 
because humans are human - the Evaluation and Repair groups; the 
Authoring Tool Working Group (amongst other things) outlines the 
requirements for all tools used to construct web content so that they 
produce accessible, valid markup to contain that content, in 
semantically and logically meaningful markup; the User Agent working 
group provides user agents and DOM-aware technologies with guidelines 
and techniques as to how to implement and slash or expose the content 
in a semantically logical way; and WCAG explains to authors slash 
overseers of web content how to implement published DTDs so that the 
markup they generate is not based on a single modality (point-and-
click) but is semantically and logically meaningful, as well as 
implementing - by default - expressly accessibility- and useability 
oriented markup 

it all comes down to this very simple fact: accessibility is a 
chicken and egg question, in which the WAI is supposed to serve as 
incubator - the problem is, we have many beautiful eggs inside the 
incubator, but the chickens outside are all running around with their 
heads cut off.  what we need is insistence on coding to a published 
standard and implementation of published standards - the Q element 
has been part of the HTML family of markup languages since 1998 - 
when does the onus to implement it FULLY and CORRECTLY (according to 
spec) fall on the implementors? it is time that they be held 
responsible for the quality (or lack thereof) of their products...  
it is NOT the role of the WAI to accomodate hacks because of lack of 
implementation on the part of developers - ESPECIALLY those which are 
members of the W3C.

gregory.

---------------------------------------------------------------
ABSURDITY, n. A statement or belief manifestly inconsistent with
one's own opinion.  -- Ambrose Bierce, _The Devils' Dictionary_
---------------------------------------------------------------
Gregory J. Rosmaita, oedipus@hicom.net & unagi69@concentric.net
          Camera Obscura: http://www.hicom.net/~oedipus/
         VICUG NYC: http://www.hicom.net/~oedipus/vicug/
---------------------------------------------------------------

Received on Wednesday, 15 November 2006 22:23:00 UTC