- From: Loretta Guarino Reid <lguarino@adobe.com>
- Date: Tue, 04 Apr 2006 09:04:24 -0700
- To: Gez Lemon <gez.lemon@gmail.com>
- CC: Cynthia Shelly <cyns@exchange.microsoft.com>, Michael Cooper <michaelc@watchfire.com>, Ben Caldwell <caldwell@trace.wisc.edu>, Katie Haritos-Shea <ryladog@earthlink.net>, Christophe Strobbe <christophe.strobbe@esat.kuleuven.be>, Becky Gibson <Becky_Gibson@notesdev.ibm.com>, "public-wcag-teamb@w3.org" <public-wcag-teamb@w3.org>
The test procedure for this failure currently says: 1. Check whether there are JavaScript event handlers on any element other than an a or area element that cause the location or contents of the Web Unit to change. I think this is too broad, since there are many instances where you may want to add an event handler that will cause the contents of the Web unit to change. For instance, our error handling scenarios do that. Since this is a failure, we don't want to rule out content that is accessible. Should we change this to <proposal> 1. Check whether there are JavaScript event handlers on any element other than an a or area element that cause the current web unit to be replaced by a destination web unit. </proposal> Does that help, or does it leave us with the same problem? On 4/4/06 8:20 AM, "Gez Lemon" <gez.lemon@gmail.com> wrote: > I said: > > <quote> > The result of following a link is that the current web unit is > replaced by the destination web unit. > </quote> > > The second I pressed send, I realised that isn't quite correct. > Fragment identifiers and targets for framesets behave slightly > different, and I can't think of a concise way of wording the behaviour > so it caters for all scenarios, so I'll rely on everyone knowing what > I meant. > > Best regards, > > Gez > > > -- > _____________________________ > Supplement your vitamins > http://juicystudio.com
Received on Tuesday, 4 April 2006 16:01:44 UTC