- From: Jason White <jasonw@ariel.its.unimelb.edu.au>
- Date: Sun, 5 Nov 2006 10:49:04 +1100
- To: w3c-wai-gl@w3.org
On Sat, Nov 04, 2006 at 09:04:15PM +0100, Carlos A Velasco wrote: > This concept of equivalence class is tricky. So if I have a site with a > stylesheet like this (exagerating): > > body { > background-color: #000; > color: #000; > } > > of course, totally inaccessible unless you use lynx, or deactivate CSS > (or you use a screen-reader). Both renderings will lie within the same > equivalence class (I think). Then, one is accessible, and the other not ... Actually, no, both renderings are not in the same equivalence class, since I defined classes only with respect to primary resources, e.g., XHTML documents. So, if two XHTML documents (or SVG or PDF or... other primary resources) are available fromthe same URI, then depending on whether they convey the same information or provide the same functionality, they are, or are not, in the same equivalence class. In your example, we have an XHTML document and a style sheet. The style sheet is a secondary, subsidiary resource loaded along with the XHTML document and is thus part of the same "page". If we define the page, as Gregg suggested, as including all secondary resources that may be rendered with the primary resource then the style sheet would count as part of it for the purpose of evaluating conformance. I'm not sure which success criterion your example would violate, but that's a separate question. I would define a primary resource as a resource retrieved by a user agent which directly or indirectly refers to the other resources retrieved in order to construct a rendering of, and provide the functionality of, the page. Thus, for example, a frameset document would be a primary resource under this conception. Of course, care would need to be taken to avoid making the definition of "page" circular. I am unpersuaded that the only viable conformance option is for all versions of the content to satisfy the success criteria. In fact, I think it is important to leave room for multiple versions, each targeted to a different delivery context (as understood by the device independence working group).
Received on Saturday, 4 November 2006 23:49:18 UTC