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

Minutes from 25 January 2001 telecon

From: Wendy A Chisholm <wendy@w3.org>
Date: Tue, 06 Feb 2001 13:24:20 -0500
Message-Id: <4.2.0.58.20010206132324.00b40f00@localhost>
To: w3c-wai-gl@w3.org
Hi all,

Sorry for the delay in publishing these.

http://www.w3.org/WAI/GL/2001/01/25-minutes.html

25 January 2001 WCAG WG telecon
Summary of action items and resolutions
       Resolved. continue to maintain errata and techniques and make every 
effort to resolve conformance related questions that arise in a timely manner.
       Action WC: reword 1.4 to include idea of semantics and include 
natural language and metadata are tecniques.
       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
       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.
       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.
       Action DB and LS: send references to the list and get discussion 
going on list re: color contrast.

Participants
william, jason, loretta, wendy, dick, matt, annushka, len, katie, andi, 
lisa seeman, charles

version 1.1 vs. version 2.0
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.

Checkpoint map
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.

9.1 Provide client-side image maps instead of server-side image maps except 
where the regions cannot be defined with an available geometric shape. 
[Priority 1]
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.

4.3 Identify the primary natural language of a document. [Priority 3]
Resolved: WCAG 1.0 4.3 also go with 1.4

11.3 Provide information so that users may receive documents according to 
their preferences (e.g., language, content type, etc.) [Priority 3]
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

--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/-- 
Received on Tuesday, 6 February 2001 13:16:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:09 GMT