DE: RichS not here
TW: move on to next agenda item
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 UAconformance 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