Beyond Caffeine

I’ve been a fan of MooTools over jQuery for a while, but jQuery just came out with something that makes it a bit more competitive - a set of widgets.

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

Recently I posted an article which talked about the reasons to avoid using javascript navigation. The article listed reasons, but not alternatives, so that’s what I’d like to spend some time talking about.

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.

Over time many bad web design ideas have been dropped or lost favour, including unnecessary splash screens and unwieldy framesets, for the good of the web user. However, one web design bad habit that persists is the JavaScript Dynamic Navigation. This is bad news for both web users and those looking to commission a web designer to build a site for them. Ultimately if your navigation is broken, so is your site.

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.

So that’s the question I’m pondering today. With the advent of the new Parallels Desktop for Mac, will Mac users who’ve clung to their IE 5.5 ditch the legacy browser for the ability to run the newer versions of IE through Parallels?

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

With the advent of what appears to be a ‘media boom’ on the Internet, I think it’s time for a reminder about accessible media on the web. Where new ideas like Dovetail, Yahoo! Current, Google Current, Memocast, Videoegg, MSN Soapbox, AOL Video, and tons more.. are jumping along on the same bandwagon that has made YouTube into a huge success, we have issues that continue to arise.

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

As I’m working on my book one topic that I’m trying to emphasize keeps coming to mind - that topic is the difference in how browsers will render the same page.

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

Today I read an article, in my local newspaper, about a woman who had left her new husband when he forgot to celebrate their one year anniversary. She went to stay with her mother, but doesn’t know if he’s figured out yet why she took off. Her mother was urging her to go back and patch things up with him.

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

If you’ve checked out your website in Mozilla Firefox or one of the other non-IE browsers, you may have been shocked to discover that NONE of the ‘alt’ tags you spent so long preparing are working.

What browser do you use to check your web pages when you’re developing your sites (or when your webmaster asks for your approval on a new layout)? If it’s Internet Explorer, you’re among the majority - around 60% of users are still using Microsoft’s browser.

But a growing number of users are moving over to other, more flexible browsers with less security problems, such as Mozilla’s Firefox (which offers a number of advantages, not least of which is tabbed browsing, making it easier to keep a number of sites running and switch from one to another quickly). Firefox’s market share has been increasing steadily every month for over a year.

When you look at your web pages in IE, you will be seeing what most other browsers see. But as usage of other, arguably better browsers increases, you need to at least double-check what these ‘renegade’ surfers are seeing as well.

One problem I spotted when I made the switch was that the ‘alt’ parameter on image tags doesn’t work. I found this annoying, but I didn’t realise that the problem is that the authors of Internet Explorer made an error in their implementation of the HTML specification (HTML was not invented by Microsoft, but by a completely independent entity).

The ‘alt’ parameter is not meant to be used in the way almost everybody uses it. And because of this it will not work this way in many other browsers.

This is a serious problem for webmasters like myself who are based in the UK, because we have a legal obligation to provide tool tips for images, to help blind users to use the internet.

To illustrate what I’m talking about, you will need to have both IE and Firefox available (If you’re developing pages to put online, this is a good idea in any case). If you don’t have Firefox already on your system, you can download it completely free here. Why not try it (no, I am not making anything out of this in any way). You will never need to pay a licence fee and you don’t need to put up with advertising banners either.

OK, so I’m assuming you now have both browsers installed on your computer. Load up this page in both of them and take a look at the picture on the left in each:

Hover over it with the mouse.

In IE, you should see a message (or tool tip), but in Firefox you will not see anything new.

Tool tips without Alt

Now, hover over the righthand picture. This time you should see the tool tip in both browsers.

So… How did I do that?

It’s really pretty easy, although depending on how many tags you need to change, it could take a while. (I have hundreds, which I am in the process of swapping over just now, as soon as I have finished this article).

All you need to do is to double up your alt tags, substituting ‘title’ for ‘alt’ the second time, in all your <img> tags like this: where you have alt=”fred”, you now need alt=”fred” title=”fred”.

