Accessibility Minutes 2010 09 21
From MemberWiki
Contents |
Present
- Rich Schwerdtfeger (IBM - Co-Chair)
- Jon Gunderson (Illinois - Co-Chair)
- David Todd (IBM)
- Marc Johlic (IBM)
- Nathan Jakubiak (Parasoft)
- Vio Onut (IBM)
- Ann Abbott (IBM)
- Prasanna Bale (Illinois - Co-Chair)
Minutes
Agenda
http://openajax.org/pipermail/accessibility/2010-September/000382.html
CSUN
Rich: Do we want to present at CSUN next year?
vonut: all agree
Rich: who wants to write a draft?
JG: I will make a draft
Rich: is not going to be a lot different other than the fact that we made a lot of progress
JG: Todd is going to do MS's part next year at CSUN 2011
Rich: maybe we'll have live demos?
there is a chance to do a demo
Rich: The repository is good to talk about this as well
JG: yes - the goal is to also help others to generate rulesets for their applications - it will give anyone a set of tools to achieve accessibility
JG: not sure if all is going to be ready for march
Rich: We are contributing to ARIA recommendations.
Caching
David Todd's Post on caching: http://openajax.org/pipermail/accessibility/2010-September/000383.html
Rich: Subject: DOM Walking
Rich: what do we want to cache ?
DT: Those are IDs of the node (in response to JG question: what are the IDs)
JG: so the ID's will be a list of nodes...
JG: when do you use headings / when do you use landmarks ?
JG: you want to have backward compatibility
JG: so you want to list both ARIA landmarks and H2
JG: proposal: if there are Landmarks those become the primary role, if not then we can look at headings ?
JG: similarly html5 vs old headings..
Rich: we could in the landmarks check for ARIA and HTML 5 (since we are referencing an element)
JG: main concern is that headings and landmarks are related
DT: what about combining them in a "page navigation" class
RS: are we avoiding the skip link?
JS: skip link is not relevant anymore. we should skip it
RS: we also have forms (form landmark in Aria)
RS: we can put that in the navigational landmarks as well
RS: does that make sense ?
NJ: yes
JG: are we talking about the html form container ?
RS: yes
DT: yes the intention was for those to be html forms
JG: in the cache is created on demand
DT: we can also use the cache for providing special views on what's on the page (hading landmarks on page / widges and form controls)
NJ: one note about images/forms/links - there are arrays that lets you get to those... we probably don't need cache
RS: let's verify that because that will save us a lot of work. btw, do they cache any ARIA landmarks ?
RS: we also have layout tables...
JG: is there any need to distinguish between data and layout table ?
JG: we want to talk about different rules for those, there might be
JG: we need to also distinguish between a table and a grid
JG: for an interactive grid: do we care if they use th ?
RS: we have table headers
DT: it can be accessible using either headers or ARIA
JG: we want a test suite that will help us calculate the headers for the cells.
JS: can headers and aria can be used interchangeable for grids?
RS: I think so
JG: we definitely want to have a good test suite
RS: there are some good things about separating those out because there may be places where you don't want to apply ARIA in HTML5
DT: agrees
RS: you could have an attribute list that you are caching for that, but then you are back in the DOM...
RS: where are we going to store all of that?
RS: it could get expensive storing all these stuff
JG: for example - having a list of headings would help (have there the nodes with the headings)
JG: another example - having only the label for each form would be sufficient
RS: so maybe forms and landmarks should share the same cache
JG: we want to make sure we don't store more
DT: Yes, I scanned the rules when I put this proposal together to make sure we save only what is required
RS: is DT going to implement the caching ?
DT: yes
XPath
NJ: we should abstract the XPath from browser specific coded
NJ: right now the rules are using firefox specific
VO: *firefox specific xpath
VO: We use the XPath - Firefox so we need to be backward compatible
NJ: yes we need to default back to firefox if we don't find any other library
Rules Help
RS: The current rules tells you if you failed a guideline - but we don't have help for the rules - we should provide more help
NJ: Hi All, I need to drop off the call early to prepare for another conf call in 10 mins
JG: we find cases when people put things in their website to bypass the rule, but not to fix accessibility issues
JG: we need to have rules that prevent people from doing that
JG: the rules will need to detect poor programing practices
JG: Runtime values is another thing that we could cache
JG: the caching logic needs to be separate than the rule logic
JG: another cache would be colors ? being able to get runtime colors vary between browsers...
RS: the CSS working group never produced a final DOM API to get that information so that is an issue
JG: firefox has a runtime style information
RS: we do a manual check for that
JG: then developers are most likely going to ignore that...
JG: if we can't do it for every browser then there may be some rules that can run in certain environments but not in others
VO: currently the rules have a 1-1 relation with Violation/Potential Violation/Recommendation/ Potential Recommendation
VO: we never had a rule in the past that was both Violation and Potential Violation depending on the browser that it runs in
RS: Subject: Consistency between the spec and rule implementation
RS: all the aria rules use functional context and they will improve speed, but they are not part of the ARIA specification
VO: maybe they need to be Recommendations then
RS: do we want to promote that to the OAA spec ?
JG: maybe we can talk about this next time?
RS: Subject: weekly or by-weekly meetings ?
JG: makes sense to start weekly.
JG: or at least a subgrup meeting?
RS: we'll start weekly
Action items
DT: Implement caching
NJ: Implement XPath abstraction
RS: look at ARIA for help separation and updating to the latest Last Call Draft
JG: Agenda for next week. Ann Abbott to scribe.
ALL: MEETINGS WILL NOW BE HELD WEEKLY