Re: Some comments on conformance levels in UA guidelines draft

Ian Jacobs wrote

> > The UA guidelines are at their current stage excellent as
> > an informal checklist, which is highly useful and a major
> > achievement, but I suggest that the UA guidelines are not
> > ready for labelling products through a compliance rating.
>
> This will be addressed by the Working Group as issue 153.
> http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#153

Thank you very much, Ian. I will await the outcome of further
discussions on this intricate but extremely important topic.
Your comments were much appreciated.

On second thought, maybe I still need to clarify some of my 
earlier remarks in relation to your most recent reply and 
in particular the motivations of the Working Group choice 
where you wrote

> The Working Group has chosen not to include a conformance
> provision in this version of the UA Guidelines that addresses
> software used in combination. Some of the limitations of such
> an approach include:
>  
> 1) Combinatorial nightmare. Your emphasis is on screen readers, but
>    we would have to address functional requirements of other
>    software combinations than desktop browsers used with 
>    screen readers.

My examples were indeed mostly for screen readers and (mainstream)
browsers, but I believe that the standardization of the proposed
intermediate user interface layer readily extends and applies to 
almost any software application as well as many accessibility 
technologies other than screen readers. Moreoever, the sole purpose 
of my proposed intermediate layer was exactly to *prevent* the
dreaded combinatorial explosion. The simple example of menus can
be carried over to many alternative representations to suit any
particular disability, and it does not and should not affect the
definition *that* for instance the use of "standard" menu items 
conforms to UA guidelines. The guidelines do not need to consider
whether or how the menu items are made visible on the screen, 
rendered to speech, to Braille, or to any other specific sensory 
representation that may best fit particular disabilities.

Maybe it helps if I illustrate the concepts with a further, already
existing, example of vendor-independent "software combinations" under
the next point. (Unfortunately, the example is not operating system
independent, so it leaves something to be desired...)
 
> 2) Conformance dependencies. Vendors should be able to claim
>    conformance alone, and not rely on the existence of other software
>    for their claims.

Exactly, but my whole point of focus was to allow for this without
a "combinatorial nightmare" through standardization of an intermediate
layer, or protocol, or set of guidelines, for using arbitrary (general)
non-accessibility applications in combination with, or on top of, any 
accessibility "wedge", which could be a screen reader or (any) other 
accessibility technology.

Perhaps a useful non-accessibility analogy of how this can be done
is given by a video technology standard that my user agent supports: 
Video for Windows. This is a Microsoft-specific API that allows for 
a very clear split between development of video *applications* and 
the underlying video capture hardware and *driver* software. It is 
an API, meaning that it is more strict than a set of guidelines, but
that does not really matter too much for the current discussion.

I can without problems "claim" conformance to "Video for Windows" 
*without* relying on the existence of software from other parties 
such as PC camera vendors: I just conform to the intermediate layer,
and that is enough. Similarly, the PC camera vendor, or capture card
vendor, or TV card vendor, can all rightfully "claim" conformance 
to "Video for Windows" as well, without relying on the existence 
of (application) software from other parties such as my video 
sonification software. Through the existence of a standard for the
intermediate layer, there is no "combinatorial nightmare": every 
Video for Windows compliant application will run fine in combination
with every Video for Windows compliant video capture device (driver).

For instance, my video sonification application has been shown to 
work fine with PC cameras, video capture cards and TV cards of many
different vendors, while I did not have to consider any specific 
vendor: there is no "combinatorial nightmare" at all!

Vice versa, I think that no PC camera vendor thought of trying to
make video (more) accessible to blind people. Nor did they have to, 
since the intermediate Video for Windows standard is all that is 
needed: it allowed me to create my own "I/O wedge" that remaps video 
to alternative non-visual sensory representations, the "soundscapes".

The screen reader is in my view very much like a device driver,
and as an application developer one wants and needs to abstract
from any underlying "accessibility wedge" that redefines I/O for
accessibility purposes. If that means conforming to some rules or
guidelines for using "standard" user interface elements, that is
OK, because it minimizes effort and cost on all sides: the screen
reader developer no longer has to worry about how to add a great
browser or mathematics package or whatever application, while the
application developer no longer needs to worry about what underlying
accessibility software the client will need or use, let alone that
the application developer would have to integrate all that with 
his/her application (to meet the current conformance requirements).

By the way, I do understand that/if in the current UA guidelines it
may not be possible or feasible to include conformance requirements
for "software used in combination", because it requires some extra
work that may be more appropriately covered by a follow-up activity, 
and I am glad that at least the issue of, and my worries about, the 
currently limited "conformance" is now registered under "issue 153".

However, I hope to have clarified that both the "combinatorial 
nightmare" and the "conformance dependencies" can be prevented
through the proposed definition of guidelines that define basically
*what* user interface elements, where applicable, can be and must
be made accessible through the disability-specific low-level I/O 
wedge offered by accessibility software, of which screen readers
form just an example.

Best wishes,

Peter Meijer


Seeing with Sound - The vOICe Video Sonification software
http://ourworld.compuserve.com/homepages/Peter_Meijer/winvoice.htm

Received on Monday, 6 December 1999 06:58:17 UTC