- From: Jonny Axelsson <jonny@opera.com>
- Date: Thu, 12 Jul 2001 01:35:57 +0200
- 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: >Jonny, >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. Jonny > 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: >http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0045 >Follow-up: >http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0079 >------------------------------------------------------------------ >Issue 502: What constitutes blinking? >http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#502 >------------------------------------------------------------------ Resolved. >------------------------------------------------------------------ >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. 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 >http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#504 >------------------------------------------------------------------ Resolved. >------------------------------------------------------------------ >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. >------------------------------------------------------------------ >Issue 514: Checkpoint 1.1: If UA functionalities are keyboard >operable, must all UI controls be? >http://server.rehab.uiuc.edu/ua-issues/issues-linear-lc3.html#514 >------------------------------------------------------------------ > >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? > >Resolution: > > - 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- type-labels> Jonny Axelsson Documentation, Opera software
Received on Wednesday, 11 July 2001 19:34:15 UTC