- From: Ian B. Jacobs <ij@w3.org>
- Date: Tue, 25 Sep 2001 19:20:56 -0400
- To: wai-tech-comments@w3.org
- CC: ij@w3.org
Hello,
Here are some preliminary comments (preceded by IJ:) about
the XML Accessibility Guidelines:
http://www.w3.org/TR/2001/WD-xmlgl-20010829
I'm glad to see this important document advancing. I think it
should be moved to the Recommendation track for at least two
reasons:
- It should undergo the same scrutiny and review as the
other WAI Guidelines. If it does not, it is likely that
people will refer to it as though it had the same standing
as the other WAI Guidelines, even if the authors warn against
this.
- It deserves the same status as the other documents and I think
it should be a core document on which the others depend. WCAG
should ask authors to use formats that conform to XMLAG.
UAAG should require that developers implement formats that
conform to XMLAG.
Sorry for the length of this email.
Thank you for your hard work,
- Ian
P.S. In a separate email, I suggested that future versions of this
document carry version number "1.0".
> XML Grammars, and The Scope Of XMLGL
>
> The XML grammars (called schemata - but see the caveat about our use
> of the term "schema" in the definition section) can be classified
> along two different axes:
>
> Data-oriented:
> Tagsets for: User Interface (UI)--oriented structural textual
> rendering, such as Docbook, HTML, MenuML, OEB, etc.;
> specialized rendering - for example MathML, Scalable Vector
> Graphics (SVG), MusicML, Synchronized Multimedia Integration
> Language (SMIL); or any generic data storage format. An
> informal definition is 'anything for which the question "is
> there a textual equivalent of all rich media data bits?" makes
> sense'.
IJ: I find this informal definition very problematic. First, the term
"textual equivalent" has not been defined yet, so I don't know that it
will be understood by a large audience (and even those closely
involved struggle over the definition of this term). Also, it's
not clear to me what "data-oriented" can be reduced to text.
Please clarify what is meant informally here.
> Data-centric schemata include both the interaction and
> behavioral aspects of an XML application.
>
> Metadata-oriented:
> When the content being marked up is metadata. Examples: For
> expressing data processing (for example XSL - Extensible Style
> Language), RDF (Resource Description Framework), Schema
> languages, etc.
IJ: The split is problematic since one person's metadata is another
person's data.
> According to this taxonomy, these guidelines only address
> Data-oriented schemata. This does not imply that there are not
> accessibility issues or features in a Metadata-Oriented schemata -
> see, for example, how XSLT, a component of XSL, can assist in Braille
> formatting. Since they do not convey end-user oriented data, however,
IJ: "end-user oriented data" is much closer to what I would have
expected, but even that's somewhat problematic. For instance, in UAAG
1.0, we a consider style sheet that cause the color blue to appear to
be content meant for humans (even though 'color : blue' is never read
by humans, only by the machine).
> Metadata-Oriented schemata are out of the scope of these guidelines.
> _________________________________________________________________
>
> Problem statement
>
> The WAI (Web Accessibility Initiative) has done extensive work in the
> HTML area, resulting in lots of new functionalities being added to the
> version 4.0 of the language (see the HTML4 Accessibility Improvements
> paper).
>
> These features includes:
> * Improved structure (such as fieldset, optgroup in form)
> * Support of separate Style Sheets
> * Better alternate content (required alt, longdesc, caption, etc)
> * Easier navigation (tabindex, link, etc)
>
> One area of concern with the advent of XML is that the freedom of
> design it bringshas and can result in a loss of accessibility
> features, present today because of HTML's pervasive presence and
> widely available specification.
>
> For instance, one could design a new XML language that would prevent
IJ: I think that "prevent" is too strong, notably since one might
still provide a secondary page for access. How about "make it much
more difficult?"
> the creation of accessible documents, by not including in the element
> or attribute set a way to attach an alternate textual description for
> a photo:
> <menu>New England Restaurant</menu>
> <appetizer>Clam Chowder
> <photo url="clam.jpg"/> <!-- no alt attribute or
> textual content model here -->
> </appetizer>
>
> In this example, the problem is not that the author of this document
> didn't put an alt attribute or textual equivalent attached to the
> photo element, it's that the designer of the language didn't put the
> attribute or the proper support in the language itself (that is, in
> the schema or the DTD).
>
> But let's start by defining what we mean by accessible schema and
> documents (Details on these definitions are provided at the end of
> this document):
> * An XML schema is accessible if it enables, and indeed actively
> promotes, the creation of accessible documents
> * A document is accessible if it can be equally understood by its
> targeted audience regardless of the device used to access it.
> An accessible document is also defined as conforming to the Web
> Content Accessibility Guidelines.
IJ: Please do not define an accessible document to be one that
conforms to WCAG. In all three WAI Guidelines, we have gone out of our
way to say that conformance DOES NOT equal accessibility. ATAG 1.0
says [1]:
"There will also be authoring tools that produce accessible content
in favorable circumstances (e.g., a text editor used by a motivated
author), or provide an accessible interface to authors with certain
disabilities, but that do not conform to these guidelines."
UAAG 1.0 says [2]:
"Note: Conformance to the requirements of this document is expected
to be a strong indicator of accessibility, but it is neither a
necessary nor sufficient condition for ensuring the accessibility
of software."
I would prefer that XMLAG (that seems to be the current short name for
this document) NOT rely on WCAG, otherwise the conformance
dependencies will be circular. I would like XMLAG to explain how to
build an XML format that supports accessibility. I would like WCAG to
require authors to use formats that conform to XMLAG (though WCAG will
also require more). I would like UAAG to require that developers
implement specs that conform to XMLAG. I imagine we will have more
discussions on this topic. In the development of UAAG 1.0, since we
did not have XMLAG, we require that developers implement
specifications that allow authors to conform to WCAG 1.0. But this is
an unnecessary indirection, I think.
[Please include references to all three WAI Guidelines in the
references section.]
[1] http://www.w3.org/TR/ATAG10/#Introduction
[2] http://www.w3.org/TR/UAAG10/conformance.html#Conformance
> As explained in the introduction, we're only considering Data-oriented
> languages here, and for them, the message is simple: be device
> independent and export your semantics as much as you can.
>
> While the priority is stronger on the first aspect (multi-modality),
> both aspects are important, as without the knowledge of the meaning of
> the XML elements and attributes, there is little chance that
> alternative user agents can do something intelligent with just the
> document bits.
IJ: As I read this I think that you need an introduction that explains
the expected processing model. The previous sentence would make more
sense if you explained how various user agents will interact, and some
things that an AT can do with semantically-rich content.
> This semantics knowledge can be provided through human readable
> documentation of course, but having machine readable assertions of
> semantics that can then be used to present the document in various
> media is paramount for pervasive access (that is, you don't need a
> programmer, you just need a program). Enabling others to map from your
> language to existing ones, or vice versa, is a useful accessibility
> feature.
>
> ICADD (International Committee on Accessible Document Design) was a
> pioneer in this topic,
IJ: Reference?
> for SGML accessibility and ways to convey
> arbitrary schema semantics (using specific SGML binding mechanisms). A
> few years later, ICADD has not really been adopted (in fact, the ICADD
> DTD was replaced by HTML and its well known semantics), and people are
> still trying to solve the same problem, albeit with more experience in
> the field of HTML accessibility, and applied to XML this time.
> _________________________________________________________________
>
> Guidelines for Designers of Data-oriented XML Tagsets
>
> This section provides a list of four guidelines, which are general
> principles of accessible design. Guidelines include rationale and
> checkpoints. Each checkpoint expresses a requirement, includes some
> informative text about the checkpoint and one or several Techniques,
> where implementations and examples of the checkpoint are discussed.
> Note that the checkpoints are not prioritized at that point.
IJ: I recommend that the structure of a guideline/checkpoint be
more formal, otherwise readers will have a hard time
distinguishing normative from informative parts. For instance, in
UAAG informative notes are identified as such. In XMLAG, there is
often an informative sentence or two after the checkpoint
text. If I were listening to the content, I would not know when
the informative material starts. Also, I think that it's useful
to distinguish rationale (i.e., why doing this helps people with
disabilities) from clarification of the checkpoint's intentions.
> * Guideline 1. Ensure that authors can associate multiple media
> objects as alternatives
> Web content providers must able to offer alternative versions of
IJ: To avoid confusion about what is normative, I recommend not using
"must" outside of a checkpoint requirement.
> their content if they wish to do so (as the Web Content
> Accessibility Guidelines tell them to do so). Textual
> alternatives, for instance, can be repurposed for many different
> output devices, whereas non-textual content is often confined to a
> certain set of devices. Thus, by allowing and encouraging
> synchronized textual alternatives, you allow your tagset to be
> more interoperable, and hence accessible.
IJ: The subject of the sentence shifts from "Web content developers"
to "you". [I prefer the impersonal form rather than "you".]
> 1.1 Provide a mechanism to explicitly associate alternative
> equivalents for content or content fragments.
IJ: Can "alternative equivalent" be reduced to "alternative"?
What is an alternative that is not equivalent? I might seek a
job as a computer scientist or alternatively as a doctor. These
are alternative careers that I wouldn't try to qualify as being
equivalent. In the context of XMLAG, are there any alternatives that
are not intended to be equivalent? If always intended as equivalents,
I recommend shortening to "alternative".
> Authors using the elements/attributes in your language
> must have the ability to provide alternatives for any
> content, be it images, movies, songs, running text,
> whatever.
>
> Techniques for 1.1
> For example, the summary and the caption elements in the
> XHTML table module can be used to provide a rich textual
> description of a non-textual media. cf. WCAG 1.0
> checkpoint 1.1.
>
> <table border="1"
> summary="This table gives some statistics about fruit
> flies: average height and weight, and percentage
> with red eyes (for both males and females).">
> <caption><em>Statistics</em> about fruit flies</caption>
> <tr><th rowspan="2"><th colspan="2">average
> <th rowspan="2">red<br>eyes
> <tr><th>height<th>weight
> <tr><th>males<td>1.9<td>0.003<td>40%
> <tr><th>females<td>1.7<td>0.002<td>43%
> </table>
>
> 1.2 Define flexible associations, where a given kind of
> relationship can link to or from objects of varying
> types.
> By flexible, we mean so that it is not constrained by the
> language itself.
IJ: Rather than use "flexible", I recommend stating the part about
constraints in the checkpoint. The indirection will lead to
confusion.
Furthermore, I think the requirement could be expressed more clearly,
but I don't have a proposal right now. I think that if the concept of
"alternative" is expanded on in checkpoint 1.1, then it may be reused
with more clarity in 1.2.. For instance, does 1.2 mean that
relationships between alternatives should be (1) explicit in markup,
not just in prose and (2) bi-directional? Add to this (3) allow rich
markup, (4) allow reuse, ...
> For example, HTML lets you add "alt" to
> images, but it does not let you add images to runs of
> text/markup, so people have to put up with less adequate
> mechanisms, perhaps by adding "see figure 1" at the end
> of a paragraph. If the content of <img> was other than
> empty, this would have solved the problem to some extent.
> Another way would have been to add an "appliesto"
> attribute to the <img> element, allowing you to put the
> associated image elsewhere in the document. Satisfying
> this checkpoint takes a lot of thought due to its
> subjective nature, but it's very important. For example,
> if <img> were non-empty, or if it had an appliesto
> attribute, it is probable that many more people would be
> associating images with text/markup runs.
>
> Techniques for 1.2
> In SVG, the desc element can be used to fully described a
> graphic, using structured text from a different tagset
> for instance, and in the graphics itself, the description
> text can be reused.
>
> <svg xmlns="http://www.w3.org/2000/svg" xml:lang="en">
> <g>
> <desc xmlns:mydoc="http://example.org/mydoc">
> <mydoc:title id="title1">The sales bar chart by region</mydoc:title>
> <mydoc:para>This description uses markup from the
> <mydoc:emph>mydoc</mydoc:emph> namespace.</mydoc:para>
> </desc>
> <!-- now the picture which includes text referencing the description
> -->
> <rect x="10" y="20" ...>
> <text x="100" y="200" font-size="15" fill="red" >
> <tref xlink:href="#title1"/>
> </text>
> </g>
> </svg>
>
> 1.3 Reuse existing accessible modules to indicate
> alternative-equivalent associations.
IJ: I think I prefer might be "accessibility modules" to
"accessible modules". I think it might be useful to preface
the requirement a little with something like:
"When building a format out of smaller modules, reuse
proven accessibility modules."
Why would one only be interested in reuse of modules related to
alternative equivalents? Are there other functionalities that benefit
accessibility (e.g., metadata) that might be reusable?
> Reusing accessible modules has the advantage of assuring
> that your "customers" can be confident that materials
> produced using your language will be accessible to their
> clients. No need to create "new" elements/attributes or
> re-invent the wheel just to satisfy some creative
> fantasy. There's a non negligeable cost for your authors
> (the people using your language) to learn new concepts.
>
> Techniques for 1.3
> This example shows how to use an existing DTD module: the
> object from the XHTML tagset
>
> <!DOCTYPE document SYSTEM "myDTD.dtd" [
> <!ENTITY % qnames
> PUBLIC "-//W3C//ENTITIES XHTML Qualified Names 1.0//EN"
> "xhtml-qname-1.mod" >
> <!ENTITY % object
> PUBLIC "-//W3C//ELEMENTS XHTML Embedded Object 1.0//EN"
> "xhtml-object-1.mod" >
> %qnames;
> %object;
> ]>
> <i:inventory xmlns:i="http://www.my.org/xmlns/inventory">
> <i:stockitem>
> etc.
> <xhtml:object...>
> to include a picture or movie of the part.
>
> * Guideline 2. Create semantically-rich languages
> Data-oriented XML should contain precise methods of encoding the
> data for its particular scope. By increasing the semantics of your
> tagset, and setting linking devices to outside presentations or
> further semantics, you allow your data to become "Webized" and
> hence to operate within many environments.
IJ: I think that the term "semantically-rich" needs more
explanation. For instance, HTML is rich in presentation semantics
(not really, but it's got presentation markup built-in). What
semantics are "good semantics" in terms of accessibility? Perhaps
that will be explained via the checkpoints below, but it would be
nice to have a model in my head as I go to read them.
> 2.1 Ensure all semantics are captured in markup in a
> repurposeable form.
> In general, languages must be designed so that they can
> be presented in a device independent way.
IJ: That's the sentence I was looking for. Can it be moved up
to the intro paragraph?
Similarly, "repurposeable form" doesn't satisfy me because I
don't know what the reference is. Repurposable with respect to
what? Probably input and output devices, and but there are other
axes as well such as spatially independent (don't make the user
have to use a mouse), temporally independent (don't require input
within a finite time interval), etc.
>Languages used
> only for presentation to a certain scope of users (that
> is, final form tagsets) should adhere to the following
> caveats:
>
> o They should not be promoted as being a generally
> suitable method of storing content that can be used
> across a variety of devices.
> o The server should make sure the client wants this
> particular form before serving it.
> o They should allow the authors to associate the final
> form with the higher level semantics of the source,
> whenever applicable.
IJ: I suggest making this a separate checkpoint (or part of 2.1),
as in:
2.x A format that represents information in a "final form"
that is device-dependent must:
a) allow the author to associate instances of the format
with source documents that are more semantically rich,
b) not be served without confirmation from the client
c) not be promoted as a suitable method of storing
information in a device-independent manner.
I think that it's probably a good idea to group checkpoints
according to their subject. For example:
1) An XML format must ... (most of the checkpoints in this
document). This can also be turned into "a developer of
a format must", but I don't think that's necessary. In UAAG
we say "a user agent must" and not "a UA developer must..."
2) An server of this format must ... (e.g., part of 2.1)
3) The create of the format must ... (e.g., checkpoint 3.1,
since it's about a default style sheet for the format, and
less about the elements of the format. I don't know whether
this distinction is useful: DTD/Schema-level requirements
versus specification-level requirements such as the default
style sheet.)
> Techniques for 2.1
> See the last paragraph of the XSL 1.1.1 section for an
> example of such wording.
>
> 2.2 Separate presentation properties using stylesheet
> technology/styling mechanisms.
> Authors must be able to mark up documents with proper
> structural elements and control presentation with style
> sheets rather than with presentation elements and
> attributes. This separation of content from presentation
> facilitates the adaptation to users with different
> presentational needs (larger font, better contrast, etc)
> and it also facilitates the maintenance of the
> pages.
> Techniques for 2.2
> Example: Wrong
>
> Do not include presentational attributes and elements in
> your language.
>
> <p align="center" font="arial" weight="bold">News items 1</p>
> <p align="center" font="arial" weight="bold">News items 2</p>
> <p align="center" font="arial" weight="bold">News items 3</p>
>
> Example: Right
>
> Support the inclusion and processing of external style
> sheets.
>
> mystyle.css: .news { text-align: center; font: bold arial }
>
> <?xml-stylesheet href="mystyle.css" type="text/css"?>
> <p class="news">News items 1</p>
> <p class="news">News items 2</p>
> <p class="news">News items 3</p>
IJ: As I understand the benefits of style sheets:
a) Most of the benefits are for authors (e.g., factorization,
reuse, caching, performance improvements, etc.).
b) The primary (only?) user benefit is the ability to override
author-specified styles. CSS builds this in. XSL does not.
I don't think that the example shown is that relevant
(other than it shows style sheets) because it doesn't say
how the user can override the authors' styles.
> 2.3 Use the standard XML linking and pointing mechanisms (XLink
> and XPointer).
> XLink and XPointer have been reviewed for accessibility
> and provide known linking and pointing mechanisms.
IJ: Change "and provide known linking and pointing mechanisms" to
"and their linking/pointing semantics may be recognized with certainty."
> Techniques for 2.3
> Example. Wrong
>
> User Agents have no way of knowing this is a link.
>
> <mylink
> linkend="http://mysite/myfile.xml">
> Current list of references
> </mylink>
>
> Example: Right
>
> Links can be recognized reliably by XLink
> applications.
IJ: Yes, that's what I mean.
> <crossref xmlns:xlink="http://www.w3.org/1999/xlink"
> xlink:href="http://mysite/myfile.xml">
> Current list of references
> </crossref>
>
> 2.4 Define element types that allow classification and grouping
> (header, section, list, etc).
> Make use of existing mechanisms (noting checkpoint 1.2),
> or create them where necessary, following these
> guidelines. Ensure that elements are present which can
> then be used for classification and grouping.
IJ: Delete the sentence starting with "Ensure" (I don't think it
adds any information). I think the previous sentence can be
reduced to a cross reference to a general reuse checkpoint.
> Techniques for 2.4
> Think about the overall structure of your documents when
> you design a tagset.
IJ: I don't think that the previous sentence is very useful.
Format designers always think about what they are doing. They may
not think about it the way you want them to. What do you want
them to think about?
> <-- menu - highest level block element
> appetizer - first child of section, major block element
> entree - second child of section, major block element
> entity meal-sequence - common paragraph level blocks -->
> <!ELEMENT menu (title , ((%meal-sequence;)| appetizer)+)>
> <!ELEMENT appetizer (title? , ((%meal-sequence;) | entree)+)>
>
> 2.5 Provide for a full containment model with chunks of
> reasonable size.
> If a document instance is fully contained, i.e. adequate
> wrapper elements around PCDATA, then both CSS and XSLT
> can be used to style content for presentation in
> alternate formats. If content is in reasonable sized
> containers, it enables the document to be skimmed quickly
> by non- visual readers. If a logical hierarchy of
> elements is used, then a table of contents or summary may
> be generated providing logical access to document
> content.
IJ: This checkpoint is hard to understand. I'm not sure I
understand what a full containment model is. Also, please try to
be more specific than "chunks of a reasonable size."
If I understand, there is an art to designing a format so that
there is "just enough markup in just the right places." You don't
want long stretches of text without any surrounding structure.
And you don't want to require the author to use tags left and
right (I don't know whether a million tags always benefits ATs
either, but I don't have data to back that up). If this is the
thrust of the checkpoint, I think it could be clearer.
Do you have any advice about the accessibility issues around
mixed content models?
> Techniques for 2.5
> In this XML Schema example, a document is broken up into
> a number of sections, and a sequence of nestable sections
> with a consistent structure may be used for both
> navigation and the automated generation of a table of
> contents to whatever level.
>
> <xsd:schema xmlns="http://www.publishing.org"
> xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">
> <xsd:element name="document">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element ref="head"/>
> <xsd:element ref="section"/>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
> <xsd:element name="head" type="xsd:string">
> <xsd:annotation>
> <xsd:documentation>Section title</xsd:documentation>
> </xsd:annotation>
> </xsd:element>
> <xsd:element name="section">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element ref="head"/>
> <xsd:element ref="section"/>
> <xsd:element ref="paragraph" maxOccurs="unbounded"/>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
> <xsd:element name="paragraph" type="xsd:string"/>
> </xsd:schema>
>
> 2.6 Define element types that identify important text content.
> Within most documents, certain elements are key to its
> understanding. If these are both clear, and identified
> for machine access, their content can be presented to a
> user to gain a swift understanding of the semantics of
> the element, section and eventually the whole document.
IJ: I'm not sure that "important" will be helpful to
designers. In UAAG 1.0, checkpoint 2.3, we decided that we would
gain more by being more specific, so we refer to "summary, title,
alternative, description, or expansion of another piece of
content". In 9.9, we do refer to "navigation of important
structural elements". This kind of vague requirement should be
made with caution (though I'm happy that there is consistency
between UAAG and XMLAG language). Here's an attempt to state
when content is *important to accessibility*.
a) A piece of content A is important if the semantics of the
format explicitly designate it as important. For instance, in
HTML, <strong> and <em> call out the fact that some content is
important. Of course, a <table> may be very important, but the
semantics of importance are not part of the specification.
b) Content A is important if it would allow a user to
understand another piece of content B more quickly. Thus,
titles, summaries, and descriptions are important.
Note: These things are important to *accessibility* for
reasons of orientation. Content may be important for
other reasons (e.g., tables are important for associating
data).
c) Content A is important to accessibility if it is
identified by specification to be an accessibility feature.
These are just some ideas on being more specific about what
is important.
> Examples of such important elements are numbers, dates,
> titles and links.
>
> Techniques for 2.6
> Mark up your text with more semantics, such as saying
> "this is a date", or "this is an acronym".
IJ: This is confusing. It sounds like the author should be using
those English words. Rather: "Use markup for datatypes where
available."
> Code example: Using the XML schema language to identify
> data types, rather than simply leaving them as strings: a
> fully constrained ISBN number:
>
> <xsd:simpleType name="ISBN-Type">
> <xsd:restriction base="xsd:string">
> <xsd:pattern value="\d{5}-\d{5}-\d{5}"/>
> <xsd:pattern value="\d{1}-\d{3}-\d{5}-\d{1}"/>
> <xsd:pattern value="\d{1}-\d{2}-\d{6}-\d{1}"/>
> </xsd:restriction>
> </xsd:simpleType>
>
> 2.7 Provide a mechanism for identifying summary / abstract /
> title.
IJ: I think this checkpoint is more helpful since more specific.
Can it be combined with 2.6?
> Knowing how to extract that information allow User Agents
> to present it to the end-user, thus facilitating browsing
> of the content (e.g. deciding if yes or no the document
> is of interest).
>
> Techniques for 2.7
> Example: XML using RDF and Dublin Core well known
> semantics.
>
> <someElement xmlns="http://xmlns.com/example">
> <rdf:RDF
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> xmlns:dc="http://purl.org/dc/elements/1.1/">
> <rdf:Description about="http://www.dlib.org/">
> <dc:Title>
> D-Lib Program - Research in Digital Libraries
> </dc:Title>
> <dc:Description>The D-Lib program supports the community of
> people with research interests in digital libraries and
> electronic publishing.</dc:Description>
> <dc:Publisher>
> Corporation For National Research Initiatives
> </dc:Publisher>
> <dc:Date>1995-01-07</dc:Date>
> <dc:Type>World Wide Web Home Page</dc:Type>
> <dc:Format>text/html</dc:Format>
> <dc:Language>en</dc:Language>
> </rdf:Description>
> </rdf:RDF>
> <!-- .....other xml.... -->
> </someElement>
>
> 2.8 Don't overload the semantics of individual elements.
IJ: Change "individual elements" to "each element type." And use
"element type" instead of "element name" below. [I may be wrong
here - perhaps "element name" is correct, in which case it should
be used consistently.]
> If an element name may be confused, within the context of
> the document instance, then it is said to be overloaded.
> If each element name is unique within context
> it is
IJ: What does "within context" mean and what is the relation to
namespaces?
> easier to access the document semantics. Note the
> relation to checkpoint 4.9.
>
> Techniques for 2.8
> Example: Wrong
>
> <report>
> <invoice>
> <amount>25 dollars</amount>
> ....
> </invoice>
> <description>
> <item>Widgets</item>
> <amount>25</amount>
> </description>
> </report>
>
> In the example above, the designer of the schema intended
> the first occurrence of the element "amount" to mean
> 'price' of the products purchased and the second
> occurrence to mean 'quantity' of the products purchased.
>
> Example: Right
IJ: I think I prefer "Incorrect example" and "Example", and it's
probably better to put the "Example" before the "Incorrect
Example" as much as possible -- that way people arrive at the
right thing to do first.
> <report>
> <invoice>
> <price>25</price>
> <currency>Dollar</currency>
> ....
> </invoice>
> <description>
> <item>Widgets</item>
> <quantity>25</quantity>
> </description>
> </report>
>
> In the example above, the meaning of all the elements is
> clear and none of the individuals elements is overloaded.
>
> 2.9 Reuse accessible modules from schemata as originally
> specified / intended.
> When using modules from other schemata, use them with the
> same semantics as originally intended.
IJ: I suggest merging this checkpoint with 1.3: "Reuse modules,
and reuse them appropriately."
> Techniques for 2.9
> Example: reusing SMIL switch
>
> ...
> <par>
> <video src="anchor.mpg" ... />
> <switch>
> <audio src="HiQuality.wav" systemBitrate="56000" ... />
> <audio src="MedQuality.wav" systemBitrate="28800" ... />
> <audio src="LowQuality.wav" ... />
> </switch>
> </par>
>
> 2.10 Allow association of metadata with distinct elements and
> groups of elements.
> This permits authors to make even more semantic
> associations than what was originally intended by the
> language designer.
IJ: There are several options here:
1) The author has metadata associated with some content A, and
the content A is unaffected.
2) The author references the metadata from A (so A "knows about
it").
3) The author includes the metadata directly in A.
Which mechanisms does 2.10 mean to address? From the prose
description, I understood 3 only.
> Techniques for 2.10
> In SVG for instance, there is a metadata element where
> RDF statements can be declared, pointing at graphical
> elements and adding more relational semantics (one object
> linked to another, or on top of another) than what is
> provided by SVG itself. See the SVG Accessibility note
> for examples.
IJ: Please include the SVG Accessibility Note in the references
sections.
> * Guideline 3. Design an accessible user interface.
> Web content is rapidly shifting from static pages to dynamic
> pages, called Web applications. This is most often done using a
> scripting language based on event callback. The language designers
> must ensure that the model they chose allows for user control of
> presentation. Always ensure that nothing in the presentational
> aspect of the document attempts to restrict user control of how
> the document instance is accessed.
IJ: Much of the previous paragraph sounds like a list of
requirements, rather than rationale that explains the
accessibility issues.
> 3.1 Provide default style sheets for multiple output modalities
> where possible.
>
> The additional effort from the language designer point of
> view in providing stylesheets which can represent an XML
> document instance in alternate modalities is minimal and
> will have a multiplier benefit for all the authors using
> the language and these style sheets. Readers of your
> documents may prefer audio access, so providing an
> appropriate stylesheet with your schema which will allow
> those readers to utilise synthetic speech to produce a
> clear rendering of the content.
>
> Techniques for 3.1
> Example: See the sample style sheet for HTML 4.0 provided
> with the CSS2 spec,
>
> 3.2 Define navigable structures that allow discrete, sequential,
> structured, and search navigation functionalities.
> Navigable structures are the key elements used for
> navigation around an XML application. Define element
> types that allow classification and grouping, or re-use
> existing accessible grouping and classification modules.
>
> Techniques for 3.2
> Example: See how the Digital Talking Book DTD provides
> elements for navigable structures.
IJ: I think that you'll need to explain the different navigation
functionalities in more detail (e.g., discrete v. sequential).
> 3.3 Use CSS or XSLT to describe a basic outline view.
IJ: Presumably, the outline view will be based in part on some of
the "important" elements (or more specifically "title"-like
elements) discussed in earlier checkpoints. I recommend a cross
reference and harmonization of the terms/expressions used to
describe the elements.
> The language designer is the best placed to provide a
> mapping of the new language constructs to a basic outline
> format, which will facilitate the deployment of content
> by making it understandable for all classes of users.
>
> Techniques for 3.3
>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> version="1.0">
> <xsl:output method="html"/>
> <xsl:template match="/">
> <html>
> <head>
> <title>Outline of x</title>
> <body>
> <-- This provides the link back to the full source document -->
> <a href="source.xml">full source of document</a>
> <h3>Outline view</h3>
> <p> <xsl:for-each select="//section">
> <xsl:number level="multiple" count="section" format="1.1.1"/>
> <xsl:value-of select="title"/>
> <br />
> </xsl:for-each>
> </p>
> <xsl:apply-templates/>
> </body>
> </html>
> </xsl:template>
> <xsl:template match="*"/>
> </xsl:stylesheet>
>
> 3.4 Use a device-independent interaction and events model /
> module.
> Any XML application which contains user interaction may
> exclude readership if presumptions are made about the
> technology used to access that application. What happens
> when the application only support mouse interaction, and
> the user is not mouse bound?
IJ: I don't recommend asking a rhetorical question here, but
explaining the issues to the reader.
> The result could be lost
> sales, it will be a loss of interest and a search for
> alternatives.
>
> Techniques for 3.4
> Using DOM2 event the right way in SVG.
>
> <script> function DoOnActivate(evt) { .. } </script>
>
> <g onactivate="DoOnActivate(evt)">
> <rect id="button" x="500" y="500" width="250" height="40"/>
> </g>
>
> 3.5 Allow for user control of interaction timing - rate of
> change, external events triggering document changes,
> etc.
IJ: I think this checkpoint needs more work. It's not clear
what "interation timing" means. There are a lot of technical
details like: events that are synchronized with the wall clock,
events that are driven by the user, events that are synchronized
relative to other presentation events, etc. I think more
explanation is required.
> If an XML application presumes that all readers will take
> in content in a fixed time period, will read at a certain
> rate, or access each page in a certain time, then readers
> and users of that application will be lost. We each do
> things in our own time, and dislike being dictated to.
>
> Techniques for 3.5
> Ensure and promote the work the user agent has to do to
> control - on behalf of the end-user - the rate of change
> of content presentation, perhaps using element attribute
> for pause facility orr settable rate to allow the user
> control of all interactions. Fixed time period time-outs
> are not popular. See the SMIL-Animation specification for
> examples of such design.
>
> * Guideline 4 Document and export semantics
> Make sure that all people can understand your design and
> map to and from your elements, and easily make assertions
> about them.
IJ: I don't think that you can guarantee that all people will
understand something. Also, I'm not sure what mapping to
and from means. Please clarify the intent of this first sentence.
> Furthermore, make sure that you provide your own first party
> assertions about your languages: for example, don't make users
> guess an element's purpose.
>
> 4.1 Ensure human-readable documentation conforms to WCAG double
> A.
> Everybody should be able to read and understand a
> technical specification, even one that is purely intended
> for a particular class of users.
IJ: I think it's overstating the issue to say that "everyone
should be able to understand a technical spec." I think that it's
one thing to write a document clearly for a particular audience,
and it's another to write related material for different
audiences. I don't think that XMLAG should set the expectation
that every piece of documentation must be usable by every person.
It may be sufficient to say "Write clearly, and provide materials
for different audiences and different reading skills."
By the way, the sentence (which is about comprehension) doesn't
line up with the requirement (which is about accessibility).
> Techniques for 4.1
> For instance, blind users routinely author Web content
> that is intended for sighted users, and they can do so
> because the HTML and the CSS specifications are
> accessible (well structured, description of pictures,
> etc).
IJ: Hey, thanks! <grin>
> 4.2 Provide a machine-understandable means/mechanism to get from
> a document instance to the schema.
IJ: What about DTDs?
How about
"4.2 Provide a machine-understandable means/mechanism
to retrieve the formal grammar (e.g., schema or DTD)
used to structure content."
I wanted to say "identify" instead of "retrieve", but the
next sentence explicitly mentions automatic retrieval. It
may be good to require 'identification' of the formal grammar
in either a machine-readable or human-readable form. And
machine-readable form for automatic retrieval.
> This allows programs to automatically retrieve the
> documentation of a language.
>
> Techniques for 4.2
> Example: Uses the W3C XML Schema language as the schema,
> referencing it via the xsi:schemaLocation attribute.
>
> <?xml version="1.0" encoding="utf-8"?>
> <my:doc
> xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
> xsi:schemaLocation="http://www.example.org/schemas/doc.xsd"
> xmlns:my="http://www.jenitennison.com/"
> xmlns="http://www.w3.org/1999/xhtml">
>
> 4.3 Provide explicit human readable definitions for markup
> semantics.
IJ: I'm not sure what this checkpoint means. Does this mean
"Write documentation?" If the format developer writes no
documentation, the format will probably be useless (or at least
not easy to use). Does this mean "Write human-readable, not just
machine-readable" documentation? Does this mean "Write *good
documentation* where the semantics of each element is made
explicit?"
> Any schema which is designed by a single person in a
> reasonable period
IJ: What does "in a reasonable period" mean?
> will only be understood by that person
> designing it. When exposed to document authors,
> interpretations will vary. If the schema designer wishes
> document authors to utilise the same semantics then those
> semantics require documentation. The better the quality
> of that documentation, the more likely the shared
> understanding.
>
> Techniques for 4.3
> Example: TREX
>
> <element name="paragraph">
> <xsd:annotation>the lowest level block container.</xsd:annotation>
> <empty/>
> </element>
>
> 4.4 Use schema (in preference to DTD) to provide explicit
> documentation/annotation of element/attribute/etc
> semantics.
IJ: Use "schemas" or "schema"? Can 4.3 and 4.4 be merged?
It sounds like 4.4 supersedes 4.3 the way they are written.
> Schema allows the language designer to explicitly attach
> documentation to elements and attributes, thereby making
> the language more understandable.
>
> Techniques for 4.4
> Example: The need for the head element is clearly
> described.
>
> <xsd:element name="head" type="xsd:string">
> <xsd:annotation>
> <xsd:documentation xml:lang="en-US">Title of the section.
> Required for table of contents generation.
> </xsd:documentation>
> </xsd:annotation>
> </xsd:element>
>
> 4.5 Provide semantic relationships to other schemata where
> appropriate and possible.
IJ: Pick one form and stick to it (schemas/schemata). [Maybe you
already do. This just occurred to me as a thing to watch for.]
I'm not sure what "provide semantic relationships" means.
Does this checkpoint mean: "When you create a schema, you should
think about explaining how it relates to other schemas
(preferably expressing the relationships with a machine-readable
format)." Or does the checkpoint mean: "You will benefit the
world by showing how different schemas relate." When the
checkpoint says "to other schemata", you mean other than what?
> This allows the authors using the language to reuse their
> existing knowledge and tools.
>
> Techniques for 4.5
> This can be done implicitly via subclassing/derivation of
> existing types, by asserting equivalence of type (e.g.
> SVG title and SMIL title) or by mapping to well known
> semantics.
> Example: mapping the Menu example provided in the
> Introduction to XHTML using XSLT:
>
> <html xsl:version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> xmlns="http://www.w3.org/1999/xhtml>
> <head>
> <title>Mapping of language MenuML to html</title>
> <body> <h1>Menu of: <xsl:value-of select="menu/"/></h1>
> <h2>Appetizer: <xsl:value-of select="menu/appetizer/"/></h2>
> etc...
> </body>
> </html>
>
> 4.6 Document accessibility features of the application.
> This is useful in order to foster the development of
> state of the art assistive technologies to identify all
> the features of a new language that make it more
> accessible.
>
> Techniques for 4.6
> SVG has provided a good example of this being a part of
> the recommendation. For W3C Working drafts, include and
> document those specific features which positively aid
> accessibility.
>
> 4.7 Include accessibility requirements in conformance
> requirements
> This promotes the development of accessible content in
> the community caring about conformance.
>
> Techniques for 4.7
> SVG has specific accessibility requirements as a part of
> the overall requirement document. When the requirements
> are drawn up, specific clauses need to be included which
> clearly state accessibility requirements
>
> 4.8 Document techniques for WCAG, ATAG, and UAAG with respect to
> the XML application.
I recommend instead: "In the format documentation, explain how
the requirements of WCAG, ATAG, UAAG, and XMLAG apply to the
format." My only concern is that if XMLAG refers to UAAG etc.,
this may create a circular dependency. I'll have to think about
this.
> The WAI suite of accessibility guidelines (WCAG, ATAG,
> and UAAG) contain detailed descriptions as to how to
> satisfy each individual document's requirements.
> Therefore, it is important to review your XML application
> to ensure that you have implemented a relevant technique
> for each checkpoint in the WAI suite of accessibility
> guidelines. For example, you could show how a
> (hypothetical) instance of your application conforms to
> WCAG, how an authoring tool which implements your
> application would enable an author to create accessible
> content; how a user agent capable of supporting your
> application must conform to UAAG, etc.
>
> Techniques for 4.8
> Still using the MenuML language, here are examples of
> WCAG techniques
>
> o WCAG checkpoint 1.1: Provide a text equivalent for every
> non-text element
> MenuML technique: use the content of the photo element
> to indicate the textual equivalent of the picture.
> o WCAG checkpoint 3.5: Use header elements to convey
> document structure and use them according to
> specification.
> MenuML technique: use the appetizer element to introduce
> a new appetizer, not a para and some bigger font
>
> 4.9 Do not assume that element or attribute names provide any
> information about element semantics.
IJ: To whom is this checkpoint addressed? Who should not assume
this? The user of the format spec (whether author or tool
developer)? Please clarify this (possibly grouping this
checkpoint with others related to format consumers).
> An element named may have a fully contextualized meaning
> for the schema author, but is unlikely to mean much to a
> non-English speaker. Equally, taken out of context,
> without semantic explanation, element names often lose
> their meaning. Simply naming an element is not enough to
> assure that document authors will utilise that element in
> semantic conformance with the schema authors intent. It
> is likely that confusion and misinterpretation will arise
> if element or attribute names are relied upon to document
> a schema.
>
> Techniques for 4.9
> For example, using TREX, avoid colloquial element names.
>
> Example: Wrong
>
> <element name="paragraph">
> <xsd:annotation>
> <xsd:documentation>paragraph</xsd:documentation>
> </xsd:annotation>
> <empty/>
> </element>
>
> Here the element name has been described using the
> element name only, which adds no semantic value.
>
> Example: Right
>
> <element name="paragraph">
> <xsd:annotation>
> <xsd:documentation>The lowest level block container.
> </xsd:documentation>
> </xsd:annotation>
> <empty/>
> </element>
>
> Here the element name has been described in an alternate
> form to clarify semantics rather than re-enforce the name
> by repeating it.
>
> 4.10 Document navigable structures. Describe how discrete,
> sequential, structured, and search navigation mechanisms
> should work
> In order to navigate around a significant document, it is
> helpful to the reader if they know what elements are
> available for such navigation.
>
> Techniques for 4.10
> Random access to any part of a document via a detailed
> table of contents, numbered headings which may be
> searched for, a hierarchical view enabling fast access to
> sought parts, and a search capability aid in this.
> _________________________________________________________________
>
> Appendices
>
> Appendix A: Techniques Rationale
>
> In the presentation of guidelines for XML accessibility, we try to
> separate abstract guidelines from implementation techniques. This
> allows us to talk about the general guideline principles without
> spending the time up-front to solve the implementation issues.
>
> In fact, there are several techniques for achieving the same result
> and people's decision will be a function of time and product available
> and their own commitment to access.
>
> For instance, if an XML designer want to create some kind of "list"
> element in a given markup, this can be implemented using various
> techniques:
> * using the XHTML namespace and its [INS: elements :INS] (xhtml:ul,
> xhtml:li)
> * invent new constructs but provide an XSLT binding (to a HTML UL/LI
> pair of element)
> * using XML/RDF schemata (if a list primitive is available; or
> through a new schema if a primitive is unavailable)
> * using Architectural forms with support for list semantics
> * etc
>
> Appendix B: XML Accessibility Definitions
>
> * Schema: Even though we use the term "schema", we don't want people
> to assume we are only talking about a schema as defined in XML
> Schema but rather some document or collection of documents which
> contains all the references for interpreting a document which is
> encoded in accordance with the usage of some application or
> community of discourse. "Profile" might be a better word for our
> usage.
> * An XML schema is accessible if it enables and actively promotes
> the creation of accessible documents
> * A document is accessible if it can be equally understood by its
> targeted audience regardless of the device used to access it.
> An accessible document is also defined by conforming to the Web
> Content Accessibility Guidelines.
IJ: I don't think these definitions work. I prefer not talking
about "what is accessible", but instead "what conforms to this
document". This document promotes accessibility, by meeting known
user needs. I think you should delete the definitions and just
refer to conformance.
> * The word "promote" is important as "enable" alone does not cover
> the case where a schema could include some open string
> representation somewhere and claim minimal accessibility.
> To take an example, suppose HTML didn't have an ALT attribute on
> IMG, it would still in theory "enable" the creation of accessible
> documents, since HTML files carry textual content and one could
> always describe images inline, as in: <IMG SRC="Tax.gif"> How to
> pay your taxes but this doesn't "promote" accessibility as most
> authors will not want to repeat "How to pay your taxes" if the
> logo already says "How to pay your taxes" (assuming CSS cannot be
> used for that instead of a bitmap). Having the ALT attribute
> "promotes" accessibility as it allows images to be described
> without performance loss - such as duplication - for image viewer.
> In any case, accessibility is not just about alternative content,
> as the next section will show.
> * The word "device" is also important as it encompasses more than
> just media independence: it's both output (graphical, voice,
> braille, text-only) and input (mouse, keyboard, voice, keypad,
> one-touch).
> This term also potentially carries with it the issues related to
> high bandwidth availability (or lack thereof), where access to
> data becomes impossible on slow connection because of their
> volume.
> * The term "equal understanding" is critical as it permits some form
> of graceful transformation when presenting in one media content
> primarily designed for another media.
> Graceful transformation is a key concept in the area of
> accessibility. Let's define it.
IJ: Don't say "Let's define it". Just define it.
Also, the term graceful transformation doesn't appear elsewhere
in the document. I recommend avoiding it if you can. The document
already talks specifically about device-independence. Is that
sufficient?
I don't think "graceful transformation" is a bad concept, but if
you don't use it, it seems best to not define it.
> Definition:
> Graceful transformation is a property of a system that can still
> function relatively error free when the system is damaged or when
> the input stimuli are incomplete. In such systems, removing a
> symbol token only results in the loss of the information stored in
> that token, with no abrupt performance decline of the overall
> process.
> For instance, suppose I need to check the online yellow line train
> schedule and I don't have visual access to the Web. If the train
> Web site uses a yellow wagon animated icon to point me at the
> schedule, and does not provide a label somewhere saying that this
> is for the yellow line, thus only relying on my capacity to see
> the color, I suddenly cannot understand this site: it does not
> transform gracefully.
> If the schema designer hasn't provided a way to attach alternate
> content to some rich piece like an animated yellow wagon, the
> content provider will not reach all of his/her audience with this
> information.
> Suppose now in a different page this Web site provides a nice
> clickable 2D map with all the stops and ask me to select my start
> and destination. If a simple list of the line stops is provided in
> textual form, it does transform gracefully: it's not as fast as a
> couple of mouse clicks, so there is some "degradation" in the
> system, but a user reliant on text can obtain the information.
> * Another aspect of "understanding" is that in order for a User
> Agent to make sense and gracefully transform the content of an
> arbitrary schema-based document some semantics have to be
> disclosed. By reusing or binding a priori unknown
> elements/attributes to well know ones (in XML core or HTML), this
> is achievable.
IJ: Please refer to the definition of "recognize" in UAAG 1.0,
rather than use the term "understand".
> Appendix C: Acknowledgments
> In addition to the editors, the following WAI Protocols and Formats
> Working Group (PF) participants have contributed directly to the
> content of this document:
>
> Kynn Bartlett , Geoff Freed, Al Gilman, Vijay Gummadi, Ian Jacobs,
> Chris Lilley, William Loughborough, Charles McCathieNevile, Dave
> Pawson, Gregory J. Rosmaita, Aaron Swartz and Carlos A. Velasco.
>
> Appendix D: References
IJ: Please add references to the other Guidelines documents and
please mark up references in a style consistent with other W3C
technical reports (e.g., check out how UAAG 1.0 references are marked
up).
> * W3C WAI Home page
> * WAI PF Home page
> * W3C XML Home Page
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
Received on Tuesday, 25 September 2001 19:21:16 UTC