some accessibility comments on the WS Description Requirements

<notes
class="inTransmittal">

These comments were developed in the Protocols and Formats working group.
They have had some of the rough edges knocked off them in that process,
but are certainly open to clarification and refinement.  We don't claim
to have absorbed all the context for the current document completely.

If there is anything in these comments which is not clear, or appears to be
un-implementable, we would welcome the opportunity to discuss these points
with you before you make a final determination on a disposition.

Thank you for your consideration of these comments.

Al
--
Al Gilman, Chair
W3C/WAI Protocols and Formats Working Group

</notes>

A:  Introduction

Thank you for developing this aspect of web services carefully, including
inviting comments on this draft.

The over-arching accessibility requirement has to do with how well the
information representations flowing in and out of web services are
characterized to clients of the service.  It is necessary that all potential
or partial obstacles to the effective receipt and use of the information in
these messages by a human end-user be identified and the means of remedying
these be articulated.

A downstream adaptation transcoder[DI] needs to be able to reason about the
accessibility of the content of Web Service messages.  It may need to reflow
and re-style the dialog to maximize usability based on the device and user
capabilities in the current (a particular) delivery context.  The
information needed to decide the optimum adaptive transformation should be
present (in the service messages processed in the context of their
description) in machinable form, and the service messages should be
constructed in a way that makes the implementation of this adaptation
processor easy.  This class of client must be included in assessing R013,
easy to implement.

While many of the requirements of the XAG are present already in the Web
Service Description requirements,  We believe that incorporating some more
concrete provisions in various areas as expressed in the current draft XML
Accessibility Guidelines [XAG] into the climate of decision factors for Web
Services Description will yield a more effective and interoperable cohort
of web services and a more accessible web.

B:  General comments

1.  The role of web service description in an accessible-by-construction Web.

The description of a web service bears a role in building an
accessible-by-construction Web similar to the Model in an XForms
application[XForms] or the UI Socket in an AIAP-URC application[AIAP-RC].
It documents the usage practiced in the messages that accomplish service
delivery by that service.  It must prepare a client for what structures and
properties to anticipate in these messages, and what interpretation to lay
upon those structures and properties when they appear.

The requirements for accessibility that get reflected to web services,
whether one speaks of accessibility by people with disabilities or universal
design for accessibility regardless of disability, are that the properties
such as being a non-text object (cf. Guideline 1 in [WCAG1, WCAG2])
affecting such accessibility be captured in this model (cf. Guideline 1 in
[XAG]), and documented in the description (cf. Guideline 4 in [XAG]), along
with the structures that capture the substitutability opportunities between
these objects and their equivalent alternatives (cf. html:object, smil:switch,
svg:desc).

These are specific modes of information capture and exposure that support
required reasoning about services in the downstream process of adapting user
interfaces dealing with information accepted and provided by these services
to accommodate human diversity, in particular to meet the needs of people
with disabilities.

The Web Service Usage Scenarios Document talks about requirements arising
from reasoning about services and in order to construct competent consumers
(clients, communication partners) of the service.  In our case, each of
those implies the other.  To adapt the presentation of a bottom-line service
that a human cares about, the service process must be presented in an
interface free of critical dependencies on particular human functions such
as vision, hearing, moving a mouse; as well as human performance factors
such as concurrent mechanical actions, rapid response, etc.  To work around
sight dependencies implicit in images used as icons, equivalence
relationships between these icons and text [and possibly sound] equivalents
must be defined and exposed in a way that a client of the web service can
comprehend in a machine process for automatic adaptation.

Methods of classifying and relating content fragments, and characterizing
user factors for use in the adaptation process will continue to evolve.
Particularly, we expect progress in these areas to come from the W3C
Activities addressing multi-modal interaction[MMI] and Device
Independence[DI].  This will be ongoing as the work on web services
progresses.  But the general outline of strategies to apply to web services
are already sketched in the XAG to a more developed degree than is present
in this draft of Web Service Description Requirements.

2.  Instance requirements drive format requirements.

