XHTML Role Module LC Comments (PR#8023)

<note
class="inTransmittal">
Reference:
http://www.w3.org/TR/2007/WD-xhtml-role-20071004/

Here are the Last Call comments on this draft from PFWG.

We would be glad to discuss them with you if anything is
unclear or contentious.

Al

/chair, PFWG

</note>

Having reviewed the XHTML Role Module draft of 4 October 2007, and
having tracked the draft's progress over the course of its development,
the PFWG is pleased to report that the document admirably suits the
PFWG's needs and concerns and provides several prominent illustrations
of how one can use the role extension model to create custom roles that
benefit accessibility.

Accessibility concerns and advice are woven into the woof and weave of
the XHTML Role Attribute Module, which is a model of integrating what
once may have been denigrated as "merely" accessibility concerns into
"mainstream" concerns -- not merely in the document's prose, but in
its examples, as well.


The XHTML Roles Module meets all of the PFWG's requirements, with the
exception of the following requests:


1. The addition of explicit markup, which is consistent across formats,
for including ARIA in HTML, XML, XHTML, and other XML-dialects and
specialized markup languages.  The PFWG has specified ARIA as a
cross-cutting technology, so the issue of embedding ARIA through the use
of the XHTML Role Module in a consistent, standardized manner -- no
matter what the format in which it is embedded -- is paramount;


2. The PFWG also notes that including "role" via the XHTML namespace
would not require changes to SVG, and could easily be (and, should be)
incorporated into SVG 1.2 Full (http://www.w3.org/TR/SVG12/)

However, there's no provision in the XHTML Role Module for a host
language to integrate it without using the XHTML namespace, whereas the
pre-Last Call drafts allowed bare-name integration.  According to
discussions with implementors of XML-based languages (especially in the
realm of specialized markup), the latter would be preferable. Therefore,
the PFWG would like to inquire why that was deemed impractical?


3. The PFWG requests the addition of the value of "title" to the list of
predefined roles

3A) Rationale:

  * Currently, there are predefined roles for "contentinfo", "main" and
    "secondary" -- why is there not a predefined role for title?  Title
    is a natural extension to the list of predefined roles -- for
    example, at the University of Illinois, Urbana-Champagne (UIUC) a
    tool has been developed based on a simple algorithm: H1 content is
    usually (or should usually be) a sub-string of the content of the
    TITLE element -- the UIUC tools look for that pattern, and if it is
    not found, it is flagged: for example, "H1 doesn't match TITLE" or
    "no H1 in document"; however, an author may have included the title
    in a level2 heading, or there may be text in the document that
    better titles the page than the contents defined for the TITLE
    element. Therefore, the algorithm is not hierarchical, but numeric
    -- if not H1, then H2, and so on.  No matter where the content
    which "titles" the document is in a heading or inline prose, the
    repair feature of the UIUC tool is predicated on the best practices
    rule that every document has an implicit H1 derived from its TITLE,
    no matter how the TITLE is defined -- using the TITLE element or
    through the use of the predefined role "title".


----------------------------------------------------------
ACCOUNTABILITY, n. The mother of caution.
                  -- Ambrose Bierce, The Devil's Dictionary
----------------------------------------------------------
          Gregory J. Rosmaita, oedipus@hicom.net
       Camera Obscura: http://www.hicom.net/~oedipus/
UBATS-United Advocates for Talking Signs: http://ubats.org
----------------------------------------------------------

Received on Friday, 26 October 2007 18:37:55 UTC