Web and Software: September 26

Miscellaneous

• Minutes approved from September 19, 2007.

Review of action items

1. 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.
2. 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.
3. IN PROCESS: Andi Snow-Weaver to make proposal to resolve harmonization issues around "Both platform and application" provision.
   • On today's agenda
4. IN PROCESS: 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.
   • On today's agenda
5. COMPLETE: Sean Hayes to post his concerns with the proposed content format language provision to the mailing list.
   • Included in larger discussion about the entire 8.1 section on content format requirements
6. Michele Budris to add a note in AT Interoperability and User Interface Component provisions for rationale of why we used the word "component".
7. Michael Cooper to work with Shannon Rapuano and Peter Korn to re-word 2.4.6 Labels Descriptive to an acceptable testable provision.
8. Andi Snow-Weaver to get the discussion on parsing issues started with AT vendors, find out how much of an issue this is, and bring it back to the group.

Technical Topics

Authoring Tools

• Judy's summary
  • 8.2-D:
    • This answers questions about remediation, but may need fine tuning to include output to assess both.
    • Getting the output back from an evaluation tool is an important part. but hopefully its not too constraining.
    • Suggestion to change it along the lines of "communicate with" Since it needs to send and receive from the evaluation tool, but "communicate with" is just as vague as "compatible with".
    • There are authoring tools that have plug ins for evaluation. Something that functions as a plug in is part of the authoring tool.
    • Some authoring tools have them built in to the native structure, and some teams use external evaluation tools.
    • Implies that there is a standard way of how the evaluation tool does the reports. There are tools which already implement EARL. They are not all conformant versions and it is a valid concern. EARL is not a finalized w3 standard at this time.
    • There are also tools such as AccVerify and AccRepair.
    • Concerns with the second half... you can only use an evaluation tool for evaluation, and the application must fix the problem. Should have a 3rd party tool fix the content. Does not know why it has to be just an evaluation tool. It was not meant to be excluded and the wording should be fixed.
    • There are a variety of tools to do this. Some without no or very little interface. This ties back to our initial discussion about defining what an authoring tool is. There are a lot of different ways to create and repair content.
    • We do not want to exclude someone from using a tool that can do its own remediation. We want to make sure that someone using a given authoring tool that produces accessible content does not have to go off and use a completely different tool. Somehow we need to address the relationship of authoring tools with regard to the evaluation function.
    • Need suggestions for fine tuning the language.
    • People want flexibility for evaluation and repair. It is difficult to define what will work in a testable way and it will be problematic. Some favor moving this to an advisory note.
    • Can keep it as a requirement and note that there is still a problem with the recommendation and not be so proscriptive that we say you must do this in your tool... or you must do this in a 3rd party tool... We just want to be able to get the job done. He would keep it in the provisions and as part of the explanatory documentation that we are having problem with it.
    • Makes sense to have a note in 8.2B that this is important for compatibility with evaluation tools.
    • Reminder to the group that this is not a Web authoring tool, but content authoring guideline.
    • The standard should come out in 2009 and then there will be a standard for interoperable formats.
    • Next steps: Check with authoring tool people on how some of the tools function. Looks like we are aiming for moving this to an advisory note.
  • 8.2-B:
    • Agreement that this this covers it good and fits the need.
  • 8.2-C:
    • This provisions is vague and a testability concern. How much prompting is sufficient?
    • In an earlier meeting "how much prompting" was addressed by having a default mode. Have a mode where it does and does not do that. Does not think there is an issue.
    • Where we draw the line in what an authoring tool must prompt for? Prompting is a way of assisting. There is always a challenge of wanting it to do more... it has to be a judgment call on the part of the vendor of the tool. This text is a reasonable compromise.
    • In a word processor with hyphens it is a violation of information and relationship, would the word processor have to provide a prompt? It is easy to break those as soon as you get out of the Web content arena.
    • Existing language is minimally satisfiable. Having it in here now puts it on the radar and encourages, but does not require.
    • Its about, does the tool have a mode, not what the mode does. We do not need to go deeper.
    • Lot of discussion here on interpretation. Needs a clarification note - "this should not be interpreted that it will cover every accessibility feature" or something like that.
    • Suggestion to pair each of these with further explanation. It would go along way to include everyone's issues without losing the importance of authoring tools to fix the content problems.
  • Definition of Authoring tools:
    • "intended" is a fine word, but could also use the word "designed". Some think "designed" is slightly better because it puts the onus on the creator of the tool and not the purchaser of the tool. The creator of the tool puts these features in. From a VPAT point of view, can clarify that this is the intent and if the agency has a different intent its up to them.
    • Suggestion from Sean's August posting:
      1. Separate content into 2 different classes. Accessibility and non-accessibility supported.
      2. Create an authoring tool that provides specifics for authoring in that format. This would exclude note pad.
      • Concern that this is a complicated way to address the definition. If there is a way to manage this with a simpler definition it may cause less problems.
    • Could scope out plain text. Concerned that some people may put Word in that category. Thinks "intended" works better then "design". Look at it from the agency perspective the word "intend" is more interpretable.
    • There are also a variety of simple editors. Sean's proposal seems to take care of it. If we don't use Sean's suggested definition, then we have to make sure in our provision of what an authoring tool must do. It should be clear its for accessibility supported content.
    • Some think that using the term "intended" solves the problem of scoping out simple editors. It says "for each accessible content format supported..." simple format and simple tools are ruled out. ** Continue discussing authoring tool definition on the mailing list.

