Accessibility Minutes 2010 05 19

From MemberWiki

Revision as of 15:25, 19 May 2010 by VioOnut (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

Present

  • Ann Abbott (IBM)
  • David Todd (IBM)
  • Dylan Barrell (Deque)
  • Jon Gunderson (University of Illinois)
  • Mike Squillace (IBM - Co-Chair)
  • Nathan Jukubiak (Parasoft)
  • Prasanna Bale (University of Illinois)
  • Shawn Lauriat (IBM)
  • Vio Onut (IBM)

Minutes

<vonut> MS: start with OAA press release [4]

<vonut> MS: press release is far to IBM centric

<vonut> MS: is anyone interested in being part of that - (persons outside of IBM)

<vonut> NJ: did look at it: sent it to the marketing folks. did not get back from them

<vonut> MS: if you are interested feel free to submit the cote in an email

<vonut> DB: the press release should contain the list of companies that are part of OAA

<vonut> NJ: is already there.

<vonut> JG: is going to submit a quote

<vonut> DB: will have to check with others - will get back to us

<vonut> DB: would be interested in being a contact person besides MS and RS

<vonut> MS: the release will be after the Memorial Day

<vonut> DT and SL: did look at it, looks good, no comment

<vonut> MS: moving on: Validation results - We agreed that the Try+Catch will be handeled outside the rule

<vonut> DT: At runtime will be a lot of browser differences that may trigger exceptions in the rule.

<vonut> DB: proposed something

<vonut> NJ: proposed a way to define an error that we can throw by type

<vonut> NJ: the javascript code will look for that error, the goal of that will help us distinguish the execution problems vs. rule problems

<vonut> VO: Seconds that idea.

<vonut> NJ: is not strictly required to throw this special exception, but if the rule wants to throw that it can

<vonut> MS: do we need to go back to the existing rules and revisit them ?

<vonut> Everyone is happy with NJ suggestion

<vonut> MS: Moving on: Testing - John are there any show stoppers on that ?

<vonut> JG: the problem: when people update rules how he is going to update that into their DB ? but that's JG problem

<vonut> present: Bresana joined

<vonut> DB: put multiple rules on the element and use that in the metadata.

<vonut> JG: the element will have a class name with the rule ID, then you can do XPath (using contains operator) to find the node, and then you can do more processing and you can look for the pass/fail that way

<vonut> DB: Mark up the elemnts that fail and which rules failed.

<vonut> DB: This will not have the list of passed in it (that Vio proposed)

<vonut> DB: this will help to reduce the number of tests. you want to test a page that will pass/fail multiple rules

<vonut> MS: is this format is simpler than the JSON format that we have?

<vonut> DB: is not simpler is an alternative

<vonut> DB: this alternative solves having multiple failures on a particular node

<vonut> JG: rule ID are descriptive but they will be subject to typing mistakes.

<vonut> JG: Thinks that the Jason will be more difficult to automatically generate that

<vonut> DB: how do you generate that automatically on your side JG ?

<vonut> JG: the database knows the relation between the test pages and the rules, and based on that you can do this automatically.

<vonut> JG: the main concern with JSON format is the manual edit of that

<vonut> MS: it would be helpful if DB will modify JG's example to show us what he is talking about

<vonut> DB: is is going to try working on that

<vonut> sorry that was JG

<vonut> MS: looking for other feedback

<vonut> NJ and VO: did not have a chance to look at the format

<vonut> MS: can everyone have a look at those and let DB know ?

<vonut> JG: use the metainformation with two class names (one for the passing of the rules and one for the failure of the rules)

<vonut> DB: but then the new format becomes just an alternative.

<vonut> MS: we don't want to make it too dificult so that people can use it

<vonut> MS: we also need a naming convention : JG suggested a solution

<vonut> JG: ids need to be simple because is potential of mistyping the rule id...

<vonut> JG: so his suggestion is to use number instead and have a short text description

<vonut> DB and JG: if we use numbers is much easier to comunicate them verbally

<vonut> MS: we already have a the right fields: so use the ID as the number and use the Label for the description text

<MikeS_> /member/wiki/Accessibility_Validation_Rule_Codification_Requirements

<vonut> that is the link to the Rule Codification Requirements

<vonut> DB: we should probably also add a description

<vonut> MS: yes. if people think is usefull, which probably is

<vonut> MS: so let's go with numbers but use a miningfull prefix such as OAA-

<vonut> JG: what if somebody repeats an ID

<vonut> JG: a classification will be useful in helping define the prefix of the rule ID.

<vonut> JG: ARIA already has rule IDs so if we start using Attribute names as rules we have some problems.

<vonut> VO: the problem is also when you remove/depricate a rule

<vonut> JS: maybe assign different number intervals for different people so that we don't overlap

<vonut> DB: each rule writer takes charge of the rule number and they use different prefix for different companies. For example OAA-IBM, OAA-Parasoft...

<vonut> MS: that's fine we can easily prefix that

<vonut> MS: so you will have a reserved Prefix

<vonut> JG: well use an id with Illinois in it...

<vonut> everyone is happy with that

<vonut> NJ: this proposed prefix is based on the people that is submitting the rule ?

<vonut> MS: yes

<vonut> MS: each company will have their numebring schema

<vonut> NJ: thinks that that will be a bit confusing.

<vonut> NJ: he still likes the idea of categorizing the rules based on the ID, but have this category based on the technology space.

<vonut> NJ: ID of the rule in that category - he likes the correlation between the ID and category, so is proposing to have some meaning

<vonut> VO: they will become long rule names

<vonut> MS: vio's point is that is kind of going back to what we have

<vonut> NJ: well we can keep it to 4 or 5 letters

<vonut> MS: well then is going to be a challenge by limiting that

<vonut> MS: the ID is used for machine, and the Label is used for description

<vonut> MS: so let's not make the IDs for human consumption

<vonut> DB: this will solve the collision problem.

<vonut> NJ: it would be good to use the same prefix and have the rule space defined in the wiki and assign ranges for different rules.

<vonut> VO: likes the idea of having in the Rule-Range numbers per contributing group

<vonut> DB: once a rule id is created don't change it

<vonut> NJ: likes the range idea

<vonut> We have an agreement of this: SAME PREFIX + have in wiki a table that specifies ranges per contributing group

<vonut> JG: we need to have a process to include a rule in the OAA and we need to make sure that the rules that are company specific are not submitted in the OAA.

<vonut> MS: yes, that's true we already have a mix of rules some of them that are specific to U of Illinois but not specific to the standard..

<vonut> MS: he highlighted the U of Illinois best practices

<vonut> DB: we need this review process because you want to discuss about the Accessibility Severity as well.