Unfortunately, some people aren’t ready to let go. We have to give them incentive to upgrade (free!) to a better browser. People aren’t going to stop using something until it stops working – so let’s make it happen. If websites start to look like junk in the IE6 browser – maybe people will consider upgrading.

Yes yes, I know, there are many corporate elements / reasons / excuses that companies continue to use IE. So fine, they can keep using IE6 for their ancient intranet applications if they want. They can still download something like Firefox or Opera for everything else. When, or if, it becomes cumbersome to use 2 different browsers to 2 different activities – then maybe it will be worth it to them to consider revamping their software, but there are few solid arguments to keep support and many to drop it.

I stopped supporting IE6 about 6 months ago, but I’m willing to get on board for the whole ‘lets make some waves’ change. Just to make sure it’s clear – when I say ‘stop supporting’ I simply mean that there should be a rollback for visitors coming to a site using less than IE7 [conditional comments a good solution here] to a plain text version. Accessibility is still an issue and since we all have simple text degradable versions of our sites (right?), this is just going to throw the IE6 users into that bunch with the old Netscape versions and plain text browsers. You might even consider adding a warning to your IE6 users that they should consider upgrading to a modern browser.

If you need help convincing someone (or yourself!), take a look at the nicely compiled reasons to upgrade from IE6.

For me, it’s time to throw in the towel, say our goodbyes – and continue moving forward.

~Nicole

In any event, I wanted to promote a special they have just for WordPress users and put the ad for that in my blog sidebar. Unfortunately, none of the graphics for the special were of a size to fit neatly into my sidebar, and they moved too fast (timed around 2-3 seconds before the text change). Thankfully, I was able to find a compromise between what I want in keeping my site accessible, and what I had as options from the premade HostGator advertising images for the WordPress special.

I decided that I could not possibly be the only person to have this problem, so here’s how I managed it.

The Problem

Since I avoid animated gifs like the plague normally, but was limited to being able to use HostGator images only, I needed to find an easy solution that did not involve me having the files they used to make it. I needed to be able to resize the animated gif to fit in my sidebar better, and while I was at it, I wanted to see if it was possible to slow down the animation speed to be more accessible.

The Solution

I started off doing it the easy way. The image had two views only where text was different, so I took a screenshot of each version of the graphic as it changed text, and cropped them down to just the ad image. I put both in Photoshop as two separate layers on a project, and followed these instructions on how to resize animated gifs from there. Voila! I have a resized gif that now changes in 5 second intervals instead.

My two favorite concepts both dealt with accessibility, and either of them could cause a huge shift in the way visually impaired people use the internet (or a computer period). I was really hopeful that at least 1 of these two wins some of the prize money. It might have been enough to jump start a marketing run to get more funding for production.

My Favorite: Siafu

Siafu does what we already have technology for (turning text into dynamic braille). However, it also takes it a step further: By allowing websites to be displayed, as designed, in raised relief:

I could talk for hours about how wonderful that would be to both web developers and people who need the technology.

My Second Favorite: Zen

The ability to ‘rake’ your hand over the platform to turn on the computer is just wonderful usability. I also love the concept of being able to simply place your phone / pda etc.. anywhere on the platform to have it sync with your computer.

The Zen really takes on the ability to simulate pretty much anything it runs across in a raised fashion, and that could really open some doors in functionality for people who need assistive technology.

Overall, there are some really great ideas out there for accessible tools – but I’m still disappointed that neither of them received the prize money to make any of those concepts a reality. Don’t lose heart though, apparently we’ll soon see technology that will allow us to jot down notes on napkins!

~Nicole

If you head over to http://ui.jquery.com/ you can see the new demos online.

Here’s a little comparison of the two for you to look at.

The Accordion

jQuery:

Mootools:

Codewise they are similar in scope. Both use containing <div>s to manage the accordion feature. Now the demo on the jQuery page uses more <div>s than I would like, but there is another page of demos that shows it’s not actually necessary to suffer from a massive case of <div>’itis in order to make it work. In fact, one of the examples uses HTML that is pretty spartan and that’s great. The Mootools accordion uses less <div>s in their demo, but is a bit heavier on the classes.