Section 8.1 Content Format provisions

• Proposal for introductory text
• Allen's summary (Thank you Allen!)
• Applicability in procurement, overlaps with requirements in section 3
  • What if a format doesn't comply with everything but it doesn't matter because the product is not using the format in a way that would fail any of the provisions in section 3?
  • What matters is that the product can do everything required in section 3.
• How are open formats handled?
• Products may support multiple formats?
• What if the format doesn't meet the provisions out of the box but can be extended?
• Trying to solve the problem of developers not being able to do what is needed because the format doesn't support it.
• The requirements are too prescriptive. For example, for non-text content, the requirement is that there be a text alternative and that there be a way to associate it with the non-text content. But there are other ways to do it rather than requiring that it be in the content format encoding mechanism.
• Harmonization issue - unique to US
• Developed with office documents in mind but governments store lots of other kinds of data - digital photographs; satellite imagery; cctv traffic, security, and other video; medical scans; geographical information, etc. - which are recorded in content formats that would not meet these provisions. If agencies decide to make this data accessible, it will be done through some other means, such as a database, not by altering the content format itself.
• Claim that reports generated by software are not considered in the 508 assessment of the software. This risk may be reduced or eliminated with the new merged section on user interfaces and content.
• Suggestion to remove the section from the technical provisions
  • Add into explanatory notes for appropriate provisions in section 3
    • Example of note that could be added to the non-text objects provision: In order to achieve this provision, such non text objects in data operated on by the software must be associated with equivalent textual descriptions that the software can obtain as readily as it can obtain the non-text object itself.
  • Add into a section on agency requirements. Important in the consideration of what format to use.
    • This is a good list of the accessibility characteristics that such formats should have in order to ensure that accessibility information is preservable in a format.
    • Suggestion: Agencies and their employees and agents must ensure electronic information is developed and maintained such that any receiving party can use software to access that information in a manner which complies with the software provisions.

Discussion:

• Suggestion that moving it to document and support section maybe a way to address all 3.
• Not sure how this can be moved to document and support. The intent was to come up with things that would help get more content in general to be accessible.
• We need a combination of Allen's suggestions 1 and 3. A section for operating it correctly by the agency and then when the software is creating a user interface the data has to be in it. There is enough text in the threads to create the 2 options. Put guidance for the agency and something in the software provision to be able to do that.
• This is one that should be "an agency should use" kind of provision. Use them where? "when they create content, buy Web site, etc..." A provision with a bunch of bullets that specify. "Agency should use or specify..."
• One of the biggest challenges is how this would be implemented. Concern is that this is completely redundant for what we are seeing in section 3. Everything will still need to meet section 3 standards. This adds extra baggage to the already long set of standards and makes it harder to read and understand.
• We have 1.2-A accessibility configuration... there may be 1 or 2 others. This may be a place to put this rather then document and support.
• The laws require this of agencies and not vendors. Needs to be spelled out clearly under section 3.
• All the requirements are on agencies and we all agree this does not go in the document section. The content section may be where they end up.
• Make sure there is explanatory notes for each provision.
• Next step is to float ideas on if we keep them, where do they go.
• Need something that says we use the "most" accessible format and then delineate it in a note. Even if we use 3 as that broader scope it won't make "what format" go away.
• Section is user interface and content. The feeling was that some of these things even though they need to be provided, they do not have to be in the content format.
• Action: Allen Hoffman and Sean Hayes to form a sub-team and come back with a suggestion. Include Andrew Kirkpatrick.

New Action Items

• Allen Hoffman and Sean Hayes to form a sub-team to look at section 8.1 (Content formats) and come back with a suggestion. Include Andrew Kirkpatrick.

Attendees

1. Tom Brett
2. Andi Snow-Weaver - IBM
3. Sharon Snider - IBM
4. sean hayes (Microsoft)
5. Jared Smith (NCDAE)
6. Andrew Kirkpatrick (Adobe)
7. Allen Hoffman DHS
8. Jim Tobias
9. Chris Meier
10. Michael Cooper, W3C
11. Alex Li (SAP)
12. Peter Korn, Sun Microsystems, Inc.
13. Michele Budris, Sun Microsystems
14. Jim Elekes (Access Board)
15. Katie Haritos-Shea
16. Judy Brewer (W3C/WAI)
17. GreggVan
18. Laura
19. Jamie Smith
20. Barbara Lybarger, Mass. Office on Disability