Accessibility Minutes 2010 02 03
From MemberWiki
Participants
- Rich Schwerdtfeger (IBM - Co-Chair)
- Ann Abbott (IBM)
- David Todd (IBM)
- Jon Gunderson (University of Illinois)
- Vio Onut (IBM)
- Nathan Jukubiak (Parasoft)
- Sandy Foltz (University of Illinois)
- Ken Jacobi (IBM)
Minutes
Rich: Link to today's agenda [1]
Nathan: submitted spreadsheet of events that trigger specific tests for his action items.
Nathan: we went for completelness
Nathan: technical issues to work out
Nathan: Link to JavaScript tutorial - DOM events[2]
Nathan: on that page, search for dom node inserted
Rich: add/remove node and not all attributes present
Rich: need to manual test for node insertions?
Jon: in Firebug, there's a refresh button that will look at all new nodes
Jon: can retest dom at any point
Jon: could timestamp it or monitor general insertions/deletions and invalidate previous
Jon: or "this report may be out of date" to notify tester to refresh to get latest info
Rich: do we need this for other than developer?
Jon: this is a bot that monitors?
Rich: maybe, yes
Jon: bot could compile
Jon: could trigger periodically
Rich: do we need to break table out based on types of tests running
Jon: scripting language that is interacting may tell tool to run test
Rich: then get log?
Rich: next need research to remove event notifications
Nathan: Another approach, rather than watching say the load event, is to simply take a snapshot or a validation pass.
Nathan: Define points
Rich: during FVT, tester identifies what to run
Rich: in the test, track all events that get fired?
Sandy: thought we were talking about on-demand tests
Rich: for reporting, need snapshot?
Rich: tester: running test 4-6 on wiki - do we take snapshot?
Jon: could track UI on capture phase on body and any event could be recorded
Jon: and some info about it
Jon: would be possible to collect info about it and report to tester
Sandy: not sure how much useful info would be captured and reported
Rich: FVT tester click on button, report name of button and report failure or delay after it occurs to report problem
Nathan: thinking something similar if you can tell what user did
Nathan: capture what actually happened so it can be reproduced
Rich: maybe capture what user did and take snapshot
Sandy: have to log along way?
Rich: subtree mod may be useful
Nathan: do you need to test right when modified - snapshot still tests same thing?
RIch: group wants to trigger on user event to tie to FVT report
RIch: could be automated based on user input
Rich: snapshot makes more sense for live events?
Rich: trigger on device input events?
Sandy: will we loose anything?
Rich: depends on when snapshot taken - how often do alt attributes change?
Rich: create menu in DHTML, takes menu that already exists in DOM - are we thinking focus change events?
Jon: do focus events propagate?
Jon: focus events can be canceled so don't bubble up
Jon: would need listener
Jon: potential propagation issue
Jon: IE has no capture phase, only has bubble and that can be canceled
Rich: Link to W3C User Interface event types [3]
Jon: doesn't talk about capture
Jon: IE doesn't support W3C dom
Rich: Focus change and user events tracked
Sandy: snapshot at any point or focus event
Jon: dom node deletions would bog system down
Jon: Live regions don't update UI controls, just data
Rich: could have chat log
Jon: chat logs don't have interactivity - are static
Jon: but may have live regions
Jon: may have optional parameter to toggle on/off
Jon: what would be event handler for live regions?
Rich: will want marked as live region
Jon: figure out how to mark what should be live region that are not marked correctly
Rich: periodic pattern that doesn't respond to user actions
Rich: or could make manual test
Rich: AT not announcing, did you make it a live region
Rich: can limit live region test to manual test
Jon: could set for time and monitor for, say 1 min, and watch for unmarked up live region
Jon: as long as no user input is detected
Jon: special test mode due to performance hit
Rich: test only operates on focus or children of focus event
Jon: makes sense for interactive mode
Jon: new name for Accessibility plugin. "Firebug Accessibility Inspector" and moving to Google code
Nathan: running on load and then on focus
Nathan: how would work if user is clicking thru application
Rich: focus changes and activation events to limit scope?
Nathan: sounds like it might work, but have to try and see what happens
ACTION ITEM for folks doing implementation: see if we can limit testing to objects with focus and decendents or elements actived by click and decendents
Rich: started presentations for CSUN? Any issues to discuss?
Jon: editing video
call ended at 10am--AnnAbbott 23:33, 3 February 2010 (UTC)
