RE: Big issues (elephants) for discussion at CSUN face to face meeting

Hi Joe,


Comments below and marked  GV: 




 -- ------------------------------ 

Gregg C Vanderheiden Ph.D. 

Professor - Ind. Engr. & BioMed Engr.

Director - Trace R & D Center 

University of Wisconsin-Madison 


-----Original Message-----
From: [] On Behalf
Of Joe Clark
Sent: Sunday, March 16, 2003 3:26 PM
Subject: Re: Big issues (elephants) for discussion at CSUN face to face



>a.  If an entire process is not accessible then components of the 

>process should not be claimed as accessible.  For example:

>    - a shopping site where the checkout is not accessible.

>    - an online course where two modules are not accessible.


Does this mean that the owner of the site could make the honest claim 

that, say, Parts 1 through 7 and 9 through 12 and 17 of a 20-part 

course meet the guidelines, but other parts do not?


GV: Well, first of all, these items don't say anything right now.  They are
just starting points for a discussion.   The concern here is that users not
find accessibility markers on the front sections of a course only to find
later that you cannot graduate because there were other required parts later
that were not.  


Or that users don't shop at a site with an access sign on it only to find
out that one of the checkout pages is inaccessible so they can't actually
finish buying things after they have done all their shopping.


All of these thoughts are preliminary though: - just wrestling with



That should not mean that the whole course is disqualified from 

claiming conformance. 

GV: Well the course would be wouldn't it?  If you can't finish it?


It is not a sure thing that the absence of 

conformance in certain parts means that no disabled person could use 

the accessible parts. They might not even need the inaccessible parts.

GV:  Sorry.  When we rewrote it we forgot and left out the word "required"
as in "required modules".  

So the course would fail to be accessible.   The modules, if packaged
separately could be listed as accessible.  But not otherwise any more than
one could claim that parts of a page were accessible so they should be
claimable even if the rest of the page was not.  


I guess you could make a case for allowing pieces of things to be
accessible, and claimed as such  - if they were meaningful in themselves.
Just have to figure out where to begin and end.   As the first part stated,
we can neither allow unchecked scoping, nor deny scoping.   Neither one is
workable.   How to find the middle ground though will be very hard.  That is
the purpose for this email.  To start that discussion and thinking.



I imagine a scenario where WCAG 2.0 is written to a doctrinaire 

standard and denies any conformance claim to a site where even a 

single component doesn't meet the spec. But this 

single-drop-of-inaccessibility scenario is one I would warn against.


GV: Our first paragraph on this topic specifically says that that approach
is a non-starter.   I see you agree. 


>b. Content can not be claimed as accessible if the path to the 

>content is not accessible.


And this means?


We don't need "paths" to content. We just need a URL, in the case of 

a Web site.


GV: Then you have an accessible path and you pass. 


Let's say the homepage,, was badly 

put together and fails the spec. But let's say they hired an 

independent contractor who created courseware in the /Courseware/ 

directory that meets the spec. (This would not be an atypical 

example, you know-- accessibility-related pages may be accessible, 

the rest of the site not.) Who particularly cares if the homepage is 

inaccessible if you can just go straight to and enjoy the 

accessible course?


GV: Again, if you can do that, then you have an accessible path.  If you
cannot and you have to go through an inaccessible sign in page first- then
you do not. 


How are there *paths* on the Web? The Web is nonlinear.


GV: I don't follow this.   Our campus has paths all over the place.  Like a
bizarre spiderweb.   But there are paths.  And the web is full of them too.


There are many places on the web where you must go through particular pages
in order to get to other pages.   Those are paths.   In other cases, you can
link into a page or even use a search engine to find and drop directly into
a page.  Those are paths too (though much shorter - and sometime from off
site).   These variations make all this very hard to figure - and hard to
settle on an approach.


The question makes it seem like the nonexpert's way of explaining how 

to get around on the Web-- think of someone on the telephone saying 

"OK, go to OK, see the blue photo? Click 

that. Now look around for 'courseware.' Click that"-- is the way we 

refer to universal resource indicators online. It isn't. The concept 

of "paths" makes little sense on the Web.


GV: Please think twice before typing this kind of reply.  If you have a
question, please ask it without the sarcastic second paragraph.  You have so
many good things to say --- and you raise so many good questions.   But when
you do this you put people off.  And we need everyone to be thinking about
your questions rather than bouncing off your comments.         But more
importantly you stop thinking yourself sometimes. You let your irritation
take over your creativity and your incisive nature.    You attribute
ignorance of certain factors when in fact the authors may have just been
floating an idea, or fishing for a good solution with the best they can
think of.   Or they may have been trying to solve some important problem and
weren't thinking themselves enough to avoid stepping into another trap.
The concern is that when you get irritated, you don't look deeper to see why
they might have done something - and then think of a way to address that
problem along with the one you identify.   You don't ask the really good 3
layer deep questions.   Those are the ones we need most.    When irritated,
you might try asking a question.   An irritated one if you must.  But a
question rather than statement of what you think the person must mean.
Remember, if what you think that what the person is saying doesn't make
sense, there is a good chance that that isn't what they meant to say.



>We also need to keep in mind exceptions and when they can and can 

>not be used.  For example, for copyrighted or legacy content.


Essentially all content is copyrighted. I assume you mean content 

where someone else owns the rights and has not explicitly permitted 

modification for accessibility (e.g., a videoclip that you don't have 

the rights to caption and describe).


GV: exactly.  


