Accessibility Minutes 2009 10 21

From MemberWiki

Jump to: navigation, search

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

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.

Personal tools