Accessibility Minutes 2010 02 10
From MemberWiki
Participants
- Rich Schwerdtfeger (IBM - Co-Chair)
- David Todd (IBM)
- Vio Onut (IBM)
- Jon Gunderson (University of Illinois)
- Nathan Jukubiak (Parasoft)
- Sandy Foltz (University of Illinois)
Minutes
Mike: Let's talk about CSUN
Mike to Group: Look over the agenda
Mike: Does anyone have concerns with ordering?
Group: no
Mike: What's the due date for the slides?
Mike: Format will be PowerPoint
Jon: my presentation will be a short video
Jon: will post his on the Web and on thumb drive - 10 min.
Mike: Due date for presentations (slides, videos, etc. - 3/10)
Rich: Did everyone get the slides Rich sent out?
Don't think so.
Rich will follow up about his slides.
Mike: Anyone doing a live demo?
Group: No one the call doing a live demo.
Mike: Moving on to events table.
Mike: What was decided last meeting about events?
Nathan: Don't want to trigger on all events in table.
Nathan: Trigger on focus change events
Nathan: Run check at defined points like onload, etc. Or could be triggered manually by user.
Rich: Looking at focus change events as one of the main triggers.
Rich: aria-busy state could be a directive to tool not to test
MIke: aria-busy helps with DOM inserts or modifies.
Rich: When element goes from busy to not busy could be a good trigger.
Mike: What about live regions and alerts?
jongunderson has left moznet (Client exited)
Rich: Trigger on selected state.
Rich: Slides got stuck because the mail system has a limit on attachments.
Mike: Send CSUN slides to Mike.
Mike: Look at rules table folks have been working on.
jongunderson (chatzilla@moz-9756017B.rehab.uiuc.edu) has joined #oaa-accessibility
Mike: Should we add column to oaa wiki page to put event trigger information?
Nathan: will transfer his table column to a wiki table.
Nathan: Describe general cases for triggers then describe unique cases in the table.
Rules table: /member/wiki/Accessibility_-_WCAG20_Validation_Rules
Parasoft's initial draft on events: /member/wiki/Image:AriaEvents.zip
Mike: Will attempt to develop format of event triggers.
Sandy: Putting triggers on the context will be too complex.
Jon: What happens a rule fails? We don't have a way to tell folks a rule failed.
Jon: Do we need a way to tell users why a rule was run?
MIke: Separating context from the trigger. Is this the way we want to proceed?
Vio: I think so.
Vio: When rule runs, user wants information about whether rule passes or fails. Maybe users don't want to know about event elements.
Mike: Developers would like to know information about event element causing rule firing.
Vio: agree
Mike: We should talk further about event triggesr and exporting information about validation results
Mike: Moving on to reporting best practices.
Mike: Dylan isn't here. Mike doesn' t know where to go from here.
Rich: Must make reporting generic.
Rich: Develop general guidance.
Jon: Functional scripts - what are they?
Rich: test procedure that was run, screen shot of the page, report of the error (xpath statement, what failed)
Jon: Suggesting two different types of tools - high level problems and more inspect type tool to root out problems.
Mike: thinks the best practices address these two different audiences.
Jon: Organize errors based on node - maybe a best practice.
Jon: Monitor events to see if different events cause failure but other events cause compliance.
Another best practice - Eliminate duplication records
Jon: Will add best practices for next week.
Rich: attach CSUN files to wiki.
Rich: will email where attachments are