HTML5+RDFa Editor's Draft Review and meta-issue: use of ASCII art in HTML5 drafts

aloha!

since clarity and coherence are in short supply in my neck of the woods,
i thought that i'd pass this by wai-xtech

COMMENT: i think the PF/WAI should give the call for consensus for
the HTML5 RDFa editor's draft

http://lists.w3.org/Archives/Public/public-html/2009Sep/0736.html

an enthusiastic endorsement with the following caveat, which probably 
should be carbon-copied to the W3C Communications Team:

PROPOSED:

While the PFWG commends the HTML5 working group and the document's 
editors, for such rapid action in drafting an RDFa in HTML5 document, the 
PF/WAI does have a substantive comment on the use of ASCII art in the 
document. Currently, the document reads:

<quote src="http://dev.w3.org/html5/rdfa/#invalid-xmlliteral-values">
<code>&#8594;</code> symbol is used to denote that the line is a 
continuation of the previous line and is included purely for the 
purposes of readability:
</quote>

but the "&#8594;" symbol is ASCII art, as it is a modality specific
means of indicating a new line.  This is especially problematic for those 
who interact with computers aurally and/or tactilely, as it creates a 
perceptual black hole for those for whom the character entity cannot (or 
cannot readily) be ascertained by a non-sighted reader. Moreover, the 
character entity may not be vailable in the users' system, or may be 
rendered as a placeholding "textual" symbol

To date, four different screen readers were tested, and none were able to 
speak the &#8594; symbol as rendered by an HTML parser or when  the 
symbol 
was copied-and-pasted into a plain text (unicode formatted) document, 
thereby DECREASING the document/example's readability, rather than 
universally enhancing it.

When the glyph rendered for the character entity "&#8594;" is directly 
queried with a screen reader, one does not hear "right arrow" (nor is 
it glossed to indicate for thos whose systems cannot render or parse 
the character entity in any meaningful way as a "new line indicator"), 
but simply as "blank".  When read in context using read-all or 
read-by-paragraph or  read-by-sentence or read-by-line, the rendered 
glyph for the character entity is not spoken.

Thus, there is a need to explore an alternate set of conventions for 
such useages and conventions which is not modality specific, as is the 
use of character entities to generate ASCII art.

In terms of markup, the explanatory blurb excerpted at the beginning of 
this post, in which the use of &#8594;  in the example which follows to 
indicate continuation of a line, one could encode the symbols in an 
ABBR

<abbr title="same line">&#8594;</abbr>

or

<code>value=yes|no<abbr title=" default">*</abbr></code>

but that tactic obviously doesn't work in cases where the document 
author intends raw code to be rendered in an example. Note, as well,
that it is assumed in the second example, above, that the CODE element
will be used by assistive technology to switch from a user's normal 
punctuation settings to "Speak All" or "Speak Extended" as per 
individual user's needs, desires, and/or preferences, so that the 
pipe glyph is used as a boolean indicator and SHOULD be exposable 
by an assistive tech to a user.

POST-SCRIPT: that's as far as i've gotten -- no cut-and-dried solution 
to the problem statement;

As for the contents of the document -- having reviewed the RDFa syntax 
and primer specs extensively, and having implemented RDFa in XHTML 1.1 i 
think that the HTML5 RDFa editor's draft should be published as a public 
working draft.

However, the fundamental (and recurring) problem i have with the 
HTML5 RDFa editor's draft, which is located at:

http://dev.w3.org/html5/rdfa/

is its use of non-interoperable ASCII art. It is up to the WAI when and 
how to address the issue of the use of ASCII art through the use of
charater-entity codes that are graphics, such as a right arrow, and 
not "text" in the "normal" sense. -- especially those for which there 
are no readily available or known means of generating the intended 
glyph from the keyboard, so as -- for example -- to choose the previous
and next sections in the multi-page "view" of the HTML5 draft

gregory.

ACTUAL POST-SCRIPT: a tangentally related issue is discussed from an 
XHTML2 point-of-view which needs to be ported to HTML5 terms and the 
HTML5 wiki, can be found at:

http://www.w3.org/MarkUp/xhtml2/wiki/XHTML2/pre_obsolete

---------------------------------------------------------------------
A conclusion is simply the place where someone got tired of thinking.
                                                      -- Arthur Bloc
---------------------------------------------------------------------
   Gregory J. Rosmaita - oedipus@hicom.net AND gregory@ubats.org
        Camera Obscura: http://www.hicom.net/~oedipus/
 United Blind Advocates for Talking Signs (UBATS): http://ubats.org
---------------------------------------------------------------------

Received on Friday, 18 September 2009 03:33:17 UTC