ALL?! I hear you say. (I just hope you have a good quality HTML editor that will do batch find and replace.) Depending on how many pages you have, yes, it could be a longish job. But it’s something you can do over a period of time, as you work on a particular site. At the moment, less than half of the browsers in use are affected by this problem. But the numbers are growing every day.

PS. While we’re on the subject of ‘title’ as a parameter in <img> tags, there’s another little known use for this: you can also add a tool tip to your links in the same way!

I don’t know whether you noticed earlier on, when I recommended downloading Firefox, but there was a tool tip on that link (of course, this only works in html, so if you’re reading this in a plain email, you won’t have seen this). I’ve also put the same link at the bottom of the demo-pictures page. Take a look now at the tool tip that comes up when you hover over the link.

What I did there was to add the title parameter to the link (in the line below the angle brackets are replaced with curly brackets):

{a href=”http://www.download.com/Mozilla-Firefox/3000-2356_4-10208565.html?tag=pao” title=”Download Mozilla Firefox from Download.com”}here

Simple, huh? So, if you’d like to, you can add extra information to your links - or perhaps an extra ‘puff’ to encourage clicking… the possibilities are endless.

Well, I’ll sign off now, with the hope that I haven’t involved you in too much work. ;D

Catch yer later,
Frann

Written by: Frann Leach
About the Author: Frann Leach is webmaster of InformationZone.biz: Internet Marketing resources and lives in Edinburgh, Scotland.

I think the thing that I am finding to be the most annoying these days is the alert for ‘Missing Plugin for Quicktime, please download.’ Well, go figure, I can’t - at least that I know of.

But it’s not just Quicktime files, it’s also those sites that embed video in Windows Media Player format (also something I can’t view) as well as those who embed things requiring Flash 8 (not yet available for Linux, only up to version 7). Similarly, there is no Shockwave player for Firefox on Linux. Which is just … unamusing. In fact, you can see a list here: Common Firefox Plugins to see which are not available on Linux.

I find this all particularly annoying. I love using Linux (Ubuntu) as my primary Operating System - but I am inordinately displeased with the lack of Linux support for such common plugins. I really hope this improves in the near future.

Now, what was the point of this rant? The point was actually Accessibility. Please keep in mind that your web viewers may not have a required plugin. Always keep up to date on what plugins are even available to your users. Asking them to download a plugin is presumptuous enough - asking them to download a plugin that doesn’t exist is downright ridiculous and reflects poorly on your site. If you are trying to determine a good media type to pick - choose the least common denominator. In this case, that means use RealPlayer file formats or <= Flash 7.

~Nicole

This is one of those topics that bears mentioning periodically - screen resolution statistics are misleading.

Often when people are thinking of creating a fixed-width layout, they are doing so due to what their statistics are telling them. If statistics are saying that 99.5% of their views are from vistors browsing on high resolutions, many people feel safe with breaking out of the box and going above the fixed width recommendation of designing for a minimum of an 800×600 screen resolution. Unfortunately, those statistics are misleading.

To explain why, I’ll use myself as a common example of a misleading visitor. The resolution that would read from a visit from me would be 1400×1050. However, that is not the amount of space I actually use when I’m browsing. I like to keep space around my windows so that I can stack things and watch them while I’m working on something else. Like this screen shot I took of my 1400×1050 resolution desktop (image is resized to 800×600 so as to avoid being ridiculously large for viewers who don’t use the resolution I do ;)):

You see why it would be misleading to assume that just because your stats say I am using 1400×1050 — that I actually am? The more screen real estate that a person has, the more prone they are to stagger windows just like this. Additionally, take a look at how small my viewport (the portion where your website is actually show, not including the tool bars) is in comparison to my browser window. So… keep that in mind the next time you are tempted to start making a fixed-width webpage just a little bit larger because your stats ‘claim’ that your users all have loads of screen space.

~Nicole

Microsoft has a new version of their IE7 Beta that will be introduced at the MIX 06 event this month in Vegas. The new beta version, which Andy is calling the IE MIX 06 release, seems to have addressed quite a few of the bugs that were causing issues for CSS in the first IE7 Beta (at least from what I can tell with the screenshots). In her post on the MIX 06 version shown to her and Andy by Markus Mielke, Molly said she is

