Accessibility Minutes 2010 02 10

From MemberWiki

Revision as of 16:12, 10 February 2010 by DavidTodd (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

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