Accessibility Minutes 2013 01 14
From MemberWiki
Present
- Ann Abbott (IBM)
- Prasanna Bale (University of Illinois)
- Jon Gunderson (University of Illinois)
- Nicholas Hoyt (University of Illinois)
- Rich Schwerdtfeger (IBM)
- Mike Scott (Illinois Department of Human Services) - Scribe
Minutes
Jon: New version of OAA extension published
Jon: Changed widget rule 11 to detect mouse and drag events; removed widget rule 12
Jon: Added prototype triage report
Jon: New version of AInspector for Firebug published
Jon: Fixed panel/column resizing problems
Jon: Will synchronize future releases of OAA extension and AInspector; possibly Fridays
Mike: tried new release on www.dhs.state.il.us; earlier issues appear to be resolved
Jon: Try new Triage ruleset
Jon: Each rule now has a boolean indicating whether it is a Triage rule
Ann: Current IBM test tools test all at once; no weighted rules
Jon: Triage rules include basics: alt on images, labels on form fields
Jon: Exporing the concept....
Jon: May be useful for some users of the tool.
Jon: Questions include terminology, UI, rules to include
Ann: At IBM, triage done on defects to determine if they are failures (?)
Mike: May be useful for users who "don't have a clue" and need to be directed to education/training instead of being confused by full report.
Nick: Interested in terminology: what basic rules should be called
Prasanna: need to tell people why we are identifying these rules as basic
Jon: note that Triage is not actually a ruleset
Ann: need to avoid telling people they passed triage, since they may stop there
Mike: discussed not showing the users a Triage options, rather providing special warning/instruction if Triage rules are failed, e.g. "Basic accessibility features are missing; please see these resources to get a basic understanding of accessibility principles before proceeding"
Nick: definition of term is appropriate
Ann: OK
Jon: Will talk more about this on Best Practices call
Jon: two main goals: indicate they need basic understanding; avoid wasting time on manual checks
Jon: Reworked Widget Rule 11, related to mouse event handlers, to include drag events
Jon: /member/wiki/Version_2.0_Widget_Rules#Widget_Rule_11:_Mouse.2Fdrag_events_must.2Fshould_have_roles
Jon: if you have mouse or drag events, those elements need to be interactive and/or have role
Rich: what about keyboard event handlers
Jon: keyboard events in subsequent rule
Jon: Widget Rule 1, widgets must have keyboard support
Rich: what if you have keyboard handler without roles?
Role explains what element is
Rich: do we have standardized drag events: not till HTML5
Rich: are we going to start supporting HTML5
Jon: including because its easier to do it now
Mike: most browsers already recognize those events
Rich: certain features are different, e.g. booleans, checked vs checked="true" vs checked="checked"
Rich: could impact ruleset
Jon: only a few things now, e.g. drag events
Jon: HTML5 element nav should have role nav; if has other role, should flag (?)
Jon: Steve Faulkner has website mapping roles to HTML5 elements
Jon: need to do something with canvas
Jon: warn that there are accessibility issues with it
Jon: also new fig and figcaption elements: assuming figcaption serves as alt?
Rich: need alt attribute on canvas?
Jon: no, just warn that there are accessibility issues
Rich: major browsers support fallback content, but don't support binding mouse interactions to fallback content
Rich: could check javascript to see if proper canvas apis are used
Jon: may need to step back, just looking to see how rules are affected by HTML5 elements
Rich: regular rules should apply to fallback content
Jon: canvan is extreme example; we don't have any rules right now
Jon: just want to make sure cache can handle HTML5 elements
Rich: with figure, shouldn't enforce alt attribute
Rich: i.e. image inside figure doesn't need alt
Jon: back to widget related rules
Jon: should we expand Widget Rule 11 to include all interface events, e.g. keyboard
Nick: if solution is the same, then yes, include all interface event
Mike: worry about exceptions, but yes, could include all interface events
Mike: any mouse or keyboard event handlers 12:40
Jon: elements that respond to mouse, drag, or keyboard events
Mike: tool is looking for those event handlers
Nick: right
Jon: elements with mouse/keyboard eventhandlers must have widget role or interactive element
Jon: includes children
Mike: what about ancestors?
Jon: potential issue
Jon: if event handlers are on children, code gets messy
Jon: people put event handler on body to handle everything
Jon: rule currently looks at element and decendents
Jon: widget rule 12 will be manual check
Jon: anything with a widget rule, ask "does the role accurately represtent the actions and purpose of the element"
Nick: no way to automate any of that?
Jon: once they put in roles, we can check for handlers according to ARIA, but need to know if is the right role
Jon: keyboard 1 OK
Jon: re keyboard 2, if a widget doesn't have tabindex is that a failure?
Rich: could be on an active descendent
Rich: container needs to have focus, e.g., grid should be in tab order
Jon: cell in grid has tabindex="0", activedescendent could point to other cells?
Jon: need to check how cache tests for this
Rich: need to be careful with HTML5
Jon: looking at just a few: figure, etc: not canvas
Jon: does aria describedby work with images for alt or long description?
Rich: accessibility taskforce supposed to prove that longdesc is used and supported
Nick: could we say "widgets with event handlers must/should have roles"?
Rich: "elements with input event handlers must/should have roles"
Rich: can't just call it event handler, "input event handler"
Jon: will modify rule; talk about layout rules next week