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

Re: UA Guideline review, rev. 1

From: Ian Jacobs <ij@w3.org>
Date: Sun, 05 Dec 1999 20:40:50 -0500
Message-ID: <384B1422.80D95C1E@w3.org>
To: Earl Johnson <Earl.Johnson@eng.sun.com>
CC: w3c-wai-ua@w3.org
Hi Earl,

Thanks for the clarifications. I've snipped out a lot that
I've incorporated editorially

 - Ian

> EJ      There may be some guideline wordsmithing but I don't
>         imagine much in today's TOC will change with my suggestions.
>         If there are changes it would be in the checkpoints.
> 
>         The basic structure I had in mind for making things clearer to
>         developers was similar to what is used in guideline #4. Using
>         the work you've done breaking up guideline #5 below hopefully
>         conveys the basic idea that all the guidelines would present.
> 
>   Guideline 5.
>         Sub-guideline
> 
>   Important for Content Display accessibility
>         5.6
>   Important for UI accessibility
>         5.2
>         5.3
>         5.4
>         5.8
>   Important for Content Display and UI accessibility
>         5.1
>         5.5
>         5.7

I'll try this out in the next draft of the Guidelines
for review by the WG.
 
> > > Section 2 - UA Guidelines
> > >
> > > Guideline #1
> > >
> > > Checkpoint 1.1 - The second sentence should be removed because it feels
> > > like a design decision. It's a good point though so move it to the note
> > > or Techniques document.
[snip]
> EJ      Ok. How about something like "Ensure that the user agent
>         supports all input device APIs support on the platforms it is
>         designed to work on."

There are a number of requirements to be handled:

 - make ALL functionalities available
 - make them available through ALL SUPPORTED APIs
 - make them available through STANDARD APIs on the system.

The first two are covered by 1.1. The third is covered by 1.2.
It was a conscious decision to split the three pieces up since
three requirements in one sentence was hard to manage. 

Your proposed checkpoint doesn't capture the first requirement above.

> > > Checkpoint 2.7 - What if the object isn't video or audio? Is this
> > > checkpoint just for timed media or does it cover things like graphics
> > > or interactive objects that say nothing about themselves?
> >
> > The checkpoint reads: "When no text equivalent has been supplied,
> > indicate what type of object is present."
> >
> > This applies to any object for which an alternative equivalent
> > has not been provided.
> 
> EJ      What if the object isn't recognized by the UA? As an example,
>         browsers that don't recognize Java applets can only tell the
>         user it's an applet they aren't viewing if the author
>         identifies it as an applet in the tag (appologies if this is no
>         longer a relevant example but hopefully you get the drift). I
>         can think of no alternate wording to propose but do feel the
>         checkpoint should be worded so it makes a nod to this reality.

This case is covered by the "applicability" provision. From
the definition of "applicability", a checkpoint doesn't apply if:

      "The checkpoint includes requirements about a content 
       type (script, image, video, sound, applets, etc.) 
       that the user agent does not recognize at all."

A lot of people have missed the applicability provision in the
glossary and I'm really starting to think it should be moved back
to the section on conformance.

> > > Guideline #4
> > >
> > > A. Mentioning speech rate and pitch suggests to me the UA is the one
> > >    providing the audio service.
> > >    1. Does this aspect of the guideline still hold true if the platform
> > >       the UA is running on provides the service?
> >
> > If the UA makes use of services provided by the operating system, that's
> > great!
> >
> > >    2. Isn't it the audio service that should provide the control?
> >
> > If the audio services is not "native" to the User Agent, then yes.
> >
> > >    3. Does this mean the UA will need to provide a controller UI for
> > >       all the audio services the user might have (e.g. different TTS
> > >       devices)?
> >
> > I'm afraid I don't understand the question.
> 
> EJ      My confusion in speech's mention is what is a developer
>         supposed to do in the way of enabling control when their UA is
>         meant to rely on the platform's speech not provide it itself? 

Then  control and responsibility reside with the OS. Refer to
recent clarification by the WG that "native" includes use
of OS features. From the 1 December teleconf minutes [1]:

   Resolved: Amend "native" definition to include features provided by
   the operating system.

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0523.html

>         I think the only resources that should be mentioned in the
>         sub-guideline are only those a UA will always be providing
>         (e.g. color for a GUI UA). Since speech and the others are just
>         examples how about just removing them or moving them to the
>         descriptive text?
> 
[snip[
> > This merits some discussion. Refer to issue 124
> > http://cmos-eng.rehab.uiuc.edu/ua-issues/issues-linear.html#124
> >
> EJ      If nuetrality is the goal then why shouldn't the guidelines
>         also be organizationally nuetral? 

We're number one! We're number one! <wink>

>         You have a bully pulpet here
>         in that you are telling all developers only W3C standards are
>         acceptable for content and that everything else can use someone
>         else's API or no as long as the base functionality defined in
>         the guidelines is met. This example seems far fetched but what
>         happens if someone comes up with a better than W3C standard
>         that the industry widely adopts, competes directly with one of
>         the W3C standards mentioned in the guidelines, and will never
>         be submited as a W3C standard? If the answer is put it in the
>         Techniques document then shouldn't the answer, for fairness
>         reasons, be the same for the W3C standards?

We'll be sure to address this at the face-to-face this coming week.

> > >
> > > Guideline #9
> > >
> > > Checkpoint 9.1 -
> >
> > Current text: "Provide information about user agent-initiated
> > content and viewport changes directly to the user and through APIs."
> >
> > > The "to the user and through APIs" part isn't clear.
> > > This isn't right either (because not all UAs will have a visual
> > > display) but "visually and programmatically" seems closer to the point
> > > it appears to me the checkpoint making.
> >
> > It's not only visually. It can be through audio cues.
> >
> EJ      Since the example caused confusion, perhaps I should have said
>         something that encompases the presentation aspect more
>         generally. How about "...through the UA's primary mode of
>         presentation and through externally available APIs." instead?
>         Externally here means it's a a part of the UA however it's a
>         public (provided by the UA and available to developers) not
>         private interface.

How about: "Through the user interface?"
 
>         Of course then the question is, since API I assume means an
>         accessibility API, what happens if the developer decides to use
>         the older fashion of suporting access - use a standard toolkit
>         that provides no but makes it possible for AT to get at what
>         they need (at least in that rev) - to support? It's for this
>         reason I originally suggested saying programmatic instead of
>         API. What does API mean if API is broader than accessibility
>         API?

The DOM is not particularly and accessibility API, but it is an API
that will be useful for accessibility, and for scripts, and for
content transformations.
 
 - Ian
Received on Sunday, 5 December 1999 20:41:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:49:34 GMT