Re: PROPOSAL: Checkpoints related to TABLE accessibility

Denis Anson wrote:
> The checkpoint on fully exposing DOM is, at best, a technique.  It doesn't
> say what functionality will be gained by doing this.  In fact, unless some
> third party AT is reading the DOM, no added functionality would be provided
> at all.


In a sense, I agree with you: the issue of interprocess communication
can be seen as an implementation issue. However, making 
support for DOM/exposing the DOM a technique means that it becomes
a non-normative solution. In my opinion, to promote interoperability,
the issue of communication must be addressed in the checkpoints
as well.
> I think that all priority 1 items should be directly related to the
> functionality that the checkpoint will provide to users with disabilities.

This is indeed the approach taken for the large majority of the 
checkpoints: they reflect user needs. As the editor, I still wonder
whether it's best to write the checkpoints with language
that reflects user requirements or UA developer actions. For
the checkpoints to have an impact, I have leaned towards expressing
them in terms of what UA developers must do (while still retaining the
essential that these are to meet user needs).

However, there are a few exceptions to the "rule", including
references to non-human interfaces.

> With regard to the DOM in particular, making this priority 1 would suggest
> that this is the *only* way to provide access to web content, and I don't
> think we can say that.

I don't think this is implied, and it's certainly not what is meant.
The idea is: when it is necessary to communicate information to other
agents, use interoperable means. It is not necessary for every
functionality. It may be *useful* to provide programmatic access 
to almost all information provided by a browser, but it is not
the only way to provide access to Web content. 

Promoting interoperability through the DOM is one issue. Deciding
which checkpoints must be implemented natively is another.

 - Ian

Ian Jacobs ( 
Tel/Fax: (212) 684-1814

Received on Tuesday, 2 February 1999 09:52:13 UTC