W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 2001

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

From: Jonny Axelsson <jonny@opera.com>
Date: Thu, 12 Jul 2001 01:35:57 +0200
Message-Id: <200107112330.f6BNUFL12277@mail.opera.no>
To: "Ian B. Jacobs" <ij@w3.org>, w3c-wai-ua@w3.org
CC: Debbie Spackman <debbie@opera.com>, Håkon <howcome@opera.no>
05.07.01 16:16:51, "Ian B. Jacobs" <ij@w3.org> wrote:


>Please indicate before 19 July whether you are satisfied with the
>UAWG's resolutions, whether you think there has been a
>misunderstanding, or whether you wish to register an objection.
>If you do not think you can respond before 19 July, please let me
>know.  The Director will appreciate a response whether you agree
>with the resolutions or not.
>Below you will find:
> 1) More information follows about the process we are following.
> 2) A summary of the UAWG's responses to each of your issues.
>Note: Where checkpoint numbers have changed, I indicate the mapping to
>the 22 June 2001 draft.
>Thank you,
> _ Ian

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.


>  Phill Jenkins:
>  http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0528    
>  Gregory Rosmaita:
>  http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0553
>[1] http://www.w3.org/TR/2001/WD-UAAG10-20010409
>[2] http://www.w3.org/Consortium/Process-20010208/tr.html#RecsCR
>[3] http://www.w3.org/Consortium/Process-20010208/groups.html#WGVotes
>[4] http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3
>[5] http://www.w3.org/TR/2001/WD-UAAG10-20010622/

>2) Issues you raised and responses

>Your original comments:


>Issue 502: What constitutes blinking? 


>Issue 503: 9.3: Clarification requested: does this mean that 
>onfocus events are not triggered? 
>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. We don't do that for keyboard access (e.g. A or TAB) 
currently, and the checkpoint prevents us from doing in the future.

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.

>Issue 504: 7.2, 10.3, 10.7, 12.3: Default values and inheritance 
>from operating environment 


>Issue 505: 11.3: Propose that single-key mode would be sufficient 
>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.

>Issue 514: Checkpoint 1.1: If UA functionalities are keyboard
>operable, must all UI controls be? 
>Issue summary: The requirement of checkpoint 1.1 is about keyboard
>access. Does this mean that all user interface controls must be
>keyboard operable, or is the functionalities they provide access to
>that must be available through the keyboard?
> - The UAWG agreed with the reviewer: it is the functionalities first
>   and foremost that must be available through the keyboard.
> - As a result, checkpoint 1.1 was modified and reads in the 22 June
>   draft:
>     "Ensure that the user can operate through keyboard input alone
>     any user agent functionality available through the user
>     interface."

I think this is doable, as I don't think there is any functionality that 
cannot be expressed through keyboard bindings. In some cases it may be less 
convenient than say pointer bindings (and in more cases the opposite), but 
the functionalities should always be expressible. Resolved.


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-

Jonny Axelsson
Opera software
Received on Wednesday, 11 July 2001 19:34:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:31 UTC