Burningbirdwritings about JavaScript/ECMAScript and Node
Firebug has released a beta of the first full version, 1.0. The previous version was extremely helpful. This version is beyond helpful. I dare say it goes all the way to, “Wow!”
I don’t use Firebug because I’m a Firefox browser user. I’m a Firefox browser user because of extensions like Firebug.
Roger Johansson sharpens his teeth and tears into Ajax/JavaScript/Web application developers with You cannot rely on JavaScript being available. Period. He poses a questions:
I have a question for people who label themselves as JavaScript developers: Have you forgotten about, never heard of, or never cared about the terms progressive enhancement, graceful degradation, and Hijax? If the answer is yes, then please tell me why.
I would also like to know whether you actually consider disregarding those best practice methods to be compatible with modern, responsible, and professional JavaScripting.
Following the question, Roger lists out several popular web sites with a description of what happens when script is blocked. I’m not surprised at Bloglines, but wouldn’t have expected Blogger to depend on JavaScript for login. That’s very limiting.
As to his question, this is a time of flash and sizzle, and anyone who programs cautiously, worrying about such things as graceful degradation or accessibility, is going to be left behind. There is a frantic need to prove that JavaScript and Ajax and the whole genre of tools is cooler than cool. This is a time of competition for eyeballs, and grabbing market shares, and wow factors, and pages so crowded with interactivity, frankly, it’s like trying to read or work with an ant hill. With angry ants.
It’s this way because if you go slow, or urge caution, or back off of some of the more ‘hip’ Ajax/JavaScript effects, you’re out of the loop–not a part of the ‘with it’ kids. This all means then you don’t get the opportunities, jobs, even the pats on the head and a well done. As for those who might provide accolades to those who do use the JS best practices, well, they’re too busy in their own world focused on web design, CSS, accessibility, XHTML–conferences here, web standard get-togethers there. The only time they might notice us ‘hacks’ is when we do something they don’t like.
So Roger, the answer to your question is: when was the last time you pointed out those who support the ‘good’ practices of JavaScript?
Anne writes today on the coming proliferation of applications combining Ajax and Flash, and where the direction may go:
What tools will be important, if hybrid Ajax + Flash + Java browser apps are the future? Perhaps toolkits and frameworks that shield developers from having to know multiple languages, object models, and browser quirks, for example, OpenLaszlo, the Google Web Toolkit, and Morfik. Abstracting the web development task like that, though, introduces its own problems.
I’ve never been a ‘framework’ person, preferring control over every aspect of my code. I’ve used frameworks, just never felt a level of comfort. To me for all the advantages of such toolkits, the disadvantage of increased bloat in code, inability to debug, and loss of fine control outweighs the benefits. Which means that I really do need to take a closer look at the tools, before I allow my natural bias to distance me from what could be handy technologies.
It’s going to be interesting to see where this goes. In particular, with the growing partnership between Mozilla and Adobe, we’ll definitely see an impact on Ajax.
I also want to extend congratulations to Anne on her new gig with Web Worker Daily.
My editor, Simon St. Laurent, and I both agreed that with the new book, Adding Ajax, the work would all be valid and accessible. Some of this effort is easy; much is not.
One particular area has to do with updates. When using a screenreader, or when using a screen magnifier, if the data in the page is updated, the web page reader may not be aware that such updates have taken place. You then need to provide some form of cue, and I don’t mean the color fade (which if you think on it, is about the most unaccessible Ajax effect there is).
As has been discussed elsewhere if screenreaders didn’t support JavaScript, life would be simpler because the readers would then get the no script version of the page contents. Screenreaders do support JavaScript, though, and that plays all sorts of havoc.
Anyway, while researching the current state of accessible Ajax (which threatens to be an oxymoron), I came across some resources I thought might be of interest.
Regardless of whether you’re a web developer or not, it’s a good idea to test your page as it appears in screenreaders. I use Apple’s VoiceOver, which is built into Mac OS 10.4 and up. Unfortunately, its behavior differs from other screenreaders, such as JAWS.
Recovered from the Wayback Machine.
The popular Ajax library, script.aculo.us has a new look. It moves away from the traditional Ajax pastels into earthier tones, and uses four bubbles to represent four main menu areas. The site navigation is quite clear, and the information you would want is immediately apparent.
I tested the site and it validates, and looking at the source, it should be text-to-speech accessible. Rather than use H1 headers for every menu block and div elements for each item, it might have been better, semantically, to use one H1 for the main title, only, H2 elements for the four main menu titles and unordered lists for the menu items. Other than these quibbles it’s accessible and valid, easy to navigate, and a refreshing change from lime green and rounded corners if…
IF…
If you have JavaScript turned on. I have the extremely popular Firefox extension Noscript installed and enabled, which suppresses JavaScript at every site until the site is ‘whitelisted’–marked as scripts allowed. When I followed the link at Ajaxian to the script.aculo.us site, this is what I saw:
Not much there, other than a “go away and come back when you have shirt, shoes, and tie on” message.
The content of the front page, as well as several other sections of the site (such as the documentation wiki) could easily be made accessible to people with scripting disabled. Why, then, shut the door so completely?
The script.aculo.us creators state in the message that displays when scripting is disabled that since the site is about a library that’s built in JavaScript, it doesn’t make sense for any of it to be available for those who have JavaScript disabled. I can understand this, but I think what the creators have forgotten is that they have to earn the trust of the web page reader, first, before the reader might be willing to open the gates. It’s difficult for trust to be earned if the reader can’t access anything other than a Paypal button, a link to a syndication feed, and credit for the company that built the page.
Of course, the script.aculo.us creators could say that everyone knows who they are and what script.aculo.us is–after all, look at who is using the library. That’s just it: you can’t assume that everyone knows the site, the library, or who the creators are. For those who don’t, the information is buried behind the NOSCRIPT wall. As for the list of sites that use the library, it’s also hidden behind the NOSCRIPT wall.
No one debates the necessity of letting people know they need to have JavaScript enabled when an application is dependent on JavaScript. However, I see little in the script.aculo.us front page that demonstrates that the use of JavaScript is anything more than just a way to add a little eye candy to the page. Eye candy is good, eye candy is fine, but eye candy shouldn’t be the only thing served for dinner.
Years ago during an acting class, I did a routine where I pantomimed being a bomb squad officer defusing a bomb. Afterwards, my teacher told me my acting was terrific and deserved an ‘A’. However, he also told me I had forgot to tie my hair back and he could only see half my face. Since he could only see half my face, he could only give me half my grade, and I got a ‘C’.
I like script.aculo.us and it’s one of the Ajax libraries I covered in the last chapter of Learning JavaScript. I like the new site and it’s rather innovative design. I liked that they made sure the site could validate. However, because of the NOSCRIPT wall in the very first page, I can only give the new web site a ‘C’, for Could have done better.
update Gucci was one of the sites that uses the script.aculo.us library. Try visiting that company’s main page with script turned off. Then try it with script turned on. I actually preferred the site with script turned off. I think it might end up being top contender for my Worst Use of JavaScript at a Site award.