- From: Charles McCathieNevile <charles@w3.org>
- Date: Tue, 19 Sep 2000 09:30:27 -0400 (EDT)
- To: "Leonard R. Kasday" <kasday@acm.org>
- cc: WAI AU Guidelines <w3c-wai-au@w3.org>, WAI ER group <w3c-wai-er-ig@w3.org>
right. <grin/> This framework doesn't do the testing, it merely provides a way of working out what tests should be or have been applied to what pieces. The problem of discontinuous sets of elements (for example a server-side image map that has replicated text links) is an interesting (difficult) one. Essentially I guess the answer is that there is an alternative version - which is the same for a number of different problem types. So the alternative version wouold have a reference - in this case a fragment identifier, in other cases a completely different URI. Something similar happens with SMIL and could also with SVG, where there are two or more equivalents for a piece of content, and a link between the two. For each alternative it is necessary to know that there is an equivalent alternative of some given type, and that there is something to link the two. Whether that is a page that provides them both (for example text in a page that describes a particular illustration), or another element in the page (the text link map for redundacny with the server side map), or a parent element (a SMIL par/switch/whatever that specifies the alternatives) doesn't matter, so long as we can have the property that something is met by an alternative version, along with that alternative version's URI. Hopefully I will get some more time to write this kind of stuff in - and I need to reference the existing conformance scheme as well. Charles On Tue, 19 Sep 2000, Leonard R. Kasday wrote: Charles, Your notes say that > For each element there can be tests that are automatic, or manual. What did you have in mind for assertions that involved multiple elements, especially non-contiguous elements? For example, if there's a server side image map there should be equivalent text links, but they don't have to be next to the image map (e.g. they may be at the bottom of the page). I guess you'd write an assertion that included all the elements and if any one of them changed the assertion would be withdrawn? Another case: when tables are used for layout, the document must make sense when linearized. Similarly, if CSS positioning is used, the elements must make sense when read in the order they appear in the HTML. In this case you'd have to withdraw the assertion if any of the elements changed, or their order changed, or anything was inserted in their sequence, or positioned into their bounding box, right? Hmmm. When tables are used for layout you could simply write the assertion against the whole table. But you'd still need to reference individual elements when CSS positioning is used. Len At 04:07 AM 9/19/00 -0400, Charles McCathieNevile wrote: >There is a canonical XML spec that could be used. And IDs are better than >checksums, since you can find them faster - comparing checksums element by >element isn't as good, just possible and saves human time. But of course the >ids can also be changed (fragment identifiers aren't part of the URI in the >http transaction at the moment...) > >Charles > >On Mon, 18 Sep 2000, Leonard R. Kasday wrote: > > And if someone simply re-arranged the elements you could still find the > originals... and without using id's, since you've got a hash of the > checksums. > > Yes. Neat. > > Only suggestion is would be to cannonicalize whitespace before doing > checksums. E.g. replace all white space with exactly one space and omit > whitespace between > and < . > > Len > > > Yes, I realised that. The value of doing it over elements specified by > xpointers is that you can also have a checksum for the particular elements, > so you can figure out which of those are different, break the document down > and up again keeping as much as is still fine. > > Cheers > > Charles > > On Mon, 18 Sep 2000, Leonard R. Kasday wrote: > > Good approach... at least for fixed web pages, or for reporting on the > status of a page at a particular time > > Problem comes in if page has changed. You do spot that via the hash > (or do > you mean checksum?). > > But if a page does change, it would be useful to retain as much > information > as possible, not just say that the RDF no longer applies. One way to do > this is to make sure all elements have unique id's that do not get > changed. Or, if a checkpoint refers to a regions of a page, with many > elements, that section should be wrapped in a <span> with a unique id. > > Still have a problem if regions overlap instead of being nested.... > hmmm... > can xpointer specify regions between two elements? > > Len > > > At 11:19 AM 9/18/00 -0400, Charles McCathieNevile wrote: > >I wrote some very rough notes on how one could work. > > > >I am sending this mostly at this stage so the page doesn't get lost > <grin/> > > > >http://www.w3.org/2000/09/conf-tool > > > >charles > > > >-- > >Charles McCathieNevile mailto:charles@w3.org phone: +61 (0) 409 > 134 136 > >W3C Web Accessibility > Initiative http://www.w3.org/WAI > >Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia > >September - November 2000: > >W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis > Cedex, > >France > > -- > Leonard R. Kasday, Ph.D. > Institute on Disabilities/UAP and Dept. of Electrical Engineering at > Temple > University > (215) 204-2247 (voice) (800) 750-7428 (TTY) > http://astro.temple.edu/~kasday mailto:kasday@acm.org > > Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools > Group > http://www.w3.org/WAI/ER/IG/ > > The WAVE web page accessibility evaluation assistant: > http://www.temple.edu/inst_disabilities/piat/wave/ > > > -- > Charles McCathieNevile mailto:charles@w3.org phone: +61 (0) 409 > 134 136 > W3C Web Accessibility Initiative http://www.w3.org/WAI > Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia > September - November 2000: > W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis > Cedex, France > -- > Leonard R. Kasday, Ph.D. > Institute on Disabilities/UAP and Dept. of Electrical Engineering at > Temple > University > (215) 204-2247 (voice) (800) 750-7428 (TTY) > http://astro.temple.edu/~kasday mailto:kasday@acm.org > > Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools Group > http://www.w3.org/WAI/ER/IG/ > > The WAVE web page accessibility evaluation assistant: > http://www.temple.edu/inst_disabilities/piat/wave/ > > >-- >Charles McCathieNevile mailto:charles@w3.org phone: +61 (0) 409 134 136 >W3C Web Accessibility Initiative http://www.w3.org/WAI >Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia >September - November 2000: >W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, >France -- Leonard R. Kasday, Ph.D. Institute on Disabilities/UAP and Dept. of Electrical Engineering at Temple University (215) 204-2247 (voice) (800) 750-7428 (TTY) http://astro.temple.edu/~kasday mailto:kasday@acm.org Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools Group http://www.w3.org/WAI/ER/IG/ The WAVE web page accessibility evaluation assistant: http://www.temple.edu/inst_disabilities/piat/wave/ -- Charles McCathieNevile mailto:charles@w3.org phone: +61 (0) 409 134 136 W3C Web Accessibility Initiative http://www.w3.org/WAI Location: I-cubed, 110 Victoria Street, Carlton VIC 3053, Australia September - November 2000: W3C INRIA, 2004 Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France
Received on Tuesday, 19 September 2000 09:30:31 UTC