W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2000

Minutes from 16 November 2000 WCAG WG telecon

From: Wendy A Chisholm <wendy@w3.org>
Date: Thu, 16 Nov 2000 17:59:25 -0500
Message-Id: <4.2.0.58.20001116175824.00d023b0@localhost>
To: w3c-wai-gl@w3.org
Available at: http://www.w3.org/WAI/GL/2000/11/16-minutes.html

16 November 2000 WCAG WG telecon

Summary of action items and resolutions
       Action WC: make sure the word "style" is used consistently.
       Action WC: Add examples to 3.2
       Action WC: rewrite 3.2 to take into account suggestions from 
today's call.
       Action WC: Rewrite 6 to incorporate today's discussion.
       Action WC: See if place for CMN/JW proposal about deciding which 
technologies to use. Perhaps as clarification to 6.
       Resolved: on the agenda for future meetings/open issues:
       Requirements for testing?
       Requirements for digital signatures on claims of conformance?
       Providing checklists and tests for technology-specifics. Learn from 
IBM checklist feedback.
       Resolved: No meeting next week.
       Resolved: New draft next week.

Participants
       Donovan Hipke
       Dick Brown
       Jason White
       Wendy Chisholm
       William Loughborough
       Cynthia Shelly
       Andie Snow-Weaver
       Loretta Guarino Reid

Regrets
       Gregg Vanderheiden
       Len Kasday
       Kynn Bartlett
       Katie Haritos-Shea
       Sean Palmer

Checkpoint 3.2
WC I'm behind on the list, what is the gist of the comments that Sean made?
WL Use of classes.
JW Use of markup is 2.3.
WL You have to identify that you are using style elements as pseudo 
elements for structure. e.g., use "sale" as class in style sheet, the only 
way to get the semantics out of it is to look at css.
JW That is an issue, but it comes under 2.3. Using markup correctly. 3.2 is 
using presentation properly.
WL Yes, 2.3 is related. There is an easy interpretation that 3.2 should 
say, "when using styles" it should further delineate that styles that are 
used must be revealed as being structural.
WC Suggesting a specific tie back to 2.3?
WL Yes.
WC Will depend on how 2 (all of it) gets reworded. I see a lot of overlap.
JW They are parallel but different.
WL This is design for comprehension, that's why you're doing it here. It 
reemphasizes that one. 2.3 is great. Color, styles, and graphics: perhaps 
find something that is general. Those apply so specifically to visual 
tricks, we might think of what this is in general.
JW Appropriate styles for the medium, then include examples for different 
mediums. Then there would be a link to 2.2 which discusses styles for the 
particular medium. 3.2 would specify in greater detail what is required.
WL In addition, 3.1 style is used in a different context. Doesn't have 
anything to do with style sheets, but rather "style" in artistic sense.
Action WC: make sure the word "style" is used consistently.
Action WC: Add examples to 3.2
DB 3.2 is more or less new? It is a requirement or an alternative?
WL We haven't put priorities on it yet. Likely in the priority 2 or 3 
neighborhood.
JW Reasonably controversial, but facilitates comprehension. Certain amount 
of criticism of 1.0 that it did not adequately emphasize the high quality 
of presentation. This checkpoint tries to address that in a more explicit way.
DB style here means markup style, right.
WL Yes.
DB In 2.3 we're talking about markup. so this is a repeat?
JW Markup is not style.
DB Why not say style sheet?
JW Doesn't have to be a style sheet. SVG doesn't necessarily use style 
sheets. PDF doesn't use style sheets. Both use styling as well as 
structure. Requirement is independent of how it is implemented.
WL Headers are designed by academics. Browser took those and arbitrarily 
assigned style characteristics to them. We're saying "add decoration to the 
structure so that people can better see it."
JW Default rendering might be enough, but might not. In which case they 
will want to add other presentational elements to enable effective 
communication. Issues? or may we move on.
WL Instead of "use color, etc." make more general. e.g., "Emphasize logical 
structure of the content." and put rest in examples.
DB Still concerned about specifics. I don't understand "graphics." How do 
you use those for the structure of the document.
WL In addition to having default header element, that you put a picture 
next to the H1.
DB I think that is unrealistic. People look at that as visual clutter. It 
adds to the download time.
WL The question is whether that something that gives you choices and still 
has a priority, the priority is that you make the choice not pick one thing 
that you have to do.
DB We're now starting to say that you need to use a graphic to communicate 
the info in different ways.
JW I don't think that's present in the checkpoint.
DB With the example of graphics, how is it not.
JW Graphics present info or content, they don't necessarily present the 
structure. Do we have a checkpoint to use graphics to convey meaning?
WL WHat about using "or" rather than "and." "Emphasize logical structure of 
the content." then right under, it says, "if the default presentation of 
the structural element is not adequate to the task of the audience then the 
introduction graphics, colors, sounds, etc. to emphasize structure is 
recommended."
DB Gives people more of a choice.
JW Provide appropriate styles or presentations to emphasize the structure 
of the content, then there could be examples and explanation of how to do 
it. No requirements that any approach be taken. Default presentation could 
satisfy.
WL What we're trying to nudge authors to do is to be aware of default 
renderings, and it if is adequate for their purpose.
JW recognizing there are some that do not have default renderings.
WL True, but the user agent may have a default rendering.
JW Yes, in HTML, but not in an arbitrary XML language. Therefore, rewrite 
this so that it depends on default rendering.
WC Good to incorporate but not apply to every case.
Action WC: rewrite 3.2 to take into account suggestions from today's call.

