- From: Gregory J. Rosmaita <oedipus@hicom.net>
- Date: Fri, 21 Sep 2007 15:58:20 -0400
- To: wai-xtech@w3.org
aloha!
a hand-encoded hypertext version of the minutes from today's meeting as
quickly as i could and archived it in the www-archive depository,
attached to an explanatory post -- the direct URI for the minutes is:
http://lists.w3.org/Archives/Public/www-archive/2007Sep/att-0065/dhtml-
20070921.html
a lynx snapshot of the minutes follows -- i checked the document source
with HTMLTidy, but wasn't able to upload to a web accessible directory
for validation, so i shouldn't have declared XHTML 1.0 Strict, but
Transitional...
--------------------------------------------------------------------------
DHTML StyleGuide Call
21 September 2007
QUICK LINKS (skip)
Agenda | Attendance | Minutes |
_________________________________________________________________
Agenda for September 21st meeting
1. Drag-n-Drop specific keyboard recommendations for ARIA
(continued).
2. Review Radio Buttons:
+ When tabbing into a Radio Group that has nothing selected
should focus go to the first button, the last button, or the
radio group?
+ Also, John would like to revisit the requirement about
wrapping.
3. We will continue the discussion about the Accordion behavior after
Earl has time to rethink the use of the Tab key and has taken the
discussion to the PFWG.
4. Review Menu after Becky reviews her notes.
5. Tabindex and Focus as a discussion is recommended by Becky.
6. Context Help and use cases like prolog.
7. AXS Library
_________________________________________________________________
Attendance:
Tom Wlodkowski (TW/chair)
Chris Blouch (CB)
Tim Boland (TB)
Colin Clark (CC)
Collin ??: (University of Toronto)
Don Evans (DE)
Becky Gibson (BG)
Al Gilman (AG)
Jon Gunderson (JRG)
Earl Johnson (EJ)
Gregory J. Rosmaita (GJR/scribe)
regrets: Lisa Pappas
_________________________________________________________________
Minutes: DHTML StyleGuide Call, 21 September 2007
TOPIC 1: Drag and Drop
DE: RichS not here
TW: move on to next agenda item
TOPIC 2: Review of Radio Buttons
DE: JRG's issue, right?
JRG: updated example -- up and down arrow keys cycles through radio
buttons
JRG: if no radiobutton checked, radio group container gets focus --
has describbedby on radio group container which would be
announced/exposed via AT
JRG: currently if tab through first one has focus (most
UAimplementations)
GJR: checkbox groupings useful if tab to grouping, use describedby to
label, user has choice to enter grouping or move to next with TAB
BG: concerns me
CC: what if automatically announces the value describedby and places
on the first button in grouping
BG: or first author-defined -- if no selected, goes on first, if
pre-selected goes there
JRG: when radio group comes into focus, focus set to first radio
button, unless one pre-selected in which case it would go to
pre-selected, otherwise go to first
BG: move to radio button and then use up or down arrow to select if no
pre-selection
CC: forms mode automatically chooses first button in JAWS; in general
should be able to use spacebar to select
JRG: when tab using FireFox, tabs through all radio buttons
BG: FireFox and MSIE behave differently
JRG: from MSAA perspective if focus on radio button, all i know is i
am on a radio button that is selected; AccessibleName in MSAA can
provide describedby label for grouping and communicate number of
options in radio group?
BG: already an HTML element -- fieldset -- and style it not to draw
box
AG: fieldset and legend with actual HTML radio buttons; what if not
using actual radio buttons? will fieldset accomodate that case?
BG: radiogroup could be used for same purpose; should define the
model; dojo doesn't choose group, but leaves it to UA, because that is
what is expected from the UA
GJR: radiogroup necessary in FORM embedded in TABLE; fieldsets and
legends can't span table cells and are invalid inside them;
BG: don't need behavior for radiogroup cause can get another way;
don't want to say you HAVE to put things into a group, but provide
best practice guidance
CC: respect UA mechanism; first one selected when radiogroup receives
focus; TAB into set of radio buttons; arrow keys control radio buttons
and then TAB out; from Style Guide perspective that's as far as need
to take this
JRG: emulate IE behavior?
CC: if can arrow through, don't have conflict with tabbing to other
items
Earl Johnson joins
CC: minimize tabbing by moving from grouping to grouping; TAB into
widget, TAB out of widget
JRG: goal - work like IE? spacebar should select and arrow keys to
inspect
BG: if come in via SHIFT+TAB would start at bottom of list
CC: expected behavior; items select as go through combobox
EJ: UAs currently when set of radio buttons receives focus, one will
always have focus
CC: pre-selected if none defined go to top if TAB to it, bottom if
SHIFT+TAB to it
JRG: have to press spacebar to select current radio button -- either
last or first one;
EJ: can't leave without at least 1 radio button chosen
DE: tab into group of radio buttons with no pre selection; arrow down,
select second button, right -- if TAB, move to the next group
JRG: IE tab moves focus to group and no pre-selected button without
selecting -- can TAB out without choice
AG: HTML states invalid if not one selected;
TW: summary: 1) tab into group of radio buttons; 2) if no button
selected group name announced and first button first to receive focus;
if use arrow keys to move between radio buttons select as go or
selected using spacebar (select/deselect)
AG: AT may voice label of group, label of selection upon entering
group, and announce state (selected/unselected) -- needs to be there
in context
GJR: why is selection different if TAB or SHIFT+TAB?
AG: minimum scroll -- moving minimum distance to get where going; if
approach from bottom encounter bottom -- nearest available point in
bag of items
TW: GJR are you satisfied?
GJR: think form controls different case from menus, question whether
should bow to legacy conventions
GJR: behaviour should be: when shift-tabbing into group, if one button
is pre-selected, it gets focus and its label is exposed, but if none
pre-selected, should go to first in gruoping
AG: inheriting legacy conventions/inherent implemented behavior
EJ: support TW's explanation
PROPOSED: emulate browser behavior by TAB selects first if none
selected; SHIFT+TAB selects last if none selected
TW:: Earl, are you ready for accordion behavior discussion?
EJ: not ready to discuss yet -- have just finished a new draft; want
to re-vett
TW: push accordion discussion to 1 October meeting
Tim Boland (NIST) joins
BG: updated spec and LisaP put into wiki and sent update emails to
XTech; second changed what was on wiki
EJ: pound 6 to mute yourself, star 7 to unmute
BG: action item changed: took proposal i had for menus, updated and
LisaP put into wiki; within the past week, proposed on list to change
-- previously said disabled menu items receive focus, but since
disabled radio buttons thought should be consistent; part of proposal
was consistency in dojo code -- if buttons in toolbar don't get focus,
why giving foucus to disabled menu items; windows does give disabled
menu items focus; mac doesn't give disabled buttons, menu items or
toolbar buttons
TW: web differs from OS -- certain actions may cause another menu to
come into focus; user might need to know what is and isn't available;
web widgets may be a one-off encounter -- user needs to know what
options are
TW: difference between software and web conventions as to what is
there and what is available or not
GJR: menu items need explicit disabled state announcement
AG: with exception of formatting bar type buttons, buttons are
arbitrarily displayed atomically -- menu a range of choices, more
often where need to hear full range of choices to understand full
range of choices
CC: web widget -- consumer point-of-view; if have things that are
there but not available, if greyed out, user needs to know (a) it is
there and (b) that it is disabled -- need to keep in mind use case --
do want to know what is not available
BG: should buttons be in tab order if disabled?
CC: yes, asynchronous world of widgets -- how do i know it exists or
doesn't exist; not sure can make assumption if disabled can skip over
it; can be used as flag of incomplete section of form (for example,
credit card info before array of choices displayed); consumers may not
interact on daily basis or enough to build up type of knowledge that
the function exists
BG: but UAdoes not include disabled in tab order
DE: still visible, right?
BG: visible but not keyboard accessible; if enable buttons -- if undo
not available, do you want to hear "unavailable"; buttons on toolbar
should be consistent with buttons on page; should not be in tab or
arrow key order
EJ: screen reader in desktop where item greyed out, the assistive
technology allows user to discover information, while allowing visual
only keyboard user to skip over it, but still aware that it is there;
logic in AT to do that; are we pushing burden from AT to UA?
TW: can't do in context of AT in UA
AG: if a screen reader reads all the text in a document instance, it
is available
BG: run out of keystrokes quickly; heading 1 or level 3 or div, need
drop down -- usually in toolbar; dojo does that
AG: 1) one will never know what one doesn't know; other side is voting
with feet -- how many blind users tab through without listening to
whole page first -- a lot because it is faster and they simply want to
accomplish a task, efficiently and with accuracy;
TW: menu perspective, tab into menu, arrow through, and then tab away,
so in menu want to know what is available and currently unavailable;
button perspective, may need to know in web environment what don't
need to know in desktop environment
EJ: AT could be expected to do it -- sighted user can skip over greyed
out portion, but what about non-visual user?
BG: don't know if assisstive technology there; either set focus on it
or don't; don't know what user wants
BG: author defining flow and focus, can't be intercepted by AT
AG: could recognize that focus moved between items on menu item, but
unlikely that special algorithms to be written for different;
TW: How do we do this here and now? menu items not available need to
be arrowable
GJR: agree with that
TW: need AT devs involved in discussion like this; can't expect that
user agent or AT will help for several years; disabled should be
arrowable and debate buttons as different issue
BG: let me play devil's advocate -- screen reader can't get info if
can't arrow to it, but adding extra keyboard actions for sighted users
might be a drawback
AG: could you live with it if ArrowDown reads label and announces
disabled state?
TW: yes, but not something web developer would do
GJR: should be under user control whether to render what is disabled;
on windows platform have option to "hide" infrequently used menu item,
so why not a UA conformance GL that states user should be able to
choose between verbose (expose all even if disabled) and terse (only
expose what is available); separate settings for menu and buttons
needed; user needs control over granularity
EJ: delivery time is an important issue
TW: consumer wants things accessible today, not "in the next 6
months..." which usually turns out to be 4 or 5 years, if ever...
AG: split menus and buttons -- leave draft position on buttons?
TW: buttons add more tab-stops
AG: more and more dubious tab stops
Consensus: disabled menu items should be arrowable; menu widget is a
tab-stop -- when arrow through disabled menus announced that disabled;
disabled buttons still an open issue
TW: next meeting -- accordion, check with LisaP on progress of Best
Practices document
EJ: will forward drag and drop use cases to xtech -- hope will help
drag and drop move forward
AG: what you're writing about is exactly what is missing
* meeting adjourned at 17:13 UTC
* next meeting Friday, 5 October 2007, at 1600 UTC
_________________________________________________________________
Received on Friday, 21 September 2007 19:58:29 UTC