<note
class="inTransmittal">
Thank you for letting us take a little extra time
to comment on this draft.
The following comments have been supported by a rough
consensus in the Protocols and Formats WG.
We would be glad to discuss anything here that is
unclear or not convincing with you at your convenience.
Al
/chair, PFWG
</note>
1. Potential of the technology
RDFa in XHTML (http://www.w3.org/TR/2008/WD-rdfa-syntax-20080221/)
has potential for accessibility and Web users with disabilities by
allowing authors to mark core information on their web pages in a
machine-readable manner. Assistive technology can use this
information in their interacting with the user, and thus make access
to information faster or possible where it would be cumbersome or
impossible for the user otherwise.
A couple of sample use cases:
A screen reader telling the user the telephone number of an online
shop web page when the user has problems finishing the transaction.
A schematic diagram illustration of the core content of a web page,
for example such as offered by SWAPviews from UB Access (http://
www.ubaccess.com/swapviews.html). This can be helpful for some
people with cognitive disabilities.
2. Potential problems of the technology wrt accessibility
2.1 Processing described for static information only (section 5)
RDFa in XHTML seems to be scoped for static information only, and the
processing model is described for a static DOM that does not account
for dynamic changes after the document has been loaded. (Cf. first
sentence in 5.5: “Processing would normally begin after the document
to be parsed has been completely loaded”.) This processing model
seems restricted with regard to Web 2.0 applications that dynamically
add or remove information while interacting with the user. Has the
use of RDFa for dynamic information in XHTML pages been considered?
2.2 Issues with @content (section 6.3.1.1)
@content may be used to indicate a plain literal which would
overwrite the element content for RDF generation purposes.
(a) What is the rationale for having the @content value replace the
element content in terms of RDF statements? Why not make the
@content value an alternative object in the statement (with the
element content being the other alternative object)? - This would
give the end user the option to choose between the two alternatives.
(b) The use of @content bears the drawback that its value cannot be
marked up. The most prominent need for markup of text for assistive
technology is the indication of language. The spec addresses this
issue (section 6.3.1.1.1) by making a sibling @xml:lang reign over
@content. However, this does not solve the problem of language
changes inside the @content value (foreign words). We propose to
add a note that warns about the drawback of @content with regard to
marking up foreign words within its value, and recommend using the
(marked-up) element content instead of @content, wherever possible.
2.3 Use of <base> element
The use of an element to denote this information (a property that
applies
"hereafter") seems to leave the end of the scope of the base information
un-marked. This is one of the problems of "tag soup" that XML is
supposed
to fix.
It would appear that this information should be denoted in an attribute.
Please explain why xml:base does not meet the need here.
2.4 Use of CURIEs (section 7)
While the use of CURIEs is convenient for the author, the procedure
of resolving CURIEs to full URIs makes the code for parsing and
generating the RDF graph more complex. Assistive technology often is
developed with little resources and often comes with small footprints.
2.5 RDFa in HTML documents
This specification does not address using RDFa in HTML documents
(only for XHTML documents). While most of the specification could
also be applied to HTML documents, the mapping of CURIE prefixes will
have to be rewritten for HTML documents (since there is no namespace
concept in HTML).
This and the complexity problem mentioned in 2.4 make us wonder if
the concept of CURIEs should be modified to not use the “xmlns:
[prefix]” attribute for prefix mapping. Have you considered
alternatives that would allow a consistent use of RDFa in HTML and
XHTML documents? From the perspective of accessibility, consistency
between HTML and XHTML documents should be a goal of the specification.
3. Typos
Section 3.8: “this this”
E. Acknowledgments: “This section is informative.” appears twice.
