28 March 2002 WCAG WG telecon

Present

Regrets

Summary of resolutions and actions

Proposal for non-W3C technologies

LGR Proposal for what to do with non-W3C technologies.

JW As much of an issue with WCAG 2.0?

LGR Comes up around technique documents. Clearly label when a technology is not a W3C tech. I would like to see such documents (Techniques) exist, since WAI is a good place for people to start. Also, I would like them to be consistent between each other.

WAC /* summarizes discussion from Saturday morning, where this was discussed. Loretta and others took an action item to propose language as disclaimer. Minutes from that discussion are not yet published. */

MM If a non-member interested in publishing a submission for technique, the requirement be they join WG as invited expert, then use that as the weight to publish in W3C space.

Action WAC and LGR discuss proposal for disclaimer for non-W3C techs. Also, process. Chase up Judy's idea about W3C member submission. Review section 8 of the Process document - Member Submission.

PB Implications for the user if they do not have the necessary plug-ins.

LGR Many of these are related to the new section 5 requirements.

Techniques for XML apps

LGR Techniques for every XML app?

PB Some overlap, but some specifics. If we have a whole bunch of techs, it becomes more complex.

MM Depends on how it exposes itself to the user. SVG is not necessarily human readable, but usable by humans when rendered. Others are for data interchance and not exposed directly to humans.

CS An XML accessibility document. If authors are expected to interact with it as markup, then have a techniques document. If XML conforms to XAG and authoring tool to ATAG, then should be ok. Many of our techniques are based on teaching authors how to do by hand.

LGR In PDF we do not expect authors to interact with directly. They need a spec as to what to generate.

CS You should write a spec.

JW Techniques doc should not assume that the material is being created by hand.

CS I would expect to find that in the spec for PDF.

LGR It will say how to do that. The actually instructions, "you must provide an alternate description" are not in the spec.

CS I would expect PDF spec would have description of structure for a graphic or whatever and specify how the image is marked up.

LGR Could have legal PDF that is not legal.

WAC HTML 4.01 onwards requires alt on IMG.

LGR For backwards compatibility, can't require structure.

WAC We need to state clearly which technologies we will write techniques for and why. If someone comes to us and says "we want techniques for technoogy xyz"

CS Great, write it.

JW If someone has experience in relevant technoogy and wants write techniques, then that's an argument for publishing. If sufficiently wide-spread, ...

WAC However, W3C process. /* reviews JB's comments from the Saturday meeting */ Basically boils down to resolving the action item that LGR and I took earlier (the disclaimer language).

Techniques document format

MM Should we use this for other techniques documents formats? /* describes format */

WAC Is it a question of should you use it or who's going to do the work? <grin/>

MM When asked before, someone had issues. I think Charles said we should use XMLSpec.

WAC I researched this and found both through reading the spec and talking with the editor (Eve) that the direction we were heading was good. I propose that we next test it against Core, since it is unique (not technology-specific). Then try CSS.

CS I would also like to do for server-side techniques.

Action MM, CS, WAC apply the techniques dtd to Core techniques, CSS and server-side.

Issues list

WAC Yes, go through, but needs to be cleaned up.

Action WAC clean up issues list.

Color contrast

2.2 Ensure that foreground and background color combinations provide sufficient contrast when viewed by someone having color deficits or when viewed on a black and white screen.

WAC This checkpoint was lost.

CS Let's put it back in.

LR Can we get more specific? white on black gets hard to read.

CS If a user can use style sheet or OS settings, less of an issue. Unless, have text in graphics.

JW It would fit under revised guideline 1. It is a perceptual issue.

Action Editors: Propose wording for color contrast checkpoint (use existing 2.2 from WCAG 1.0) with some success criteria?

Action LR: draft success criteria for contrast checkpoint.

Normative technical specifics?

not ready to discuss

Server-side solutions, multiple versions of a document

CS Had proposed something a couple years ago. Could be part of server-side techniques.

JW Make conformance claim if multiple versions if only one served at a particular time.

CS In addition to conformance, there is work to build that UI for switching between versions. Therefore, it might need to be a checkpoint.

LR Is that legal?

CS We have a consensus that under WCAG 2.0 it would be legal. WCAG 1.0 is ambiguous.

LR Issues of privacy. It would not be correct under U.S. law to ask someone about their disability.

CS Unwise to ask that way, but if you had a set of renderings, then the user selected or a cookie not tied to user's personal information. e.g. I have "large format" and "small format" and let the user's choose.

