15 February 2001 WCAG WG minutes

http://www.w3.org/WAI/GL/2001/02/15-minutes.html

15 February 2001 WCAG WG minutes
Summary of action items and resolutions
·       Resolved: Issue 41 is still open, although if no one can come up 
with a real world example we will close it out.
·       DB still needs to carry out action item from ·  1 February 2001 
telecon: "Work through 2.0 and latest techniques to identify user agent 
capabilities which are assumed by the checkpoints and techniques."

Participants
Gregg, Cynthia, Wendy, Jason, Marti, Matt, Len, Loretta, William, Katie, 
Dick, Bruce

User agent capabilities
JW Issue still exists but latest draft may have changed context. Concerns 
text immediately after guideline 1. Capabilities of device refer to device 
currently have or able to get. I think the way in which the issue was 
raised is a product of earlier drafts. The mention of device capabilities 
used to be in the text of guideline 1. It's now in explanatory text under 
guideline. Therefore not normative. Still relevant to checkpoint 1.7.
WC Disagree, applies to all of guideline 1. Let's just answer the question.
JW Even tho the question may occur...
WC Think it's part of stating our assumptions.
CS Commonly have argument, this won't work in netscape 3 - make them 
upgrade to 4!
JW Same issue as far as how far backwards compatibility extends.
CS Some new tools won't run on 486. In the U.S. not unreasonable, but not 
sure. We have to balance feasibility needs of author: can't say has to work 
in oldest browsers vs. only ie5.
JW Want to avoid making a semi-arbitrary decision.
CS It is arbitrary. Look at usage numbers. That's how people make 
decisions. There is not a "right" answer.
JW One approach might be, these guidelines are accessibility. Then say that 
in relation to disability issues then if there are implementations that 
support a feature that will overcome an access problem then that solves it 
so far as the disability related character of the problem is concerned. 
Then becomes socio-economic problem of people upgrading. Once 
implementations as far as access for PWD, the problem is solved and content 
can make up own minds how far backwards they want to support.
CS That's reasonable.
WC Multiple platforms?
WL Absurdist position: hire someone who has the latest 
equipment..availability is complex.
WC Platforms? Language?
JW No longer accessibility question. Perhaps say backwards compatibility is 
important but not part of conformance requirement. Not intrinsically 
disability related matter. There is an assumption that someone needs to be 
able to use the technology independently.
WL Persuaded me.
CS Good idea.
KHS Makes task feasible.
LK Related: should blinking be minimized or avoided. Minimizing optimal 
accessibility with other factors. If we apply to blinking image...
JW If a particular feature is implemented in latest versions of 1 or more 
user agents, then become more precise for technologies and compatible with 
assistive technologies then we can say the backwards compatibility feature 
has moved outside the realm of access and then problem with people upgrading.
WC Therefore, as a concrete example, I use tables for layout. Home page 
reader exists and can navigate the table. Therefore, I can use tables 
without worry.
JW Yes.
LK Someone has a linux program that can read alt-text in images. Would we 
drop the requirement for alt-text for images?
JW Depends on how you want to say, "this is the requirement you have to 
meet before we regard something as being implemented." Therefore, how would 
we describe the situation.
WC various axes:
·       with assistive technology (jaws and ie), without (home page reader)
·       platforms: linux, mac, win
·       disabilities: visual, hearing, physical, cognitive
LK Different thresholds for different sites. e.g. government has to 
accommodate for much further back, vs. commercial entertainment site. Also, 
different countries. We draw a line and let users draw their own.
JW We draw line at latest, broadly with considerations of platforms and 
assistive technologies. We provide people info to let people provide 
backwards compatibility route.
LK That should be provided in conformance declaration rather than something 
to do on the side. i.e. W3C+these enhancements or W3C-these exceptions.
JW Good idea. Then you can say, "we're conforming to this and we're only 
taking into account the latest versions or what's been around for 2 years." 
although want to make it more precise.
MM Backwards compatibility endorsement on top of compliance. We have 
compliance levels based on: it's impossible to do things w/out this level 
of compliance...we're dealing with audience. If we take the technology and 
separate it and cast a wider net. If you have an endorsement system for 
backwards compatibility people can expand definition to cover that.
DB A level of compliance you can climb up if you say "we are also backwards 
compatible."
JW As far as conformance is concerned you can say this is accessible to 
people with disabilities under a certain level of conformance, that they 
have the latest versions of user agents and ATs. Then define platforms, etc 
that should be supported. In addition in conformance statement additional 
claim to make that ensure backwards compatible to support technologies that 
have been around for more than x years. Basic level of conformance does not 
require backwards compatibility. Then people use latest technologies if 
want to. Additional access to claim conformance.
GV Doug Wakefield on other line, asking about questions we're discussing. 
Could repeat what you said. i will pass along questions he had.
DB What are the practical implications? They would no longer mention 
script? If they do have a way to be backwards compatible with scripts, say 
that in conformance statement?
JW Depending on definition we put forward.
GV Can we take the same topic, so we're not talking about specific 
technology. If you have XML, where it does not make sense w/out a style 
sheet, saying it needs to work without one it doesn't work. Unless change 
it on the server side. If say, have script but always render so that screen 
reader is one thing but that it must work with lynx is another thing. they 
can't handle scripts. there is an issue of, will we abandon the position 
where lynx is a test for accessibility. Will pages be getting so 
interactive they resemble programs rather than documents. Most pages still 
look like documents.
CS I would venture to guess that most of the hits on the web go to those 
that are more programmatic rather than document.
GV Increase in bandwidth and other factors cause this to further grow. You 
can claim conformance if accessible to latest technologies and ATs?
JW Yes, plus additional claim about backwards compatibility.
GV If I have a $5,000 talking browser that a page could claim accessibility 
if it was accessible using my browser.
JW No, that was the other issue we discussed. We would qualify what we 
meant by "latest version" based on compatible with ATs, browsers, 
platforms, etc. Then we would separate backwards compatibility issues from 
that.
GV That begins to address the issue, but it is normative and then how do we 
make that list? Means the list doesn't change. The list of criteria, but no 
one knows what it meant.
JW I don't think that will be a problem. You can either put the criteria as 
normative and provide informative list of how it applies today. That could 
be updated. Like techniques. Or user agent support page. These are the 
criteria in the latest version, we provide documentation that tells you if 
that is the case or not. If you disagree with our assessment you apply the 
criteria independently.
GV That sounds complicated, but I don't see another way to do it better. 
Let's think of how to simplify it.
DB The practical implications are tricky.
GV Political reality: dangerous if we say there are 2 expensive screen 
readers that accessibility depends on. Not sure that it's practical that 
pages need to be made accessible to screen readers that do not have web 
savvy built in.
JW We could advise people to be backwards compatible, but we don't preclude 
conformance to older technologies.
WC What about 1.7?
JW Advisory.
GV Or priority 3. Then may cause us to redefine priorities.
JW Low priority and can specifically state.
WC In ERT, writing a language that can let someone claim above and beyond 
Level A or some level of conformance. Therefore, this would not be the only 
checkpoint that one could claim about. I am Level A plus these 5 checkpoints.
GV If there are too many at each level, it gets too cumbersome. I am level 
A plus these 18.
JW Or, I am AA minus these two checkpoints. That would be equivalent to A + 
7 checkpoints. Could restrict, can't claim anything below A.
GV Concerned that that is false advertising.
WC Need to go through to determine our assumptions.
DB That's my action item from a couple weeks ago. I will begin work on that.
JW Are people comfortable with handling the issue by stating conformance 
claims in these ways? If so, then what are the minimum requirements? If 
claiming conformance to only latest versions, what will be the requirements?
WC Not comfortable with first part: claiming conformance based on latest 
version. However, like the idea of conformance in steps. Should move 
forward, but cautiously.
MM Need to state it simply.
JW Move forward with idea and test.
DB Will it make a difference? Don't see many conformance claims. More 
important to determine if have met a particular checkpoint.
LK I hope that people who say, "I can't do this AA thing, it's too hard." 
Then they ignore the rest of the checkpoints. Presumably it will help them 
if they make a claim, but even if not, might help the mind set. See that 
there is good in going past A even if don't reach AA. Just a hypothesis.
JW Yes, Kynn has emphasize this. It could operate as a disincentive.
CS At MSN one thing I struggled with was become compliant and filtering out 
browsers that we had decided not to support.
JW If we go this path, it's reasonable to support a subgroup of user 
agents. Then go through checkpoints to determine how this criteria would apply.
GV A language to use would be "recent" rather than "latest." On AT say 
recent? May be web-aware. The thing to do is to build the list to see if we 
can move forward.
JW Also, development of techniques.

