Regrets

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.

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.

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.