Accessibility Minutes 2010 09 21

From MemberWiki

Jump to: navigation, search



  • 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)




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.


David Todd's Post on caching:

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


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.


Personal tools