W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 1999

Re: Some comments on conformance levels in UA guidelines draft

From: mark novak <menovak@facstaff.wisc.edu>
Date: Mon, 6 Dec 1999 12:11:52 -0600
Message-Id: <v01540b0ab471a936e08b@[]>
To: peter.b.l.meijer@philips.com, <w3c-wai-ua@w3.org>
Cc: <ij@w3.org>
see comment at MN next:

MN:  Hi Peter:   Don't want to get into this too deep, but I think the UA
working group shares many of your concerns.  It truely is a difficult area
to "draw a line" in.  However, I know you realize that there is a lot of
"distance" between a "guideline" and a "platform specific API".

On an encouraging note, there are APIs which are continuing to evolve for
on multiple platforms, and I think we can safely say that the origins of
those APIs were in part do to, someone(s) first developing guidelines.
as the UA guidelines evolve, they will continue to feed and support that
process across platforms.  Also, hopefully, those accessibility related APIs
will just become part of the standard platform APIs <smile>

>At 12:58 PM 12/6/99, peter.b.l.meijer@philips.com wrote:
>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
Received on Monday, 6 December 1999 13:09:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:24 UTC