Re: [Review] Tantek Çelik / Ian Jacobs comments on 9 April 2001 UAAG 1.0 (Part I)

Hi Eric,

My comments preceded by IJ: (and lots snipped).

 _ Ian

"Hansen, Eric" wrote:


> EH: Worth discussing.
> 
> > ========================================
> > 5) Configuration not required when the user agent always or
> >    never does something?
> > ========================================
> >
> > Many of the checkpoints involve configuration
> > requirements. However, configuration may not be necessary if the
> > user agent always or never provides the critical functionality in
> > question.

We started to discuss this at the 10 May teleconference [1] but
didn't get very far. The way it was expressed at the teleconference,
it was not clear whether for each checkpoint, the configurability
was as important as the feature being configured. 

This will require more work and discussion.

[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0127

> > ================================
> > 6) Checkpoint 2.9: Automatic rendering of all conditional content
> >    at once required?
> > ========================================

[snip]

> > Comments:
> >
> > - Tantek asked whether alternative style sheets should be
> > considered conditional content. I didn't think so at first, but
> > the more I think about it, the more I think they should be
> > considered conditional content. The definition of conditional
> > content starts:
> >
> >  "Conditional content is content that, by specification, should
> >  be made available to users through the user interface, generally
> >  under certain conditions (e.g., user preferences or operating
> >  environment limitations)."
> >
> > Checkpoint 4.16 requires that the user be able to choose from
> > available author style sheets, which includes alternative style
> > sheets. I note that the definition says "user interface" rather
> > than "viewport" specifically (where *content* is rendered).
> >
> > The proposed change to 2.9 is consistent with providing
> > alternative style sheets one at a time (instead of all at once,
> > automatically) as required by 4.16.
> 
> EH: I think that this would be an expansion of our intent. I am really not
> sure of the consequences of such an expansion. This gets back to what is
> "content" and what is its relationship to the DOM.

IJ: Content = DOM in UAAG 1.0. I agree that style sheets and
scripts were not part of our original intention when discussing
conditional content. I think we meant "stuff that can be rendered
for consumption". This is not to be taken as a challenge but
as a sincere request: can you provide a better definition of
conditional content?

> > ========================================
> > 8) Require focus for enabled elements only. Don't require
> >    selection. Clarify that "user interface focus" is not related
> >    to viewports (but instead to other controls of the user
> >    interface).
> > ========================================

[snip]

> > To implement this proposal:
> >
> > 8a) Fix 9.1, which is broken in a number of ways (that are not
> > really serious):
> >
> > <NEW 9.1a>
> > Allow the user to make the selection of each viewport (including
> > frames) the current selection. For content only.
> >    Note: UAAG 1.0 does not require a conforming user agent to
> >    implement a user selection. The selection requirements of this
> >    document only apply when the user agent implements a selection.
> > </NEW 9.1a>
> >
> > <NEW 9.1b>
> > Implement one content focus for each viewport where
> > enabled elements are part of the rendered content. Allow the user
> > to make the content focus of each viewport (including frames) the
> > current focus. For content only.
> >    Note: UAAG 1.0 assumes that a viewport has at most one content
> >    focus. The requirements of this document should still make
> >    sense for viewports with more than one focus.
> > </NEW 9.1b>
> >
> > <NEW 9.1c>
> > Implement a user interface focus mechanism. Allow the user
> > to move the user interface focus to any enabled user interface
> > control. User agent only.
> > </NEW 9.1c>
> >
> > Comment on 9.1c: This is like checkpoint 9.2, but for the UI.
> >
> 
> EH: What priorities for the foregoing?

IJ: All P1 (as is the original 9.1).
 
> > 8b) Add an applicability provision related to selection:
> >
> >    "A checkpoint (or part of a checkpoint) applies unless any one
> >    of the following conditions is met:"
> >
> >    <NEW CONDITION>
> >    The checkpoint makes requirements about the selection, but the user
> >    agent does not implement a user selection mechanism.
> >    </NEW CONDITION>
> >
> > 8c) Checkpoint 9.3: I think that the "user interface focus"
> > should *not* be associated with the viewport for any requirements
> > in the document, including for checkpoint 9.3.  The user
> > interface focus is set on other controls of the user
> > interface. Therefore, I think that checkpoint 9.3 should not
> > include "user interface focus" in the list of state information
> > that must be part of the *viewport* history.
> 
> EH: Sounds reasonable.