>the success criteria. For example, Checkpoint 3.2 (Provide multiple 

>methods to explore sites that are more than two layers deep) seems 

>to refer to sites but some of the success criteria refer to 

>documents. As written, this checkpoint does not seem to apply to Web 

>applications. "Layer" is not well-defined and implies a hierarchy. 

>However, if we are talking about a Web of information, there is not 

>necessarily a linear order nor a hierarchy.


Indeed. I don't see an accessibility need that this requirement meets 

in the first place. Perhaps it could be removed.


GV: It was intended to address situations where it would make things easier
if there were multiple ways to do things.  But we think that this might be a
level 2 or 3 success criterion for making things easier to use -  rather
than a checkpoint.  


>How can we help the developer understand what a checkpoint means and 

>how a checkpoint applies to different types of content while not 

>relying on Techniques for understanding?


You probably can't. The hidebound and procedural WCAG manner of doing 

things pretty much condemns WAI to issue a requirements document and 

then also what is essentially a real-world translation or companion 

document. (The requirements could simply be better-written, of 



GV: Sorry.  It is not a matter of WCAG hide boundness, but rather
constraints on standards documents that causes much of the problem here.   

Can you explain what you mean by "hidebound and procedural" and how that is
causing the problem cited here?   ( I can't tell if you're on to something
we can address or if you are just frustrated with the requirements of a
standards doc.)  Thanks


>4. Requirements to change content


>There are two issues with altering the primary content rather than 

>supplementing it:

>    a. it potentially limits the author's freedom of expression,


It invariably limits the author's freedom of expression. You're 

essentially saying "Write the way we want you to write or we withhold 

our WCAG 2.0 conformance badge." The whole enterprise isn't gonna 

stand up to scrutiny. It just so happens that it has not received 

much scrutiny yet. That will inevitably change.


GV:  Joe, you sure have a caustic way of agreeing with the point we were
making.  Why not say you agree.  Or even  "I agree - though I would go
beyond "potentially". I think It would do so most of the time.  And this
will be a problem when these go out for broader review." 


>    b. it is not appropriate or permissible in some circumstances,

>        e.g., in the case of legal documents, and historical, artistic,

>        and literary works.


For "some circumstances," read "most circumstances."


>How should we address the tension between solving current problems 

>without constraining the author's freedom of expression? How do we 

>address the opportunities that emerging technologies such as 

>metadata will provide? Can we achieve some of this with semantic 

>markup and next generation assistive technologies?


By eliminating any *requirement* that authors rewrite their content 

to suit some outside opinion of how they should write.


I'm sorry, but this stuff ain't gonna fly. I would personally not 

want to see the Web Accessibility Initiative face its first-ever 

constitutional challenge over this issue.


The benefits aren't even proven: Nobody has provided convincing 

evidence that a site that follows these invasive, prescriptive 

guidelines will become *as much more accessible* as, say, a site that 

meets requirements for blind accessibility would.


GV:  Well, clearly this is part of what we were raising as issues.  

But you didn't really mean to say that if it is easier to address one
disability than another, that we should not address the harder one.  If that
were the case we should stop at access for people who are deaf (at least

I presume that the major concern here is not the effectiveness but the
invasiveness or prescriptive-ness? 


>7. Web applications, Web sites, documents


>Related to definitions, which terms do we use to make sure that the 

>principles we are writing apply to applications, Web sites, and 

>documents? In particular, we have been looking at the variety of 

>ways we use "content." Also, we use "Web site" or "document" or 

>"page" instead of something more general that would include Web 



Web applications are essentially not covered under WCAG 2.0 because 

there are no Web-application experts writing the appropriate 

guidelines. As mentioned before 


WAI volunteers continue to act as though they are topic experts on 

the numerous similar but not interchangeable topics covered under 

WCAG 2.0.


A month from now, I may be able to give real-world examples of how 

the current WCAG 1.0 fails to take Web applications into account. 

That won't make me an expert either, but it'll add to the limited 

corpus of available data.


GV: The working group is composed of all those who we can get to join, with
all sorts of backgrounds.   We can always use more.   Would you mind asking
some of those you feel are more expert to join?  They would be welcome.  In
the meantime, the best we can do is talk with them.  


I also think you underrate the level of expertise on the team.  Just because
some members to jump on things when they see issues and instead try to work
out the problem over time (trying to address the issue that raised the
offending item at the same time as trying to change the offending item)
doesn't mean that people don't see things they don't like.  Often there are
things that drive people nuts - but they don't (yet) have an alternative
suggestion for addressing the problem - so they wait a bit.   


It isn't the working paper that is the issue.  (they always have lots of
temporary junk in em.   We just have to slowing figure out the junk from the
necessary things. 


>8. Collapsing navigation into perceivable and understanding?


The titles of WCAG 2.0 sections are still not clear enough. They're 

too abstract; among other things, they shouldn't be adjectives. They 

betray the undiscussed fact that WAI is labouring to shoehorn a 

mishmash of different subtopics into artificial categories.


GV:  Please elaborate.    I don't follow.  

But perhaps it would be best to wait for the next round of re-org an provide
your input there.    Since you agree with so many of the issues raised,
perhaps the next version address some of your concerns a bit.



But please try to have a little faith and just point out the things you have
a concern about.   If we refute or blast them, then let loose with your
second paragraphs.  Else, wait to see if there are others that agree.   Or
if the author just left a word out or didn't express themselves well. 






     Joe Clark |

     Accessibility <>

     Weblogs and articles <>

     <> | <>

Received on Tuesday, 18 March 2003 13:18:58 UTC