Accessibility Minutes 2010 01 20
From MemberWiki
Participants
- Michael Squillace (IBM - chair)
- Ann Abbott (IBM)
- David Todd (IBM)
- Nathan Jukubiak (Parasoft)
- Sandy Foltz (University of Illinois)
- Shawn Lauriat (IBM)
- Vio Onut (IBM)
Minutes
Dylan: mike, I will not be able to join today's call
Dylan: apologies for the late notice
Mike: ok. sorry to hear that
Dylan: quick update on the example code...it is progressing, have some basic code working but need to clean it up
Mike: great. looking fwd to seeing what you've done
Dylan: its based on the OAA_Nexus.js that Sandy referred me to
Dylan: thanks
Dylan: bye
Mike: c u
Sandy: Goals:
Sandy: provide feed back on level of accessibility
Sandy: reduce accessibility errors
Sandy: what do we want to do with accessibility errors:
Sandy: log/display
Sandy: categorize, display critical ones on the desktop as pop up
Sandy: account them, keep statistics
Sandy: trigger events
Sandy: debug
Sandy: good error prosessing needs a lot of state info (what about foot pring size & overhead)
Topic: Reporting Best Practices
Mike: Link to wiki page for Reporting Best Practices[1]
Mike: Goals listed in wiki
Nathan: primary audience = developers
Vio: management, development, auditors, all roles
Sandy: managers, development
David: development. test
Mike: target development as it isn't necessarily happening today
Mike: can Sandy develop the first goal this week? Sandy agreed.
Mike: second goal is confusing
Sandy: may be for pages that allow input and then gets tested
Nathan: may be after page refresh (Ajax related)
Mike: make sure validation takes place dynamically as state of application changes
Mike: second aspect - what gets reported, if anything, to help reproduce violatioin
Mike: keystrokes or http messages
Mike: three areas for reporting - Role based reporting, dynamic validation and how to reproduce violation
David: implementation - button to reproduce violation
Mike: two axis = role based reporting and what goes into report
Shawn: if targeting developers, highlight one element and test, instead of going thru entire DOM
Mike: determine format of individual record in a report may be too detailed for this grouip
Mike: need to return to this topic when Rich and Dylan are present
Nathan: Need to determine what level on which we need to provide guidance
Mike: need to give guidance on level of detail in report - more generic
Mike: remove last two and stick with general roles and features
David: include references back to WCAG?
Mike: reference back to WCAG rule
Ann: refer to rule, but not fix because of how WCAG 2.0 is written
Nathan: that level is not too specific
Vio: agrees
Mike: need to be not too general or granular
Mike: Mike & Sandy will work on wiki page - Sandy agrees
Mike: are recommendations restricted to dynamic content validation or apply to static content as well
Vio: will want to show same type of information for both
Topic: Rule Requirement discussion
Link to wiki page [2]
Mike: context for text nodes?
Mike: testing for abbreviations and acronyms per WCAG focusing on all text nodes in document
Link to WCAG 2.0 rule [3]
Nathan: does test
Sandy: does not
Vio: may test
David: performance hit?
Mike: not seeing a hit using XPATH or DOM method
Mike: few rules where this would be useful
Mike: looked at for internal IBM compliance
Sandy: brings back issue of tables or filtered out?
Mike: how wouild you handle alternative?
Sandy: make them context and define as functions
Mike: issue isn't closed so post to mail list
Mike: how to determine syntax to fire rule on a div
Sandy: using rules for this
Sandy: no performance hit
Nathan: Problems in IE with that
Nathan: event bubbling is an issue
Nathan: IE doesn't have capture phase and can be stopped by a node
Nathan: ways to get around that, but can't do at document level
Mike: need to be as browser neutral as possible
Sandy: if it wont work in both browsers are we not adding or adding with comments?
Mike: one rule uses XPATH and comment states only works on Mozilla but should have a way to delineate those
Nathan: will need all rules, but tool will need to switch
Vio: in order to do that, must notify tool or batch
Nathan: keep maintenance effort in mind
Vio: check first what imiplementation to be used to notify engine
Nathan: should not have multiple rules for different browsers
Nathan: check under hood and have logic switch for it
Vio: agrees
Vio: checked implementation for text - not for AAA compliance, but does for text look-alikes, and list tags
Mike: concensus is to avoid browser specific rules when possible, if necessary put under hood.
Sandy: are XPATH rules browser specific?
Mike: doesn't know what Opera and Webkit has
Nathan: has library for IE and API may be slightly different - just need a wrapper. Main issue is performance.
Nathan: for now state that XPATH is cross browser until we see different
Shawn: uses Safari
Shawn: happy to test that
Vio: support for IE & FF, no problems with XPATH so far
Mike: future meetings - next week discuss CSUN presentations. Come with ideas and whether will be attending - presentation decks not necessary.
Sandy: will put in events specific to FF plus browser check with comments that it is specific to FF.
Nathan: have warning for manual check
[09:57] call ended --AnnAbbott 20:16, 20 January 2010 (UTC)
