Accessibility Minutes 2009 02 18
From MemberWiki
URL: http://www.openajax.org/member/wiki/Accessibility_Minutes_2009_02_18
Contents |
Participants
- Jon Ferriaolo (IBM) - OAA Director
- Jon Gunderson (University of Illinois)
- Ken Jacobi (IBM-Rational/Watchfire)
- Nathan Jakubiak (ParaSoft)
- Preety Kumar (Deque)
- Bill McKenna (IBM)
- Rich Schwerdtfeger (IBM - chair)
- Derk Stegemann (FIT)
- Michael Squillace (IBM)
1. Goal of group
- Goal is to test dynamic web pages using the ARIA taxonomy
- Need tools that can test the page as it is dynamically changing
- This is similar to functional testing the dynamic environment
- We want to develop a common set of tools that can be used by a wide variety of rules engines
- We want to be able to report accessibility information in relation to WCAG
- We need to look at tools that help developers find the problems
- This effort is basically to try to spring board this effort to create much better tools
- Microsoft is not here today, but Adobe and Microsoft
- Jon Gunderson talks about:
- A11y Firebug Extension for Firebug extension work
- Firefox Accessibility Extension
- Functional Accessibility Evaluator
- iCITA HTML Best Practices
- Rule sets
- Rule representation
- Reporting results
- Enhanced DOM view
- Interested in rules that are library independent, so not specific to a particular toollkit GWT and Dojo
- Ken: We have enhancements and a roadmap for the product, but should talk to you privately, but we want to spread the used of the tools by IBM consultants
- Nathan: We are similar to Ken, we are planning to enhance accessibility testing for rich internet applications, we want to learn from the knowledge of people who have been working on accessibility
- Derk: We want to have automatic testing rules, but some things need to be tested manually. We do not use a browser for the testing.
- RS: You need to be attached to the browser
- Jon: Describes about the use of the tools at the University of illinois and the importance of automated tools in helping web developers and companies make more accessibility
2. What is a reasonable meeting schedule for this group
- Some people feel weekly is good for starting out
- We will start by meeting weekly for an hour or less at the same time
3. Overview from my perspective (RS)
- We need to run tests as the user interacts with the web page
- For example when using a menu, the menuitem has a parent of menu roles and are consistent with the ARIA specification, so syntactically valid
- test have to be triggers with focus changes and waiting for content to be updated
- There are landmark roles for different sections, are sections marked up are they described
- How do developers feel about warning levels?
- For example there is a div with a border with some content, we warn the user that there is no landmark and no description
- We need to bridge between static and dynamic content
- Developers like specific feedback on accessibility on the elemnet level and examples of the correct way
- People can use headers instead of aria regions
- Regional can use both ARIA and header markup
- Some of the reporting is what the tester could take to a developer
- How do represent the information, use XPath
- Tools might be different dependent on the task people are doing
- The person will need to start a test and begin a log of accessibility problems
- Allow the user to annotate the information
- I think a log describing user actions and accessibility changes is good
- How would the annotation system work, in annotations who would use them, I need to think through them
- As errors and warnings are generated
4. Rules representation
Jon: We are investigating YSlow's (Yahoo performance analyzer plug-in for Firefox) rules engine but it would need extending
RS: What formats should we best represent our generic rules in (Schematron, Our own XML Grammar, JSON/JavaScript)?
RS: I don't believe schematron is flexible enough given the varying ways that we create content
Jon: I don't like schematron.
RS: Too many dependencies on other XML modules like XPath and XSLT
Group: General agreement not to use Schematron
RS: IT would appear that JSON/JavaScript would work and is flexible. Would that work for the group?
Group: Unanimously voted to use JSON/JavaScript to represent the rules
5. Model and test of Implementation
RS: Mike, there is a new Java plug-in applet that allows generic DOM evaluation?
Mike: Yes, provides direct interaction with the DOM
RS: This works for IE and FF?
Mike: Yes
RS: Do all people here support more than these browsers?
group: We support only these two browsers.
Mike: Java 6 update 10 comes with the new applet support for the DOM
Rich: So we can use JSON/JavaScript here?
Mike: Yes
Rich: So you are adapting your test tool to do the modeling? How long will this take?
Mike: Potentially up to three months.
Rich: Need to
Rich: Challenge will be how we test for keyboard style guide compatibility. Preety, what your thoughts?
Preety: I have to come back and think about this.
Action: Preety to come to come to next meeting with some thoughts around testing the keyboard
Rich: We can discuss at the next meeting
6. Reporting Best Practices
Rich: I think the challenge will be switching to a Functional Verification Test strategy since the accessibility of the page changes as you operate it.
Rich: More like a test run
Rich: Is there a way for the tester to annotate the test - such as "I am exercising the Lotus Connections WIKI?
group: no conclusions here
7.Test Strategies
Rich: need to be able to test for <divs> which have styling and no semantics that there shoud be some sort of warning like lack of aria support
Preety: Yes, should be a warning. If we have s border on a section this could be a warning.
Rich: Need to flag errors if things like aria properties do not match the role of the element
Rich: Also need to make sure the document structure around an element having an ARIA role matches its design pattern e.g.
<div role="menu"> <div role="menuitem">foo</div> <div role="menuitem">bar</div> <div role="menuitem">baz</div> </div>
8. ERT/ATAG
Rich: What about ERT. How should they play into this?
Mike: We may be able to use ERT but we need to discuss next week with Johannes
Dirk: Yes, I am very interested in this
Rich: Sueann, regarding ATAG, are they in working draft stage?
Sueann: Yes. I need to bring this work back to the ATAG group to see how we can incorporate it in ATAG. I will do that.
8. Next steps
Rich/Mike to provide thoughts on types of tests to perform and look for - to get the group started
Preety to look at keyboard design pattern testing and how should approach
Jon Ferraiolo - To consider feeds for minutes, etc.
Meeting is next week at the same time.
