Accessibility Minutes 2013 01 28
From MemberWiki
Contents |
Present
- Jon Gunderson (University Of Illinois - chair)
- Prasanna Bale (University Of Illinois)
- Nick Hoyt (Uinversity Of Illinois)
- Ann Abbott (IBM) - scribe
- Mike Scott ((Illinois Department of Human Services)
- Rich Schwerdtfeger (IBM)
Minutes Of The Meeting
scribe: Ann Abbott
Jon: trying to pull together groups, Open Accessibility Alliance, to have support for rules, techniques and examples plus test suite.
Jon: Coding practices: rules, techniques, examples and rule test examples
Jon: http://collaborate.athenpro.org/groupa>
Jon: http://html.cita.uiuc.edu/
Jon: http://www.oaa-accessibility.org/
Jon: sites are out-of-date, need to bring together to organize new web site.
Jon: Standing call at 2pm Central on Thursdays
Jon: will clean up lists and send new invitation in next couple weeks
Jon: has 2 students who will help create new web site - may be a couple weeks or into March
Widget Rule 11
Jon: covered event handler rules last call and cleaned them up afterwards.
Jon: that page isn't quite up-to-date yet.
Keyboard Rule 1
Jon: /member/wiki/Version_2.0_Widget_Rules#Keyboard_Rule_1:_Widgets_must.2Fshould_support_keyboard
Jon: Widget Rule 11 will get triggered when roles don't exist and probably should.
Jon: Keyboard Rule 1 checks if interactive widgets support default actions
Mike: should native HTML interactive elements be excluded?
Mike: need another rule to ensure native HTML interactive elements are not also coded as ARIA widgets lacking required ARIA semantics.
Jon: http://www.w3.org/TR/wai-aria/roles#textbox
Mike: what if well-meaning, but uneducated developer puts an role=textbox without ARIA semanatics?
Jon: no required ARIA semantics on role=textbox.
Mike: should KBD Rule 1 definition have "or interactive elements" added to end?
Mike: link with role=checkbox?
Jon: should still have event handler on it
Jon: can't think of any role that doesn't need event handler.
Jon: if native kbd support exists, should be ok with onclick event
Jon: if onclick exists on body, would pass rules.
Mike: do we need this rule or should all checking be manual?
Jon: think we need this because there will be lots of manual checks that are easy to ignore
Jon: when developers add roles, they need to add kbd handlers
Jon: especially useful for spidering checking tools
Jon: test it - if problem can modify or dump it later
Keyboard Rule 2
Jon: /member/wiki/Version_2.0_Widget_Rules#Keyboard_Rule_2:_Tabindex_for_focus
Jon: checks to see if tabindex exists on widgets
Jon: especially for aria-activedescendent needs tab index of 0 or greater (not negative)
Jon: anything that can get focus can have aria-activedescendent applied
Rich: can have menu that only drops when key sequence triggers it
Rich: toolbar and grid, same way
Jon: will change Kbd Rule 2 so child widget rules are supported also
Rich: has to be part of widget heirarchy
Jon: also takes into account aria-owns
Jon: only kbd rules at this time
Jon: will anyone add tabindex without widget roles?
Rich: yes, that can happen
Jon: will fail if widget waits for kbd focus to add tabindex
Rich: has seen roaming tabindex
Rich: was in early days but hasn't seen in a while
Jon: can modify if causes a problem
Mike: think need manual check to ensure anything that can be done with mouse can also be accomplished via only the kbd.
Mike: to cover fallback methods that have nothing to do with ARIA
Nick: all user actions triggered by mouse are also available via kbd
Mike: if legacy page is functionally accessible, don't want rules to create violations.
Jon: easy solution is to make aria rules recommendations in transitional rules
Call ended at 1: 02pm Central --AnnAbbott 22:46, 28 January 2013 (UTC)