IJ: I thought about this some more. Instead of an applicability
provision, perhaps a selection label would be better. There are
about 10 checkpoints related to the selection.

> > 8d) Change 5.1 so that "current focus" (which includes both
> > content focus and UI focus) does not refer just to viewports.
> >
> 
> EH: I wonder if the definition of focus needs to be clarified in the
> document.
> 
> Old:
> 
> In this document,the unmodified term "focus" means both "content focus" and
> "user agent focus".
> 
> When several viewports coexist, at most one viewport's content focus or user
> interface focus receives input events; this is called the current focus.
> 
> I am not sure if BOTH means SIMULTANEOUS or not.
> 
> New:
> 
> In this document,the unmodified term "focus" means SIMULTANEOUS "content
> focus" and "user agent focus".
> 
> When several viewports coexist, at most EITHER one viewport's content focus
> or ONE user interface focus receives input events; this is called the
> current focus.
> 
> =
> Maybe I am misinterpreting, but I think this could be clarified.

IJ: I agree that clarification is required. I think of them
as not being simultaneous, but rather any requirement that
applies to the "focus" applies to both the content focus and the 
UI focus.
 
> > ================================
> > 15) Definition of "non-interactive element",
> >     checkpoints 9.2 and 9.6
> > ================================
> >
> > Tantek did not like the definition of "disabled" element as any
> > element that is not enabled. This means that a paragraph of text,
> > which might never be enabled in any session, would be considered
> > a disabled element.
> >
> > Instead, he proposed adding a definition of "non-interactive
> > element". Please consider this definition:
> >
> >   "A non-interactive element is piece of content that, by
> >   specification, is not expected to be an enabled element in
> >   any user session."
> >
> > The definition of disabled element would become:
> >
> >   "A disabled element is an element that is not enabled
> >    in the current user session but could be in some user
> >    session."
> >
> > Non-interactive elements might be enabled in some sessions
> > because of how the user agent chooses to handle them.
> 
> EH: Need an example of this.

IJ: I don't have a good example. I think it will be a rare
occurrence.

> > ================================
> > 16) Checkpoint 9.5: Moving focus without triggering handlers
> >     may be wrong.
> > ================================
> >
> > Tantek argued that:
> >
> >  a) If there are no focus handlers on a page, this is not necessary.
> >  b) If there are no focus handlers on a page, not firing them
> >     may break the page.
> 
> EH: Ian, is the above quote correct? "If there are no focus handlers on a
> page"..?

IJ: (b) should read "If there are focus handlers on a page..."

> > We did not discuss the technical feasibility, only whether it was
> > a good idea at all.
> >
> > This functionality (like others in our document) does not
> > guarantee access, and it may even break some pages. Still, it may
> > enable access in some cases where access would not otherwise be
> > possible. Perhaps the best approach is to get more experience
> > with implementations of this checkpoint and see if it's actually
> > usage.
> >
> > A good place to start is to design a test case where we think
> > that not firing an onfocus handler automatically would improve
> > access (in conjunction with the other checkpoints for manual
> > firing).
> 
> EH: Maybe I don't fully grasp this. Needs further discussion.

IJ: Tantek's point (I think) was that the functionality of
a page may be tightly bound to the behavior of focus handlers.
And so turning off might make the page unusable.

To this type of comment I generally say: It might also make the page 
more usable. This is where we let the user make the decision.
 
> > =======================================================
> > 21) Checkpoints 12.2, 12.4, 12.5: Definition of features
> >     that benefit accessibility.
> > =======================================================
> >
[snip]
> > 21a) In checkpoint 8.1, change the statement to:
> >
> >   "For the purposes of this document, the accessibility features
> >   of a specification are those identified as such and those that
> >   enable the author to satisfy the requirements of the "Web
> >   Content Accessibility Guidelines 1.0" [WCAG10], whatever the
> >   priority."
> >
> >   Editorial: Should this read "and those" or "or those"?
> >
> EH: Possible alternative wording:
> 
> "For the purposes of this document, the accessibility features
> of a specification are those identified as such and those that
> enable the author to satisfy ANY OF the requirements of the "Web
> Content Accessibility Guidelines 1.0" [WCAG10."

IJ: Yes. Although it might still be valuable to reiterate
all levels in the Note (for example).

 - Ian

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

Received on Friday, 11 May 2001 23:22:28 UTC