Web and Software: September 12

Miscellaneous

• Minutes approved from August 29, 2007.
• Co-chair report from TEITAC meeting
  • Replace "multimedia" with "synchronized media" - accepted
  • Remove "Bypass blocks" provision - accepted
  • TEITAC report draft, September 3, 2007
    • Need to finish up and deliver to the Access Board Jan. 2008. The next deadline is Oct 19. There are 6 meetings to finish up provisions. This is a firm deadline. May need to take forward multiple versions.
    • We can continue to collect explanatory material, and sufficient techniques after the October 19th deadline.
    • If there is any disagreement, TEITAC members only can submit minority reports. Drafts of these reports should be in by 10/19.
    • After the TEITAC report, the Access Board will issue a notice of proposed rulemaking which will be open for public comment for 120 days. There may even be multiple public comment periods.

Review of action items

1. CLOSED: Allen Hoffman will sync provision 2 with AV group definition by next week.
   • Remove the provision. See discussion under Technical Topics below.
2. IN PROCESS: Katie Haritos-Shea will write a proposal for tactile and aural user preference settings.
   • Mailing list discussion started
   • Katie will repost proposal because most of the conversation on the list was off topic.
3. Judy Brewer to collect all clarification and rationale for the authoring tools provisions for the final TEITAC report. Not required prior to August 17, 2007.
4. IN PROCESS: Shannon Rapuano to look at "if" provisions to determine if we need an "else" provisionalso.
   • See minutes from the August 22, 2007 meeting
5. Andi Snow-Weaver to make proposal to resolve harmonization issues around "Both platform and application" provision.
   • Andi will try to get something out to the list later next week.

Technical Topics

Remote Systems Access

• Proposal from Allen and summary of mailing list discussion
• Discussion from August 8, 2007
  • Previously discussed adding a note to the AT interoperability provision. Currently there is no proposal for the note.
  • This could be be viewed as a special case, similar to platform on a platform, which we do have a provision for.
  • There are hamonization issues with the "both platform and application" provision.
  • Action: Andi Snow-Weaver to add this to the list of issues to consider in the harmonization work for the provision.
  • There is a section of the report for things we discussed but did not propose a provision. If we end up without a provision to address remote access, we need to provide the rationale here for why we didn't add a provision.

Pausing

• Add "hiding" as an option in addition to stopping for decorative content. See Andi's post on August 20, 2007.
• Also, harmonization with WCAG Blinking provision.
  • WCAG has a separate provision on blinking and also they also have it in pausing. But there is currently a proposal to merge them to match TEITAC. Used to be 2 kinds of blinking... setting a font to blink, and flash files that flash and blink, which does not fit the blinking... solutions are basically the same and look like they can be merged. Gregg will find the proposal and send it to the list.
  • We will wait and revisit this next week.

Content Format

• Outstanding work item on provision 8.1-B Multimedia
  • Current: A content format that supports multimedia must provide an encoding mechanism to include synchronized text of verbal content, and audio descriptions of critical nonverbal activity displayable by a user-agent.
  • From A/V subcommittee - captions may be provided in a separate text file - player merges them
  • Audio (video descriptions) are usually provided in natural pauses in the audio track, not encoded in the format.
  • Do we need this provision at all? If so, we have to remove term "multimedia" and replace with synchronized media
    • There is active debate in A/V group. This would be a problem for most media formats today. There is already a way to deliver captions and video descriptions and this probably isn't necessary.
    • Agreed to remove this provision. If Allen has any issue we can reopen.

• New provision on identifying the language:
  • Proposal: Content formats which support multiple languages must provide a programmatically determinable mechanism to identify both the primary language, and the language of any sections that are in another language from the primary language.
    • Any objections
    • No other standards that have content format standards. This is unique to the US.
    • The closest thing to content format in WCAG is we talk about technologies that are supported. Looking at it from the standpoint of an accessibility supported concept.
    • WCAG requirements for accessibility-supported technolgoes are not as prescriptive as the content format requirements. WAI is looking at defining a standard for "accessibility supported content technology" and this could feed into that process.
    • Concern with the wording "support multiple language". There is no specific mechanism to determine that, so this could be somewhat unbalanced. It may have intended to include some kind of encoding and could apply to formats that could not provide a programmatically determinable mechanism.
    • Action: Sean Hayes to post his concerns with the proposed content format language provision to the mailing list.

• Guidance on when compliance with these provisions is required. Who makes claims? Concern for duplication of effort.
  • Every tool does not need to answer these questions, and this could be a logistical problem.
  • Email needs to be accessible as well as other documents and that part is important.
  • Problem is the standard has to have something technical that can be met. Could be less proscriptive. How to do this is not as tightly covered.
  • Some think that the idea of content formats is when one software system is talking to another software system, not about how software saves something to disk. When 2 pieces of software are communicating, they need to do something to transfer the necessary accessibility. We should re-craft the provisions. Information may be persisted for some time and it is an active communication. The sending software is providing data, so the receiving software has the necessary information.
  • Others disagree. Think this is more then just machine to machine communication.
    • A user agent can not convey the language from a document if the language is not available somewhere. Some of this is mute if the supporting information is not there. It is an accessibility issue that agencies should be aware of when they move forward with such choices.
    • When a user works through the document tool to include accessibility information, they need to be able to add alt tags or language information. It's not reasonable to expect each tool to have a language parser. That is the issue in general. The right step may be to move to potential counter proposals. We understand the goal, but we need to come up with wording that addresses that goal.
  • Suggestion to put in general provisions that cover everything. Then you have less of a problem and it would make it a general requirement of all.
  • Agencies have to be able to implement this. The goal with 508 is to give agencies that procure the most accessible available, and maintain and use the tools in an accessible manner. They are having problems training to make email accessible. This provision should take them to the next step, to help agencies become more accessible.
  • Action: Michelle Budris will add a note in Friday's draft that we have a to-do to add guidance on how the content format provisions should be applied in the VPAT process.

