JW Questions:
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.
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.
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.
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:
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/12/12 22:27:28 $ Wendy Chisholm