31 January 2002 WCAG WG minutes ?

Here are the minutes from yesterday's meeting. 

attendees:
wc - wendy chisholm
jw - jason white
lgr - loretta guarino reid
cs - cynthia shelly
mm - matt may
kb - kynn bartlett
jo - jonathan o'donnell
jm - jo miller
lr - lee roberts
es - eugenia slaydon
ms - mark stimson
ap - annuska perkins
gv - gregg vanderheiden
asw - andi snow-weaver (scribe)

regrets:
katie haritos-shea
paul bohman

action items:
wendy:      post to the list the reworded consensus item on server side
solutions. allow review and comment until Monday, 2/4
lee:  look into research on objective conditions for the proposed success
criteria in jason's proposed new checkpoint 3.2.
all:  look at jason's proposal for 3.2 at
http://lists.w3.org/Archives/Public/w3c-wai-gl/2002JanMar/0105.html
      comment specifically on the issues that have been raised: divide into
two checkpoints, specific proposals on success criteria, overlap with 3.3
mark: look at research for objective rule of thumb we could apply to
jason's proposed new checkpoint 3.2. might also be applicable to 3.3

jw - agenda today is the requirements document and action items distributed
a couple of weeks ago. discuss chaals comments on mailing list regarding
consensus item regarding server side techniques.
asw - what if one version of the content is not accessible? what good does
it do to put a link to the accessible version in an inaccessible version.
jw - have issue with 3rd bullet: seems to preclude content negotiation as
acceptable way to meet the guidelines.
jw - suggested rewording: "can be reached via content negotiation or
accessible, easy-to-find links in the other versions of the content"
kb - even if use content negotiation should still provide link to other
versions.
cs - adding a link to a content negotiated page may be necessary now but
won't always be needed. Should be in techniques document
jw - guidelines need to last for very long time.
wc - as long as it can be reached easily, we don't need to specify all the
ways
jw - "can be selected according to user preferences"
jm - need to cover the case where links to accessible content are placed
after the inaccessible content so people can't get to them.
wc - "can be easily selected according to user preferences"
wc - may add a note: "we will not make any assumption about the method that
is used, whether it be content negotiation or a link. we leave that to the
techniques document."
wc - do we need another few days of discussion on the list? concern that
gregg and chaals are not here.
jw - short window - four days or so

ACTION: wc will post to the list the reworded consensus item on server side
solutions. allow review and comment until until Monday, 2/4

[after gregg joined, some further discussion on this topic]
gv - how will we close out requirements document if we get a lot of
comments before Monday?
wc - can remove consensus item because we don't have consensus, publish
with issue, or not publish. 
gv - if everybody on the call agrees, we have consensus
gv - chairs could decide if something is significant enough. could send
e-mail to members in good standing to see where they stand on it.
gv - should not post something that does not cover server side solutions
gv - if anyone has serious issue with server side solutions being in the
requirements, need to raise immediately
gv - when does draft requirement cease to become a draft
wc - will always be in that state (working draft), since don't think we'll publish as note and it is not on the rec track. 

