Accessibility Minutes 2009 07 08

From MemberWiki

Jump to: navigation, search


  • Anne Abbott (IBM)
  • Jon Gunderson (University of Illinois)
  • Nathan Jakubiak (ParaSoft)
  • Vio Onut (IBM)
  • Rich Schwerdtfeger (IBM - chair)
  • Michael Squillace (IBM)
  • David Todd (IBM)


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.

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 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.

Personal tools