Accessibility Minutes 2009 07 08
From MemberWiki
Participants
- Anne Abbott (IBM)
- Jon Gunderson (University of Illinois)
- Nathan Jakubiak (ParaSoft)
- Vio Onut (IBM)
- Rich Schwerdtfeger (IBM - chair)
- Michael Squillace (IBM)
- David Todd (IBM)
Minutes
Mike: covered the structure of the document at: /member/wiki/Accessibility-Reorganization
Mike: I sent out a note detailing the updates with a link to the email in the agenda
Mike: From the minutes of the last meeting I updated the document
Mike: The note on event handlers there was a decision as to when the could be detected programmatically and when not
Jon: There is no standard DOM way to determine what event handlers are part of a node
Jon: This has been an open issue for Firefox
Jon: There is no interferace to query it
Jon: This is a huge testing issue. The only way to determine this is from an attribute in the markup
Jon: As people start to use toolkits this continues to be a problem
Rich: Did you speak with David Bolter
Jon: I will speak with David Bolter
Jon: We don't even care what will be returned - just that a keyboard handler exists
Rich: I had placed this requirement on the DOM working group roughly 6 years ago
Michael: there are success criteria for section 2.1.1
Michael: The keyboard issue and layout tables issues, as to how far we can go with them, will be ongoing
Update email on event handlers
Michael: The differentiation of widgets with roles and widgets with event handlers
ACTION GROUP: Create a table of ARIA roles which would define which roles would have a keyboard handler (e.g. grid vs. gridcell)
Michael: It is a violation a non-form or non-anchor has element with an event handler without ARIA properties it is now an interactive element and is inaccessible
Rich: thinking of rollovers
Jon: CSS should be used for these
Jon: If handlers are on a link this may be an exception
Jon: Form controls should be in question too.
Jon: When we have event handlers are standard form control is is murkier
David: I am thinking of the calendar widget in Dojo. For each of the dates they have roll overs
Rich: If they are calendar widgets then the cells will have a roll of gridcell
Michael: If you look at 211.M01 This should be manual
Rich: If you have a keyboard handler on an element it must have a role and a property on it
Jon: If a container is is using tabindex="0" to manage focus then that should be a violation. You should not have tabindeces >=0
Michael: Looking at 211.V02
Rich: there can be only one child element with tabindex >= 0
Michael: I should finish this work by next weeks meeting
Michael: With the exception on roles states and properties for Robust
Rich: We need a table of components with their loose DOM structure. There should be a template or design pattern for each widget
Rich: Looking at speclenium for design patterns of ARIA widgets. http://monotonous.org/specular/
Rich: would need a variation of this for each of the widgets for the DOM
Michael: This dovetails into rules that processable by a machine
Michael: We need to define a set of rules xml, javascript, etc.
Jon: Sandy has been rewriting the rules using JSON and the YSLOW engine
Michael: the YSlow developer is on maternity leave so there is some delay
Michael: Sandy has a prototype
Jon: we need a way to openly integrate into YSlow 2
Jon: It would be a lot cleaner if we could work together
Jon: We need to rewrite using JSON
Rich: Is the JSON you are writing work to test widget design patterns
Jon: I don't know the details about sharing
Jon: Sandy is on vacation until the 20th of the month
Michael: The fact that you are using a JSON like approach to the rules and this is what we are considering we should consider standardizing on JSON
Jon: The current YSlow 2 rules set makes use of their proprietary DOM. We need additional information in the definition of the rules
Jon: Yahoo has their own programming language. We can use our own JavaScript library and we would need a slightly different data structure.
Jon: People could write rules that would work for either
Jon: we would like a VPAT view of the rules
Jon: It would help if there were a default set of accessibility rules that were shipped with YSlow
Jon: We would like to be able to have custom rules
Jon: The YSlow team is not for an external setting of rules
Jon: These are some of the issues we have been dealing with wrt. YSlow 2
Rich: Are you drafting a design for the rule sets
Rich: ... rule set engine
Michael: It will be fully open source eventually
Michael: We would need to use our new one. The ACTF version on Eclipse is out of date
Jon: JSON is more portable
Jon: We have been using the HTML Java Unit library
Jon: We have a utility that serializes the DOM.
Jon: I can't get to irc.freenode.net from our campus
Jon: I will try chatzilla
Michael: I like HTML unit as it runs in multiple browser environments
Jon: It would be great to work with you
David: what does the utility do?
Jon: are you familiar with wget?
Jon: What this will do is download the url and store them locally with the page requisites so you can analyze the JavaScript
Jon: you can exclude files you don't want, etc.
Jon: It is like a DHTML version of wget
David: I would like to get that link as well
Michael: we have one page on the wiki and then have separate pages for rules, requirements document, etc.