LR We would have to be very clear about how people would implement profile searching and questioning.

CS I'm not a lawyer, but if not tied to personal information, I don't think there is an issue.

JW CC/PP a method. apart from discussion in conformance scheme, what other provision do we need to make?

CS There are plans for server-side techniques. Most of what we've been thinking about is configuration of the UA or user CSS. Multiple rendering is more about author providing set of renderings and you pick from them. It might have to be a checkpoint - having a way to switch between them.

JW You could draft one for under guideline 5.

CS Thought I had before...

Action CS either find previously proposed checkpoint for switching between multiple renderings or propose one.

Issue #29 - covered by Cynthia's new proposal

Need consensus on it.

Issue #32 - Tool-specific requirements

LGR If you are going to repair problems in PDF, I can write instructions for how to do that if using Acrobat. It is a repair tool. Do we want to talk about Acrobat when talking about WCAG?

JW It belongs in ATAG.

CS Also a repair tools doc?

JW When previously raised, CMN working on a doc.

LGR Checked with, refered me to ATAG group.

WAC Don't think much has happened with. Check with Jutta and Jan. Related issue: people who are not technical who test for accessibility. EO working on a document already. We need to work with them. But, we also talked on Sunday on how to test manually and w/a tool.

LGR Heavy dependencies between ATAG and UAAG.

JW WCAG specifies code in format. ATAG and UAAG write corresponding requirements.

Resolved: an ATAG issue.

#34 - Mapping between 2.0 and other guidelines

CS Seems reasonable.

JW Problem is that if there is another set of guidelines and the requirements are similar but they set different thresholds or are not explicit about success criteria or word things differently, it could be easy for someone who sees a mapping to conclude that the requirements are the same. They might fulfil the same need but be different. Require someone to spell out the differences. Become a large work item. There used to be lots of guidelines out there. Which one would it be worth the tiem and effort?

CS I was assuming this was mapping between this and ATAG. If others in the world, except 508.

WAC Two suggestions that I have heard:

  1. map between our guidelines and others. There are several that exist: 508, IBM, etc.
  2. keep our own internal list and review to make sure that if something good is happening in another set, that we are aware and try to get those people invovled.

CS Keeping mapping up to date too much work. Our own list sounds good.

JW Mapping between 1.0 and 2.0 is necessary.

CS Harvesting other docs and looking for good ideas is a valuable exercise.

Action ASW: map WCAG 2.0 against IBM guidelines.

Resolved: we want to keep ourselves up to date with other guidelines, but not keep a mapping between WCAG and other guidelines up to date. We will keep mapping of WCAG 1.0 and WCAG 2.0 up to date.

CS Maybe XAG.

Action WAC: find someone to help keep internal list of other guidelines so we can track other work in this area.

#58 - Skip navigation link

CS Core. General UI issue.

JW Legacy. If have good structure, don't need it.

CS Any UAs that do support good structure?

WAC Grouping not really provided in HTML.

CS In table.

JW Moved since a technique and technology-specific.

WAC Navigation mechanisms?

Action WAC: while cleaning up issues list, issue #58 needs some digging. Why did we get rid of this? Where did it go? Under navigation mechanisms?

#61 - Examples of and tests for flicker

WAC How do you test for flicker?

LR Look away from screen. Success criteria provided in drawings. If you need to see something at night, look 10 degrees on either side and you'll see teh object. If you look at something that is flickering you might not see it head on but off to the side you could see it.

CS How do you determine if it is in the range that would give someone a photoepileptic seizure?

LR That would be hard.

CS We could provide examples of flicker on either side of the safe zone.

JW Is there software?

LR Don't know of any.

MM It is dependent on the client machine.

CS Something that is fast enough on one machine could be dangerous on another.

JW Designing something with an animation rate in the range would fail.

CS The speed that it renders will be hardware dependent.

PB in graphics authoring tools you can determine the animation frame rate. You can set that. It doesn't help with hardware flicker issues.

MM When talking about 2-59 Hertz. You have a range that is basically impossible to do reliably on anything. I think the situation is it is the jumpy nature, smooth motion.

WAC Are other factors that can cause seizures (patterns, colors, size). However, testing for flicker rate is difficult.

JW Can create success criteria, but it is the testing.

Action LR find out more about testing for flicker rate.


$Date: 2002/03/28 22:38:18 $ Wendy Chisholm