Web and Software:January 10

Miscellaneous

• Minutes from January 3, 2007 approved
• Meetings in February and March have been scheduled.

Review of action items from January 3rd

1. IN PROCESS: Judy Brewer to send requirements for W3C copyright notices. WCAG working group is documenting how to reference WCAG standards.
2. Andi to check with Access Board staff to confirm that we can quote provisions in other standards.
3. Unassigned: Need a presentation on where graphical applications are going.
4. ONGOING: Gregg Vanderheiden to do some research with the low vision community to see what they want with regard to color and contrast.
5. COMPLETE: Add a discussion topic on "programmatically determinable and the relationship with assistive technology". This has been added to the General Issues page.
6. IN PROCESS: Andi to develop proposal for keyboard requirement for Web.
7. COMPLETE: Andi to post WCAG 2.5.1 for error handling as a base proposal including a pointer to the sufficient techniques.

Gaps in Web Requirements

Keyboard proposal

• No consensus yet to adopt the proposal.
• Suggestion to use "keyboard interface" instead of just "keyboard"
• Clarification that "textually discernible" means that you can describe the result. For example, even though you may draw an object with a mouse, such as a circle, rectangle, or line, you can exactly describe the resulting object and therefore 508 requires that a keyboard method of doing it be provided. But free-form drawing cannot really be described to the degree that you could replicate it without seeing it. So free-form drawing is excepted by the phrase "textually discernible".
• No suggestion for a better phrase for "textually discernible".
• Andi to make another proposal for next week to attempt to address the concerns.

Error handling proposal

• Marking the fields in error so that they can be identified by the user is also an issue. If color is used, that would violate the color requirements.
• WCAG 2.0 technique of providing suggestions that are not required for conformance is to use advisory techniques. Could provide an advisory technique on linking to the errors.
• Can't require errors to be marked semantically as defined in W3C ARIA because it's not supported by other technologies. Could document this in sufficient techniques though.
• Summary: In TEITAC report, include WCAG provision as additional recommended requirement with semantic identification of errors as sufficient technique for ARIA implementations.

Valid and well-formed code

• WCAG definition of parsed unambiguously provided.
• Tabled until next week.

General Issues

AT responsibility

• It's difficult to define where the boundaries are between IT and AT in a general way. Easier in areas where there is a lot of AT and good APIs but not so easy in areas where there is not much AT yet.
• Market forces seem to be working. That is, the government levies requirements on the AT vendors for the technologies they intend to use. But there is a lag time where people with disabilities may not have access.
• There is disagreement as to the application of the functional performance criteria and to the interpretation of what they mean. Some think that the functional performance criteria are used only to evaluate "equivalent facilitation" claims. Others advocate that a product must meet both the technical standards and the functional performance criteria. But even in this case, there are different interpretations as to what "support for" assistive technology means. Some could say that if you have implemented the APIs correctly, you have provided support for assistive technology. SSA interprets 508 this way.
• WCAG is taking a stricter interpretation. "Theoretically" working with AT is not enough. It has to actually work.
• If 508 takes a stricter interpretation, then AT needs to share the burden. In other technology standards, both parties have a responsibility to conform. This seems to be the only area where all of the burden lies on one party yet there is a dependency on a second party for conformance.

Remote Access

• Need to distinguish between a thin client and a dumb terminal. The thin client is really a "platform" of sorts.
• It's important to be able to get the same function and data even if you have to get it another way. Example is Blackberry. It is not accessible. But if you can get the same data and function using another platform, this is acceptable but not desirable.
• If agencies cannot acquire an accessible product that meets their mission need, they still have to provide an accommodation through some kind of alternative means.
• Inheriting system settings for color and contrast doesn't usually work for the remote access environments. Added to notes on 21(g).

Browser Requirements

• W3C User Agent Guidelines require browsers to provide structured navigation.
• Browser is an instance of the "platform on a platform" case.
• Deferring "platform on a platform" discussion until the API proposal discussion is finished.
• Revisit the issue of browser requirements during that discussion.

Attendees

1. Peter Korn, Sun Microsystems, Inc.
2. Tom Brett
3. Andi Snow-Weaver (IBM)
4. Mike Fratkin (SSA)
5. Nick Truesdell (IRS)
6. Donald Evans (AOL LLC)
7. Rex Lint - ITAA
8. Sean Hayes (Microsoft)
9. Luke Kowalski, Oracle
10. Jessica Brodey (ATIA)
11. Ken Kipnes, oracle
12. Curtis Chong
13. Andrew Kirkpatrick (Adobe)
14. Amy Chen - Oracle
15. Blene Bekure (LMIT)
16. Alex Li - SAP
17. Jim Allan (W3C)
18. Terry Weaver, GSA
19. Michael Cooper, W3C
20. Laura Ruby - Microsoft
21. David Oyola (Ricoh Corporation)
22. Katie Haritos-Shea
23. Earl Johnson (Sun)