Re: Responses to Opera issues raised during third last call of UAAG 1.0 I

Hi Jonny,

Thanks for responding. My comments are preceded by IJ2: below.
I have snipped out comments that don't require clarification.

I have registered your objection about the DOM requirements and will
carry it forward (along with your selection) in our request to
advance to Candidate Recommendation.

Thanks again Jonny,

 _ Ian

> Jonny wrote:
> Mostly I am satisfied (a little more clarification on a couple points below
> would be appreciated), with a major exception at the end where I hope you
> will reconsider.
> 
[snip]
 
> >------------------------------------------------------------------
> >Issue 503: 9.3: Clarification requested: does this mean that
> >onfocus events are not triggered?
> >http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#503
> >------------------------------------------------------------------
> >
> >Issue summary: Do the requirements of 9.3 (now checkpoint 9.5) mean
> >that onfocus events are not triggered?
> >
> >Resolution: Yes (and more for the case of HTML)
> >
> >In the 22 June 2001 draft, checkpoint 9.5 reads:
> >
> >   "1.Allow configuration so that moving the content focus to or from
> >   an enabled element does not automatically activate any explicitly
> >   associated event handlers."
> >
> >The informative Note that follows gives examples for HTML:
> >
> >   "For instance, in this configuration for an HTML document, do not
> >   activate any handlers for the 'onfocus', 'onblur', or 'onchange'
> >   attributes. In this configuration, user agents should still apply
> >   any stylistic changes (e.g., highlighting) that may occur when
> >   there is a change in content focus."
> 
> I just want a clarification here. Normal behaviour when an element gets a
> focus is to activate onfocus and UI events and trigger the :active or :focus
> pseudo-classes.

IJ2: Yes.

>  We don't do that for keyboard access (e.g. A or TAB)
> currently, and the checkpoint prevents us from doing in the future.

IJ2: I'm not sure I understand your comment. We hope that the normal
behavior (triggering focus events, changing styles based on :focus, all
of which is defined by HTML and CSS) happens UNLESS the user has
configured 
the user agent per checkpoint 9.5.In this configuration, you should not
execute any onfocus/onchange event handlers.
 
> Alternatively (preferably?) this is a toggle to be set either in our
> accessibility panel or our javascript panel to turn off some (all?) events
> triggered as a part of normal document navigation. There is no need for such
> a toggle for CSS :active, :hover, :focus.

Right. You should continue to change styles in this setting so that the
user
may know through rendering where event handlers are found (but not
executed).
 
> >------------------------------------------------------------------
> >Issue 505: 11.3: Propose that single-key mode would be sufficient
> >technique
> >http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#505
> >------------------------------------------------------------------
> >
> >Issue summary: To meet the single-key requirements of what is
> >checkpoint 11.4 in the 22 June draft, can the user agent provide a
> >single-key mode (that may be turned on and off, and in which there are
> >the required single-key bindings)?
> >
> >Resolution: Yes. Checkpoint 11.4 now reads (in provision 4):
> >
> >   'The single-key binding requirements may be satisfied with a
> >   "single-key mode" (i.e., a mode where the current bindings are
> >   replaced by a set of single-key bindings).'
> 
> We can do that with the obvious limitation that we can only do as many
> single-key functions as there are keys available, after the OS has taken its
> dues. Also I hope, but cannot guarantee, that we can do this for Opera
> mobile devices and kiosks as well, but that is out of scope.

IJ2: Right. I think that the limitation you cite is covered by
checkpoint 11.4, provisions 3 and 5 together in the 22 June draft
  http://www.w3.org/TR/UAAG10/guidelines.html#tech-single-key

> ------------------------------------------------------------------
> 
> There is one issue that evidently hasn't been registered in the database. It
> is my major problem with the current working draft, which in my opinion
> makes it so broken as to be unusable in practice: Section 2.6, "Guideline 6.
> Implement standard application programming interfaces."
> 
> My issue with this checkpoint is practical and principal. To put it bluntly,
> unless a UA has DOM support or is advanced in the process of implementing it
> the current WD will have no relevance to UA implementors. Making a good DOM
> implementation is not a small (or cheap) matter of engineering, to my
> knowledge there are only two UAs with close to full DOM support,
> incidentally from the same two companies that created the specification to
> begin with.
> 
> That is not to say that DOM support isn't a worthwhile goal in itself or
> that DOM isn't superior to some proprietary API (not that all APIs are
> proprietary, conceivably it could be possible to make an accessible browser
> using SAX [1] for instance). But I object to the statement that the only way
> to make an accessible browser is to make one with full support of DOM2Core.
> 
> On principle it is bad thinking too. As stated [2] and not truly rebuffed
> [3], W3C specs use existing recommendations, but they don't build explicit
> dependencies unless there is an obvious reason to do so. Obviously XSLT
> doesn't make much sense without XPath, and SVG DOM builds upon DOM Core. But
> notably SVG itself does *not* depend upon DOM, you can have either static or
> dynamic SVG support [4].
> 
> I reiterate my suggestion that programmability should be a label, just like
> content type, input modality and selection [5].
> 
> Not resolved.
> 
> [1] <http://www.megginson.com/SAX/>
> [2] <http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0045>
> [3] <http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0079>
> [4] <http://www.w3.org/TR/SVG/conform.html#ConformingSVGViewers>
> [5] <http://www.w3.org/TR/2001/WD-UAAG10-20010622/conformance.html#content-
> type-labels>

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

Received on Friday, 13 July 2001 18:49:50 UTC