Accessibility Minutes 2013 01 14

From MemberWiki

Jump to: navigation, search


  • 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


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; 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

Personal tools