1 Sweet

I really like the idea of using more JavaScript in order to make life easier while still keeping accessibility, even if either JS or CSS are disabled.
When javascript came up, people used to use it for everything, including important things such as navigations which were unreachable for those having JS disabled. However, soon most of them noticed that they excluded them and therefore they decided to completely set it aside. But now the point is reached where we start to combine the power of JS with the DOM. This makes it possible to view and use pages having JavaScript disabled without causing any problems. But if you have it switched on, it’s more comfortable. And that’s what I really like!

posted at 08:37 am on May 24, 2005 by Nicolai

2 example files

I downloaded the example.zip from the link at the end of the article, but it failed at decompression ( Stuffit 9, OS X 10.3.9 ), with an indication that zipping of the files was not correctly executed.

posted at 08:50 am on May 24, 2005 by Peter

3 well done

Progressive enhancement is the way to go. The AJaX problem is really a problem though. It makes me wonder if I should reset values in cookie with each action taken by the user. That way the back/forward could possibly bring them to where they left off, but that could get messy.

posted at 09:01 am on May 24, 2005 by jim

4 Usability?

Jakob Nielson would have a great deal of negative things to say about such a system. Having so many levels is not usable, especially for partially sighted people.

posted at 09:09 am on May 24, 2005 by alex

5 Accessable?

I sometimes wonder if which audience is more important, the people that navigate without js, groups of visually imparired people or the not so small group of 60%+ that navigate with ie…

your example has images of arrows are all over the show… this is definately due to bugs in ie but i think that all solutions should cater for this audience.

posted at 09:36 am on May 24, 2005 by david

6 The Ajax Problem

A lot of articles, such as this one, discussing Ajax and the use of Javascript for “progressive enhancement” seem to acknowledge “the Ajax problem”, but few seem to offer any ideas as how to overcome the problem.

Anybody got any bright ideas for implementing the benefits of Ajax without breaking the older, less-cool, but hugely important web controls such as the back button and bookmarking?

I can’t think of the number of times I’ve hit the Back button whilst using Gmail, only to be spat back to the entry page.

posted at 09:57 am on May 24, 2005 by Mike R

7 Possible Solution to back button problem

I really dug the article. I may implement something very similar on a site of mine now.

As for the back button, I picked up an idea from [url=“http://www.ajaxian.com/archives/2005/05/ajax_summit_eri.html”]Eric Costello’s Ajax Summit presentation[/url]: Use cookies to store the state. When the person goes back to the page, it looks at the cookie and gets the necessary data to revert to their current state. If you were just concerned with knowing which list item was selected, you could possibly pass something in the URL hash. Something like “#deserts-pancakes-short_stack”.

Just a thought.

posted at 10:06 am on May 24, 2005 by rick

8 Accessibility vs. Usability

I’m with Alex on this one. This solution (purportedly) increases accessibility while decreasing usability. Actually, the point he made about partially sighted people might infringe on the accessibility front as well. Don’t get me wrong, interesting concept and definitely worth exploring derivatives and other applications, but I just don’t see this being a viable alternative.

posted at 10:29 am on May 24, 2005 by Dan

9 Accessibility?

This is no triumph for accessibility, either. Using the keyboard, you must tab through all of the links, regardless if they are currently shown or not. A solution to that would need to be found before I would consider implementing this anywhere.

posted at 11:46 am on May 24, 2005 by Michael Niggel

10 AJAX Problem

I haven’t been able to toy with AJAX much, but I have had a similar problem with the back button in a WYSIWYG editor we used. When you hit back (before we modded it), everything in the editor was gone.

The trick was to store the state information in a hidden form element when the onbeforeunload(IE)/onunload(Mozilla) events were raised. When the onload event gets raised, you just pull the state information you stored out and load it. Since onload fires when you hit back/forward and the state information is stored in a form, you can maintain it without using Sessions/Cookies and running into the trouble storing navigational elements in Sessions/Cookies tends to cause (e.g. what if I hit back more than once).

Again, I’m not absolutely sure the will work in AJAX (or even if it’s a great idea), but it’s probably worth a shot.

posted at 12:37 pm on May 24, 2005 by Brad Davis