william, jason, loretta, wendy, dick, matt, annushka, len, katie, andi, lisa seeman, charles
JW The position so far is that errata have been issued when necessary. there have been a significant update to techniques. those written against 1.0. questions have arisen asking if we should write techniques against 1.0 and if we should continue to support 1.0.
WL techniques could be adjusted.
JW No reason not to rework techniques, unless editorial difficulties in the future.
WC I know LK has concerns and we've talked about...
LK Right, good way to proceed, but oftentimes things don't seem to be resolved for 1.0. An issue comes up such as Q and it fades away.
WC I am the hold up on that.
LK If we could resolve within so many weeks and see that resolution that would be fine. Say 2 weeks.
WL Please give an example.
LK Any question of the form, "Here's a web page, the accessibility of which is not clear in 1.0." Most recent case "Is Q allowed." Have the group vote yes or no. General philosophical wording can take a long time, but if a particular construct and we could agree yes/no. Wordsmithing I'm not so concerned about.
JW We can't arbitrarily agree to resolve something in a given number of time. We should be as expeditious as possible, but need to consider all of the issues. continue to maintain errata and techniques and make every effort to resolve conformance related questions that arise in a timely manner.
Resolved. continue to maintain errata and techniques and make every effort to resolve conformance related questions that arise in a timely manner.
4.1 Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions). [Priority 1]
JW Case of providing logical structure. Falls under 1.5
MM following the language specification.
JW None of them says you must, they only provide the mechanism.
LS What happened to "expose structure of the content." That's part of it.
ASW that's 1.4.
JW The identification of a natural language is a semantic issue. Question if wording needs to be expanded. not all important distinctions are structural.
LS Perhaps added to the text under 1.5. "Use markup to give as many details about the document as possible."
WC What about a separate checkpoint for semantics? Since WCAG 1.0 13.2 does not have a home either.
KHS Could see separate, but perhaps under same checkpoint.
JW Combine in checkpoint and discuss both.
LS Discussion emphasize diff implementations.
JW If you have an emphasis indicator, that is semantic rather than structural. Lists have a structural role as well as semantic role. Therefore 1.4. then natural language and metata data are techniques.
Action WC: reword 1.4 to include idea of semantics and include natural language and metadata are tecniques.
JW 1.1.
LK primary motivation is provide text, so 1.1
LS Agree. it's text content for non-text content.
Resolved: HTML techniques will address server-side image maps vs client-side (WCAG 1.0 checkpoint 9.1) as well as mention in Core Techniques. SVG image descriptions also falls into this category.
Resolved: WCAG 1.0 4.3 also go with 1.4
WC Perhaps 2.1?
ASW high-level guideline 1
KHS or guideline 2
JW Belongs under server-side techniques rather than techniques, means of allowing access techniques to be satisfied.
LK I like that. It's a means to the end.
JW Also with content negotiation.
WC but where do we tie in the server-side techniques??
JW it doesn't matter where it is satisfied as long as it is satisfied. could be a combination of server proxy and client-side techniques. what are the underlying access issues that are covered?
WC Marking up the language and doctype will allow either the server or client to pull what they want.
JW An I18N issue. not sure if it's appropriate that multiple language versions be provided. Not sure it is an accessibility issue. therefore if you do provide, allow a way.
WC this is related to providing alternative versions.
KHS 2.1
DB won't just have one version, will have multiple alternative versions. SR could talk directly to the server.
KHS design content and deliverables according to users needs.
ASW define deliverable
KHS what DB is talking about.
DB We get into interesting criteria.
JW The guidelines should not determine these issues. there should be different ways to satisfy them. XML, alternative version, one version w/diff style.
LS You have to be able to go to the rendering you require versus the one you happen to be at. That would be navigation. The second issue, there is an area of things that aren't violations but that are good ideas (like provide alternative renderings). How do we want to put that in the document.
JW Add a section before the guidelines that explains the assumptions of the document re; the delivery model of the web. It would explain the fact that content is generated, or sit on a server, that it can go through proxies, it may be generated in response to user preferences, then to a user agent where it may be further processed (transofrmations, style sheets) and then interact with AT which may or may not be part of the UA itself. The guidelines specify access requirements that can be met along the processing chain. Semantics and structure could be introduced as well.
LS that would do it.
KHS yes.
LS A mapping or flow diagram of where you can do which techniques. Here's where server-side fit in, here's where HTMl fit in. Like a process flow that a company might have.
JW the path from author to user. clear where interventions on point of author can take place.
Action JW: write conceptual model of the path of info from author to user and the points of intervention where accessibility issues need to be satisfied. It would explain the fact that content is generated, or sit on a server, that it can go through proxies, it may be generated in response to user preferences, then to a user agent where it may be further processed (transofrmations, style sheets) and then interact with AT which may or may not be part of the UA itself. The guidelines specify access requirements that can be met along the processing chain. Semantics and structure could be introduced as well.
LGR What can you count on as the author?
LK How much do you put on the author? on the UA? on the proxy? We could abandon the need for alt-text if UAs had optical character recognition.
WC Yes, there are
LK also what we are assuming UAs don't do.
LGR: Does the intro (for 2.2 idea) catagorize where these things are?
JW: It shouldn't. Where were we?
KHS: 2.2
LGR: Perhaps under 1.7? Color is a newer technology. It feels like it fits somewhere under guideline 1.
WL: It could also go uder 2.
LS: It could be under 3.
JW: If the author provides color, they should also provide appropriate contrast.
WL: When does it become appropriate?
SL: What about 4.3?
Action LK: Write up assumptions that we make about UAs (what they do support and what they don't) as well as about what ATs can do. Likely to be included in the Introduction.
WC Perhaps under 1.5 - benefit of doing this. so that if you have designed in a way that is not high contrast for someone they can modify to their preferences.
LS what about 3.1?
WC a benefit of separating content from presentation is that if it is not high contrast enough for someone they could change it to their preferences, and that consistent presentation uses good presentation which includes high contrast.
LGR Slippery slope. What is good? We're defining accessible.
LS Then need to define accessible presentation. Some people have difficulty with fonts that are irregular. It can be difficult to process. Opens that door.
WC That is a door that Jonathan Chetwynd and Anne Pemberton have been asking us to open for a while.
JS Or we could split into 2 checkpoints. If the default presentation can be overriden then the accessible presentation, then providing accessible is not highest priority.
DB Are we expanding high contrast to accessible presentation.
WL If the user can control it, burden is not on the author.
JW IF the author does provide proper presentation, it is helpful.
DB Proper presentation is very subjective. contrast is easier to test.
LS I'm thinking specifically for the internet.
WC font size, color, and font size are all configurable by the user.
LGR Here we lean towards 1.7.
WL No way of knowing what contrast is appropriate for someone.
MM Designers dont have control over screen resolution, what pantone color appears on the screen. Even fonts on same platform: verdana on laptop looks different than on 17" screen. overriding using client-side style sheets might be an idea. We dont have control (as a designer).
JW Put it under 1.7 and drop 2.2 in version 1.
LS Has to go to the list.
WC as long as have control, user can change. issue with what can't change: a jpg for instance. to convey "mood" of site, want to design to be as high contrast as possible.
DB Can't do anything about photographs. As long as they can get the text equivalent should be o.k. It is difficult to get guidance since so very complicated. When we specify what colors people use, people will think we're crazy.
LS We're talking about contrast on particular elements.
DB We have that. 2.2
WC Not clearly represented in the 2.0 draft.
LS Can't drop it here. We need to gather more info.
Action DB and LS: send references to the list and get discussion going on list re: color contrast.
$Date: 2001/02/06 18:15:36 $ Wendy Chisholm with help from Katie Haritos-Shea