- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Fri, 21 Sep 2007 16:40:56 -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 Since that broke in transmission, I pumped it into a TinyURL: http://tinyurl.com/2fzyec Al > >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 20:41:15 UTC