However, jQuery tops Mootools on one small (but major) issue in the demos. I’ve always disliked the fact that the Mootools accordion demo shows how to set the default content tab of the accordion by putting the text in the Javascript that will show on load. That’s a HUGE accessibility issue, and isn’t very practical unless there is non-essential content in the first tab to load (but then why would it be your first tab?). jQuery doesn’t do that.

The Javascript call for the accordion is:
jQuery('#myaccordion').Accordion();

<div class="basic" id="myaccordion">
<h3>Tab 1</h3>
<div>
<p>The content to show.</p>
<p>The content to show.</p>
</div>
<h3>Tab 2</h3>
<div>
<p>The content to show.</p>
<p>The content to show.</p>
</div>
<h3>Tab 3</h3>
<div>
<p>The content to show.</p>
<p>The content to show.</p>
</div>
</div> <!-- end the accordion wrapper -->

And it ends up looking similar to this:

jQuery has separated the control of which section shows first by putting a function and parameter set in that handle it separate from the content. You can see those here.

The only catch is that you can’t do this out of the box with jQuery. The function is dependent on the Dimensions library addon, which you can get here.

In the end, I think jQuery just built a better accordion.

~Nicole

Secondary Navigation

I feel that the best alternative to javascript navigation is to create secondary navigation for your pages. What is secondary navigation? In a nutshell, I consider secondary navigation to be any separate section of navigation that applies to a particular page or area of your site. Let’s look at some examples of this by taking a peek at the WordPress.org website. Below is a screenshot that I’ve scribbled on:

You can easily see that the secondary navigation sections change according to what page you are on. Here’s a different page:

This is a great alternative to using drop-down menus (a menu with a sub-menu on hover) because this method will work for any and all browsers.

CSS Drop-Down Menus

So what’s wrong with using CSS for drop-down menus? The answer may not be a huge surprise to you: IE doesn’t handle it well.

For most drop-down menus controlled with CSS, you essentially use a list structure with a sub-list for each menu item. The top list item is the shown menu item, and the sub-list contains the sub-menu items. You start by setting the value of the sub-list to display:none and then on hover of the main list item, you make it change the value of the secondary list to display:block. It’s a very simple concept, and theoretically this is how all menus will be done at some point in the future.

The problem is in IE6 and lower, primarily. It is possible to create this effect in IE7 (though typically you need some CSS magic specifically for IE7 to make it work), but earlier versions don’t support it properly. Why? Because IE6 and earlier had serious problems with handling actions on child-elements when triggered by a parent-element.

So, if you really want to use CSS for your menus, what’s a good way to handle this? Anything server side is ideal, but then you get into the issue of trying to detect browsers – which can work well most of the time, except that many versions of Opera cloaked itself as IE as the default setting.

Degradable JavaScript

This is a good solution, but it requires layout adjustments in some cases. You have to have the kind of layout that will work with this solution. Conversely, you can create a layout adjustment for people who have JavaScript disabled.

Let me show you an example of a decent (but not perfect) degrading JavaScript menu implemented on the US Patent and Trademark website. I have clicked on one item in the left menu bar, and you can see what happens, it dynamically opens up and shows the sub-menu:

But what if I don’t have JavaScript enabled? Here’s a screenshot of the same page with JavaScript disabled:

I think you can easily see that there are some pros and cons to this site. The good thing is that the menu is done in HTML using lists, so content is there for someone who has Javascript disabled – which is more than I can say for many sites that embed links into their Javascript. The cons? When it is disabled — the menu spans nearly twice the height of the content in the page when it’s all expanded. The visual aspect isn’t what comes to mind for me, it’s how awful it would be to listen to that many menu items on a screen reader. The idea alone is daunting.

I’m going to leave that thought to simmer in your mind, and move on to how this works (or doesn’t, as the case may be) for horizontal menus instead of vertical ones.

You saw what happened to the previous site when the JavaScript was disabled, but let’s pretend that you used a normal list structure again to create a horizontal list. Then you used Javascript to hide the sub-menus by default and to let the sub-menus drop down when you hover over the primary link. So, what happens if you have Javascript disabled? Well, in the described scenario, you’ll have all the links show at once, because the Javascript is no longer hiding the sub-menus. Depending on your layout and how these menus are styled, they’ll either push down your content to make space for all the sub-menus, or they will float on top of your content constantly.