..very proud to be here today watching history unfold.

I can’t help but agree. It is a wonderful thing for developers to see the screenshots given of how the IE7 beta is evolving. Even more encouraging is that they are reportedly trying to fix a few more of the problems in IE7 before the MIX 06 event.

I have to admit that I’m very surprised. Maybe I shouldn’t be. Perhaps the fact that I am is an example of exactly how jaded I have become over time toward the Microsoft crew. So, I’ll start right off with saying this… I feel bad that I’m surprised you did something you said you would do, but in all honestly, you should understand why that is. IF (*note the slightly hesitant tone*) Microsoft is going to continue to keep making a real effort to better their technology toward standards, then it is only fair that we should all make a real effort to give them a fair shot and not be quite so harsh on them. Okay, enough apologies to Microsoft, I think I’ve eaten enough hat for one day.

If you want to attend the MIX 06 this month (March 20 through 22), but can’t afford the cost - there are a couple of contests going on to get you there completely free. They are open to International entrants, and cover every aspect of getting you there and back so that you don’t need anything to go. Keep in mind that there is a very quickly approaching deadline on these contests, as the conference itself is this month.

~Nicole

Lawsuit Filed for Lack of Accessibilty

One would expect, or are we just hoping, that the larger the company, the more capable they are of affording to have their sites made accessible. The idea to this, of course, is that those with the financial power of a mega-chain should be able to hire people experienced in web standards and knowledgeable enough. On the other hand - they could just contract one of the companies or private consultants that specialize in making websites accessible. Obviously, this was not the case with Target.

Apparently, some 10 months ago, original complaints were made to Target about the lack of accessibilty of their website. It was never fixed. Ten months is far beyond the amount of time needed to fix the problems cited. Those problems noted were fairly straightforward:

1. Pages were lacking the requisite alt text.
2. Pages used image maps (without alt text) for navigation, but there was no function on the page to do the same as the images in a text version alternative.
3. The pages required the visual input use of a mouse - inherently pushing keyboard-only users away.

Simple changes. Any web developer worth their salt could manage those changes quickly. Apparently Target either lacks those kinds of web developers, lacks motivation to please their customers, or blatantly has disregard for the 25% of all web users who are disabled. None of those are exactly what I would consider good options.

In any event, the National Federation of the Blind (NFB) has filed a suit against the U.S. based (California) Target company. They are attempting to have it done as a class-action suit. (Full document available here in PDF.) Now, apparently just in the last few days (after the suit was filed) there have been some changes made to the website to help improve some of the accessibility.

I find it truly pitiful that a fear of losing money in a lawsuit has to be the motivator for a change so simple to do. In this time, when web standards are absolutely necessary for any business (and eventually, we can hope, across all websites), I find it very disappointing that a major company would go to such lengths to alienate customers. Obviously they are concerned about their bottom line — are their analysts so entirely behind as to not realize the percentage of people who would be lost as potential customers due to this? It would seem not.

Again, another reason to learn standards. I hope that this case goes through successfully for the NFB, and that Target is penalized for its blatant disregard to its customers, and its lack of consideration toward those with a physical handicap. Hopefully, this case will set a new ’standard’ (a legal one this time), that might make people sit up and pay attention to what is going on in the world of the web.

~Nicole

CAPTCHA - What are the Alternatives?

In a very interesting document published by the working group over at W3C, it was discussed in detail how CAPTCHA’s are very bad for accessibility.

In case you don’t recall, CAPTCHA is that nice acronym for the terribly long phrase “Completely Automated Public Turing test to Tell Computers and Humans Apart”. Yes, it’s much easier to say CAPTCHA. A Turing test is something that many websites use nowadays to verify that the person filling in a log-in form, or posting on a message board or blog is actually a person - not a spamming program. Picture one of those little images with letters all crunched together, skewed this way and that, and you have to type what it says into the little input box nearby to enter.

