At 6/30/2009 01:41 AM, Mathew Robertson wrote:
> I like to think that this is where web
> development should begin, with JavaScript added to enhance, not to
> provide core functionality.
Why?
Most modern accessibility aids (eg: font increase, JAWS, etc) use an
existing browser, which can handle javascript. Google processes
javascript and RDF tags.
I've only ever heard a single argument as to why javascript-disabled
should apply as a baseline for websites, specifically: if some
percentage has JS disabled, you would be losing those visitors ->
which of course can be measured.
Is there any other strong aruguments for making pages available,
without javascript enabled?
One example of why support for non-JS UAs is a good idea is form
validation. Assuming that all requesting user agents are running
JavaScript and therefore will be forced to submit a valid form is
like barring the front door of the bank but leaving the back door
wide open. Since you need server-side validation for fundamental
security, build that first, then add client-side validation to speed
things up for users running JavaScript.
Read the rationales & arguments for progressive enhancement &
graceful degradation. Rather than creating pages that depend on
specialty technologies that don't have universal coverage, and then
back-filling (when & if there's time!) to support Those Other user
agents, the PE approach is to build sites that work in all user
agents and then add enhancements to enrich the experience of visitors
using special features. That way you don't have to try to calculate
how many people you're shutting out and whether you can live with
that on your conscience and on your bottom line.
User agents that don't support JavaScript include search engines,
many new mobile devices, browsers whose users have turned off
JavaScript, and browsers with JS enabled but situated behind
corporate firewalls that strip scripts out of incoming pages. Can you
really count them? Will you really do so? If you do, what conclusions
will you draw from the numbers? What percentage of visitors (human
and otherwise) to a site do you consider expendable? What kind of
online business model includes the deliberate alienation of some
percentage of prospective visitors or customers?
The attitude that we should shut out minority visitors is born from
the assumption that it's expensive to cater to them, which of course
it is if you try to back-pedal for them in the final stages of
development instead of including them from the beginning. It's always
more expensive to retrofit than to incorporate something into the
original design. It amazes me that, decades after we've raised our
consciousnesses around architectural accessibility and now commonly
see ramps and Braille elevator controls and wheelchair-accessible
bathroom stalls, we're grousing about minority support in website
design where there aren't even any real materials used to build them.
The main effort is one of shifting one's internal paradigm. That
might not be easy, but it should be welcome exercise for thinking people.
This discussion is about accessibility to the extent that some
assistive user agents are not JavaScript-enabled and even among those
that are a huge number of JavaScript user interfaces require a lot of
fine motor control on the mouse. At the same time, a) accessibility
isn't just for disabled people, it's for everyone (just ask Jakob
Nielsen), and b) this isn't all about accessibility, it's also about
parseability by search engines and other software.
Google themselves recommend, "Use a text browser such as Lynx to
examine your site, because most search engine spiders see your site
much as Lynx would. If fancy features such as JavaScript, cookies,
session IDs, frames, DHTML, or Flash keep you from seeing all of your
site in a text browser, then search engine spiders may have trouble
crawling your site."
- from Google.com > Webmaster guidelines > Technical guidelines
http://google.com/support/webmasters/bin/answer.py?answer=35769#2
Unlike most search engines that don't interpret JavaScript at all,
Google attempts to process inline JavaScript embedded in the HTML but
not external .js files. This means that if you want to build a site
that depends on JavaScript for core functionality and content and
have it be indexable by Google, you cannot separate the content &
behavior development layers. Even if I were motivated to hide
hyperlinks from humans not using JavaScript and from search engines
other than Google, I would consider the prospect of writing inline
code too expensive, inefficient, non-modular, unreusable, and
altogether distasteful to be worth the effort. Why would anyone
knowingly go there?
If you don't supply identical content to JavaScript-enabled and
-disabled user agents, Google will consider that cloaking --
directing different content to search engines than to human users --
which can get a site banned from Google. If you're going to supply
the same content, it makes obvious sense to produce pages with all
the content and then use JavaScript to selectively hide parts through
DOM or CSS manipulation as part of the user interface, for example to
implement tab controls. That's progressive enhancement.
Hyperlinks that are simply hashes because their sole purpose is to
trigger Ajax operations aren't registered by search engines as links
to separate content, so that's shooting yourself in the foot SEOwise.
Better to create real hyperlinks to real pages (or real page-reloads)
with the different content, and then override the links with the Ajax
logic. That's progressive enhancement.
I'll be very interested to read other people's contributions to this topic.
PS. Gut-feel tells me that non-JS should work, so thats how I prefer to code.
Smart gut!
Regards,
Paul
__________________________
Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [email protected]
*******************************************************************
