Re: Some comments on conformance levels in UA guidelines draft

as I see this, it boils down to three components.
1> the ua.
2> the os.
3> the assistive technology that interfaces with the computer/device.

Further, there are myriad combinatorials of this for instance, there is
a ua with built in a t or more than one.  there are possibly ats which
ride on top of a specific ua.  There are integrations of all three
components into specialized systems.

Our focus is on the ua which in many respects generalizes to the os.

This leads us according to our charter, purpose and scope to draw some
lines which can be extended as you suggest.  I don't have specific
sitings to hand, however, the extendability can be done through w3c
standards and os support.  Many of these are still in development and as
we have many ua types to deal with the best we can do for the moment is
in part what we have done in refering to extention through os standards
and w3c standards.  It is our hope I believe that this layer will come
about through this approach in that the os and the w3c standards will
develop towards your stated level where an a t will only need to hook
into what is going on with the os and that the ua will provide
additional ui through the w3c standard protocols.

As to the conformance issue, there may be something in the compliance
requirements that exempts special uas from compliance and allows what
might be a conditional rating meaning that it quallifies in a certain
class, but I doubt we'll tackle this before we finish the guideline
process its self.  This conformance rating would be based upon
documentation which has yet to be finalized if it is done at all.  I
think a better approach for our current purpose is to strongly emphasize
that our conformance is aimed squarely at the general class of browsers
to provide accessible rendering and ui capabilities to the extent
possible as this field evolves and that there should be other more
general a t software development documents that would come from a
process similar to this one but perhaps out of an operating systems
guidelines group from the at community.  There is an parellell to the w3
in the software/computer field which this could possibly be extended
through.


There are sisters to this working group as you know within the wai which
have and will be putting forth guideline documents which address some of
these issues.

I really want to send a strong wake up call to ua developpers some of
which are working with us so they don't need it that there Is a large
population which is or can be excluded by practices that do not take
certain things into account which these guidelines address well I hope. 
Much of this awareness raising has been done by the release of the web
content accessability guidelines and I am encouraged by this success so
far.
 
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
> 
> Seeing with Sound - The vOICe Video Sonification software
> http://ourworld.compuserve.com/homepages/Peter_Meijer/winvoice.htm

-- 
Hands-On Technolog(eye)s
Touching The Spider Web
ftp://ftp.clark.net/pub/poehlman
http://poehlman.clark.net
mailto:poehlman@clark.net
voice 301-949-7599
end sig.

Received on Monday, 6 December 1999 07:52:28 UTC