wc - reads the list of success criteria assignments
jw - jason's guidance on writing success criteria posted to list. number of
people posted their work to the list
lgr - sent thoughts on 4.1 to lisa but lisa had no time to work on it this
week. defer until next week
wc - not ready yet on 3.4
jw - posted proposal for 3.2 to the list
wc - reads jason's proposal
wc - jason proposes dividing 3.2 into 2 checkpoints: 1) Emphasize structure
through presentation. 2) Divide long sequences of elements such as
paragraphs, lists or user interface components into logically organized
groups, which are labeled appropriately.
jm - should the first one under second checkpoint be above testability
line?
jw - no way to tell whether or not the divisions are adequate, appropriate,
or logical
gv - what if someone writes a long letter? do they have to break it up and
have titles in the middle of the letter?
gv - how do we have an objective mechanism for figuring out when they have
to do it at all?
jw - not always appropriate. don't have clear pre-conditions. comments?
wc - very much about how to divide up a document but not about user
interfaces. how does this apply to forms or applications?
jw - next success criteria applies to user interfaces
jw- tried to organize it by type so that it wouldn't be incomprehensible
jc - both success criteria are testable if remove the word "logically" from
the checkpoint
jc - assume that anyone who divides something does it in some logical way
gv - there are some things where it may not be appropriate to put headers
in it, such as a love letter
asw - content may not be original in which case you can't modify it
jm - quoted material can be bracketed. think letters should have
headers in them
gv - not right to say that something is not accessible unless it has
headers in it
wc - i believe it is required to make it accessible
gv - different from talking about a tuned site vs. something that you
require all sites to do
ms - remember that these guidelines could become law. accessibility vs.
usability
wc - headers VERY important to people using screen readers. otherwise,
can't skim it.
jm - does this strictly require headers or something like them (labels)?
jw - yes, this is meant to require whatever labels the markup language
allows, such as headers
jw - need to separate out compliance issues from applicability issues
jw - once someone decides they want to comply with this checkpoint, is
there something we can put in the success criteria that helps them know
when they
should apply it?
gv - good point. should decide what it means to meet a checkpoint then
later figure out whether or not we want it to apply to every site or not.
jw - are there any broadly accepted UI principles that suggest how to
divide things up?
mm - five plus or minus two is a general guideline that is often applied
mm - 640x480 display in IE
cs - find pages where you have to click on a link to get to the next
paragraph are annoying
gv - suggestion was on where to apply headers, not on limiting page content
to an arbitrary size
gv - there are rules of thumb that can be applied but might make a bad rule
jm - especially if legislation requires is
mm - can we really separate things that are good to do from compliance?
wc - can we really write rules or are we writing rules of thumbs?
ms - people can't see as much on screen as they can see on paper. are there
differences for screen reader users?
jw - purpose is to improve comprehension. obviously, it would apply to
people using assistive technlogy but it is intended to improve readability.
jw - is there any cognitive research around that would help?
jm - is the assumption that this can't go above the testability line unless
we tell them how to do their divisions?
gv - criteria is that 10 experts must agree when someone has properly
applied the success criteria
jm - thinks they can both go above the line because logic is defensible.
jw - how long does something need to be before it needs divisions?
ms - there is research available that shows that all material is less
comprehensible if it cannot be chunked
gv - key is that information needs to be "chunkable"
gv - understandability is dependent on topic
gv - are we really saying that things should be divided to improve
comprehensibility and here are a list of tools that could be applied but
don't specify when to use which?
jw - if it isn't clear when to apply it, people evaluating can't determine
whether or not it is appropriate to apply it.
jw - expect to run into similar problems when get to checkpoints on
paragraphs
jw - suggest that cp 3.2 in the proposal should be moved into 3.3
wc - want to get a set of success criteria first then figure out how to group them
later
jw - any objections to the success criteria for 3.2? until we can advise
when to apply them, they should remain below testability line.
jm - are we keeping them below the line because think some documents are
too short for it to apply to?
ms - in English composition, taught that each paragraph should start off
with its main topic.
wc - before worry too much about wording, need to make sure concepts are
there.
jw - posted to list two weeks ago. no comments. revisit this next week
lr - some guidelines suggest that people use h1's styled to look like
regular text to increase hits in search engines
jw - but that violates 3.1
jm - human testable pretty easily
wc - need success criteria under those checkpoints that tell you not to do
these things
jw - belongs in the techniques
jm - could give good and bad examples
jw - thought we weren't going to give bad examples
wc - have a lot of them now and they are very helpful

ACTION: lr to look into research on objective conditions for the proposed
success criteria. other wg members need to look at proposal and comment
specifically on the issues that have been raised. should we divide into two
checkpoints, specific proposals on success criteria, overlap with 3.3
ACTION: ms to look at research for objective rule of thumb we could apply.
might also be applicable to 3.3

jw - any issues with checklist jason and gregg drafted regarding drafting
good success criteria?
gv - so many things that authors can do to make their documents easier to
understand but somehow we have to figure out how to tell them what to do in
such a way that they don't fail a checkpoint for not doing it in a place
where it really doesn't apply.
gv - there's one guideline "write things in a way that makes them clear and
easy to understand". there are lots of things you can do but none will
guarantee that the reader will understand it.

Received on Friday, 1 February 2002 11:48:59 UTC