This document addresses requirements for a web service description notation.
Not a web service description practice.  Requirements that pertain to the
description of each web service, but not to the notation in which one can
write all web service descriptions, are not covered here.  This makes it
awkward to assert that accessibility concerns are being adequately
addressed; as the most obvious form of accessibility requirements are claims
against the specific description of a particular web service.  The notation
then must provide feasible and convenient means for description instances to
meet those requirements.

In the Web Accessibility Initiative, we have instance requirements
represented by the Web Content Accessibility Guidelines [WCAG1, WCAG2] and
the User Agent Accessibility Guidelines [UAAG1] and platform requirements
represented by the Authoring Tool Accessibility Guidelines [ATAG1] and the
XML (dialect) Accessibility Guidelines [XAG].

There is an open question as to whether the document set for Web Services as
presently planned is complete, or whether the Web Services document set
should include a Service Description Guidelines document capturing
requirements on description instances that cannot be guaranteed to be
satisfied by the built-in semantics bound to the descriptive medium alone.

3.  Extension vs. Interoperation.

The area of "information integrity of extensions" is under-developed.  There
need to be more requirements laid out for any extension capability or this
descriptive notation will be too-easily abused to create private i.e.
un-interoperable service interfaces.  Understand that for accessibility,
anything that the service offeror has a desire to publish in the service
description is something that we probably need to reason about.  So while
R070 -- that a mapping to the RDF model can be introduced -- is necessary,
it is not sufficient.  Anything that could be reasoned about in the sense of
the service description should be captured and exposed in a
machine-recognizable and machine-reasonable way.  Compare with Guidelines 2
and 4 in [XAG] -- have a model, export the model.  "Export" here means to
share the model in machinable form.

This requirement for a machine comprehensible rationalization of the service
behavior applies to the description including all extensions.

You may wish to restrict extensions to run-time information, or at least
set as a PR-entry requirement that it be demonstrated [one reference
implementation here, not two competing] that there is a way, given
a suitable programming model, to process all allowed extension contents
interpretively and extract the full sense of the service characteristics
described using the extension.

4.  Interoperation Testbed.

We are aware of research and government activities [US-WS-WG, IRIS, RAINBOW]
who a) want to use web services to migrate their operations to a more
cost-effective platform, and b) want to implement accessible-by-construction
services and/or accessibility-aiding transformation services.  The essence of
Web Service pilot and prototype efforts is to evaluate the interoperation of
service and client prototypes implemented by different organizations.

How can we and they participate with you in inter-prototype operability
evaluation on an ongoing basis?

5.  Conformance.

There is enough intrinsic complexity latent in the extensibility
requirements so that conformance to the resulting specification may indeed
be less than simple.  Our experience has been that success in gaining
compliance is directly related to the clarity of the conformance
requirements.  Where these cannot be stated in a way that is terse and
correct at the same time, it helps to be prolix but concrete.

Please consider whether the document(s) should not include a conformance
section.

If there is no such guidance in the specification, we would be concerned
that Web Service descriptions using this technology will often not meet the
requirements of XAG Checkpoint 4.6, 4.8 -- document how you meet
accessibility requirements.

C:  Comments on specific numbered Requirements

1. [R001 any transport protocol]  Demonstrate that the technology works in
particular for services with ports that source and sink streams.

There are application scenarios for services that assist in adapting real
time collaboration for people with disabilities that would seem to call for
web services that have ports that source and sink streams[MODTRANS].  This
requirement would seem to imply that such services will be covered, but it
is not clear that unless the applicability to stream ports is confirmed
concretely, that the resulting specification will be sufficient for this
use.  How would the Web Services Description Working Group best like to
follow up on this?  Should there be an additional "in particular" numbered
requirement, some sort of a coverage requirement attached to this
requirements, or what?

Notes:

[Section 4.4 Interactions]  This section casts doubt on the capability of
the result to deal with streams.  Web services should include stream
processors.

[R114 unambiguous unique Operation for any message]   It is not clear what
is actually required here; "must allow" is ambiguous.

Do you mean that for all services, the information in the Web Service
Description must be sufficient to resolve the myOperation property of any
particular message to one and only one defined Operation?  Or do you mean
that the Web Service Description specification(s) must define mechanisms
such that if that uniqueness property is appropriate, the service can
provide description which consumers of the service to identify the unique
value of myOperation for each message.  If the former, this requirement may
be incompatible with stream-processing services (and if so should be relaxed).

