Accessibility Minutes 2009 11 11

From MemberWiki

Participants

• Nathan Jacobiak (ParaSoft)
• Michael Squillace (IBM - chair)
• Ann Abbott (IBM)
• David Todd (IBM)
• Rich Schwerdtfeger (IBM - co-chair)
• Sandy Foltz (University of Illinois)
• Jon Gunderson (University of Illinois)

Minutes

Mike: Problem of participation

Rich: Mike and Sandy doing most of coding. Lot for 2 people. Important to work with ruleset to get comfortable with framework

Rich: Helps when lots of people working to find issues

Mike: Talking about an hour or two a week

Nathan: Can probably commit some resources

Mike: Trying to get Vio to be more participitory with the rules

Mike: People chipping in with wiki would help too. Adding more rules would help

Rich: Will see if can help with that

Mike: Don't want people taking advantage without giving back

Mike: Moving on to rules and rulesets

Mike: Talking to Sandy and others. Let vendors choose their own rule ids

Mike: Vendors will likely have id systems already

Sandy: Testing for uniqueness? What about versioning?

Mike: There is a uniqueness check

Sandy: Any way of tracking rule at given point in time?

Mike: Does that mean that ruleset version would need to change too, say if an individual rule changes?

Jon: It would look like every rule changed instead of just one

Jon: Better to do versioning by rule

Jon: Rel. between ARIA and HTML 5 will probably require lots tweaking

Rich: Also need vehicle for deprecation?

Jon: Probably will have some rules become obsolete

Jon: Deprecation system could be gradual

Mike: Honor system where rule updater must update rule version?

Jon: Have SVN, could look at rule like Trak, may want some kind of tracking system about what changed in each rule

Jon: Hopefully there would be group consensus before changing a rule

Mike: I was thinking about versioning rule logic. Need to also version rule metadata?

Jon: Keep it simple for now. Rule has one version - whatever changes in that rule documented and affects that one version

Jon: Need consensus process

Mike: Can use SVN commit comments

Mike: Can discuss when versioning will start next week

Nathan: Should have default ids, so can talk about easily, and users can correlate between tools and ruleset

Nathan: Vendors can override if they wish. We would probably use the default ids and append something of our own for categorization

Mike: Agreed

Mike: Talking about specifying rule constants

Mike: Suggestions by Vio putting the constants in the rule. Example in the weekly agenda

Mike: Good because ids in the rule, don't have to look elsewhere

Nathan: These only defined inline in the rule?

Mike: Yes. Constants usually only apply to one rule

Sandy: Need to be careful for language-specific constants

validateParams:__forebidden_words__:{value:['picture','graphic','photo'...], type:"array"}

Mike: Vio suggested putting validateParams in each rule

validateParams:__forebidden_words__:{value:['picture','graphic','photo'...], type:"array"}function(ruleCOntext, vparams) {

function(ruleCOntext, vParams) {

vparams = vparams || this["validateParams"];

Mike: This would allow vendor to override params

<We had long discussion about whether params should be defined in rule or not. Everyone liked except Nathan - when users customize the rules are not necessarily written. Decided to leave as is for now, bring up again if needed>

!(img) | input

Mike: Now talking about exclusivity of rule contexts

Mike: exclusivity contexts must be used separately for now

Sandy: Can pick up all ARIA attributes?

Mike: Not now, but need that

• [@aria-*]

Sandy: That's what's needed