Keyboard Operation

• Lost concept of scoping this to devices that have keyboards.
• Current: All functionality of the product operable through the user interface must be operable through a keyboard interface without requiring specific timings for individual keystrokes. The only exception is where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
• Proposal 1: All functionality operable through the user interface must be operable through a keyboard interface, on products that have keyboards, without requiring specific timings for individual keystrokes. The only exception is where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
• Proposal 2: Where products have a keyboard or keyboard interface , all functionality of the product operable through the user interface must be operable through the keyboard or keyboard interface or other mechanical buttons without requiring specific timings for individual keystrokes. The only exception is where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.
• Proposal 3: Where products have a keyboard or a keyboard interface, all functionality of the product operable through the user interface must be operable through: the keyboard, or a keyboard interface, or other mechanical buttons. Specific timing for individual keystrokes may not be required. Where the underlying function requires input that depends on the full path of the user's movement, not just the endpoints, this section shall not apply.
• Proposal 4: Where products have a keyboard or a keyboard interface, all functionality of the product operable through the user interface must be operable through the keyboard or keyboard interface. Specific timing for individual keystrokes must not be required. Where the underlying function requires input that depends on the full path of the user's movement, not just the endpoints, this section shall not apply.
  • Concern that "or" in first sentences causes intent to be questionable and it may need a rewording.
  • Assumption that everything that accesses the Web has a keyboard. WCAG may need to revisit this in light of iPhone and others that browse the Web without a keyboard.
    • Iphone has an on-screen keyboard. This requires a keyboard or keyboard interface. iPhone will have a bluetooth keyboard that will allow it to conform.
  • Concern that proposed wording allows you to make it operable through the keyboard but not the keyboard interface. Could mean a user would not be able to plug in a custom keyboard.
  • This can be a keyboard software interface, and may not have a jack on the product. To require everything to have a keyboard jack could be a problem. Most devices that support text input will support bluetooth keyboards, which will get your connection back.
  • Would like to have clarification added that a keyboard interface supports an on-screen keyboard.
  • The key is that the content and application be available regardless of how the keyboard is connected. The application should be keyboard controllable.
  • Greg posted something to the list with the last sentence rearranged that may address this.
  • Suggested that we look at it on the list and let it settle for a week.

Reading Sequence

• Current: When the sequence in which information is presented affects its meaning, a correct reading sequence can be programmatically determined and sequential navigation of interactive components is consistent with that sequence.
• Jared's Proposal combined with editorial suggestion: When the sequence in which information is presented affects its meaning, a correct reading sequence must be programmatically determinable. The navigation sequence must be consistent with the reading sequence.
  • The understanding was that we wanted the first text, because the first text was in harmonization with WCAG.
  • WCAG has updated wording. Action: Michael Cooper to provide updated WCAG wording. Andi Snow-Weaver to review it to see if there are any issues.

Focus Indicator

• Close on testability note: A focus cursor that is visually locatable by people with unimpaired vision at 2.5 meters when software is displayed on a 38 cm (15 inch) diagonal screen at 1024 x 768 pixels resolution, without moving the cursor is sufficient.
• A note on this provision will be used to determine what is highly visible. It was included in the draft with a note that we are working on this.
• Could use 2.5 x the typical viewing distance as a general metric.
  • Works for cell phones where the typical viewing distance is 9".
• Concern that a person needs to know what they are looking for and have some familiarity with the software. A person with 20/20 vision may not know what a focus cursor looks like
  • Suggestion to add "and is familiar with the software" or "familiar with that type of software".
• Suggestion to add locatable by people with unimpaired vision and add an example with other devices. This is meant to be a note that explains what the provision is saying that is more understandable.
• Action: Gregg Vanderheiden to make proposal to the mailing list.

New Action Items

• Andi Snow-Weaver to add remote system access to the list of issues to consider in the harmonization work for the "both a platform and an application" provision.
• Sean Hayes to post his concerns with the proposed content format language provision to the mailing list.
• Michelle Budris will add a note in Friday's draft that we have a to-do to add guidance on how the content format provisions should be applied in the VPAT process.
• Michael Cooper to provide updated WCAG wording on "Reading Sequence". Andi Snow-Weaver to review it to see if there are any issues.
• Gregg Vanderheiden to make proposal on focus cursor to the mailing list.

Attendees

1. Tom Brett
2. Andi Snow-Weaver - IBM
3. Eric Damery, Freedom Scientific
4. Sharon Snider
5. Chris Meier
6. sean hayes (Microsoft)
7. Peter Wallack (Oracle)
8. Laura Ruby
9. Amy Chen (Oracle)
10. Angela Hooker
11. Peter Korn, Sun Microsystems, Inc.
12. Andrew Kirkpatrick (Adobe)
13. Jim Elekes (Access Board)
14. GreggVan
15. Katie Haritos-Shea
16. Michele Budris, Sun Microsystems
17. Jim Allan (W3C-WAI)
18. Michael Cooper, W3C
19. Jamie Smith
20. Barbara Lybarger, Mass. Office on Disability