W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2001

29 March 2001 WCAG WG minutes

From: Wendy A Chisholm <wendy@w3.org>
Date: Fri, 30 Mar 2001 10:25:24 -0500
Message-Id: <>
To: w3c-wai-gl@w3.org

29 March 2001 WCAG WG minutes
Summary of action items and resolutions
       action: gregg, jason, and andi will take a pass through the 
document and state whether something is objectively discernible vs. not 
objectively discernible. also determine whether something is accessibility 
or usability. due 4/12/01.
       The issues raised in the change log from the latest draft as well 
as Kynn's proposal for deleting the "clear and simple" checkpoint are still 
open issues

       Paul Bauman (webaim)
       Jeff Isom (webaim)
jw: agenda is 1) consider general issues with latest draft of WCAG 2.0 
released yesterday and 2) discuss checkpoint 3.5 - write clearly and simply
wc: issues concerned about. action item to write introductions to each 
guideline. seems displaced to write intro after guideline. instead, added 
overview in introduction. became very metaphorical. is this the right 
direction? would this be more appropriate in executive summary?
kh: likes categories added to each guideline.
wc: suggestion from f-2-f
wc: still need to update checkpoint mapping
wc: edits are all marked and listed in change log
wc: checkpoint 2.1 reworded. used to say "provide a variety of navigation 
mechanisms". too vague. new wording is "provide more than one path..." At 
CSUN, disussion about providing more than one path may not be appropriate 
for all sites, especially if they are very simple.
as: what is the rationale for this checkpoint?
wc: different people find things in different ways
pb: the way 2.1 is now, read it that any one of the suggested methods would 
meet the checkpoint
wc: WCAG 1.0 13.4 - use navigation mechanisms in a consistent manner. WCAG 
2.0 history is that this got split into 1)provide a variety and 2) provide 
them in a consistent manner
jw: primary driver is for cognitive disabilities. propose we limit it to 
relatively large and complex web sites. must be defined; i.e. more than xx 
documents and linked with great many cross references, structure is 
reasonably complicated. must do research to decide what complexity 
threshold must be.
wc: WCAG 1.0 defined "important". people had a very hard time dealing with 
it. maybe something like this would apply to some of the other checkpoints 
as well such as the one on writing simply and clearly. at f-2-f meeting in 
October, at device independent workshop, Tom ? said they found it useful to 
categorize web sites and apply guidelines based on category. seems 
complicated but keeps coming up as a possible solution.
pb: one method that stands out in 2.1 as not having to do with cognitive 
disabilities is the skip navigation links method. concerned that this one 
will get lost and not correctly categorized.
jw: trying to get rid of legacy issues
gv: where is the skip navigation links requirement?
as: in 2.1
gv: not sure this really fits under this guideline.
kh: how about "provide more than one path .... for ease of navigation"?
jw: invite proposals on how to handle 2.1.
mm: design of everyday things by Norman. decision trees and how to organize 
them. seems like that's what this checkpoint is trying to get to. e.g. if 
you have something that is 100s of items and 2 levels deep, do A. if you 
have something that is 1000s of items and 3 levels deep, do B.
gv: suggest removing 2.1 and 2.2 because have nothing to do with 
accessibility. they are usability
kh: why shouldn't they be in there?
as: because it confuses the issue.
gv: these are here for cognitive reasons. in example above, "complex" is 
different for someone who is profoundly retarded. in cognitive, no matter 
what you recommend, you will leave someone out. if pursue putting these 
things in, will come up with something that is not only untestable. you 
can't even agree with yourself.
gr: have a list of guidelines for accessibility, not usability. what we are 
thinking here is that the ultimate usability of a site is the baseline for 
our work here. Steven Pemberton (?) from f-2-f looking at creating IG on 
usability. for now, we are stuck putting in things that are really 
"usability" but have a quantifiable benefit for accessibility.
gv: but no one will legislate that a site be usable. accessibility 
guidelines or derivatives of them will be legislated. propose we remove 
usability items out of the checklist. if we do this, we will eliminate 
anything that we have now for cognitive disabilities. dilemma. could take 
usability things and put them in a separate section - general usability 
concepts, interact strongly with accessibility
kh: would this be in the normative document
gv: yes
gr: need to define accessibility and usability if we take that approach. 
muddies the waters a lot more than addressing some of the usability because 
accessibility is a subset of usability.
gv: usability makes it easy to use. accessibility removes barriers
bb: accessibility is also about compatibility which is not usability
gr: if we don't address these issues, we're not addressing accessibility
jw: should continue but need to address Gregg's concern about accessibility 
issues that have to do with cognition. no matter what you do, there will 
always be some people with cognitive problems that will not be able to 
access it. cognitive-related checkpoints can improve acess but are not 
decisive. is there a way of developing these in a way to say "the more of 
these you implement the more accessible the site will be. assign priorities 
based on type of web site being developed." unlike other checkpoints where 
meeting the checkpoint means it is accessible and not meeting the 
checkpoint means it is not accessible.
wc: need to provide rationale for each checkpoint
gv: all of cognitive ones will benefit all disabilities. can say you want a 
site usable by blind or deaf users but can't say a site will be usable by 
people with cognitive disabilities.
wc: because cognitive disabilities is such a broad category. you could pick 
specific cognitive disabilities and make a site usable by that segment. Ann 
has a lot of sites that are just pictures. the reason she is using them is 
educational. there are a lot of people who communicate through images. 
could provide guidance on specific cognitive disabilites.
gv: information about how to design targeted sites for people with 
cognitive disabilities should be taken out of WCAG document and published 
in a separate document. not recommendations for all sites. W3C can decide 
whether or not this document should be on a W3C site or somewhere else.
wc: we've learned so much about other disabilities.should do the same for 
cognitive and learning.
gr: same conversation we have been having since the winter of 1999. don't 
believe there is a strict demarcation between usability and accessibility. 
talking in last half hour about an impact matrix more than we have about 
accessibility guidelines.
mm: issue here is that when it comes down to cognitive disabilities, 
changes are made to content itself and are not quantifiable. with vision 
and hearing disabilities, the requirements are well defined because you are 
really targeting a "tool" that the user uses. with cognitive disabilities 
though, you are targeting the person.
gr: i was not born blind so my abitlity to conceptualize is different from 
someone who was born blind. we should honor the work that has been done 
over the past two years to try to solve these issues.
jw: is there anyone who wants to remove the usability issues from the document
gv: i argued strongly to include cognitive requirements in the document. 
keeping something in the guidelines should not be decided by how much work 
was put into it. been wrestling with the cognitive part a lot. not able to 
find a good solution. nobody appointed this committee to develop usability 
guidelines. some of the things should come out of the guidelines. "clear 
and simple" language checkpoint should be removes. need to separate those 
things that are absolute and measurable and people should do from those 
things that people should work toward. can leave in but in a separate 
section. we are watering down the other things by keeping these things in 
mm: design practices document
gv: if pages are terribly laid out, it may be impossible for someone to 
figure out with a screen reader
gr: have to be adept at reading document source
jw: idea - move cognitive issues into a checkpoint "these are factors that 
need to be taken into account in designing content." In some instances 
there are measures - more than xx documents and yy links, complexity 
threshold exceeded. problem is that no matter what you define, you will 
leave out some people. people in cognitive disabilities communities are 
distrustful of numerical measures of reading grade level.
wc: checkpoint we hear the most complaints about in WCAG 1.0 is the "write 
clearly and simply" one. uncomfortable removing or moving cognitive things 
just because it is hard to do
jw: not that they are hard to do but hard to define when you have "done" them
gv: they are impossible to do. can't put something in guidelines that can't 
be done in all places on all web sites. if guidelines are "advice" you can 
write them a particular way. if guidelines are for compliance, people must 
be able to prove that they have met them. could put them all as priority 3 
but that doesn't seem to be the right thing to do.
gv: can require that somebody require alt text. can't require that the alt 
text is clear and simple
jw: never had trouble with "write clearly and simply".
wc: in 1.0 don't have tests required to ensure that you have met a requirement
gv: who decides if it is clear and simple? author. fought for this to be 
priority 1. want people to try and do it.
gr: can prompt and assist them in making that judgement.
as: agree with Gregg that cognitive/usability issues cloud the issue. in 
IBM, I have to be able to tell someone how to test/validate that they have 
met a requirement. these are not testable.
pb: agree. could separate into objective and subjective elements.
gv: might be a good exercise to look at what we have and categorize as 
objective and subjective. can we come up with an objective measure for 
them. we might find that some we think are subjective can be made to be 
jw: checkpoint 3.5 - say you had a numerical measure of readability from 1 
to 100. If you test a web site and come out with a measure of 65, have you 
met the requirement or not? if lower from 65 to 60, does that have an 
impact on readability for people with cognitive disabilities or not? could 
set a target but not achievable for all web sites.
pb: leave in subjective area and not try to come up with measure for it. 
allows you to include fuzzy areas in the document with the recognition that 
it is not an all or none criteria.
jw: still concerns that division is what we can implement and what we can 
wc: but that is already occurring. Bobby has so many things that have to be 
manually checked. Most people just ignore those and say they pass.
gr: Bobby approved with subjective hat
gv: could have q&a session. answers to questions determine whether you pass 
or not.
wc: must be able to automate or describe process of how you test each 
thing. biggest thing that is not included in WCAG is what is the process 
and tools you use to assess a site
lg: whatever we write, the people who are developing the web sites will 
have to understand what we mean. we have things in mind when we write the 
checkpoints but it may not be clear to the web site developers
gv: how do you apply "write clearly and simply" to quantum theory? very few 
people in the world can understand it.
wc: WCAG 2.0 is not written clearly and simply. not trained to do that.
lg: most people in the world are not trained either
wc: impact matrix
jw: go through the draft and indicate where tests are required
wc: have already for WCAG 1.0 with AERT
gv: need applied to WCAG 2.0
jw: indicate where there are well-known criteria and where there are judgements
gv: create parallel table to use as we study it
jw: with 2.1 for example, there is an issue of when to do it. is it 
applicable to your particular web site and have you achieved it? a lot has 
been done in AERT document. not always technology specific.
wc: matt is going into AERT to create HTML techniques. Jason is suggesting 
that we go through WCAG 2.0 and split them up into things that are 
subjective and objective. think that this can only be done at technology level.
jw: automated is totally different thing
wc: in ER it is the same.
gv: things that are discernible by all of us that are not automatable
pb: quality of alt tag is subjective
wc: i have written alt text that people have told me is "wrong"
gv: just decide if it is passable. it can always be better
wc: still subjective
gv: think we could have a set of rules that would work
jw: reasonable semantic relationship where most people would agree on 
whether or not you have met the rule
wc: who will take the action item?
action: gregg, jason, and andi will take a pass through the document and 
state whether something is objectively discernible vs. not objectively 
discernible. also determine whether something is accessibility or 
usability. due 4/12/01.
wc: still have all issues that were on the mailing list and Kynn's rewording
jw: most of the issues are related to this

$Date: 2001/03/30 15:24:32 $ Andi Snow-Weaver (scribe), Wendy Chisholm

wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
Received on Friday, 30 March 2001 10:25:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:36 UTC