Report on Access Board questions
GV Was asking about screen flicker. Is it talking about blinking or 
flicker? What do authors have to control? My response was that we don't 
have control over hardware flicker. Animated gifs, authors can control 
rate. Flash and other programs, no way to turn it off, authors have 
control. Times when author create a page and if moving stuff around may 
flicker. If know happen, should control that. Should not purposefully flash 
something, particularly at bad flicker rate. WCAG also has stuff that 508 
has chosen not to address. e.g., animations can be distracting. It's not a 
seizure issue but drawing attention away. 508 does not address any 
cognitive issues.
The bigger issue is forms created by XML where style sheets are required. I 
asked if also running scripts and if the form is interactive? If so, have a 
form of this that could be used by people using older browsers. He raises 
the same discussion we were having. At some point, don't we assume that 
people have more reasonable browsers?
For employees of government, if part of their job is to work with the Web, 
you can assume they have up to date browser and screen reader. However, 
public sites, like the IRS, you can not assume that people will have the 
latest and greatest. Therefore, what is it safe to assume that they do 
have? We have not defined that in the past.
In our discussions, discussed making 1.7 a priority 3. It seems to me, that 
not supporting new technologies and viewable even if it doesn't is either 
an accessibility issue or is not. If it is, should be at whatever priority, 
if not should not be in here. We are now changing the definition of 
priority. Somehow we need to future out how to separate pure accessibility 
issues from doability.
JW Yes, that was the early part of the conversation. Once a feature is 
supported to a certain level it no longer becomes an accessibility issue.
GV What if we did it with plus: I am AA+. Not only was it accessible but 
made it accessible to people with older technologies. Can't get plus unless 
works on older technologies.
LK Yes, that's what I had in mind.
GV Then can go right on the conformance logo.
DB Then figure out 2 levels for each checkpoint?
WL Only work on older technology.
WC Beyond A but not AA.
CS Need a way to say I'm taking into consideration older technologies.
WC But that's a checkpoint.
GV AAA as well as latest and greatest.

