Re: UA Guideline review, rev. 1

Hi Ian,

One response to your latest feedback. It starts with EJ and ends once
the > symbols start back up.

ej

> > > > 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?"
>  
EJ	This doesn't seem to catch the API aspect of the checkpoint.
	"Through the UI" suggests to me that this is refering to the
	user who is able to interact with the UA through it's primary
	mode of presentation (e.g. visually in a GUI). Keeping with the
	GUI example, this doesn't seem to cover the situation where a
	user is utililizing an assistive technology (AT) to translate
	this visual information into another presentation modality
	(e.g. audio). This type of situation is, I believe, what the
	mention of API in the checkpoint was meant to cover. I thinks
	it's good for the checkpoint to still clearly cover the jist of
	the point being made by mentioning API even if API isn't
	specifically mentioned in it (not mentioned, for example,
	because developers may not utilize an accessibility API to
	enable the alternate interaction modality while still
	supporting the programmatic capability that enables an AT to
	get at the info so it can be translated).

> >         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 Monday, 6 December 1999 15:07:53 UTC