W3C home > Mailing lists > Public > w3c-wai-er-ig@w3.org > February 2001

12 February 2001 ER WG Telecon Minutes

From: Wendy A Chisholm <wendy@w3.org>
Date: Mon, 12 Feb 2001 13:06:11 -0500
Message-Id: <4.2.0.58.20010212130535.00cde770@localhost>
To: w3c-wai-er-ig@w3.org
http://www.w3.org/WAI/ER/2001/02/12-minutes.html

12 February 2001 ER WG Telecon Minutes
Summary of action items and resolutions
       Resolved: Check for point size and suggest don't use. Instead use a 
relative unit of measure, ala WCAG.
       Resolved: Will look at properties for assertions such as 
"exists/doesn't exist" , "should exist or should not exist.", "qualify/does 
not qualify." which is basically "valid/not valid" or having one property 
that can take one of the following values: 
needs/doesn't-need/unchecked/appropriate/inappropriate/suggested"
       Resolved: Will propose to WCAG and AU to discuss at the face to 
face joint meeting the idea of scales for rating conformance to checkpoints.
       Action: Chris will minute the next meeting.
Participants
Chris, Len, William, Harvey, Wendy
Point size
CR WCAG says that point size must be flagged.
LK That's what it says. Propose that ER adopt WCAG. It is clear in WCAG.
WC Reason that specify relative no matter where specified, is so that 
people just can't easily turn it off but want to increase the font size and 
have the layout adjust to fit.
/* Discuss sections 6.1 and 5.2.6 of CSS1 spec. */
Resolved: Check for point size and suggest don't use. Instead use a 
relative unit of measure, ala WCAG.
EARL
LK Reactions to how EARL is going? It's mostly CMN, SP, and sometimes DB 
and I talking about it. In terms of process, do you have suggestions.
CR Good to see progress.
LK Are people buried or is there something we can do to make the dialog 
more appetizing?
CR It's fairly complex. A practical example, a program that would do 
something so that people could play with it, would make it easier to grasp.
LK A while back CMN and I talked about WAVE outputting some EARL and Amaya 
inputting it. Nothing has happened with that. Also talk about putting this 
in a framework where you could have automated reasoning, to make some 
inferences.
CR How would you view the results? Some images require a longdesc and some 
do not, if you wanted to see which images on a page require longdesc and 
the results stored in EARL how would you view?
LK You have an EARL file. You have a program...how would it do it in 
A-prompt? It would give you wizard boxes with image and place for longdesc. 
If you have a program that would do that, what is the information it needs?
WL It needs to know where the author believes it needs a londesc. Can say 
insert longdesc here or put in following phrase, "image does not need 
longdesc."
CR Give it a file, need longdesc, yes/no. When run through tool can say, 
"this image needs longdesc or not."
LK How refer?
CR How handled in EARL? How refer to it later? What if it is in another file?
LK In Sean's e-mail, "first crack..." Tool needs to know who asserted it, 
what the image is, what the file is.
WC could say x:person assert y - that image needs a longdesc.
LK Don' thave the last part.
WC Is it a comment or detail? Problem is, need more detail in the examples.
LK Perhaps we need an EARL term "needs longdesc" or "needs alt." or more 
generic "needs attribute." That's a defined EARL Term, then give the name 
of the attribute.
WL THen have "does not warrant longdesc?"
LK Have "needs" "does not warrant" or "doesn't need." "Unchecked"
WC Want to assert, <Using the rule URI-from-WCAG-technology-specific [image 
x] "needs/doesn't-need/unchecked/ok"> doesn't-need and ok are both "ok" 
states, but one in that it doesn't need it in the other it's been provided.
CR Per document basis. In one document may need longdesc, in another might not.
LK There are some sites that have a logo that would be interesting to hear 
described once.
WL Take an iconic photograph of the raising of flag over iwojima. The 
longdesc is different depending on use. If analyzing shadows vs use in history.
WC Assertions at object level and at context level.
WL Several assertions per each level. Can't carry all of the annotations 
with everything. Take the bible more annotations than passages. I'm leary 
of too many "needs/doesn't need/could use" etc.
LK OK doesn't handle provided but inappropriate.
WC Could have appropriate and inappropriate instead of OK.
HB Different checks for different places.
WL Right.
LK Another property, "Should-be." Person going through review could make a 
recommendation as to what an attribute should be.
WL Wherever you got the image from, could carry such a thing. I vote that 
we stick with 4 and go on.
WC Don't need to limit it to 4, currently have: 
"needs/doesn't-need/unchecked/appropriate/inappropriate/should-be"
LK Appropriate - exists ok. inappropriate - exists but doesn't qualify.
HB Prefer suggest to should-be.
LK Ok.
WL This apply to a whole lot of things other than images.
LK Yes. Titles, objects, etc.
WL The summary of tables.
LK If we want to be technology-specific, we've been talking about attribute.
WL Or more than one element.
LK Apply to an attribute of an element (longdesc) or content of element 
(object). Needs means it doesn't exist, but should. Not-needed means it 
doesn't need to exist and doesn't exist. One case we haven't covered is 
where it doesn't need to exist but does. Are there any cases where putting 
an optioanl element is bad.
WC There could be a rule set that would keep track of Jaws oddities, like 
how it handles alt and title that could be confusing. In which case someone 
might want to be warned.
LK A rule database for JAws.
WL One for IE 5.5 vs 4.7 to see what style sheet attributes are implemented.
LK Could imagine a page where lots of images and the longdesc is helpful 
and in the others it is useless. Someone who is blind read the worthless 
longdesc then read another longdesc and get tired of reading the longdesc. 
Then they miss the useful longdesc. This is theoretical since no one uses 
longdesc.
WL What about more complex elements like object?
LK What do you think is missing?
WL They contain applets. Is the language that that the applet written in 
accessible? Fundamentally, if get a good set could be used to address object.
HB Object remains in limbo in HTML world.
LK I've never seen a page that uses object.
WL Don't know what browser supports.
CR Can convert applet to ojbect. Will work on IE on Win. If running on mac, 
get an applet since doesn't support. A script at beginning of page that 
loads correct.
LK Another way to cut the pie is to have an attribute "exists/doesn't 
exist" another one that says "should exist or should not exist."
WL Then need "qualify/does not qualify." It should exist, it does exist, 
but the one that's there isn't any good.
LK Have several variables that can appear in different combinations. You 
either take all of the combinations and make a value or take the individual 
ones. Every time I look at needs/not needs I have to translate. Independent 
of how we describe it, do we have all of the semantics that we want?
WC Might reflect the process better. i.e. one tool automatically check if 
alt exists or not, up to the human or another tool to determine if 
appropriate or not.
LK When we say so and so says such and such, split human versus machine.
WC For now, but hope that some human checks be machine checkable in future.
WL Seems logical to me. Take all of those things where can conceive of 
something and then bring to life. We know whether we can check for 
attributes and most of those we already have in place.
LK We can tweak the vocabulary more, have we covered all of the semantics 
we want to express?
WC At this point, "exists/doesn't exist" , "should exist or should not 
exist.", "qualify/does not qualify." which is basically "valid/not valid"
WL Not all are yes or no.
LK Need a rating scale?
WC Also "suggested." A rating scale...would need an algorithm to help 
someone decide.
LK When I rate a site, I do wind up saying stuff like this. "that gets by, 
but it could be better."
WC qualify/not qualify/kinda qualifies with a suggestion.
LK Like jumbo and extra large, which is bigger? Rather have a number. If 
EARL is general evaluation rather than "can i put a AA stamp on it." there 
are shades of grey, such as "how usable is the site." You'll have people 
who have never been on an ER call who can say "usable" or "this stinks" or 
whatever.
WL No doubt that you have to have a scale. Not on whether there or not, but 
anything that requires human judgement, that's what human judgement means - 
scaling and rating.
WC What's the scale and gradations?
WL 7 + or - 2.
LK Analogy to CSS, x-large, large, medium, etc. Could have different scales.
WL If you have any human comments, count on a scale.
WC Verbosity, appropriateness, lots of scales. degrees of each.
WL Appropriateness on different scales - technical languages use, etc.
LK In questionnaire land they reduce to good or bad on the 2 ends although 
they phrase it differently. A scale is a rating method.
WL Then we get to pick vectors. Perhaps they tie in with checkpoints. If 
you have a checkpoint that says clear and simple then you have clarity 
barometer and simple barometer. Then the tool that we design has the 
purpose to evalute on the axis specified by the checkpoint.
WC reads from latest WCAG 2.0 techniques.
WL Those are instructions to give to person doing the evaluation.
LK Out of compliance model from 1.0.
WL Talking about expanding check/no check to 7 +/- 2 level. This is close 
to simple enough so i give it a 4.
LK What is happening to compliance?
WC Nothing yet. Not sure where to put priorities.
LK This raises a problem for WCAG, should scales play a role in WCAG?
WL Right, an issue. There is no such thing as Level 2 1/2 A. The 
checkpoints themselves in the new ones are abstract and that essentially 
demands scalarization. Have to say if something is clear in the context for 
this audience. That's why these tools might help push in that direction. If 
we are commissioned to make a tool to determine if the checkpoints have 
been followed we need leeway. You have specified something that requires 
scales (by the phrase "for this audience). Is therefore different for 
another audience.
WC Propose that this be the main agenda topic for the AU/ER/WCAG meeting at 
the F2F.
LK Yes.
WC Currently it's all or nothing. Need gradation.
HB Here are the checkpoints I meet.
WC Use EARL to make the claim as to which checkpoints you've followed.
WL Need a gestalt index.
LK Overall usability. When you pick up popular website of the week magazine 
they talk about content and usable.
WL Why don't they have accessibility included there? It's not on the radar 
in so many places.
WC Accessibility or usability? Are you saying that we need to begin to make 
the bridge from our end to get accessibility included?
WL It's a superset not a subset.
LK Current philosophy is that it's a subset or something different. Can 
have a AA site that may not be usable.
LK We've come out with a bunch of properties, we might want to rearrange. 
we've also gotten into the issue with scales.
WL Use joint meeting to arrive at some agreement on fact of scalable 
paramteres. Already picked some that need it. Also need to be tested. To 
write up a checkpoint that is not testable is to not write a checkpoint at all.
LK Another real issue is there are practical objections to putting in 
accessibility. For example, something may endanger intellectual property or 
really hard to do. We wind up handling then in ad hoc ways. Shall we build 
into EARL a mechanism for including objections?
WL Bet you have to have a joint meeting with EO. Deals with outside agency 
saying it's too much trouble. That's EO.
LK It comes up in WCAG. e.g. minimize distractions. instead say "don't do" 
it was minimize. If said don't do, be too many objections.
WL Purpose of banner ad is to distract.
LK Something where external consideration found way into checkpoint.
WL Started out with flicker.
WC But it's been hard to measure.
LK Discussion of compliance and consider these expectations.
Next meeting
Chris will minute.

$Date: 2001/02/12 17:56:41 $ Wendy Chisholm

--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/-- 
Received on Monday, 12 February 2001 13:02:40 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:10:38 GMT