Re: 9 March 2001 UAAG 1.0 Guidelines and Techniques available

"Hansen, Eric" wrote:
> 
> Following are a few comments:

Eric,

Thank you for comments. I've snipped out points of agreement.
My comments preceded by IJ:.
 
> > 2) Please review checkpoints 4.13, 4.14, 4.15. I rely
> >    on the expertise of the group to get the wording
> >    of these speech requirements right.
> >
> EH: It is not obvious to me that checkpoint 4.15 (user defined extensions
> re: speech) expresses a clear minimum requirement. Seems to need refinement.

IJ: I think we will need a little bit more work on these 
checkpoints. Refer to related proposals/comments:

On terminology used
 http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0449
Suggestion from Al for more precise wording for 4.14:
 http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0459

I think we should try to do for all three what Al suggested for
4.14.


> EH: Enabled element entry is out of order.

IJ: Fixed.
 
> Re: Enabled it is not clear who or what is doing the 'choosing'.... Is it
> the user or the user agent or the state of the interaction causes it to be
> chosen? Also, if it can happen through an API then other programs can do it.
> Why not remove the parentheses? Also since it must happen during a session,
> it could not be enabled through prior configuration.... right?
> 
> Old:
> Enabled element, disabled element,
> An enabled element is a piece of content that is subject to user activation
> through the user interface (or indirectly through an API) at a chosen moment
> during the user's session. The set of elements that a user agent enables is
> generally derived from, but is not limited to, the set of interactive
> elements defined by implemented markup languages. ...
> 
> New: ?
> Enabled element, disabled element [REMOVED COMMA]
> An enabled element is a piece of content that is subject to user activation
> through the user interface or indirectly through an API at a chosen[???]
> moment during the user's session. The set of elements that a user agent
> enables is generally derived from, but is not limited to, the set of
> interactive elements defined by implemented markup languages. ...

IJ: I have adopted your proposal.

> Focus
> Can the first sentence be made more precise (at most, at least, etc.)?
> 
> "When several viewports coexist, each may have one content focus and one
> user interface focus. At all times, only one viewport's content focus or one
> user interface focus receives input events; this is called the current
> focus."
> 
> New [????????]:
> "When several viewports coexist, each may have AT MOST one content focus and
> AT MOST one user interface focus. At all times, AT MOST only one viewport's
> content focus or one user interface focus receives input events; this is
> called the current focus."

IJ: I have adopted your proposal.
 
> Comment:
> Are these definitions incompatible with braille output viewport... Just
> checking robustness.

IJ: I will let a reviewer with more experience using a braille
viewport comment.
 
> > 7) Check out the new section on how to refer to this document.
> 
> Old:
> "For very general references to this document (where stability of content,
> anchors, etc. is not required), "
> 
> New:
> "For very general references to this document (where stability of content,
> anchors, etc.,[ADD COMMA] is not required), "

IJ: Ok.


> >  * Add executive summary
> 
> EH: See separate memo.

IJ: Thank you for getting the ball rolling. I expect to 
be able to spend some time on the summary this week.
 

> > * 3.2: Content type "Animation", not "Image". But leave video as
> >   well.
> EH: Not sure what this comment means.

IJ: Sorry, this was kind of cryptic. Because the definition of
"animation" includes "video", I was wondering whether
animation/video/image
content type labels should all refer to mutually exclusive sets of
checkpoints. In the end, for 3.2, I thought it best to leave
two content type labels: Animtion (for animated images), Video.

In general, I have been wondering whether animated images should
fall under the "Animation" label or the "Image" label or both.
I think that I prefer just under Animation given the nature
of the requirements (and the document reflects that). 
Comments are welcome.
 
> > * 5.1, 5.2, 5.3: Changed per proposal from Ian, adopted at 8
> >   March teleconf.
> EH: Does confirming a prompt meet the definition of 'on demand'? Just not
> sure may be OK (checkpoint 5.3).

IJ: Yes, it is supposed to (the user selects "yes", which is an
option known to the UA).

> > * 9.8: Clarification about where the default search starting point
> >   should be (when user has not indicated). Based on resolution from
> >   1-2 March face-to-face.
> EH:
> For checkpoint 9.8, the idea of the 'alert' seems like only half the
> requirement. Do we mean to say the the person should have a choice about
> whether to terminate or continue the search wrap that is about to occur?
> Also, if one wants to terminate the search, what should happen to the
> focus/selection? Seems it should be made explicit...

IJ: I think that we limited our requirement to "alert" because the
issue was simply not knowing that you had wrapped. I don't think it's
as important a requirement to not wrap.

We haven't discussed what happens when a search terminates. Do you
have any proposals? I'm not sure we need to say anything.

 - Ian
-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Monday, 19 March 2001 17:28:48 UTC