22 Jan 2004 - WCAG WG Teleconference Minutes
IRC log
Present
Wendy Chisholm, Roberto Scano, Doyle Burnett, Roberto Castaldo, Yvette
Hoitink, Matt May, Gregg Vanderheiden, Ben Caldwell, Jason White, Mike Barta,
Loretta Guarino Reid, John Slatin, Andi Snow-Weaver, Bengt Farre, Dave
MacDonald
Regrets
Avi Arditti, Charles McCathieNevile, Cynthia Shelly
Action Items
- ACTION: gregg and ben take first pass at proposal for rewriting 4.1 and
4.2 based on today's discussion.
- ACTION: gregg propose reorg of 3.1, 3.2, 3.3
- ACTION: john determine from list in 3.3 which items apply across all
sites (level 2) from those that are less widely applicable (level 3)
Summary of issues and proposals for Guideline 4.1
There was concern that guideline 4.1 is general (all technologies should
be used according to spec) but there is only one success criterion and it
only applies to markup. Many felt that "use according to spec" should apply
to other types of technology. Discussion of Guideline 4.2 and how the two are
related as well as different.
Guideline
4.2 Programmatic user interfaces are accessible or alternative,
accessible versions are provided (17 November 2003 draft).
Other issues:
- The phrase "structural elements and attributs as used in the spec"
(part b of success criterion 1 of Guideline 4.1) can be read as "generic
elements of technology" and thus 4.1 applicable to wider range of
technologies. However, in javascript, have "objects" rather than
"elements." "Features" is more broadly applicable, but concern that b, c,
and d all say something about "features."
- Success criterion 1a: what does validity test mean? use deprecated
features? how many people feel using transitional html is ok for
accessibility? what if someone writes their own dtd? can use own dtd if
meet other wcag 2.0 guidelines. if i meet the other guidelines, why do i
have to meet this one? e.g., dtd that includes embed, passes validity
tests. only viable way to include multimedia in today's browsers.
- expect untechnical people to declare appropriate dtd/schema? expect the
tool to do that for them.
- validity test for javascript? testing javascript is tested by running,
not so much a validator.
- anyone program according to ECMAScript spec? joe
claims that only zeldman does. browsers claim conformance to
different versions of ECMAScript. ECMAScript evolves, then gets
documented.
If 4.1 is "use tech according to spec" and 4.2 is "make custom user
interface accessible or provide alternative" then 4.3 (declared and widely
available) becomes a technique for 4.2.
You can use scripts according to spec and the result could be
inaccessible. Therefore, we need both pieces to apply to scripts: 4.1. use
tech according to spec (write valid scripts) 4.2. make custom interfaces
accessible or provide an alternative. Both guidelines should also apply to
markup.
Possible steps forward:
- delete: c & d in 4.1
- collapse 4.3 into 4.2 and 4.1?
- make 4.3 a technique for achieving 4.2 and 4.1 or include it as a
criterion? perhaps move "declared" to 4.1 (you validate to that) and
"widely avaiable" to 4.2 (related to user agent support and baseline)
- don't say "custom" nor "programmatic" plainly "user interfaces..."
- be careful not to require accessibility features everywhere. e.g., in
html you have accessibility features that can be useful, but in most
cases optional rather than applicable (e.g., accesskey) - not useful
everywhere. specify the effect not the method
action: gregg and ben take first pass at proposal for
rewriting 4.1 and 4.2 based on today's discussion.
Summary of issues related to 3.3
- plain language proposals, best step forward at this point
- some people think that this issue is usability not accessibility
(address by clarifying that this is in our scope)
Discussion about moving parts of 3.3 to other guidelines:
- the
plain language proposal proposed moving some of this to Guideline
2.5
- since the underlying problem is that people don't understand the text
on the page (acronyms, etc.). perhaps move to Guideline 3.1 (Language of
content can be programmatically determined.) or Guideline 3.2 (The
definition of abbreviations and acronyms can be unambiguously
determined). If put at level 2, we could say design so not more complex
than necessary.
- 3.3.1.d - could be in 2.4, where we talk about structure. have to
perceive the organization.
Concern about testability of plain language
proposal and that it still includes a "review" criterion. if remove "have
been reviewed..." and look at list of things to review for, perhaps can find
properties that can be present or absent.
action: john determine from list in 3.3 which items apply
across all sites (level 2), those that are less widely applicable (level
3)
Discussion about combining 3.1, 3.2, and 3.3 into one guideline
- perhaps: acronyms/abbreviations (level 1), determine from list in 3.3
which apply across all sites (level 2), those that are less widly
applicable (level 3)
- "we don't make any sites talk" - the technology transforms sites into
speech.
- 3.3 has success criteria related to structure; that goes beyond words
and phrases.
- if combine 3.1, 3.2, 3.3: 3.1 covers "do you understand the content,"
while new 3.2 could cover "do you understand how to operate what is
there."
- don't want to impose structure in content (effects way people write,
can't do at level 1). in some cases, don't need to add headings/titles
because there isn't enough to break up. in other cases, there are blocks
of text that are obviously chapters. archival material is counter-example
because can't change the content. rather, if possible to change content,
then structure is there. otherwise, doesn't make sense to add abstract
structure. just dividing it up not structuring.
action: gregg propose reorg of 3.1, 3.2, 3.3
Memorable quotes from this discussion:
- John Slatin - "This guideline (sic) tries to capture 3500 years of
intellectual history."
- Gregg Vanderheiden - "We have strategies for people who have no vision;
we have no strategies for people who have no cognition."
$Date: 2004/02/10 16:53:54 $ Wendy
Chisholm