Accessibility Minutes 2010 01 20

From MemberWiki

Jump to: navigation, search

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)

Personal tools