You know, I have a confession to make. I have a turing test active to post to the comments for this blog. By default, it also gives me one of those darn things every time I edit a post of my own, or create one. I probably enter the letters wrong at least 1 out of every 5 times. (And that’s being nice to myself.) The document points out:

This type of visual and textual verification comes at a huge price to users who are blind, visually impaired or dyslexic. Naturally, this image has no text equivalent accompanying it, as that would make it a giveaway to computerized systems. In many cases, these systems make it impossible for users with certain disabilities to create accounts, write comments, or make purchases on these sites, that is, CAPTCHAs fail to properly recognize users with disabilities as human.

I think that summarizes it quite well. They are not good for accessibility. And if:

many of the systems can be defeated by computers with between 88% and 100% accuracy, using optical character recognition.

is true… then why are we using them? But what are the alternatives. Some were suggested, but most had their own set of accessibility problems also. One was the idea of logic puzzles instead — but that would not meet accessibility standards for people with mental / cognitive disabilities. Another was sound based — but that disqualifies for a number of reasons (lack of a sound card, poor or no hearing, etc..).

In the end, the working group suggests that the CAPTCHA’s stick around for websites that have users in the millions, but not for those with a small user base (i.e., most blogs). For smaller sites, spam-filering and heuristic checks were suggested in the place of CAPTCHA’s. I don’t know about you, but I’ve decided to turn my CAPTCHA off.

~Nicole

What is Accessibility Compliance?

As was mentioned in the previous discussion on code compliance, there is some substantial overlap between code and accessibility compliance. However, the one distinction is that code compliance is more geared toward coding a webpage in a way that it will be functional for all methods of viewing it, and accessibility deals more with ensuring that it is easily comprehensible by all people viewing it.

The common association with accessibilty standards is that these are for viewers with disabilities. That is not wholly accurate, but it is part of what they are for. Overall, you want to create your site in a way that you do not alienate your visitors due to either technical or physical limitations. For technical limitation, think of how your website would be viewed by someone using an alternative method of accessing the Internet (such as a small cell phone or PDA display, or even an in-vehicle dash display). For physical limitations, you should keep in mind that millions of people accessing the Internet are disabled in some way. An easy comparison is that your business would not be considered respectable if you didn’t allow for handicap access ramps, or other accomodations for those with limitations, so why would you consider doing that with your online business presentation.

These standards are, most certainly, considered something that is not only proper etiquette for a website to use, but also extremely good for business. However, U.S. government websites are now required to make their websites accessible, and anyone who plans to work as a web developer in any sector or sub-sector of the U.S. government should make certain they understand how to make a site accessible.

The Web Accessibility Initiative (WAI) which is a large subgroup of the W3C. When you are dealing with creating a webpage(site) that follows the standards set by the WAI, you will be following the Web Content Accessbility Guidelines (WCAG). The current standards set for WCAG is version 1.0 and contains 14 general principles of accessible web design. Keep in mind that these are just categories, and there are many elements within each.

14 General Principles of for WCAG 1.0

1. Provide equivalent alternatives to auditory and visual content. (ex: using alternative text for images that don’t display)
2. Don’t rely on color alone. (making sure that there is proper color use, and that the site is still understandable if it was all black & white)
3. Use markup and style sheets and do so properly. (this goes along with code compliance & separating design from code)
4. Clarify natural language usage. (indicating the site language in code, and explaining any abbreviations)
5. Create tables that transform gracefully. (use tables for tabular data mostly, and make sure to lable your tables using headers and footers to describe what they are)
6. Ensure that pages featuring new technologies transform gracefully. (make sure that your page still is understandable without all the frills - like scripts and flash)
7. Ensure user control of time-sensitive content changes. (anything that is active on your page - like scrolling or blinking or sound - should be able to be turned off by the user)
8. Ensure direct accessibility of embedded user interfaces. (again, making sure your site layout follows guidelines)
9. Design for device-independence. (take into account that users may be using various methods to access your site, and provide alternate ways to get to information - like shortcuts and links)
10. Use interim solutions. (Don’t wait, start changing your site now.)
11. Use W3C technologies and guidelines. (Be sure to use the current coding standards.)
12. Provide context and orientation information. (ex: Clearly lable your page and data sections - especially if you use frames.)
13. Provide clear navigation mechanisms. (ex: Use a consistent navigation layout for your whole site - not putting the links on the left on one page, then the right on the next.)
14. Ensure that documents are clear and simple. (Keep your information relavant, and use language that is understandable by your readers.)

