- From: Ian B. Jacobs <ij@w3.org>
- Date: Tue, 17 Sep 2002 23:46:36 -0400
- To: Charles McCathieNevile <charles@w3.org>
- CC: WAI Cross-group list <wai-xtech@w3.org>
Charles McCathieNevile wrote:
> I am very pleased to announce the publication of a new Editors' draft of XML
> Accessibility Guidelines...
>
> The new draft is available at http://www.w3.org/WAI/PF/XML/xag-20020915 and
> is what you currently get from the "latest version" URI -
> http://www.w3.org/WAI/PF/XML
Hi Charles,
Thanks for publishing this new draft. Below I make some
very substantial comments.
Summary:
a) Some checkpoints are far too general. I think it's
far preferable to have a few specific checkpoints
for known cases (that catch most of the common cases
and a few edge cases) than a single overly broad
(and unverifiable) checkpoint. Some of my comments below
suggest replacement checkpoints based on this observation.
b) XAG should support the requirements of the other
guidelines; I'm not sure that all of the WCAG, ATAG,
and UAAG requirements are supported here. I recommend
documenting:
- How each WCAG, ATAG, and UAAG requirement is supported
here.
- Which XAG requirements are not mentioned in other
guidelines documents.
c) I recommend considering the UAAG 1.0 chapter one [1]
as a model for the XAG introduction. Below I
suggest some changes that will turn the XAG
introduction into something like this:
* 1.1 Relation to WAI accessibility guidelines
* 1.2 Target user agents
* 1.3 Known limitations of this document
* 1.4 Relation to general software design guidelines
and other specifications
* 1.5 Security considerations
[1] http://www.w3.org/TR/2002/WD-UAAG10-20020821/intro
d) I don't make any substantial comments about techniques
other than the following: I'd prefer it if the "right
way" were shown to the reader before the "wrong way".
Thank you for considering these suggestions,
- Ian
==========================================================
|XML Accessibility Guidelines [EDITOR draft]
|
|W3C Working Draft 15 September 2002
|
| This Version:
| http://www.w3.org/WAI/PF/XML/xag-20020915
|
| Latest Published Version:
| http://www.w3.org/TR/xag
|
| Latest Editor Draft:
| http://www.w3.org/WAI/PF/XML
|
| Previous Version:
| http://www.w3.org/WAI/PF/XML/xag-20020617
|
| Editors:
| Daniel Dardailler, W3C (danield@w3.org)
| Sean B. Palmer (sean@mysterylights.com)
|
| Charles McCathieNevile (charles@w3.org)
|
| Copyright ©2000 - 2002 W3C^® (MIT, INRIA, Keio), All
| Rights Reserved. W3C liability, trademark, document
| use and software licensing rules apply.
| ________________________________________________
|
|Abstract
|
| This document explains how to design accessible
| applications using XML, the Extensible Markup
| Language. Compared to the XHTML or MathML languages,
| XML is one level up: it is a meta syntax used to
| define these languages, as well as new ones. As a
| meta syntax, XML provides no intrinsic guarantee of
| device independence or textual alternate support. It
| is essential, therefore, that XML formats and tools
| designers are provided with guidelines that explain
| how to include basic accessibility features - such as
| those present in XHTML, SMIL, and SVG - in all their
| new developments.
Suggested simplification:
This document provides guidelines for designing Extensible
Markup Language (XML) applications that lower barriers to Web
accessibility for people with disabilities (visual, hearing,
physical, cognitive, and neurological). XML, used to
design applications such as XHTML, SMIL, and SVG, provides
no intrisic guarantee of the accessibility of those
applications. This document explains how to include features
in XML applications that promote accessibility.
|Status of this document
[snip]
|Table Of Contents
[snip]
|Introduction
[snipped most of the introduction]
I recommend starting with an explanation about what one
will find in the document, such as:
This document specifies requirements that, if satisfied by
designers of XML applications, will lower barriers to
accessibility. This document includes:
* This introduction, which provides context for understanding
the requirements listed in section 2.
* Section 2 explains four general principles of accessible
design, called "guidelines". Each guideline consists of a
list of requirements, called "checkpoints", which must be
satisfied in order to conform to this document.
* Section 3 explains how to make claims that software
components satisfy the requirements of section 2.
[Will need to add a section on conformance.]
* An appendix offers a summary of this document's principal
goals and structure.
[Will need to add an executive summary.]
* A second appendix lists all the checkpoints for convenient
reference (e.g., as a tool for application developers to
evaluate software for conformance)
[Will need to add a checklist.]
| Relation to other WAI Guidelines
Call this section 1.1.
| "XML Accessibility Guidelines 1.0" is part of a
| series of accessibility guidelines published by the
| Web Accessibility Initiative (WAI). The documents in
| this series reflect an accessibility model in which
| Web content authors, format designers, and software
| developers have roles in ensuring that users with
| disabilities have access to the Web. In this model:
| * Format specifications (e.g., XHTML, SVG, SMIL,
| MathML) include features that support
s/MathML/and MathML/
| accessibility, such as elements and attributes
| for alternative text, navigation tools, semantics
| that respect user control over presentation, etc.
Here and generally, delete ", etc." and put an "and"
before the last example in the list.
| The current document (XAG 1.0) explains how to
| design XML formats that include features to
| benefit accessibility. The principles of this
| document apply for the most part to non-XML
| formats as well.
| * Authors make use of these features when creating
| Web pages and Web applications. The "Web Content
| Accessibility Guidelines 1.0" [WCAG10] explains
| how to create more accessible content through
| features offered by formats, and also through
| consistent design, clear writing, use of
| multimedia, and more.
| * Authoring tools help authors create more
| accessible content through support of formats
| with accessibility features, and through
| interactive and automatic assistance (e.g.,
| prompts for accessibility features, validity
| checking, reuse of accessible content, etc.).
Delete ", etc." and put an "and" before the last example in the
list.
| The "Authoring Tool Accessibility Guidelines 1.0"
| [ATAG10] explains the responsibilities of
| authoring tool developers. ATAG 1.0 addresses the
| accessibility of authored content but also the
| accessibility of the tool's user interface.
| * User agents promote accessibility by implementing
| formats with accessibility features, and by
| providing an accessible user interface, allowing
| communication with assistive technologies,
| documenting accessibility features, following
| operating environment conventions, etc.
Delete ", etc." and put an "and" before the last example in the
list.
| The "User
| Agent Accessibility Guidelines 1.0 [UAAG10]
| explains to user agent developers how to create
| more accessible browsers, multimedia players, and
| other user agents.
Add here:
Formats that conform to XAG 1.0 will support the features
of the other WAI Guidelines. For instance, this document
requires that formats include elements and attributes
that:
* Will allow authors to associate text alternatives with
non-text content;
* Will allow user agent developers to recognize these
alternatives and provide easy access to them in a reliable
manner;
* Will allow authoring tool developers to design tools
that reuse recognized alternatives when the same non-text
content (e.g., a corporate logo) is reused by the author.
Also, I note that there are some requirements here related
to *servers* (e.g., checkpoint 2.11). That should be called
out in the introduction as well.
|
| The requirements of making the Web accessible to
| actual users do not always match this model
| perfectly. In all the guidelines there are cases
| where there is a need for overlapping requirements to
| ensure that people can in fact use the Web. These are
| sometimes due to particular problems in widely
| implemented and used technology, and sometimes are
| provided as a "safety net".
Next, make explicit the cross-references to the other
WAI Guidelines.
The requirements of this document interact with those of the
other WAI Guidelines as follows:
* Checkpoint 4.1 requires that human-readable documentation
of the XML application conform to WCAG, Level Double-A.
* Checkpoint 4.8 requires that the application documentation
note features used to satisfy the requirements of
WCAG, ATAG, and UAAG.
| There are also cases where guidelines rely on each
| other in what seems to be a circular dependency. For
| example, these guidelines require that documentation
| conforms to WCAG, and WCAG suggests that content
| (i.e. the documentation) is written in a format that
| can conform to XAG. Rather than attempt to reproduce
| every requirement of WCAG as requirements in the XAG
| document for documentation, we feel that it is easier
| to make these references. In any case, we feel that
| to implement XAG it is important to have enough
| familiarity with the other guidelines to recognise a
| mutual dependency and be able to apply the
| requirements successfully.
I find the previous paragraph confusing. Suggested
rewrite:
Note: The WAI Guidelines cross-reference one another.
XAG 1.0 requirements to satisfy the requirements of other
WAI Guidelines should be interpreted to mean "Follow the
requirements of other guidelines EXCEPT for those that
in turn require conformance to XAG 1.0." Thus, if XAG 1.0
requires that the documentation of an XML application conform
to WCAG 2.0, and WCAG 2.0 states that conforming content must
also conform to XAG, read this as: "Documentation of an
XML application must conform to WCAG 2.0 except for WCAG 2.0
requirements that in turn require conformance to XAG 1.0."
<new section>
1.2 Target XML Applications
</new section>
Put reduced form of former section "XML Grammars, and The Scope Of
XAG" here:
- XAG 1.0 is expected to improve the accessibility of XML
applications designed to be rendered by a user agent rather than
those designed exclusively for "machine processing." Some
examples of the former include XHTML, DocBook, MenuML, OEB, SVG,
MusicML, and SMIL. Some examples of the latter include XSL,
RDF, and XML Schemas.
- XAG 1.0 focuses on the following aspects of XML applications:
* Adequate structure
* Support for Cascading Style Sheets (which support user
control over style).
* Support for alternative content
* Support for navigation indicators
* Support for orientation indicators
- HTML 4.0 is an example of a markup language that includes
a number of accessibility features (refer to "Accessibility
Features of HTML" [HTML-access]). XHTML 1.0 carries forth
these accessibility features, using XML syntax. Some XAG 1.0
features as they are implemented in XHTML 1.0 include:
* Adequate structure (improved form structure with fieldset
and optgroup, elements and attributes to convey more
structure for tables)
* Support for style sheets (inline and linked)
* Support for alternative content (alt, summary, longdesc
attributes, caption element for tables, object element
semantics)
* Support for navigation indicators (tabindex attribute, link
element)
- XAG 1.0 addresses the concern that new applications will not
include accessibility features such as those found in XHTML
1.0, SVG, and SMIL.
[Fill in later with other target application characteristics.]
<new section>
1.3 Known limitations of this document
</new section>
- While there are accessibility issues or features for XML
applications that are not designed to be rendered by a user
agent (e.g., how XSL can assist in Braille formatting), XAG 1.0
does not address these issues directly.
[Fill in later with other limitations of XAG 1.0.]
<new section>
1.4 Security considerations
</new section>
This document assumes that security issues (e.g., representation
of passwords) will be addressed outside of conforming XML
applications. Consequently, unless permitted explicitly in a
checkpoint, this document grants no conformance exemptions based
on security issues. For information related to security, refer
to "XML-Signature Syntax and Processing" [XMLDSIG] and "XML
Encryption Syntax and Processing" [XMLENC].
[Fill in later with other security considerations.]
| ________________________________________________
|
|Guidelines for designers of XML dialects
Don't use the term "dialect"; stick with "application".
| 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.
I recommend a more formal treatment of the structure
of this chapter (as is done at the beginning of section
2 of UAAG 1.0 [2]). In particular, when XAG 1.0 includes
a conformance section, indicate what is normative and
what is not.
[2] http://www.w3.org/TR/2002/WD-UAAG10-20020821/guidelines
| * Guideline 1. Ensure that authors can associate
| multiple media objects as alternatives
| Web content providers must able to offer
| alternative versions of their content if they
| wish to do so (as the Web Content Accessibility
| Guidelines tell them to do so). Textual
| alternatives, like a caption for a movie, or a
| table summary, can be repurposed for many
| different output devices, whereas audio content
| for instance is confined to a certain set of
| devices (those that can play sound).
| 1.1 Provide a mechanism to explicitly associate
| alternatives for content or content
| fragments.
I suggest replacing this checkpoint with much more specific
checkpoints, such as:
1.1a Allow the author to include a text title for
each element.
1.1b Allow the author to provide a text summary
for any piece of content (e.g., abstract, summary,
or description elements and attributes).
1.1c Allow the author to provide a text alternative
for each piece of non-text content.
1.1d Allow the author to provide a synchronized
text alternative for each piece of audio content.
1.1e Allow the author to provide a static
text alternative for each piece of audio content.
1.1f Wherever it is possible to provide a text alternative,
allow the author to provide any number of text
alternatives in different scripts (i.e., written
languages). Allow the author to identify the script
of each of these text alternatives.
1.1g Allow the author to provide an audio alternative for
each piece of non-text visual content (such as a movie
or animation).
1.1h Wherever it is possible to provide an audio alternative,
allow the author to provide any number of audio
alternatives. Allow the author to identify the language
of each of these audio alternatives.
1.1i Allow the author to provide a synchronized
text alternative for each piece of video or
animation content.
Note: When an audio track is synchronized with the
video content, authors should synchronize this alternative
with the one used to satisfy checkpoint 1.3.
1.1j Allow the author to provide a static
text alternative for each piece of video or
animation content.
Note: When an audio track is synchronized with the
video content, authors should synchronize this alternative
with the one used to satisfy checkpoint 1.4.
1.1k For any content intended to be rendered in two spatial
dimensions (e.g., frames), allow the author to specify
alternative content that may be rendered in one
temporal dimension.
1.1l Allow the author to specify alternative content to
any executable content.
1.1m Allow the author to provide a description of any
content other than audio, video, or animation
content that varies over time.
As I mention at the top of this email, I think the
document will be more effective by being very specific
for known cases.
| 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.
Please delete "whatever".
| 1.2 Define flexible associations, where a given
| kind of relationship can link to or from
| objects of varying types without
| constraint.
I propose replacing 1.2 as written with:
1.2 For any two pieces of alternative content, allow
the author to associate each one explicitly with
the other (i.e., in both directions).
Is this what is intended?
| Relationships between alternatives
| should be explicit in markup to allow
| users to select which alternatives are
| useful to them, and should allow
| multiple types of alternative, not just
| text as an alternative for an image. For
| example, the HTML img element lets you
| provide a text alternative in the alt
| attribute, but it does not let you
| explicitly associate images to text or
| markup. To do this people have to put up
| with less adequate mechanisms, perhaps
| by adding "see figure 1" at the end of a
| paragraph. If the img element could have
| content, like the object element, this
| would have solved the problem to some
| extent.
"Would have solved the problem to some extent" suggests that
there's a better way to do this, but it's not mentioned here.
| 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.
I suggest reordering the examples in the above paragraph so that
the right way to do things comes first.
| Satisfying this checkpoint
| takes a lot of thought due to its
| subjective nature, but it is very
| important.
Fix 2.1 so that the above sentence can be deleted.
| * Guideline 2. Create semantically-rich languages
| End-user-oriented XML should contain precise
| methods of encoding the data for its particular
| scope.
The first sentence of G2 prose doesn't add anything and can be
deleted.
| By increasing the semantics of your
| elements, and setting linking devices to outside
| presentations or further semantics, you allow
| your data to become "Webized" and hence to
| operate within many environments.
I don't love "Webized". How about a new intro paragraph
such as:
Increased structure in an XML application (i.e., elements
and attributes that correspond to meaningful terms in
the chosen domain) allows authors to encode their knowledge
in a manner that user agents can recognize reliably. XML
applications deployed on the Web should include linking
semantics.
|
| 2.1 Ensure all semantics are captured in markup
| in a repurposeable form.
As written, this checkpoint is too vague.
| XML languages must be designed so that
| they can be presented in a device
| independent way. They must be
| repurposable with respect to input and
| output devices, as well 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.
The above qualification suggests that the checkpoint could
be broken down into the following more specific checkpoints:
2.1a [Input device]
i) Ensure that the semantics of elements and attributes do not
depend on a particular input device (e.g., pointing device).
ii) For elements and attributes that do depend on a particular
input device, ensure that the author can specify alternative
behavior for other input devices.
iii) Allow the author to describe author-specified input device
behaviors (e.g., to provide a description of the behavior of an
event handler).
2.1b [Output device]
i) Ensure that the semantics of elements and attributes do not
depend on a particular output device (e.g., color graphical
display).
ii) For elements and attributes that do depend on a particular
output device, ensure that the author can specify alternative
behavior for other output devices (e.g., CSS @media).
2.1c [Space]
i) Ensure that the semantics of elements and attributes do not
depend on two-dimensional visual output.
ii) For elements and attributes that do depend on two-dimensional
visual output, see checkpoint 1.1j.
Example: Client-side image maps instead of server-side image
maps.
2.1d [Time]
i) For elements and attributes that involve user input,
ensure that the input semantics allow for time-independent
interaction.
|
| 2.11 Specific checkpoint for Final-form dialects
Don't use "dialect".
(The sort algorithm is not working: 2.11 should not follow 2.1...)
| Languages used only for presentation to
| a certain scope of users and media are
| called, Final-form and they should
| adhere to the following caveats:
I suggest the UAAG 1.0 term "provision" instead of caveat.
Split 2.11 into three separate checkpoints (or leave as
three provisions):
| o They should not be promoted as being a
| generally suitable method of storing
| content that can be used across a
| variety of devices.
This is a requirement related to the documentation of the
XML application and should be called out as such.
| o The server should make sure the client
| wants this particular form before
| serving it.
This is a requirement related to servers and
should be called out as such.
| o They should allow the authors to
| associate the final form with the
| higher level semantics of the source,
| whenever applicable.
Delete "Whenever applicable".
Proposed rewrite:
2.11
i) Allow the author to identify by URI the source
used to generate the final form instance.
ii) In the application documentation, indicate that
final form instances SHOULD NOT be served except
upon explicit user request (e.g., through a
configured preference).
ii) In the application documentation, indicate that
final form instances SHOULD NOT be the only
form used to store information persistently;
a semantically rich source should be stored
instead or made available by dereferencing
the URI required by provision 2.11i.
| 2.2 Separate presentation properties using
| stylesheet technology/styling
| mechanisms.
Yes. However, in light of checkpoints 3.1 and 3.3, which
imply conformance to CSS or XSLT, I think 2.2 should
be rewritten:
2.2 Implement style sheets.
2.2a Conform to either CSS or XSLT.
2.2b Implement presentation properties using CSS or XSLT
instead of XML elements and attributes.
|
| Techniques for 2.2
| TW2.2.1Example: Wrong
| T2.2.2 Example: Right
I suggest putting the right way first (for this checkpoint
and in general).
| 2.3 Use the standard XML linking and pointing
| mechanisms (XLink and XPointer). [[Note
| this checkpoint is under discussion and
| may change]]
| Xlink [XLINK] and XPointer [XPTR] have
| been reviewed for accessibility and
| their linking/pointing semantics may be
| recognized with certainty.
Ok.
| 2.4 Define element types that allow
| classification and grouping (header,
| section, list, etc).
I think that the proposed checkpoint 1.1a (Allow the author to
include a text title for each element.) covers the case of
section headings (H2 is a title for the section that follows,
TH is a title for a table or or column). I propose narrowing
this checkpoint to:
2.4 Allow the author to create classes of objects
(e.g., via the "class" attribute in XHTML 1.0).
See below for information about grouping.
| Make use of existing mechanisms (noting
| checkpoint 1.2), or create them where
| necessary, following these guidelines.
Instead of this sentence, include a cross-reference to
checkpoint 2.9.
| 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.
I don't understand the expression "full containment model."
Perhaps it just requires definition. However, I'd narrow
the checkpoint to that technical requirement:
2.5 Provide for a full containment model.
The "chunks of reasonable size" are generally
determined by the author, not the format. How about:
2.5b Where the application allows the author to build a set
of more than five to seven objects, ensure that the
author can also create subsets either through
classification or explicit grouping.
It may not be useful to distinguish classification for the
purposes of style from classification for other reasons.
(i.e., may 2.4 and 2.5b can be combined).
| 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.
| 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. Examples of such
| important elements are numbers, dates,
| titles and links.
Titles and links are covered in previous checkpoints (1.1a and
2.3, respectively). I recommend replacing 2.6 with more specific
provisions. For example, pick the important ones from XML Schema
Part 2 [3]: Datatypes (sections 3.2 and 3.3).
[3] http://www.w3.org/TR/xmlschema-2/
| 2.7 Provide a mechanism for identifying summary
| / abstract / title.
Delete this checkpoint, which is covered by proposed
checkpoints 1.1a and 1.1b.
| 2.8 Don't overload the semantics of elements.
Should this checkpoint talk about overloading
names or overloading semantics? What about:
2.8 Don't overload element and attribute names.
| 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 easier to
| access the document semantics. Note the
| relation to checkpoint 4.9.
| 2.9 Reuse existing accessible modules, as
| originally specified / intended. [[Note:
| This checkpoint is under discussion, and
| may be changed to techniques, or may be
| augmented with a list of modules that
| should be re-used]]
I suggest instead talking about XAG conformance explicitly:
"Reuse portions of XML application modules that conform
to XAG 1.0, and reuse them as originally specified."
| Reusing accessibility modules has the
| advantage 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 authors (the people using your
| language) to learn new concepts. When
| using modules from other schema, use
| them with the same semantics as
| originally intended.
| 2.10 Allow association of metadata with distinct
| elements and groups of elements.
I think you can simplify to:
2.10 Allow association of metadata with each element
(notably grouping elements; see 2.5b).
| This permits authors to make even more
| semantic associations than what was
| originally intended by the language
| designer.
| * Guideline 3. Design an accessible user interface.
| Web content is rapidly shifting from static pages
| to dynamic pages, called Web applications.
I would delete "is rapidly changing" and make the prose
a statement of fact that some Web content is dynamic.
| 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.
|
| 3.1 Provide default style sheets for multiple
| output modalities where possible.
Please delete "where possible". If it's not possible, then
people won't do it.
Merge this checkpoint with :
| 3.3 Use CSS or XSLT to describe a basic outline
| view.
The result would be something like:
3.1 Provide useful default style sheets.
3.1a Provide default style sheets for multiple output modalities.
3.1b Provide a default style sheet that creates an outline
view composed of labels for important structural elements
(e.g., heading text, table titles, form titles, and other
labels that are part of the content).
[The language of 3.1b is taken from UAAG 1.0, checkpoint 10.4.]
| 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.
| 3.2 Define navigable structures that allow
| discrete, sequential, structured, and
| search navigation functionalities.
Proposed:
3.2a Allow the author to specify a sequential navigation order
among enabled elements other than the default document
order. [See UAAG 1.0 for definitions of enabled elements
and sequential navigation.]
3.2b Allow the author to specify default input configuration
bindings for direct navigation to enabled elements.
[UAAG 1.0 requires that the user be able to override
default input configurations.]
3.2c Allow the author to identify navigation groups (e.g.,
groups of links).
3.2d Allow the author to identify elements that have navigable
substructures (e.g., tables).
3.2e Allow the author to exclude elements from any navigation
mechanism.
I am uncertain why "search" is part of this checkpoint. Is this
something the author would have to encode? Or is this just
a user agent functionality?
| 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.
| 3.3 Use CSS or XSLT to describe a basic outline
| view.
See comments on 3.1 above.
| 3.4 Use a device-independent interaction and
| events model / module.
This is the same as proposed checkpoint 2.1a.
| 3.5 Allow for user control of interaction timing
| - rate of change, external events
| triggering document changes, etc.
This seems like a UAAG 1.0 requirement, not a XAG
requirement. See, for example, UAAG 1.0 checkpoints 2.4 and 3.5.
Instead, I think a general checkpoint about user override of
author-specified presentation parameters is appropriate (though
it will have to be phrased diplomatically so that format
designers accept it).
| 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.
Please delete the previous sentence, which doesn't add
much.
| * 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. 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.
s/documentation/documentation of the format specification/
| 4.2 Provide a machine-understandable
| means/mechanism to get from a document
| instance to the schema.
Ok.
| 4.3 Provide explicit human readable definitions
| for markup semantics.
I'd recommend reordering 4.1 and 4.3 as follows:
4.1 Provide human-readable documentation of the
XML application (was: 4.3).
4.2 Ensure that the documentation required by checkpoint
4.1 conformance to WCAG 1.0, Level Double A. (was: 4.1).
Then:
4.3 Provide a machine-understandable
mechanism to get from a document instance to schema.
|
| 4.4 Use a schema language that can support
| explicit human-readable documentation or
| annotation of semantics.
Does checkpoint 4.4 imply that a schema language must
be part of the application definition? If not, the
checkpoint should read:
4.4 When a schema language is part of the XML application
definition, ensure that the schema language supports
explicit human-readable documentation or annotation of
element and attribute semantics.
| 4.5 Provide semantic relationships to other
| schema where appropriate and possible.
This checkpoint is problematic:
a) It is difficult to know when one has satisfied this
checkpoint. How many mappings must be provided in order to
conform?
b) This checkpoint conflicts with checkpoint 2.9 when the
relationship is equivalence: that means the designer didn't
reuse existing markup. [If the equivalence relationship is
identified after the fact by a third party, that's not the
application designer's problem.]
I would suggest:
a) Narrowing the scope of 4.5 to "Use schema subclasses", and
b) Deleting "where appropriate and possible".
| This allows the authors using the
| language to reuse their existing
| knowledge and tools.
| 4.6 Document accessibility features of the
| application.
Yes, but please align the language with UAAG 1.0 checkpoint 12.2:
4.6 Document all XML application features that benefit
accessibility.
I recommend adding:
"For the purposes of this checkpoint, an XML application
feature that benefits accessibility is one implemented to
satisfy the requirements of this document."
I note that XAG 1.0 has two documentation checkpoints
that sound just like UAAG 1.0 checkpoints:
a) XML application documentation must conform to
WCAG (see UAAG 1.0 checkpoint 12.1).
b) Document all XML application features that benefit
accessibility (see UAAG 1.0 checkpoint 12.2).
I'd recommend importing the other three checkpoints
of guideline 12 as well. I summarize UAAG 1.0's
checkpoints 12.3-12.5 as follows:
c) Document default bindings.
d) Document changes between versions that affect accessibility.
e) Provide a centralized view of all features that benefit
accessibility.
These checkpoints can all be imported with few changes,
and it would be great if XAG and UAAG language were the
same.
This emphasizes a point I made at the beginning of the
email: the language of XAG should be consistent with other
guidelines and the requirements of XAG should reflect
the requirements of other guidelines.
| 4.7 Include accessibility requirements in
| conformance requirements.
Yes. See UAAG 1.0, section 3.3, which explains how to
include UAAG 1.0 requirements in other specs (direct
inclusion or by reference). Something similar in XAG
would be useful.
| 4.8 Document techniques for WCAG, ATAG, and UAAG
| with respect to the XML application.
I agree with the idea: a format specification should
include information about how to satisfy WAI Guidelines
requirements.
UAAG 1.0 section 3.3 talks about including UAAG 1.0
requirements in other specifications. I think UAAG 1.0
should only talk about user agent requirements, and XAG should
only talk about XAG requirements (as is done in checkpoint
4.6 already). Each Guidelines document should only impose
this for its own checkpoints. I disagree with the scope
of 4.8 and think it should be deleted.
| 4.9 Do not assume that element or attribute
| names provide any information about
| element semantics.
This checkpoint seems out of place to me. First of
all, I don't see the relation to accessibility. Second,
I don't know who is addressed by this checkpoint. I suggest
deleting it.
| 4.10 Document navigable structures.
This checkpoint can be deleted for the following reason:
- Checkpoints 3.2a, 3.2b, 3.2c, 3.2d, and 3.2e make
navigation requirements.
- Checkpoint 4.6 requires that access features be
documented. Those are defined to be features used to
satisfy the requirements of XAG.
- Therefore, 4.6 includes the navigation features and
4.10 can be deleted.
[snip]
|Appendices
| Appendix D: References
[snip]
| [UAAG10]
| "User Agent Accessibility Guidelines," J.
| Gunderson and I. Jacobs, eds. The latest
| version of the User Agent Accessibility
| Guidelines is available at
| http://www.w3.org/WAI/UA/UAAG10.
Please change the editorship to read:
"User Agent Accessibility Guidelines 1.0" I. Jacobs,
J. Gunderson, E. Hansen, eds.
| [UAAG10-TECHS]
Same comment as for UAAG 1.0.
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
Received on Tuesday, 17 September 2002 23:50:44 UTC