Here’s an example of what could happen if the layers are set to float over the content, and they were no longer collapsed:

The obvious problem is not just that it looks lousy, the -real- issue is that the content is blocked.

Or if they are not set to float over the content, here’s what you could end up with:

In the second example, you’ll see a different problem – the content gets shoved down by the constantly expanded menu. Depending on how you have designed your page, moving the content like that could break your design by shifting other elements too far out of place. Aside from that, it looks bad, but not nearly so bad as the first option.

Be very careful with how you handle those horizontal menus. They can be really tricky to get right, and you have to really think ahead to make sure they degrade properly (which neither of the above examples do). Think about where those sublinks could be if you did have to show them to someone without Javascript. Could there be another area in the page where they could go? You know… like a secondary menu area.

Middle Ground Option

I commend everyone who creates their multi-level menus in CSS. As we’ve seen, those can be great and the only sticking problem is with IE 6 and lower. One middle-ground solution to that is to manage the menu controls for those affected IE versions using Javascript and browser detection as a combination. If the user doesn’t have Javascript, you have to offer a text version of the menu somewhere in your page, surrounded by a noscript element.

Best Choice Suggestion

Overall, there are lots of different ways that you can handle navigation. Some are significantly better and easier than others. Some are accessible, some aren’t.

Which brings me back to my main suggestion. If you want to ensure the biggest audience, without having to jump through hoops of ‘what-ifs’ (do they have javascript? are they on IE 6 or less? etc…) — use a secondary navigation instead. As a reminder, the secondary navigation was what I showed above in the screenshots of WordPress.org. It really makes life as a developer tons easier if you create navigation sections that are perfectly compatible in browsers and very accessible. In my opinion, the best way to do that is to make a secondary navigation section.

The seven top reasons why you should not use JavaScript Dynamic Navigation are:

Site navigation is difficult when navigation is not permanently displayed.

Everyone likes to know where they are going and even where they are! A site with a permanently visible navigation structure meets both of these requirements, but popup or dynamic navigation systems do not. Remembering that Google and the other search engines are as likely to deliver a visitor to a subpage as they are to your home page, a clear navigation structure is essential. Think of it as they “You are here” icon in your local shopping mall’s map.

Embedded elements can clash with dynamic navigation

A typical dynamic navigation structure will result in an overlay or pop up/down display. The challenge here is that if your site is media rich (ie contains flash animation or embedded video) these embedded elements will take precedence on the page. The end result is that part of your navigation will be hidden behind these elements making site navigation difficult if not impossible.

Cross browser/platform compatibility issues

As any developer will tell you, since the dawn of the internet, not all browsers are created equal. Some applications will follow a stricter implication of JavaScript than others. The only way to combat this issue is through vigorous testing – something that takes time and money. When you consider how quickly some browsers release code updates you have to be prepared to be in constant test and verification mode.

Usability issues- Dynamic Navigation is not for everyone

Just like menus in Windows or OSX, dynamic navigation structures require good hand/eye co-ordination. Not everyone will be as fast or as accurate as you are when it comes to using a mouse and nested dynamic navigation can be particularly hard to use. Usability studies with elderly users or those new to computers and the internet shows that such nested menus quickly cause frustration and are far from easy to use. Operating systems have addressed this issue by allowing a user to navigate using their arrow keys as well as a mouse but this is a complicated and difficult task to accomplish in JavaScript.

The Experts don’t do it

Go and visit your favourite site and then all the big internet names such as Google, Amazon, YouTube, BBC, MSN, Yahoo!, MySpace, eBay, Wikipedia, Craigslist, IMDB, etc, etc. There is a reason that you don’t see these sites using dynamic navigation and that’s because there are better ways. Any coaching or strategy expert will tell you the secret to success is to model those who are already successful. So if th336e experts don’t use dynamic navigation why would you?

You have plenty of other options

One advantage of a dynamic JavaScript navigation structure is that everything is contained in a single script file. Changing any aspect of the whole site’s navigation can be achieved by modifying this one file. However, this benefit is not unique to JavaScript. An external xml navigation structure or a range of server-side scripting processes can achieve the same effect and all are capable of outputting standard XHTML without any of the drawbacks listed in this article.

