26 October 2000 WCAG WG telecon

Minutes available at: http://www.w3.org/WAI/GL/2000/10/26-minutes.html

26 October 2000 WCAG WG telecon

Summary of action items and resolutions
·       We do not have consensus on how to clarify WCAG 1.0 Checkpoint 3.1.
·       Resolved: We will adopt Judy's proposals in our charter.

Participants
·       Gregg Vanderheiden
·       Ian Jacobs
·       Dick Brown
·       Andi Snow-Weaver
·       Len Kasday
·       Katie Haritos-Shea
·       Marshall Jansen
·       William Loughborough
·       Jason White
·       Wendy Chisholm
·       Judy Brewer
·       Lisa Seeman
·       Donovan Hipke
·       Cynthia Shelly
·       Charles McCathieNevile
·       Kynn Bartlett

Checkpoint WCAG 1.0 3.1
JW Questions:
·       Agree with WC's proposal
·       If not, how modify it.
WC reads Summary of proposals for checkpoint 3.1 How about one minute 
around the table?
JW We could combine a few of them.
30 seconds for each
IJ attempt to limit discussion to 2 issues. If to clarify wCAG 1.0, ok 
w/wendy's proposal.
DB People will use text in images. when markup language they should use it. 
more in 4 or 5.
ASW lean towards 4
LK leans toward 4. weak yet restrictive.
KHS like #1 addition of gregory's note.
MJ since edit, 1 or 4
JW most would satisfy. similar in many ways. 7 & 8 don't agree with. 
combine 1 and 4.
LS i suggested 5 because others open to abuse.
CS 4 w/last sentence replaced by 5.
CMN With CS. Would reverse sense in which 5 is written.
GV 1 says "do this" in 4 it says "when this exists, do this" then 
explanation makes sense. but 4 says "avoid using" next says "can use". the 
write-up should have a consistent message.
JW 4 and 5 seems to have agreement. some support 1.
IJ Is there a problem with putting text in images if there is a text 
equivalent?
agreement
IJ Low vision, other?
WC Primarily low vision.
IJ proposal to delete, said that 1.1 covered text equivalent.
WC Don't believe we can delete 3.1 b/c we need something similar in 2.0.
IJ 3 issues: Scalability, structure and characteristics
LK In addition, can change font color and font type.
JW lose structure when lots of text in images.
WL what lisa raised. if you have alt-text then same problems exist in 
alt-text that existed originally.
GV We're talking about combination of 4 and 5?
KHS From 1 i Like "raster-based" and "fonts" easily fold into 4/5.
GV 4 used to say, "when markup exists" - they exist but don't always work. 
suggesting: "when an appropriate markup lang exists and will work, use text 
rather than images for text scalability. [p2] e.g. use svg for line art, 
etc. these all follow scalability." dropped "avoid text in images" seems 
redundant, just said use CSS. "you may use text in images when text does 
not convey literal meaning, i.e. has graphical function. if not achieved 
with CSS provide text equivalent in image." now 3 sentences. but, still 
bothered by this talked about "not convey meaning" or "limited accent 
elements" in one case used in navigation but only on one place where to do 
with CSS. That is covered in what i read. The question would that hit the 
issues.
LS CSS should be exchanged for markup so not technology specific.
GV perhaps the next sentence rather than in the examples.
LS Yes. have problem saying "if it works." we might want to say, "and 
cannot transform gracefully" most markup do not "work" all over the place.
IJ I have a sense that making the checkpoint more precise will help 
communicate the goals. "When markup exists..." is too general. It could be 
broken into pieces. We're trying to convey that there is info related to 
text. Positioning (3.3). Also Scalability and adaptability. text needs to 
be stylable, don't position with images, if use markup language allow 
content to be repurposed.
JW Looking at GV's proposal, do you think that 3 items are addressed? or 
what propose?
IJ We prefer markup languages over images or is too much lost. This is 
independent of whether it works in images.
KHS people want clarity.
CMN I propose that we have other checkpoints that say "provide structure" 
"divide large blocks" "label blocks" all of those inWCAG 2.0 suggest that 
putting text in image doesn't do that. I think this is a special case of 
applying those checkpoints.
LK Given GV's proposal. If you have a web designer w/a train schedule, if 
you want the heading text to look like metal rails. an artist home page 
uses text in a moving and gorgeous way. both say "it's graphical, i can use 
that right?" does it allow me to say no to the first and yes to the second.
GV Are we saying you should markup where you could have but you didn't.
LS Sometimes use of text in images is to represent something graphical.
IJ Represent it in text, braille, and auditorily. Text equivalents 
previously how do. 2nd set of issues with particular rendering. It may be 
useful to point out that we're doing this for graphical rendering. You can 
do that as long as you know you won't meet the needs of users and not get a AA.
·       for non-text element use text equivalent
·       if you encode text in images, could be AA if you use markup rather 
than raster
WC but you can not meet that today.
IJ that's a separate issue
CMN I agree with IJ. We should push this to requirements. You could use 
raster-based and provide stylable fonts. The crux is, "what do we mean by 
is available." W/out answering we don't have a good answer. We should bear 
in mind we are balancing needs of various people. If designers laugh at 
guidelines rather than meeting needs of people with disabilities, we should 
push back hard. Here is the problem you are causing.
DB I don't understand that the main problem is scalability. However, there 
are lots of images that don't scale that don't have text. in either case, 
the message that they are trying to get across is not happening.
KHS I'm looking at 508 "final rule" it is watered-down. (sent to CIOs, not 
officially out). There is a need for us to be as specific as possible.
LK We have to consider if we have to make the judgement on a site by site 
basis.
IJ Do people feel that WCAG 1.0 covers scalable, non-text graphics. If the 
goal is to repair 1.0, then probably not best to go into issues with low 
vision but only deal with text. Clarification versus bug. Or is it a bug.
JW We need to make an amendment to 3.1 and keep that separate from any 
provision that might be moved into 2.0 that deals with scaling of images in 
general.
IJ Key points of 3.1: text equivalency and style sheets for positioning. 
this checkpoint does not cover scalability and control and presentation 
characteristics.
WC Disagree.
IJ Still worthwhile to limit to text.
JW I was hoping to have some words of wisdom to offer, the best that I can 
say is that we need to consider it more on the list. Of the proposals 
before the meeting, we have support for combining 4 and 5 with elements of 
1. GV posted a proposal. We need to examine it on the list and see if any 
further proposals arise.
KB Correct what Wendy said, "designers will laugh at us." Those are her 
words. They will ignore us or not give us credibility. Laughing at us is a 
bit more negative than the response I've heard.