2. [R004 XML Infoset model]  It is not clear to us that this is sufficiently
broad or powerful where it comes to describing external relationships of a
service.  This may be fine for describing the internal workings (messages,
and their parts) of a binding, but that relationships across bindings and
with external information may be better, or necessarily, expressed in some
more general framework such as the RDF Model.

3. [R100 type system extensibility]

See the general comment 3 on the issues raised by the current description
of extensibility in the requirements.

4. [R003 use available]  [cf. XAG Checkpoint 2.9]

It would be helpful to have some rough idea, while not necessarily a closed
or definitive list, of the working hypotheses of the WS Description Group as
to what these established foundation technologies are.  WCAG 2.0 Checkpoint
5.2 (backward compatibility)[WCAG2.C5.2] points out that it takes time for
assistive technologies to adapt to new technologies, and that existing
support through assistive technologies (such as screen readers and screen
magnifiers, voice command and on-screen keyboards) should be considered in
assessing what constitutes "commodity technology."

5. [R013 simple to understand and implement correctly]  It is hard to
reconcile the use of MUST in this clause, where MUST is applied to an
unenforceably vague predicate.

6. [R021 describe the messages]  Essentially the whole of the XAG as now
drafted serves as an accessibility annex to this one-liner.  This is the
point where this document implicitly creates a requirement for WSDL to
satisfy the provisions of the XAG.

7. [R021 describe the messages] [R003 use available]  In particular, there
may be assertions that one can make about elements of a given service that
have not been anticipated in the general syntax for all services, and that
can be conveniently expressed as RDF metadata embedded in the service
description after the manner employed in SVG and SRGS.

8. [R116 abstract policies]  Is there any reason why this should not be
required to be expressed in a form reducible to the RDF model [or more
specifically DAML+OIL]?  Otherwise there is no definition to what one
considers an 'abstract policy.'  See also general comment 3.

9. [R083 separate design-time from run-time information]  What is intended
by the "design time" referred to in this requirement?  This requirement is
incompatible with R001 (any programming model).  It is not possible to
distinguish design time and run time without making assumptions about the
programming model.

Is "design time" the activity in which one is designing a service wrapper to
embed the service in an API accessible from programs on the [network-]
client node?  Is it presumed that all services require human intervention to
create such a wrapper?  What is the standard for determining design time
information -- the maximum set of constraints that can be bound in hard
code, or the minimum amount of code that must be hand-crafted?

10. [R026 Human-readable comments.][R123 unconstrained comment content]

This requirement is important, but inadequately specified.

The human-readable expression of what the formal structures in the service
messages etc. are about must be captured in a little more formal form than
what is provided by, for example, XML comments.

The XAG requirement (Checkpoint 4.4) for _explicit_ documentation requires
that the human-readable documentation of the schema is formally connected
with the [items in the infoset].  The 'annotation' construct in XML Schema
meets this requirement.  Comments in XML DTDs do not.  Please capture this
distinction into the WSD Requirements.  Make the WSDL be a literate
programming medium where the formal code that expresses what the immediate
processors of the message need and the narrative explanation that expresses
what this means for the beneficial users of the expressed information are
related as tightly as possible by the structure and other markup of the WSDL
document.


D:  References

[XAG]  http://www.w3.org/TR/xag

[XForms]  http://www.w3.org/MarkUp/Forms/

[AIAP-RC]   http://www.incits.org/tc_home/v2htm/docs/V2/02-0086/v2020086.htm

[WCAG1]  http://www.w3.org/TR/WCAG10

[WCAG2]  http://www.w3.org/TR/WCAG20

[MMI]  http://www.w3.org/2002/mmi/

[DI]  http://www.w3.org/2001/di/

[ATAG1]  http://www.w3.org/TR/ATAG10

[US-WS-WG]  http://web-services.gov/

[IRIS]  http://www.iris-design4all.org/default.htm

[RAINBOW]  http://rainbow.essi.fr/

[MODTRANS]  http://trace.wisc.edu/world/modtrans/

Received on Tuesday, 31 December 2002 14:40:56 UTC