- From: Jason White <jasonw@ariel.ucs.unimelb.edu.au>
- Date: Wed, 5 Feb 2003 18:57:54 +1100
- To: Web Content Guidelines <w3c-wai-gl@w3.org>
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