4.3 and 6.3
WL The way JW wrote it made sense to me.
JW I had some private comments saying that they liked the rewrite.
4.3 Give users control of mechanisms that can interfere with their ability 
to navigate, or which require content to be read or responded to within a 
limited period of time.
WC concerns about the wording. Would like to simplify or to divide into 2.
DB agree. Have major concerns with what it means.
JW Gets rid of until user agent clause.
DB But it is not clear. We don't say which user agent to use as a base line.
JW If the user agents support it then the author doesn't have to. We're 
discussing "baseline capabilities" on the list. It provides guidance.
DB I disagree, unless we know that user agents are supporting it then we 
are requiring authors to do it.
CS We used to say authors should not use automatic refresh. Now we say, you 
can but you have to be ware.
DB If I'm a content developer, how do i know to author in a way that gives 
user ability.
CS Today, no one supports it.
DB We're trying to soften it in the note. If the user agent does it, you 
don't have to worry about it. But if someone does it next year we're not 
going to say only design for this browser.
WL We're clearly moving the "until user agent" to a different level. 
Question of whether it should be anywhere is not arguable. At some point, 
we have to say we no longer support Mosaic.
DB That's fine. I understand that this is an issue we have to deal with 
elsewhere.
/* discussion about UAAG requirements for stopping refresh */
CS There are 3 ways to satisfy the checkpoint:
not do it
let the ua control it
write something that let's the user control
Today, only 1 and 3 are possible, and at some point in the future #2 is 
hopeful or likely.
WL It's still important enough to write as a thing to do.
WC "Give users control of timed mechanisms that may interfere with 
navigation, comprehension, or interaction...?."
JW One checkpoint or 2?
WC I do think we can combine them, but "timed mechanism" is too jargony.
JW There are aspects that are not "timed" however.
WC Timed mechanisms and extreme changes in context.
WL I'm still troubled by guideline 6 itself. That's why I'm trying to get 
everything out of it. "capabilities of user agents" bothers me. 6 seems 
parallel to others.
CS 6.2 is a special case of timed mechanisms.
WC Boil down 4.3, 6.2, and 6.3 to timed mechanisms and extreme changes in 
context?
JW blinking has a bit different rationale.
CS Then 6.1 be part of 5, device independence.
WL Yes. The "user" is a device could gain credence.
CS Netscape 3 and a cell phone are both devices.
JW Very strange definition.
WL When we talk about device independence.
JW Guidelines 2, 3 and 4 are output and 5 is input.
CS We may run into that confusion more and more. There is emerging jargon 
in industry that device is browser, PDA, etc.
JW Or a cell phone.
CS From an author's perspective, a crummy browser and a cell phone browser 
are similar creatures. Many think of those as writing for device independence.
WL I have less objection to guideline 5 than 6. As I understand JW, forcing 
6 into 4 and 5 has to do with notion of device.
JW And the importance of compatibility with software that includes user 
agents, and assistive technologies.
WL How do you reconcile "capabilities of user agents" with getting rid of 
"until user agents."
JW Somebody who developed content which they believed would not be 
compatible with UA's and would fail to satisfy under that guideline, that 
the UUA detail of determining if something is implemented in a UA is in the 
technique. but someone who carries it through inappropriately has to fail 
to conform to something. what they would fail to conform to is under 6.
DB I think 6.1 is part of the larger issue. It is very broad. I don't 
understand it. It seems to say the same thing.
WL DB and I are agreeing. The newer technologies being turned off means ... 
not supported, seems to be very broad. CSS2 is essentially not supported. 
CSS1 is barely supported. X* is essentially not supported. At some point 
they will be somewhat supported. This is the "until" department. We will 
have to supply a when. "Now" this is a requirement b/c we passed the "when."
DB WHat is "newer" versus "older." I don't think 6.1 should be a checkpoint 
or come across in broader concept.
JW What would people fail to conform to if they didn't take it into 
account. I'm thinking of mapping between 1.0 and 2.0.
DB "newer technology" does that mean features of a browser, or something 
that we can't imagine now?
CS Flash? TAbles? at one point, tables were a new technology.
JW Obviously relative to what is implemented in the field. That's the kind 
of relativity that comes here. We need a more detailed discussion.
WL In a certain sense, we have decided that guideline 6 requires quite a 
bit more discussion than what we have time for today.
/* agreement */
JW Part of that discussion will end up in the techniques for each of the 
specific points. This is based on a checkpoint from WCAG 1.0.
WL One improvement might be to leave something out. It needs to be clear 
when one has conformed to the checkpoint. The idea of "newer" is too vague.
JW There has to be a checkpoint somewhere that one would fail if they did 
not act appropriately in the area.
WC Guideline 6 from 1.0 is where this checkpoint comes from. Stating a fact 
that in 1.0 we had a checkpoint that said scripts need to degrade 
gracefully, that is only represented by checkpoint 6.1 in 2.0. Nowhere else 
in 2.0 are applets and other programmatic objects covered. Therefore, we 
can't get rid of it, but it is the wording of a guideline in 1.0 that 
covered several checkpoint. Perhaps a way to make it less encompassing.
CS We're talking about graceful degradation. Can't we define it immediately 
afterwards? with examples?
WC Yes, like text equivalent and auditory description.
JW 6.1 is the only place where this requirement from 1.0 is mapped into 
2.0. We need to add some criteria.
CS Graceful degradation is something people usually learn in month 9.
WC Then reword it as 1.1, use graceful degradation?
WL If you rewrite 6.1, then incumbent on that is a rewrite of guideline 6.
JW What you should take into account when deciding which technologies to 
use. There is a proposal that could fall into guideline 6, as a clarification.
WL If something is already written out, and it gets included in the next 
couple of weeks we can discuss it.
JW If WC working on 6, then incorporate that. Can that fit logically under 
the rewrite. Referred to in the agenda for this meeting. CMN has been 
talking about it for a while.
Action WC: Rewrite 6 to incorporate today's discussion.
Action WC: See if place for CMN/JW proposal about deciding which 
technologies to use. Perhaps as clarification to 6.
WL To get into queue for potential agendas or issues list, i want to deal 
with the notion of having checkpoints or guidelines dealing with indexing. 
The first phase is to implement a claim of conformance statement. It is 
part of accessibility process that the who, when and affirmation of 
conformance is included.
CS RDF stuff?
WL How it gets implemented is not as important as that there be indexing.
CS Related, encrypted certificates that say "this is certified to be safe." 
May be interesting to look at a certification for conformance. Don't know 
how realistic.
JW CMN has written a program that lets you make a checkpoint by checkpoint 
claim.
WC CS is talking about a certification body.
CS Or that the claim is digitally signed and unforgeable.
WC Don't know about certifying sites, but some are trying to certify people 
as developers.
JW Came up in a conference yesterday. There is skepticism. 3rd parties 
should be allowed to make assertions about content or developers. Then to 
verify the assertion you could look up trusted parties of your choice. If 
they confirm the assertion you could have more confidence in the assertion.
CS Even just adding a digital signature would help.
WC Related idea, ER is discussing a checkpoint that requires testing. 
Recently, I've been working on a checklist that includes the checkpoint as 
well as the automatic and manual checks.
JW Both manual and automatic checks are important. Would it be good to 
include it under each technique.
WL My intention to do that in my x-checker. At the end of each checkpoint I 
link to the appropriate techniques, guidelines, and a few cases to tools.
WC See that the in the technique-specifics for 2.0 we have checklists and 
within the checklists have tests. Algorithms for humans, and where possible 
tools can then automate.
ASW That's how the IBM checklists already are. We get feedback that people 
want one place to get tests. They don't like the format. They have to go 
through each checkpoint to figure out how to plan their tests. One place 
for knowing what tools to use.
WL There are lots of skeleton keys to the guidelines available. What i've 
implemented in x-checker. The checkpoint has a link at the end of it to 
each technique documents, to the specific point in the technique document. 
It is an easy way to get to the specific section.
Resolved: on the agenda for future meetings/open issues:
       Requirements for testing?
       Requirements for digital signatures on claims of conformance?
       Providing checklists and tests for technology-specifics. Learn from 
IBM checklist feedback.
Resolved: No meeting next week.
Resolved: New draft next week.

$Date: 2000/11/16 22:53:12 $ Wendy Chisholm

--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/-- 
Received on Thursday, 16 November 2000 17:54:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:08 GMT