Synchronization of audio only events
WL What are we trying to achieve.
JW GV Raised this issue before the draft became public. When have a media 
specific event that requires time dependent response, do equivalent shave 
to be synchronized.
GV An example, if the thing says "do such and such hit it now, do this then 
hit it now." The transcript does not help since don't know when now is or 
was so do n't know when to do something. if translate to a link then one 
way to satisfy. otherwise synchronize audio with interaction.if there is 
time dependent interaction, got dropped out.
JW My non-chair reaction is that wouldn't it be preferable that instead of 
adjusting synchronization that you must provide alternatives to 
time-dependent interactions. We already have a requirement that requiring 
someone to respond to something is an accessibility issue. There should be 
a way of having a version that avoids that which avoids the synchronization 
issue. Therefore make that clear rather than adjust synchronization 
requirement.
WC Agree with that.
JW Never guaranteed that person with disability can interact in time.
GV That is kind of like saying we don't need to worry about large print b/c 
can use as if they are blind. there may be people who are deaf, with good 
reflexes, who would want to use regular interactive game. but can't b/c you 
didn't synchronize the captions.
JW The problem we ran into last time was getting the language right.
WC GV's proposal was: 1.2 Synchronize text equivalents with multimedia and 
time-based interactive presentations
WL Is it possible that timing itself is content?
CS Interesting way to look at it.
JW Add wording into checkpoint and add example.
GV Something just occurred to me: if basic multimedia, already covered. 
Only time need this is if there a visual-only with a response that had to 
response or an auditory only where needs a response. I have not seen 
auditory only and that people who see are drive to present things visually. 
will we do anything as a pure auditory "hit now."
JW I have encountered one, but not on the web. A piece of software to 
measure people's reaction time to auditory events.
GV Right, and we'll caption our spelling tests as well.
<laughter/>
GV Perhaps it is so unlikely to happen, we don't have to worry about it. 
e.g. "are you still there? if not i'll reset the page." Usually people have 
to put up something visually. Therefore, would be surprised not be 
synchronized.
JW Press the space bar when the sounds are equal volume.
GV A hearing test. Not necessary. Is there ever a time when something is 
presented visually and you are supposed to react when something visual 
happens. Click when proper one is displayed.
JW If you see them you can interact with them, if you can't then no reason 
to have time dependent interaction.
GV Right. Usually need mouse. Let's raise this again at the end of another 
session to see if anyone can think of an occurrence of when this will 
happen. If we can't, then we can drop it. I'm feeling it may be esoteric or 
hypothetical.
Resolved: Issue 41 is still open, although if no one can come up with a 
real world example we will close it out.

$Date: 2001/02/15 22:47:01 $ Wendy Chisholm

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