RE: Style guide: request two agenda items.

Focusing of disabled elements:

I think everybody should get rid of the idea that disabling means for
Keyboard Users "you don't need that, so skip it" in all cases. Blind
people will miss something that is disabled in PC Cursor mode while
tabbing (by the way, "disabled" is an information, too!).

We resolve that gordian knot issue by having a special keyboard
navigation user configuration property in which disabled elements are
also in the tab chain, overridable default is false.

The behavior of disabled elements is very much like read-only when
focused, meaning no action, just KB navigation is allowed.

For example, it is perfectly possible to navigate between disabled tabs
of a tab strip with arrow keys.

- Stefan

-----Original Message-----
From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On
Behalf Of Wlodkowski, Thomas
Sent: Dienstag, 15. April 2008 17:23
To: Joseph Scheuhammer; Evans, Donald; wai-xtech@w3.org
Subject: RE: Style guide: request two agenda items.


We can discuss today time permitting.

Reminder: The DHTML style guide is scheduled to meet at noon Eastern
time today. To participate call:
Local- 703-265-5000
Toll-free U.S. 877-708-6777
Meeting ID- 51999

Tom



-----Original Message-----
From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On
Behalf Of Joseph Scheuhammer
Sent: Tuesday, April 15, 2008 10:31 AM
To: Evans, Donald; wai-xtech@w3.org
Subject: Style guide: request two agenda items.


Don,

On behalf of the PFWG and the Dojo community, I am requesting two items 
be added to the agenda.  The PFWG wants a recommendation about keyboard 
access with respect to disabled widgets.  Dojo is looking into adding 
keyboard navigation to their DateTimeBox, and want some pointers.

PFWG:
----

At yesterday's (Mon Apr 14), teleconference, we discussed the problem of

disabled, invalid, and required properties of widgets.  In particular, 
the issue of keyboard navigation for disabled composite controls such as

a spreadsheet or a menu came up (yes, that old nut again).  The group 
decided to ask the DHTML style guide for a reommendation, and I 
volunteered to pass that request along.

Some background in this regard:  the main example discussed was a 
spreadsheet, and some thought that if the spreadsheet was disabled, then

users could not arrow around the cells.  When asked how a blind user 
and/or screen reader would explore the composite, a proposal was that 
that the screen reader could be switched to "browse mode" for that 
purpose.  A couple of questions:  would that work in the case of a 
disabled menu?  Do all AT's have a browse mode; for example, does an 
onscreen keyboard have a browse mode?  And, in general, how should 
disabled controls be handled via the keyboard?

Dojo:
----

The latest dojo/dijit meeting brought up a question about key strokes 
for their DateTextBox widget.  An example can be found here:
http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test
_DateTextBox.html

Currently, keystrokes are confined to the text entry field of the 
DateTextBox.  Users cannot navigate the popup calendar view using the 
keyboard. (Becky has pointed this out to the group, in the past).  
Entering a date via keyboard is accomplished by typing a year, month, 
day and arrowing about that text string.

The style guide recommends a rich set of keystrokes for the date picker:
http://dev.aol.com/dhtml_style_guide#datepicker

The questions that the dojo developers asked:
- is the style guide date picker month view a popup?  Or, is it a static

component on the page? (I believe that answer is:  it can be either).
- if it is a popup, is it ever associated with a text entry field?

The style guide is neutral with respect to the last question.  This is a

Good Thing (TM) in that it allows implementors to decide when, and where

to provide a date picker.  That is, if a developer want to use it as a 
popup companion to a text entry field, then that's up to them.  But, if 
they do, the recommended keyboard access is as described in the style
guide.

Keyboard focus and keystroke issues arise in the text entry field + date

picker combination.  Where should focus go -- should it always be in the

text entry field, or switch between the field and the picker?  What do 
arrow keystrokes do -- navigate among the characters in the text entry 
field, or among the dates in the picker?

A solution is to allow focus to switch between the text entry field and 
the picker, and then define the keyboard behaviour relative to where 
focus is.   As such, a date picker feels related to a combo box in the 
sense that there is (1) an editable text entry field in which to 
enter/edit values, and (2) a popup from which to select values.  Note, 
however, that the style guide for combobox does not specify any key 
strokes for the text entry field:
http://dev.aol.com/dhtml_style_guide#combobox

-- 
;;;;joseph

'This is not war -- this is pest control!'
      - "Doomsday", Dalek Leader -

Received on Wednesday, 16 April 2008 07:04:29 UTC