Accessibility Minutes 2009 10 21
From MemberWiki
Contents |
Participants
- Jon Gunderson (University of Illinois)
- Nathan Jacobiak (ParaSoft)
- Michael Squillace (IBM - chair)
- Ann Abbott (IBM)
- David Todd (IBM)
- Shawn Lauriat (IBM)
- Rich Schwerdtfeger (IBM - co-chair)
- David Bolter (Mozilla)
- Sandy Foltz (University of Illinois)
Minutes
Topic: Continue the rule set object discussion
Mike: We are not writing a standard, so the property id's for our purposes can be modified by the rule set consumer.
Mike: The importance is the rule logic
Mike: We need to encapsulate the logic
Mike: Hopefully, people have looked at the code in the repository
Mike: Any comments on the pseudo namespace in the code?
Sandy: It seems fine
Mike: There are two name spaces
Sandy: Namespace OpenAjax.a11y
Shawn: with the name spaces under a11y. Will these change if new rule sets are introduced with WCAG?
Shawn: will a wcag 2.x supercede this?
Jon: The rule sets are general enough in WCAG 2 so there would be no need to change any time soon.
Shawn: So the rule set for WCAG 2 would be updated to support new technologies
Jon: yes
Shawn: cool. that namespace makes sense to me then
Jon: one of the challenges is dealing with different media technologies and how we may test them for WCAG compliance
Shawn: One challenge is Bespin.
Rich: Bespin should be doable but with a combination of ARIA and accessibility apis
Rich: We would ultimately need to have a test tool execute the accessibility api (via script) in future versions of HTML
Mike: Rules need to be generic but not just for WCAG 2
Rich: WCAG is supposed to be harmonized with the 508 refresh
Rich: so we could map ids.
Sandy: I think the rules should reflect the test
Sandy: If we had the rules carry a more descriptive name then we could be more tightly bound to what it does
Sandy: For example: msg.altmissing
Nathan: I think the names now are hard to modify. This prevents us from re-ording them. I think the id's should reflect what they do.
Mike: so the rule should be descriptive of the logic?
Nathan: Yes. Currently what we have provides no context. Even if this is just for us it would be easier:
Shawn: So, the id's would be reflective of index text
Mike: OK. Do we want to start replace the id's in the table with what you are already using?
Mike: I will take a stab at those this week. We need some type of pattern yet it cannot be too long and descriptive enough.
Sandy: For example, missing id can be used in more than one place.
Sandy: I can do that. Could you add another section 1.3.1 so that I can see how you plan on dealing with multiple groupings?
Sandy: Validation Rules
Sandy: what we are talking about is that some of the rules have the text that can be displayed in the messages. Some do not. This url could be the place for the text messages.
Mike: that is my understanding. However, some of these are rather complicated.
Mike: I thought these were more pseudo algorithms.
Sandy: I think we need both.
Jon: As we develop the rule code we could update the Wiki with the messages for passing and failing.
Jon: In here we have potential error message ...
Sandy: We have one message with a particular level
Sandy: we would have another entry with a rule message explaining the error
Mike: Do we want this in the wiki? The table is getting big.
Sandy: We have best practices on the site as to how we tested for "this"
Jon: We are about 80 percent there
Jon: We could have more specific information on rule messages.
Rich: Nathan: what do you do to give more information on a rule violation to the user?
Nathan: We put this in the help system.
Mike: Do you explain the logic?
Nathan: at a high level
Rich: what about a URL to the help information?
It would be better to have a list of all the information for the rules. That way we could consume it into our system.
Rich: we could have a url with the XML markup
Shawn: I believe sourceforge supports xml markup exposed to consumers
Jon: Do we have language issues?
Jon: For a while we took the RDF for ARIA from the W3C web site.
Jon: Having a URL that people could download might be good for translation.
Mike: Dojo does something like this such as the locale for a label name
Mike: We could do something like that.
Mike: We already have a locale directory. We could have JSON or property files for each locale.
Mike: We could incorporate localization into that.
Shawn: Our Viewable Source
Shawn: This url has access to the source code repository. We could have the file rather than just a view
Shawn: Example URL to a file
Mike: we could have a link to the repository.
Mike: A tool could pull it in or we could just view it in the wiki.
Shawn: I need to look at the extension in more detail.
Issue number 2 in Sandy's email
Mike: I sent out a note on the repository change
Sandy: We spoke about rule number 1 already
Mike: I modified the wiki. We now have a result object that says true/false whether the rule was satisfied. There is an offenders property indicating the offending nodes.
Sandy: I think we need an attributes array as well
Rich: Per node respectively?
Sandy: Yes
Sandy: the message argument 1%2 ...
Mike: In the wiki I indicated that how you process them are rules dependent.
Mike: The idea is that those tokens would be in localized strings.
Rich: the open source community helps with this often
Rich: Should talk to Willie Walker about Orca
Mike: Dojo did it too
Mike: We should investigate how the open community gets this done
Mike: Sandy, could you provide an example of how a rule group would be encoded?
Mike: It is tedious to have to reproduce the rule group every time
Mike: You could have a context function
Mike: I don't understand what you mean by criterion number
Sandy: this gets back to grouping. It would be nice to having a grouping
Mike: Please provide an example
Sandy: Do you want a working version?
Mike: I just need to see it encoded.
Sandy: OK.
Mike: I added criterion description for a rule property
Mike: I added dependencies as a property. This is sequence of rules that must be executed before the rule is executed.
Mike: Sandy, this is why you are getting that length violation.
Mike: Sandy, you don't have that in the code you sent me.
Mike: No, dependencies we came up with here but I did add the property to the rules table.
Mike: I will perform some cleanup.
Nathan: how are the dependencies to be used.
Mike: the dependencies are a list of rule id's that must first be executed to be able to execute the rule that I am on now.
Sandy: It fits nicely with groups.
Nathan: this must be tool dependent
Nathan: A user may turn off some rules
Nathan: the concept is useful. I just need freedom to address this.
Mike: If the rule is enabled, executed, and passed.
Mike: We had this in ACTF as an optional property and it is in our rules
Rich: if you turn off some rules does it mean the dependent rule would be turned off?
Shawn: we would need to see some examples
Mike: We have worked on the same 6 or 7 rules to get the structure vetted out.
Mike: So, we should see more rules coming.
Mike: We talke about native heuristic dependencies.
Mike: We need to determine how to specify that.
Mike: originally we had rule set objects with ids. now we have ids that are keys to the rule logic.
Mike: basically, we have a rewrite of Jon and Sandy's rule test to test what we have works.
Mike: I learned a lot about Firebug development
Mike: I am learning venkman
Mike: I could not debug extension code.
Shawn: There is some setting in Firebug that allow you to debug the chrome extensions
Rich: what about your accessibility issue and XUL accessibility?
Mike: I am using Venkman as it is command line driven.
Mike: some of the extensions are not accessible. There are some shortcomings for each tool
Jon: we do have access to students for a project that could do this work.\
Jon: I am working on a Nitre proposal
Jon: if there is support for this in the community we could address this
Shawn: Tools List
Jon: Are you familiar with some of these tools?
Sandy: Yes.
Mike: Rich sent me a link on XUL accessibility
Shawn: If there is an overall effort to make the extension accessible that would be good.
Shawn: Google hired Charles Chen to do Firevox
Mike: Venkman is the tool I would most like to be made accessible.
Mike: I did want to mention that the CSUN deadline was extended to September 2nd.
