- From: Leonard R. Kasday <kasday@acm.org>
- Date: Tue, 19 Sep 2000 09:24:01 -0400
- To: Charles McCathieNevile <charles@w3.org>
- Cc: WAI AU Guidelines <w3c-wai-au@w3.org>, WAI ER group <w3c-wai-er-ig@w3.org>
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/
Received on Tuesday, 19 September 2000 09:21:59 UTC