Editorial comments Re: [XAG] New draft Announcement

Hi folks,

I have trimmed out everything except what I think are editorial improvements
from Ian's original proposals.

(for example, anything that touched on an existing issue has been removed
here)

I propose to incorporate any of these that people don't object to into the
next (Public) draft, but do not feel that we have time to resolve things that
are not agreed to. So if you think there is something in here that is not an
editorial improvement please say so, and that change will be held over for
later discussion.

(And as a general note, please don't send monolithic proposals if you can
break them into pieces - they take a lot more time for me to work with as an
editor, and as the person trying to track issues).

Cheers

Chaals

On Tue, 17 Sep 2002, Ian B. Jacobs wrote:

>==========================================================
>  |Abstract
>  |
>
>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.
>
>  |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.

(use "XML application" in place of "software component")

>     [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.]
>
>
>  |       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.
>
>  |   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."
>
>  |
>  |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 2. Create semantically-rich languages
>  |       End-user-oriented XML should contain precise
>  |       methods of encoding the data for its particular
>  |       scope.
>
>  |       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.11 Specific checkpoint for Final-form dialects
>
>Don't use "dialect".
>
>  |                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.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.
>
>  |        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.
>
>  |                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.
>
>  |        4.1 Ensure human-readable documentation conforms
>  |                to WCAG double A.
>
>s/documentation/documentation of the format specification/
>
>  |        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.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).
>
>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.
>
>  |   [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.
>

Received on Monday, 23 September 2002 10:29:03 UTC