Your site will be broken if JavaScript is turned off!

With increased security awareness and the constant screen invasion by pop-ups many users restrict or even turn off JavaScript settings in their browsers. While this activity is designed to stop the JavaScript based popups, squeeze pages and floating ads, it will render your site inoperable. Statistics from W3Schools show that 10% of the visitors to your site will have JavaScript disabled. As there are plenty of better alternatives to a dynamic JavaScript navigation structure why even risk alienating 10% of your site visitors?

Written by: Iain Row
About the Author: Iain Row is the lead developer at Prominent Media, Milton Keynes Web Development that specialises in producing website navigation solutions. This article was prepared by Andrew Silvers of Attraction Marketing. 2006 Prominent Media Ltd.

I’m really not sure, but with all the known issues / weaknesses of IE 5.5 Mac… I wouldn’t be surprised if some Mac users decided to drop it in favor of being able to run IE6 or the new IE7. Of course, Mac is really pushing the ability to run Windows software from their OS. Who can blame them? Linux has been touting Wine for ages, and now Mac can do the same thing.

I’m genuinely curious though about whether or not this new product will cause a significant plummet in the remaining IE 5.5 Mac’s we see around. If it does in the long run, it will be interesting to see how long it takes for web developers to start feeling safe excluding or minimizing IE 5.5 Mac support.

Personally, I don’t understand why a Mac user would choose to stick with a Windows browser (an unsupported one at that) when they have the option of running a stronger browser like Safari or Opera, or any other of a plethora of choices. Maybe it’s just me, but I don’t quite comprehend the reason for the choice. Perhaps it’s just a holdover from someone who switched from Windows to Mac? Who knows.

Regardless, I’m hoping that some analyst starts projecting whether people are going to shell out the $79.99 for Parallels, or not. I’m betting they will, at least a good many of them. If nothing else, they’d be able to run all the millions (or so it seems) of graphical games that are produced only for a Windows enviroment.

I haven’t run across any data projections yet – but I’m looking. If anyone sees one, please toss it my way.

~Nicole

The biggest issue for me with most of those companies is the format in which most require you to watch videos – that being Flash. Now, don’t get me wrong, I like Flash for displaying video. In fact, I prefer flash to most media options because if used sensibly, it doesn’t require severe hacking of your Linux install to view videos. Note that I said ‘used sensibly’ — most do not. It is the job of the web developer or media person to decide the format videos play in, and to make that choice well, they need to know what versions are compatible with what operating systems. Sorry if that sounds like actual work, but research is part of the job of being a web developer. This applies to more than just Flash – you need to check what kinds of support there is for any kind of media you intend to use, you need to know whether this is something that comes supported in the base install or if they would have had to be tech-savvy enough to install it manually. It’s about understanding your user.

My first issue with Flash movies – the version of Flash player required. You absolutely need to check what versions are compatible with which operating systems. Read the specs, that is what they are there for. If you hop on over to the Flash section on the Adobe site, and dig around a bit you will find the following system requirements documents:

• Flash 9.
• Flash 8.
• Flash 7.

Now, I hope you’ll go and read those documents, but I’ll summarize here: The only Flash player version inherently available for all Windows, Mac OS, Linux, and Solaris is Flash 7.

Unfortunately, a lot of sites are not using Flash 7 player requirements to display their content. My daughter players games on NickJr and PlayhouseDisney – or she did. They started changing their content over to types not inherently supported by Linux, and now that has become an issue. (Yes, Linux has changed. If my 6 year old can use it, so can you.) A friend of mine tends to place the blame on Flash itself for this, and is boycotting them based on the fact that they aren’t releasing more system compatible versions of the player. While I agree with this in part, I place the majority of the blame on the web developers and media designers. It truly is quite simple to allow the most users to access your content – remember common denominators in mathematics? – use Flash 7 player output.

It’s simple to do. Using Flash:
File -> Publish Settings -> Flash (tab) -> Version (dropdown) -> Select Flash 7.

Now why is YouTube so successful? They have the right idea:
From their troubleshooting page (emphasis mine):

Next, check to see if your system meets these requirements for running the Video Viewer:

