Checkpoints 5.3 and 5.4

At last week's meeting I volunteered to set forth my conclusions
concerning checkpoints 5.3 and 5.4 on the mailing list, in what is
hoped to be a more coherent form than I was able to give at the
meeting.

I think Ian is essentially right: the question is not how interactive
an item of content is, nor whether it involves the execution of
client-side code or the interpretation of a markup language; the
fundamental question for purposes of the guidelines is whether there
exists a user agent that can present the content in a way that enabled
it to be accessible to the user. More concretely, the problem is as to
the existence of a suitably accessible user agent, quite independently
of the interactive (or otherwise) character of the content. This point
can be developed by considering what I take to be the paradigmatic example of
inappropriate practice that checkpoints 5.3 and 5.4 are designed to
avoid, in which the developer bypasses standard API functions that
the user agent and/or assistive technology support.

A parallel case is that of using a custom-designed XML markup in a
document and supplying a visual style sheet to accompany it. The user
agent's internal support for XHTML, SVG etc., is thereby bypassed; no
aural or other style sheet is supplied that would enable the user
agent/assistive technology, even if it were able to do so, to render
the "non-standard" markup intelligibly. My argument is that the
preceding example corresponds exactly to the impact of designing a
"custom" user interface element by circumventing standard API calls.
In both situations the access problem results from the lack of
support, by client-side software, for the author's choice of
implementation technique, which fails to include the necessary
semantics for an accessible rendering to be provided, or at least
violates the expectations of user agent developers regarding the
application of the relevant technologies. Most of the details
concerning API conventions - what to use, how to apply it correctly
and what to avoid - will of course be technology-specific, as are the
details of what elements/attributes are standard in a given markup
language and how to use them correctly (i.e., as intended in the
defining specifications). I don't think there is any difference in
principle between the two categories of case, and if, as I understand
everyone in this discussion agrees, our purpose is to set forth the
central principles and requirements of accessibility in the
guidelines, checkpoints and success criteria, while addressing the
technology-dependent aspects in the Techniques, then the appropriate
course of action is to write requirements pertaining to user agent
support and to make particular mention of API's, markup languages and so
forth in that context.

As a final objection to any distinction between "interpreting markup"
and "executing code" in this connection, I would point out that a
programming language can be expressed in XML; XSLT is arguably an
example, and I have heard that there is interest among developers of
expressing functional languages in XML. Of course, the details of what
one "has to do" in order to write accessible scripts or other
client-side applications is different from what one needs to
accomplish so as to write accessible HTML; but the same could be said
with regard to SVG, Smil and other technologies. In each case the
question addressed under guideline 5 relates to whether one's
implementation choices are supported appropriately by user agents, not
the interactivity or otherwise of the content. Thus I suggest we
should consider what requirements ought to be established concerning
user agent support, correct use of standard features of a technology
and avoidance, in appropriate circumstances, of implementation
techniques that bypass or neutralize the benefits of the features
on which user agents and assistive technologies rely for purposes of
accessibility. In doing so, we should make clear that these
requirements apply to API's just as much as to markup languages.

Received on Wednesday, 5 February 2003 02:58:03 UTC