W3C Web Accessibility Initiative

WAI Authoring Tool Guidelines Working Group

WAI AU Teleconference - 29 November 1999

Details

Chair: Jutta Treviranus

Date: Monday 29 November 1999

Time: 3.00pm - 5:00pm Boston time (1800Z - 2100Z)

Phone number: Tobin Bridge, +1 (617) 252 7000


Agenda

The Latest Draft is the Proposed Recommendation draft dated 26 October, available at http://www.w3.org/TR/1999/PR-WAI-AUTOOLS-19991026.


Attendance

Regrets:


Action Items and Resolutions


Minutes

Agenda

Issues raised during PR review

Procurement issue

Issue: Is it appropriate for these guidelines to be used as a basis for making procurement decisions?

GR: Can't regulate how they will be used.

WL: Current wording, w3c process sufficient

IJ:There is no language about Recommendations v. Standards. This is just Comm Team practice.

DB: I don't think we need particular information about this issue in the document.

WL: Just because we don't say they shouldn't be used for procurement decisions doesn't mean they should be.

JT: We should rely on people's intelligence. It may be a good idea to refer to ATAG for procurement some day.

WC: The EITAC already refers to the other two guidelines?

JB arrives

JB: The EITAC Report recommends that the access board, in their rule on section 508, refer to three of the W3C Recommendations (the guidelines). It recommends that it refer to them at the Double-A level. The EITAC report was submitted last spring. The NPRM has not yet been issued. That NPRM may or may not carry through the EITAC recommendations. Due to conversations of the past couple of weeks, I called the access board last week with some questions. The types of the authoring tool accessibility guidelines related to prompting, help, etc. are not as much a concern w.r.t. section 508; the primary concern is the user interface. It appears there might be a disconnect between what that particular US law would be looking for as a reference for that regulation, and what they would point to if they pointed to Level Double-A of the ATAG. I'd like to get confirmation in the next couple of days. This would be available as background for our group.

JB:

  1. In one or two of pertinent communications, it may have appeared that I recommended using language he was advocating. This is absolutely not the case.
  2. I am not sure that the Recommendation v. Standards language exists. (Confirmation of Ian's comment).

JB: We could ensure that the introduction includes information about how to use the document.

WL: I thought it was understood.

IJ: I think it's not about philosophically opposing the use of the guidelines in a procurement context (this has in fact, I believe, been part of the design from the beginning). So what's the motivation behind the request? Is it that it's too hard today? Let's choose language to address that.

Exit William, Enter Charles

JB: Other issues - will all AU Tools be ruled out if none complies?

JB: Perhaps language useful in the document about what the document is and isn't.

JT: More precisely?

JB: A sentence in the intro or conformance section. Not a major redefinition.

JT: Would a statement such as "these are goals, not the status quo" cover your requirements?

IJ: Proposed language (action item from last week):

The Working Group recognizes that the requirements of this document are ambitious in light of the accessibility of most authoring tools at time of publication. However, this document represents consensus in the WG on accessibility requirements for authoring tools today and tomorrow.

JT: Would like to limit a statement to goals, not talk about ambitiousness.

DB: What about a statement very directly that W3C does not control how these are used.

JB: Something like: "As with other W3C Recommendations, this specification represents requirements and goals, not status quo of authoring tools at time of publication."

GR: Something like "The purpose of these Guidelines is to specify base functionality for an accessible authoring tool." Keep it simple.

JB: I am siding with the proposal to emphasize the notion of "Recommendation", which we don't always do in other Recommendations.

JB: Clarification; the Guidelines are technical reports and full-valued Recommendations. They do differ from other language specifications from W3C, however.

CMN: We should be absolutely clear in the "Status of the document" section.

DB: Yes, we can add words to the effect of "W3C does not police or enforce, dictate use", etc.

IJ: I recommend that this WG do what it wants, then W3C will pick up on it if it wants it. WGs are encouraged to avoid boilerplate text in the status section anyway.

.Resolved:

Proposed:

Action Jutta: Send this proposal to the list.

Action Jutta and Charles: Draft a summary for the reviewer who raised this issue (1: not up to WG to say how guidelines will be used; 2: status section will contain all the pertinent information).

Extent of a tool's responsibiliity in relative priority checkpoints

Matrix?

CMN: As expressed last week, I think it's not desirable to include a matrix in any case. It's probably also impossible.

JT: Yes, since relative to a specific tool. All of the checkpoints need to be supported by the tool in one way or another. Whether the support comes from the tool or the author depends on how close the author is to decision points.

IJ: Sounds like the "applicability" clause in UAGL. The notion of "applicability" is not present in the ATAG. One idea is to provide applicability as a stepping stone towards understanding what a particular type of tool might have to do.

JT: They all apply, since more general. But how they apply varies according to the type of tool. And how they are implemented varies with the user interface.

CMN: Perhaps we should include a half-paragraph in the conformance section that addresses:

  1. Assessments of conformance don't have formal standing.
  2. In assessing conformance, each checkpoint stands alone. A tool may conform to a checkpoint while not conforming to another. That's why conformance claims are based on priority levels, not individual checkpoints.
  3. While all checkpoints are broadly applicable, there are some cases where some requirements don't make sense. We should make a statement similar to UAGL to this case.

IJ: But it doesn't sound like my proposal of "applicability" helps that much.

CMN: It helps a little to clarify how to do things right. I like Jutta's proposed text about positive examples.

Proposed:

Action Jutta: Create a few sentences that state how checkpoint interpretation is relative to tools.

Resolved:

Enter Judy

JB: Related issue to above resolutions. There are some issues about the clarity of how the checklist is presented. There are 9 Priority 1, then X relative priority checkpoints (horrific multipliers...).

CMN: Propose a note in the checklist "Relative priority testing of these must be done on a checkpoint-by-checkpoint basis with WCAG."

JB: If you think the priority levels will remain stable, then I recommend that you break it down further to give them a flavor for what to do.

Action CMN: Draft text for the checklist explaining that the relative priorities expand.

JB: Rather than trying to finish the document by this week, if you had an additional week, would that matter? Would it only matter if you had an additional three weeks?

CMN: I'd like to have the extra week. I think that three weeks would not be better.

Birds in Australia concur...

Discussion of REC release timing.

CMN: I intend to review/edit the issues list with current understanding, for review by WG.

Action CMN: Update the issues list with WG resolutions and apparent resolutions on the mailing list.

JB: Other layers of requirements: drafting replies to comments, Director message, etc.

Conclusion:

JB: Please note, however, that I can't commit to a release date yet, even if the WG is ready.

Level of user skill and interpretation of priority

What level of skill in producing accessible markup can the developer assume on the part of the author?

JT: How skilled is the average user?

CMN: I suggest that we mean the "average targetted user" for the specific tool. If your tool is marketed to power users, that's who we mean. If your tool is for everyone, that's who we mean.

Action Wendy: Draft a sentence for the priority statement that reflects the following:

Resolved:

Priority/Redundancy of Checkpoints 4.3, 7.3, 7.4

CMN: I think these have been addressed adequately by email.

Action CMN: Propose a resolution to the list and document from issues list.

Interpretation of checkpoint 7.1

CMN: I think these have been addressed adequately by email.

Action CMN: Propose a resolution to the list and document from issues list.


Copyright  ©  1999 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.


Last Modified $Date: 2000/11/08 08:11:51 $ by Ian Jacobs