EO/WCAG dependency proposal
JB This is on the agenda because JW sent a summary of proposal that I sent 
to him, Gregg, and Wendy. This is coming up because it was brought up to me 
as a request for resolution (as domain leader for WAI and chair for EO). 
This needs to be resolved before charters go out to AC. The initial 
response was that this was already discussed and resolved. That is not how 
it was represented to me. There are 2 points to the proposal.
WCAG scope
dependency with EO
The details start with what is currently in WCAG, there appears to be an 
ambiguity of the WCAG audience (only for technical audiences?). This does 
not match the audience of WCAG. I know you have talked about this. WCAG has 
a unique audience compared to other W3C documents. All other W3C docs have 
a very technical audience. WCAG has technical and less technical as well 
(perhaps call them "lay"). We want to avoid fragmentation of the standard. 
EO is not the appropriate place to develop something derivative and 
normative. The "easier to use parallel" for example. The external public 
would not accept that as a W3C referenceable specification. The proposal 
comes down to 2 things:
revised scope
revised dependency
How do people feel about the proposals? Any questions?
KHS The way it was explained to me is, "it wasn't our department" but I 
agree that it is.
CS We need to make sure that we don't lose the technical audience.
KHS Two documents?
JB We should try to figure out if there is agreement on the goal and then 
figure out how to do that later.
GV We talked about specificity, also don't want to lose generality. We have 
been too specific. Also want simple. Perhaps we get to the essence of get 
down to what we're doing. Just a change of phrase can make things clearer: 
what achieve and what the rules are for getting there. Lay something down 
and then lay down a couple sentences to clarify. 2 documents doesn't work 
because only one is normative.
JB Proposed revised scope. /* Judy reads from e-mail */ Highlights that 
pieces exist that are accessible to non-technical but not that all language 
must be at this level.
LK Mean that they don't know HTML?
JB Why look only at HTML? Document should not be specific to HTML.
LK Just trying to figure out what you mean by "non-technical." For example, 
would not know HTML.
WC Think we can answer yes, we do not assume people know HTML.
CMN agree.
LS What are our priorities? What is more important? need to create 
guidelines that make sites accessible for different groups or to make sure 
they are implemented and to accommodate authors? Further discussions will 
be succinct if we agree. 1. Technically correct, 2. Easy to read and use 3. 
Easily used
JB When I look at priorities in any group, my job is to bear in mind the 
context across the WAI effort. There are projects across the WAI groups 
that are looking at "what is accessible content," an accessible user agent, 
etc. And therefore how a particular group contributes to these goals. It is 
extremely difficult to combine these priorities in this group, if that 
responsibility is put outside this working group the overall impact of the 
guidelines will fall short of what it would. this group is best equipped to 
develop the technical statements and reformulate them somehow.
JW I don't have any difficulty with the proposal, it's been in need of 
clarification. I think the issue that raises contention in previous 
discussions of whether there is a conflict between the two goals. We are 
not sure if we can have one document that meets these needs. Issue really 
of when those goals conflict? If choice of means left up to working group, 
then that will be o.k.
GV Always try to make it as simple as can.
WC Main question is, who does the work? Let's give it our best shot, then 
do usability testing with people who are not technical. If they can't 
understand it, we have more work to do. If they can understand it, we're good.
CMN Agree.
WC 3 minutes left, who disagrees?
LS Before making WCAG in 10 points, is that us?
JB What I had seen with the document you were doing, looked more like an 
overall "WAI in 10 points" rather than "WCAG in 10 points." The dependency 
statement is different than the scope. /* judy reads proposal from her 
e-mail */ If we were to come up with "WAI in 10 points" or "Why do web 
accessibility" that is clearly EOWG. If someone wants to do "WCAG in 10 
points" that is not normative, that could be EOWG, just like we developed 
QuickTips. They were reviewed by WCAG WG.
LS That helps.
JB WCAG WG would probably not be developing derivative work.
Resolved: We will adopt Judy's proposals in our charter.

$Date: 2000/10/26 21:35:50 $ Wendy Chisholm

--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--

Received on Thursday, 26 October 2000 17:36:59 UTC