* Macromedia Flash Player 7.0+ plug-in
* Windows 2000 or higher with latest updates installed
* Mac OS X 10.3 or higher
* Firefox 1.1+, IE 5.0+, or Safari 1.0+
* Broadband connection with 500+ Kbps

While there are lots of new media companies on the web – if they are not implementing their ideas from the start with all users in mind, then they are missing the boat. When there is a simple solution to making your media viewing content accessible to other people – there is no excuse for not doing it.

~Nicole

I think that far too many people see this as a huge problem, when it’s not. I also think this is the whole reason that so many people got started developing this plethora of CSS hacks we are left with today.

So… let me say this loud and clear:

Your site -does not- have to look identical in all browsers. Your site -does- need to be functional (and hopefully attractive) in all browsers.

If your footer is 2 pixels taller in another browser.. so what? Does the text still look fine? Alignment is still okay? Did the design completely lose it’s quality because of 2 pixels? If it’s built well, I rather doubt it made a huge difference. Who cares if your font of choice isn’t rendering on the operating system of your viewer… does an equally nice one render? If not, specify better alternative font families, don’t turn to dynamic font graphic generation to solve something like that unless it is -really- vital to the design. And I mean -really- vital. Something would have to be darn important to waste precious load time rendering and loading extra graphics when you know you have only a few seconds to capture a viewer in the first place.

So many people stress about because IE cannot handle so many of the nifty little CSS things like the :after and :before. So what? Use them on non-vital things. The important thing about making your site accessible to all people isn’t that it be exactly the same to everyone visually. It’s that you need to ensure that your design is close enough to the same, but even more importantly… that all the -content- is available to everyone regardless of the method they use to access your site.

Now, don’t get me wrong. Some things that happen in different browsers can have ugly results. No designer wants their pages to be ugly. But they don’t have to be identical. I have watched people tweak a design for hours and hours just to get it all perfectly the same in several different browsers. I’ve done it myself many times, until I realized that the little things (small, insignificant non-content things) … really don’t matter in the long run.

Overall, I think that a non-hacked CSS is better than a hacked one. If you can avoid using hacks just to solve minimal issues, then do it. I’m not talking about major things like a div that is floating around aimlessly and overlapping your content. I’m talking about minor differences in rendering. Hopefully, people will start seeing these differences as less of a stumbling block, and more of an opportunity to use varying technology while still providing a good user experience.

~Nicole

I just had to laugh at that girls impulsive reaction to leave her husband over something like that. But then, I started thinking about how many things in the world people do that with. They see one thing, assume the worst possible scenario, and react based on that. In this case, the girl was convinced that he didn’t love her because he forgot the anniversary. A more likely answer is that he simply forgot. Sometimes, the truths that are the most basic and simple elude us in favor of a more dramatic reaction.

I can rather easily relate this to something I see regularly in the web development arena. It often appears that web designers are doomed to continue to see accessibility as the bane of their existence for many years to come. I truly think that much of what is feared about accessibility has more to do with a lack of understanding, than well-founded dislike.

So many web designers seem to view accessibility requirements for a website to somehow translate into meaning that they are supposed to design a boring or spartan website. Devoid of interesting tools or functionality that they want to add and lacking beautifully crafted graphics. That is simply not the case.

In my mind I can visualize a play where we have a web designer storming off the second they hear the accessibility person wants them to include some text-only function for the disabled. They may hear ‘more work’ or ‘less graphics’ or ‘boring’ and that’s what they’ve decided to think. The accessibility person, on the other hand, may not know why this person stormed off, and perhaps if they had stuck around they could’ve explained that they didn’t necessarily need to take away their graphics, only learn to add accessibility features.

To be quite honest, the people who have walked away thinking that there is going to be tons of work involved… should at least give it a shot. Try to understand what is involved with providing accessibility features to a website. Discover what it means to give alternate text value to a graphic image. See examples all around the web where people have used accessibility standards and still provide a graphically lovely user experience.

Quick tempers, and dislike for being told what they -have- to do, is rather common among tech people, so I’m not entirely surprised. In some ways, perhaps they are viewing the wrong opponent. In my view, it’s not so much the accessibility people that the designers have to fear … it’s the usability experts

~Nicole