From MemberWiki
Pre-goals
- Goals:
- provide feed back on level of accessibility
- reduce accessibility errors
- What do we want to do with accessibility errors:
- log/display
- categorize, display critical ones on the desktop as pop up
- account them, keep statistics
- trigger events
- debug
good error prosessing needs a lot of state info (what about foot print size & overhead)
Goals
- Provide detailed reports for persons in different roles of the software life cycle
- Define when to trigger validations or "snapshots" of compliance
- Static - one-time process of each page during a crawl
- Manual - developer or tester manually defines snapshot
- Automatic - reporting in response to focus change, aria-activedescendant change, mutation events of children of content of live regions (Configurable what will test)
- Note: IE fires the focus events before and Firefox send focus events after
- Reproduce Violation
Test Scenarios
How tests are triggered and annotated is important to each of these tests. Also, what tests are triggered needs to be specified due to performance limitations
- Web Crawling Snapshots
- IDE Debug and Feedback
- Functional Verification Tests
Error Reporting
Under construction
| Test Scenario | Report of Context for Error | Error Information
|
| Crawling | URL being tested and XPath Statement | Rule Violated and diagnostic information (role structure, states and/or properties in error)
|
| IDE |
- Take People to the actual DOM node causing a violation
- highlighted in browser widget
- highlighted inn source file (if available and can pinpoint useful location information)
- keep track of state of application or path via which violating state was reached (e.g. current URL, monitoring HTTP request/response, recording keystrokes and mouse actions)
|
- Provide visual diagnostics regarding the violation
- provide as much information as possible from original validation rule (e.g. message, severity, help, repair techniques, etc.); probably do not need to provide information regarding actual checklist or criteria to developers
|
| FVT Test and storage |
- Annotated (by tester) FVT Test
- URL being tested and XPath Statement
- Event that triggered the violation
|
- Provide diagnostics regarding the violation
- provide as much information as possible from original validation rule (e.g. message, severity, help, repair techniques, etc.); probably do not need to provide information regarding actual checklist or criteria to developers
|
}
Reporting Record Format
- Rule ID
- Rule version
- Event triggered
- Error Record Data
Firebug
- Get accessibility feedback at the node level
- Generate a report on demand - generate whatever is in the DOM at that point
- Save reports and produce a meta report
- Check text equivalents and is it unique
- can you provide a view of form control labels. They forget to do it or the labels don't match the radio. Fail uniqueness rule. Meaningful labels are important. 2.4.6.
|