Now, as I said above, there are subaspects to each, and those will be addressed in a later article. However, if you want to jump ahead you can take a look at the full page explanation of the WCAG 1.0 list of 14 needed aspects.

The 3 Priority Levels & Conformance
Each of the 14 guidelines has checkpoints within it. For instance, let me give you an example of one of the checkpoints for the first guideline.

Guideline 1. Provide equivalent alternatives to auditory and visual content.
Checkpoint 1.1. Provide a text equivalent for every non-text element (e.g., via “alt”, “longdesc”, or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.
Priority Level: 1

Each checkpoint is assigned a specific priority. There are 3 levels of priorities possible for each checkpoint.

• Priority 1 : A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents.
• Priority 2: A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. Satisfying this checkpoint will remove significant barriers to accessing Web documents.
• Priority 3: A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. Satisfying this checkpoint will improve access to Web documents.

Now, based on whether or not you followed each of the checkpoints for the 14 guidelines, and which priorities you completed, your website may lay claim to a certain level of conformance. If you’ve seen websites with a little button that says ‘AA’ or ‘AAA’ then you will understand where that comes from in the following list.

• Conformance Level “A”: All Priority 1 checkpoints are satisfied.
• Conformance Level “AA”: All Priority 1 and 2 checkpoints are satisfied.
• Conformance Level “AAA”: all Priority 1, 2, and 3 checkpoints are satisfied.

So, overall, you want to aim for following the conformance to the highest level that you can. Aiming for ‘A’ is a minimum. You want to always aim for the ‘Triple-A’ ranking.

~Nicole

What is Standards Compliant Code?

Well, it actuall is more of an overall category than a single thing, however, I’ll define it as this:

“Standards Compliant Code is the utilization of the current standards combinations, as set forth by the W3C Recommendations, in order to create code that uses certain standards to ensure that it is readable by the greatest number of people and systems. Essentially, the common feature is to compartmentalize in a way that you keep the code separate from the appearance of a page and (in some cases) from the data displayed on the page.”

Now, you’ll notice that I said the ‘utilization of the current standards combinations’ and that is a key point to make. The HTML language is not the only option, there are variations that have come about through the incorporation of XML, and thus the use of XHTML. Also, you can see that I mentioned that the appearance of a page should be kept separate from the page code. That is where the use of CSS will take place.

What is the benefit of following the W3C Standards?

There are many, but I’ll highlight some of the most important.

The first thing to consider is that when you write code not following W3C standards your page may look different in different browsers. Yes. There are other browsers besides Internet Explorer, in fact, I personally don’t touch IE anymore. I use FireFox as my primary browser and Opera as my alternate. Why would they look different? Well, unfortunately not all browsers interpret poorly written code in the same way. Some are more forgiving than others, so your page may display in a variety of ways.

Another thing to keep in mind is that, without standards compliance, your page may also look different depending on operating system. Yes. There are other operating systems besides Windows. There is a very active group of Linux users in the world, as well as those who use Macintosh, Unix, etc… Again, why would it look different? Many reasons, but one is that different operating systems come with different fonts (for example) and if you use a font in your page that someone doesn’t have on their computer to be able to read — then they won’t see it the way you made the page.

Additionally, without standards compliance, your page may look different depending on the screen size of the person viewing your page. Your page should be flexible enough to accomodate a variety of screen sizes, but if its not, it may end up looking far too huge or too small on various screens.

Also, standards compliance often encompases accessibility compliance, though accessibility expands the concept further (including coding and designing your page in a way that will not be difficult for a person with disabilities or physical limitations to still be able to access) — but I’ll be addressing those aspects later.

Overall, there are many reasons why you want to use the standards compliance, and it is to your benefit to learn now, not later, how to do it.

~Nicole