In This Issue...

• Introduction
• Avoiding Evil JavaScript
• New Technical Articles
• Techy Forum Threads
• More Techy Blog Entries

ECommerce Software for Professionals

Xonca shopping cart software by Arquan is built for web designers and SEO professionals.

• Supported software
• SEO friendly and SEO tools
• Easy to use admin area
• Complete design control
• Partner opportunities – earn revenue

Limited Offer – Next 50 people receive FREE Certified Reseller Partner training ($295 value).

Free 30-Day Trial of Xonca and More Info

Introduction

To bring you this issue of the Tech Times, I'm taking time off my other writing project: a new book! No, it's not the Java book I've been threatening to write, but it's close. JavaScript Anthology co-author Cameron Adams and I have teamed up to write a beginner's book on JavaScript.

What this means is you can expect the Tech Times for the next few months to be filled with my thoughts and discoveries on JavaScript, and specifically how to get started with JavaScript without writing code that is fundamentally Evil.

Speaking of Evil, how have you been coping with Internet Explorer 7? The browser has been out for a few months now, and with Windows Vista having just hit the streets more and more end users are browsing your sites with it. OneStat reports that as of January 22nd, Internet Explorer 7 has claimed nearly 11% of global browser marketshare, nearly equalling that of Firefox.

So, did the release require you to make fixes to your site, and did you get them done in time for the launch? Has IE7 added yet another browser to the list you need to test your sites with, or were you able to discard an older browser (IE 5.5, anyone?) to make up the difference? And in general, how have you found the process of getting things like CSS layouts to work the new browser?

Send me an email so I can share your experiences next issue!

Avoiding Evil JavaScript

What makes some JavaScript Evil, and can beginners learn to write Good JavaScript code from day one? Cameron and I have set out to write a book that proves that they can, but it's not proving to be as easy as I'd hoped.

Bad JavaScript is worse than no JavaScript at all, because it can prevent some users from accessing your site. There are at least three groups of people that you need to look out for when adding JavaScript to the mix, and I've listed them here in order of increasing difficulty:

1. users that don't have JavaScript-enabled browsers
2. users that browse without using a mouse
3. users that browse using a screen reader

Perhaps a little idealistically, I'd consider any JavaScript code that prevents one of these groups of people from accessing your site to be Evil.

At last week's meeting of the Web Standards Group in Melbourne, James Edwards (coincidentally, Cameron Adams's co-author on The JavaScript Anthology) summed it up very neatly:

"One person's preference is another person's real need. It may be that a group of users finds it easier with Ajax, but if another group of users finds it completely impossible then you're cutting people out, and you're doing it for basically nothing.

"I think of it as a hierarchy, basically, where accessibility is the most important thing, and usability comes next, and preference and design and aesthetics comes next. All of those things are important, but if one affects the other then you have to think which is the most important.

"And to my mind, accessibility is always the most important, because accessibility impacts on what people really need. Everything else is just preference."

James finished his talk with an appeal to Ajax-happy developers to avoid using Ajax if at all possible unless you can do it without impacting on the accessibility of your site. James was speaking specifically about Ajax, but the same argument can be made about JavaScript in general.

So the question becomes, can we reasonably expect JavaScript beginners to write code that doesn't degrade accessibility? Read on after the ad to find out.

Build Your Own Ruby on Rails Web Applications

"Build bulletproof web apps with ease using Ruby on Rails."

Build Your Own Ruby on Rails Web Applications is an easy-to-follow, practical and fun guide to Ruby on Rails for beginners. It covers all you need to get up and running, from installing Ruby, Rails and MySQL to building and deploying a fully featured web application.

This book will:

• show you how to install Ruby on Rails on Windows, Mac, or Linux
• walk you, step by step, through the development of a Web 2.0 social news application, just like digg.com
• show you how to test, debug, benchmark, and deploy your Rails application

Download four free sample chapters in PDF format now!

I mentioned above the three user groups that present increasing challenges to developers looking to enhance their sites with JavaScript without giving up accessibility. I want to briefly cover the specific difficulties of supporting these groups, and consider whether beginners should be expected to deal with them:

Users that don't have JavaScript-enabled browsers

If you build a site that relies on JavaScript to provide access to certain features, or even for fundamental navigation features, you are effectively shutting out a large number of users that, for one reason or another, do not have a JavaScript-enabled browser.

Thankfully, the way to tackle this issue is relatively straightforward, and is primarily a matter of approach. If you start by building a site that works without JavaScript, and then apply enhancements using JavaScript, then the problem is solved.

We can definitely teach beginners to think of JavaScript this way, and indeed that's what the first chapter of our book is all about.

Users that browse without using a mouse

Due to a wide range of impairments, particularly those that affect fine motor control, certain users are unable to use a mouse when browsing the web. Instead, they use the keyboard navigation features of browsers to get around on the Web.

In most cases, keyboard navigation is no more complicated to implement than mouse navigation. All it takes is a little thought, and some extra code to handle this alternative method of interaction. For example, you need to make sure users can reach every "active" element on the page with keyboard focus (typically with the Tab key), and take equivalent actions once there.

Supporting keyboard interaction as a first class citizen is something that you can teach beginners from the moment they begin writing interactive JavaScript.

Users that browse using a screen reader

Here's where things get tricky. Currently, the best available web browsing experience for many visually impaired users is screen reader software. A screen reader sits on top of a desktop web browser, reads the page aloud, and provides additional ways to navigate within the content and to accomplish tasks like filling out forms.

Unfortunately, there are no accepted standards for how this software interprets the content of the page, and consequently compatibility with younger web technologies like CSS and JavaScript varies greatly from vendor to vendor.

That said, there are some limitations that are pretty much universal. Two of these are particularly relevant to JavaScript development:

• Screen readers do not read content that is hidden by setting the CSS display property to none.
• Screen readers operate on a static snapshot of the page, which is occasionally refreshed in a process that can neither be initiated or detected by the developer.

Writing scripts that operate under these conditions without interfering with the user's ability to understand the content and use the features of the site can be extremely challenging, if not impossible in some cases. So what do we teach beginners about this issue, and how well can we expect their scripts to work with screen readers?

At one extreme, we can adopt the attitude that users can always switch off JavaScript if it doesn't work well for them, and simply write scripts that work for sighted users.

At the other end of the spectrum, we can take James Edwards's plea to heart and avoid using JavaScript altogether in order to maximize accessibility.

The approach to encourage in beginners, I believe, is somewhere in between. Make them aware of the issue, demonstrate some easy ways that you can cater for screen reader users in your scripts (e.g. by using offleft/offscreen positioning to hide elements instead of display: none), and enable them to make informed decisions about the accessibility of their own scripts.

So, that's the approach we're taking with JavaScript and accessibility in our book. Will every example work perfectly in all screen readers? Almost certainly not. But keyboard users will be catered for, and we'll provide an easily-accessed alternative for screen readers whenever it makes sense to.

And you'll pardon us for taking a little pride in writing the only beginner's JavaScript book (apart from The JavaScript Anthology, that is) that gives accessibility its due from the very first page.

I hope this issue hasn't been too preachy for you! Next time, I'll try to have some code for you to sink your teeth into.

Time for me to get back to writing the book before our managing editor Simon notices I'm a week behind!

Kevin Yank
techtimes@sitepoint.com
Editor, The SitePoint Tech Times

Help Your Friends Out

People you care about can benefit from the wealth of information on new and maturing technologies available on the Internet. Help them learn how to do it by forwarding them this issue of the SitePoint Tech Times!