22 July WCAG WG Teleconference

Participants

  1. Chair: Wendy Chisholm
  2. Scribe: Ian Jacobs
  3. Charles McCathieNevile
  4. Jason White
  5. Dean Denmon (Lighthouse International)
  6. Rob Neff (US Mint)

Summary of Action Items

Editors:

  1. Make the errata page more visible from the WAI GL home page.
  2. Draft a proposal on clarifying 3.3 thread and send to GL list. Once "approved", add to Techniques, FAQ, and errata page.
  3. Request to EO WG that they point to/highlight Techniques as place for clarifications.

Rob: Send us usability data to GL list.

Chair: In two weeks, put on agenda a discussion of what questions to ask about guidelines to Rob's users (and for others as well).

Discussion of checkpoint 3.3

JW: No need going over old ground. Clarification of cross references.

CMN: Not so sure.

/* CMN explains background of issue to Dean */

CMN: Three conformance levels is a good thing. RN has suggested that either we change checkpoint priorities. But since they're based on impact, we're not in a position to do so. JW has talked about a compliance profile - you specify which checkpoints you comply to. But this is too complicated in my opinion. Difficulty in current explanation is that it's not clear how it works in practice. In my message today, I discussed 11.1, 6.1, 3.3. Note that CSS spec discusses interaction between HTML and style sheets. If you are using HTML elements and attributes in addition to CSS, then you are still using style sheets for your control. The inclusion of FONT is not the accessibility killer - it's the inclusion in place of structural markup.

JW: So how does HTML presentation markup interact in the cascade? Do user style sheets still override? Are there implementations that follow section 6.4.4 of CSS2?

CMN: Amaya gives you user style sheets. IE gives you user style sheets. When you get user style sheets, the cascade has worked (though survey is not exhaustive).

JW: To move forward, I recommend making clear cross references (e.g., in FAQ). I don't think we should revisit the basic requirement.

CMN: We should make clarifications in promotional material. And in the Techniques document, point these things out (e.g., section 6.4.4). Need to say what counts and what doesn't for implementing style sheets.

JW: Other observers have arrived at the same conclusion.

RN: Some of the verbiage of WCAG 1.0 concerns me. People will take these things verbatim. Visit http://www.usdoj.gov/cot/508. People creating a checklist for accessibility. Follows an older version of WCAG. A lot of "N/A". The feedback that I'm getting: People are going to say "N/A" to a lot of things.

WAC: What are they saying "N/A" to today?

RN: What they don't want to do or don't understand. How are people going to fill out the form accurately? How are managers going to know that the checklist is right or wrong?

RN: People say "CSS, no, we don't trust style sheets."

CMN: The way we need to address "caveats" or "explanations" is to provide clarifications.

RN: People don't take the time to read the notes. People don't care about the conformance logo, they care about accessibility.

JW: Can't prevent people from misusing the document or not reading carefully.

RN: My proposals have been to create a summary clarification.

CMN Proposes:

List requirements before doing a new Recommendation release. E.g., boost visibility of Techniques document. Also make guidelines leaner in the next version.

JW: Some surveys are showing that people spend most of their time in the techniques document.

CMN: But a number of people don't: those with more understanding of the topics.

b) Make clarifications in the Techniques Document, FAQ. (CMN Notes that lack of explanatory information in guidelines document forces people to look at Techniques document).

c) Tell EO to point people to Techniques Document for clarification.

RN: We need to write to least common denominator. A lot of secretaries are managing Web sites. I propose renaming "Errata" to "Addendum". Make more visibile from WAI GL page. (IJ: This can be done already.)

JW: I don't think guidelines should be written for "low comprehension level". Up to EO to do promotion. I think it would make the guidelines work to simplify further (since some is inherently complex). EO should be writing summaries, tutorials, etc. People should even be encouraged to start with tutorials.

Action Editors:

  1. Make the errata page more visible from the WAI GL home page.
  2. Draft a proposal on clarifying 3.3 thread and send to GL list. Once "approved", add to Techniques, FAQ, and errata page.
  3. Request to EO WG that they point to/highlight Techniques as place for clarifications.

RN: Proposes changing the title of the errata page to include mention of clarifications. Add link to FAQ from errata page.

CMN: Need EO to point people at Techniques document. Also need to get EO group to draft how-to use. Ensure visible links from GL/EO home pages to techniques doc and other clarifying documents.

RN: I have some usability issues with the document and not being able to touch bytes.

/* Ian compares stable published documents and dynamic pages */

IJ: There's no "best document". There are many pages and many slices that are important. Each serves a particular audience.

JW: Use WAI home page as a starting page.

WAC: We need to put all GL-related documents in one place: the GL home page. Before trying to fix more, let's

Action RN: Send us usability data to GL list.

RN: People using Word, Front page, dream weaver, ..

WAC: So people not using guidelines.

RN: We need to make the checklist easier to use.

WAC: Cross refs don't appear in checklist.

RN: People will take checkpoint text verbatim in checklist. Need clarification there.

CMN: Perhaps use GL page as the primary reference point?

Action Chair:

In two weeks, put on agenda a discussion of what questions to ask about guidelines to Rob's users (and for others as well).

CMN: I publish (on the Web) the questions and answers in my presentations I give as part of my slide shows.