Re: SC 1.3.1 Failure: Using Scripting Events instead of anchors to create links

This has been an interesting and unexpected discussion.

On the issue of whether buttons should be an exception, this makes me wonder
how we characterize "link-like" behavior. Certainly, if I activate a Submit
button on a page, I expect the contents of the web unit to change. What is
different about that behavior from activating a link, so that we can sharpen
the test procedure?

And perhaps we need to add more description to the examples to make it clear
that the simpler examples could be applied to any element that is usually
non-interactive (such as a span and a div), and an example that demonstrates
that even if you add keyboard support and address other accessibility issues
in the scripts provided, the example still fails this success criterion
because the role won't be recognized.

Thoughts?
Loretta


On 3/31/06 6:58 PM, "Gez Lemon" <gez.lemon@gmail.com> wrote:

> Hi Cynthia,
> 
>> I believe that onclick on <button> or <input type="button | submit | reset">
>> is also ok, in addition to <a href> and <area>
> 
> I disagree. Even though these elements may have scripting associated
> with them to fetch a document, it's not (or shouldn't be) emulating a
> link in the sense that the purpose of a link is merely to fetch a
> resource. The expected behaviour of command buttons (however they're
> marked up) is to perform an action.
> 
>> The div example can use the same simplified script from either of the other
>> examples, and would more clear if it did so.  People will wonder why a div
>> is so much more complicated than a span or an image
> 
> I think it would be better to completely remove the div example rather
> than provide another example of mixing event handlers in the markup. I
> suspect that anyone who is confused by the separation of behaviour and
> structure is also likely to believe that adding behaviour
> unobtrusively to emulate a link is not a failure (the same mentality
> as people who add the target attribute to anchors when using a strict
> DTD, and believe it's compliant because a markup validator couldn't
> catch it).
> 
> I completely disagree with the notion that mixing behaviour with
> content is "simplifying" things. I think we should at least assume
> that markup, presentation, and scripting techniques are being
> interpreted by people who are reasonably competent, otherwise the
> techniques documents should be complete tutorials. There's nothing
> complicated about unobtrusive scripting techniques, but there is
> something complicated about mixing behaviour with markup, and that's
> when it comes to repurposing content. Repurposing content is important
> for people with cognitive difficulties, as it allows for content to be
> presented in a way that suits the visitor. As cognitive problems are
> so varied, what benefits one person could hinder someone else, so the
> most suitable approach is to provide bookmarklets, Greasemonkey
> scripts, browser extensions, etc, to allow people to repurpose content
> to suit their preferences.
> 
> It's difficult to repurpose content if structure, presentation, and
> behaviour are not completely separated. We don't advocate mixing
> inline styles with markup (or I've never come across an example), so I
> don't understand why it's considered an issue when it comes to
> scripting. It's not possible to remove event handlers that are
> attached inline (without adding a proxy service that removes the event
> handlers before they reach the client, but that introduces problems
> when you want to add the event handlers back in, as they've been
> removed before they reach the client). Consider the following example:
> 
> objAnchor.removeEventListener('click', somefunction, false);
> 
> Or the IE version:
> 
> objAnchor.detachEvent('onclick', somefunction);
> 
> If the function is added in markup, then neither approach removes the
> event handler:
> 
> <a href="..." id="hook" onclick="return somefunction();">link phrase</a>
> 
> If the event handler is added with scripting, then it can safely be
> removed using the W3C method or the IE method, allowing the content to
> be repurposed.
> 
> Best regards,
> 
> Gez
> 
> --
> _____________________________
> Supplement your vitamins
> http://juicystudio.com

Received on Tuesday, 4 April 2006 14:23:03 UTC