Thanks for the reply.
“i fear i don’t get your point. how would that help? you’d have to a)
add the code for adding the onclick() event somewhere (thus not making
the code any shorter) and if a client does not fully support javascript,
it will not matter very much where he does not understand the js…
maybe i just seriously misunderstood you?”
Well let’s say for example that you wanted to have hyperlinks that open
popup windows. Since “target=”_blank"" is deprecated, you’d have to do
a javascript popup.
But, let’s say you’ve got a blind user using a screen reader. Many
screen readers just don’t understand JS, and popups can be confusing.
So you might just have the link point to the page by default, and use
client-side js to “apply” the popup by changing the href from ‘foo.htm’
to ‘javascript:popup(‘foo.htm’)’.
The same can be true for “show/hide” elements on a page… Show them
all when no javascript is enabled, and use client-side js to create the
“show / hide all” link on the page as well as hide elements on the page
load.
I also might find that instead of using the same "onclick=“foo{params,
parsms, params)”, I have a common file that I could reference.
Just like prototype… Why do ‘getElementByID(‘foo’)’ when you can do
$(‘foo’);
- “how is that helpful? i’d say the most important thing is that the
code you generate is understood by the application you want to support
(pragmatic view of things, i know) and if i think about the fact that
the most-widely-used browser - alas - still cannot fully deal with
css2.0, i don’t see how standard-compliance on the web-application side
can further accessibility :-)”
Accessible means accessible… By anyone on any platform. Those with low
vision might require screen readers… Those with old browsers still
want to buy your product. Those with fine motor skill impairments have
difficulties using the mouse, so you’re careful how you make things
appear and disappear based on events… Etc.
A great start to achieving this is to ensure that your XHTML and CSS is
valid. If you’ve got “onClick” all over the place, you’re not going to
have valid docs… And you’re going to skip validating because you
know it won’t be valid.
I would say that your application (especially if you’re attempting to
reach the largest audience possible) is not useful unless it can be used
without css or javascript enabled. It’s not going to be a fun
experience, but it doesn’t have to frustrate the user who
happens to be using a 320x240 smartphone to do some quick work.
Finally, as a person who supports (and occasionally has to use)
assistive technologies, I want to do what I can to make the Web a little
more friendly and accessible.
- content separation: “good point, but that depends on the developer,
not on the standard-compliance of the framework, i’d suggest.”
I agree, but if the majority of the community is using the built-in
helpers, the framework is negatively contributing to
standards-compliance… Just like developers who use FrontPage or some
of the .Net widgets out there and thus only support Internet Explorer on
Windows.
I recommend the following reading for some more examples and strategies:
http://www.onlinetools.org/articles/unobtrusivejavascript/
http://www.kryogenix.org/code/browser/
Thank you! I really appreciate your interest in this conversation. If I
can be involved any more, please let me know. I hope I’ve helped make a
few things more clear.
Regards,
-Brian
