If you’ve worked with site accessibility before you’re probably familiar with skip navigation. Skip navigation helps visitors ’skip’ to different parts of the HTML page to quickly get to the content they need. The most frequent use of skip nav involves jumping a page’s primary content, so users don’t have to revisit repetitive header, navigation, and other global content on recurring pages. Typical HTML markup looks something like this:

HTML Code

<div id=”skip-nav”>
<strong>Shortcut Navigation:</strong>
<ul>
<li><a href=”#content” accesskey=”p” title=”Skip to page content”>Page Content</a></li>
<li><a href=”#nav” accesskey=”n” title=”Skip to main navigation menu”>Site Navigation</a></li>
<li><a href=”#search” accesskey=”s” title=”Skip to search”>Search</a></li>
<li><a href=”#footer” accesskey=”f” title=”Skip to footer (ctrl/alt + f)”>Footer</a></li>
</ul>
</div> <!– end skip-nav –>

Most often, skip nav is hidden from visual users by shifting the content outside of the page viewing area (be sure to use a positioning property as display:none can render your content invisible to some devices). In this way traditional users who can scroll to what they’re after aren’t burdened with extra visual cruft while visually impaired users can jump around to the content they want.

Unfortunately, this approach ignores a number of different users. For example, skip nav could also be useful to sighted users who are unable, or simply choose not, to browse with a mouse and opt for a keyboard or other assistive device. Unfortunately, hiding this content off of the viewing area can create confusion.

One way we can improve this implementation is by using JavaScript/jQuery to display the content when it receives focus. This way we’re being accommodating to non-traditional users while still preserving the aesthetic integrity of the site.

The Plan

To do this we’ll test if any of the skip nav links have focus, and if so, show the container. We’ll set a timer that checks every 100ms to confirm a skip nav link still has focus, and if not we’ll run a function to hide it.

The JavaScript

Because only the links in the container can receive focus (at least without tweaks like tabindex) we’ll use their status to control when to open the container. So:

1. If a link receives focus add class nav-focus to the link, animate the container and give it class active.
2. Use setTimout to test if nav-focused no longer exists, and if so, close the container(use this instead of focusout to keep the container from closing when switching between links)

That’s the logic, here’s the demo beaconfire.com/blog/demo/skip-nav/.

To add it to your site add the HTML to your page and skipNavigation('name-of-container-id'); to your jQuery documenty read function

One last issue concerns the possiblity that JavaScirpt is turned off. A good habit is to use JavaScript to initialize elements rather than having default behaviors baked into the CSS. We’ll remove the CSSthat hides the skip nav, and do it with JavaScript.

$('body').addClass('js');

Now the following code hides the skip nav only if JavaScript is available:

.js #skip-nav {position:absolute; margin-left:-9999px;}

Note: This concept is based on a CSS based promoted by jimthatcher.com/skipnav.htm

When it comes to slideshows on Web sites, you’re pretty much got two choices: Adobe Flash, or JavaScript (which for the purposes of this post we are no going to call jQuery*).  Up until the last year or so, the only way to deliver the level of sophistication required for slideshows, has been with Flash.  Increasingly though, we are recommending the use of jQuery over Flash for the majority of the slideshows that we make as  part of our site designs, and are even being asked to convert existing Flash slideshows to jQuery .  First things first, though, what is Flash and what is jQuery?

Flash

The best way to think about Flash – for the purposes of this discussion – is as a bit of magic, included on a Web page just like an image, that can do all kinds of really cool animations, transitions, play sound and movies, and nearly display nearly identically on nearly all browsers that have the flash plug-in installed.

Flash has been around for quite a while and has a very robust set of tools (made by Adobe, and formerly by Macromedia).  It has been used to create the sites, movies, slideshows, or multimedia players, that you see on millions of Web sites.  For the sake of this comparison, I am going to talk specifically about slideshows that are created in Flash compared to those using  jQuery because that is the vast majority of the Flash that we have traditionally used in our projects.  And ’cause that’s what this post is titled.

Flash Advantages

• Great looking fonts
• Smooth, complex animations
• Robust development tools

jQuery

You may have noticed that I have referred to “slideshows created in Flash” and “slideshows using jQuery.”  This is a fundamental difference between the two.  While Flash is an embeddable object created in a specific application, jQuery is a JavaScript library that can add a bunch of really neat-o functionality and effects to elements that already exist on the page. This means that you have HTML, and then on top of that, you have jQuery making that HTML jump through all kinds of hoops, sit, roll over, and even sometimes, though hopefully not often: play dead.  jQuery is JavaScript, which means that some experience with the ubiquitous scripting language is going to make things much easier.  There are hundreds of plugins which exist as additional JavaScript files along with the HTML they need to act on that you can simply copy and paste in to your web page to add whatever slideshow you want.  Many of these existing plugins slideshows have comprehensive documentation that even those without lots of experience with JavaScript can follow.  Basically, if you know your way around HTML and CSS, you can figure out how to at least use jQuery.

The jQuery library can either be downloaded from the jQuery Web site, or you can link to hosted versions from jQuery, Google, or Microsoft. I tend to use the Google-hosted version because it is very popular and likely in use on many other sites. Because of that, if your visitors have previously visited a site using the same linked library that you do, their browser will not have to download it again and you’ll save the 150-ish KB of download that the library requires.

jQuery Advantages

• Generally smaller, and quicker (150KB+ though, for the main library)
• Less time to create, very simple to manage
• Superior accessibility and findability
• Works on iPhones
• Free

Picking One

There are many questions to consider before you when even decide to use a slideshow (see “Parting Shot” below).  I’d say that, if you do decide to add a slideshow to your page  jQuery will be the best choice in 98% of cases.  It offers most of the abilities of Flash (depending on how adept you are at JavaScript) and has the added advantage that it is used to animate images and text that already exist in the page.  This is of monumental importance to search engine optimization, accessibility, and cross-browser/cross-platform support.  That your images and text already exist in the page means that it is basic content that you manage in your authoring system.

Even if a visitor has all styles and JavaScript disabled in their browser** the content contained in your slideshow will be present for them to see (albeit in a way that may break the beautiful layout of your page which is already the case if they have styles turned off).  This is the essence of accessibility: that all content on your page is available to all visitors regardless of how they access your page.

There is no cut-and-dried answer to the question “Flash or jQuery,” though I’d argue that in the limited scope of slideshows jQuery has a decided advantage.  In the end it really depends on what you are trying to communicate, to whom you are trying to communicate it, and how you want it to look.  If you want to be able to use any beautiful font available to your designer, utilize sophisticated transitions (though jQuery can match much of Flash’s capabilities in this regard), ensure that your slideshow works on all browsers with the Flash plug-in installed, and don’t need to support iPhone users, then Flash may be your best bet.  If you are, however, willing to limit your font options, want to be sure that your content is available to all users, on all browsers, regardless of platform, and are willing to limit slightly the sophistication of transitions and animations, then jQuery is the clear winner.

Parting Shot

And that brings us to the end, but I simply cannot leave without a final parting shot regarding putting  a lot of time and money in to designing and developing a slideshow.  I, and others in the office are looking with an increasingly critical eye toward the effectiveness of using slideshows at all to highlight important information.  A too-cursory review of too-few site analytics begins to suggest that very, very (very!) few visitors see more than the first slide of any slideshow; Even fewer engage with the sideshow controls (if present, to move forward, back, or pause);  And fewer still click on any links found on slides beyond the first.  Do not assume that the third, or even second, slide will get any attention at all.

One of the drawbacks of many new interface options presented by Flash or jQuery (or any of the other JavaScript libraries out there) is that they have offered an easy solution to a very old problem: gigantic homepages where every department in an organization demands a presence.  Similarly to simply adding more and more content to a homepage until visitors have to scroll tens of screens down to read it all, we are now asking visitors to engage more and more frequently with tabs, slideshows, accordion widgets, and more to access the same “too much content.”  Have we just shorted the all-too-important conversation about focusing an organization’s message and simply allowing “all of it” to go on the homepage?  And what about people who don’t or can’t use these new widgets? Perhaps another blog post?  I nominate Jo!

** Chances are pretty good that if styles and JavaScript are disabled in a browser, so is Flash.  If your slideshow reads its content from an XML feed, the path to which you define in the JavaScript call to the Flash object, your slideshow will not work even if Flash is enabled but JavaScript is not.

Much has changed since humanity acknowledged the word knowledge and started to classify the various subject matters into categories and taxonomies of learned disciplines.
The definition of knowledge is outside the scope of this article because of simple reasons. I am not as qualified as the university professors, or librarians who pour their blood, toil, trouble, and tears into the understanding of knowledge and wisdom.

What I do know about is what knowledge is online. Since Sir Tim Berners-Lee (Yes. He was knighted.) created the World Wide Web to link documents together on the then nascent Internet, knowledge became more than monolithic documents or books that were linked loosely via citations and references. Instead of specifying in APA, MLA, Chicago, or Turabian style where the source of a particular knowledge was, one could directly link it using something called “HyperText”, or what some know as “Hyper Text Markup Language”. Today, all websites that you see online are built with a combination of HTML, some JavaScript, and possibly some Flash or Java.
(more…)

The iPhone is arguably the most advanced piece of technology commonly found in people’s hands these days. It has a GPS to tell you where you are. It has a phone to let you communicate with people. It has a multi-touch LCD screen that lets the user use the device with no more and no less than one button. The iPhone is a computer … with the Internet. Ten years ago, try to imagine describing to someone what an iPhone does and they’d think that you were talking Sci-Fi. Well, folks, as much as people like to deny it, Science Fiction becomes reality every day in our world.

Jules Verne could see us going to the moon, and John F. Kennedy  actually pushed our country to do it. Star Trek could see us using tri-corders, and Motorola created it as the first cell phone. In my opinion, the iPhone, it’s market of applications, and growing user base is the best way to gain access to and interact with information. It also helps you get in touch with people, but I think face to face is the best way to interface with other humans.

Over the course of my trip to New York City this weekend, I realized exactly how valuable my iPhone is. When I got off my bus at 31st Street and 7th Avenue, I wanted to use my gym membership at the sports club. I went online on my iPhone, looked up the nearest 24 hour gym in their network, and copied and pasted the address into the Google Maps application. In about 2 minutes, I was on my way. After I arrived and couldn’t get into the side of the building which was advertised, I looked up the phone number online, gave them a call and got in. That’s convenience.

The sports club’s web site is not optimized for the iPhone, but since the built-in Safari Browser is a full-fledged browser, I was able to navigate with some effort and get what I needed. If the web site was actually created for the iPhone, it would have saved me some time from zooming in and out, panning left and right to get around. If they had an "app" for that, I might have been able to log into it with my account and it would have been geo-location aware of where I was and tell me the nearest branches of the club. Why don’t they create an "app for that"?

This is all possible and contradictory to popular belief, the functionality that I just described doesn’t have to be developed as an iPhone Application. Much of the functionality can be created in HTML as a web application and placed on the Internet. Google has done a great job by making all of their applications as iPhone friendly "webapps" which behave like iPhone applications.

Recently, some plugins have been released to make your WordPress blog iPhone friendly. Available at Brave New Code, the WPTouch Mobile Theme and Plugin for WordPress takes your standard WordPress blog and makes it look, feel, and behave as an iPhone application with nice transitions.

Static Content Sites

Many organizations have also released informational web sites in a handy, iPhone friendly format. Their sole purpose is to disseminate information. Web Apps such as the Athens Tourist Guide :  and Pocket Cambridge : are basically lists and tables of static HTML that look nice on an iPhone or an iTouch. Do you have information that can be useful to iPhone users? There are some really easy ways to get it out there.

1. iWebKit – “Iwebkit is the revolutionnairy kit used to create high quality iPhone and iPod  touch websites in a few minutes and is based on an LGPL license. In the first 4 months of it’s existance the pack has greatly evolved from a basic idea to a project that has reached worldwide fame!”

2. iUI – It has the following

1. Create Navigational Menus and iPhone interfaces from standard HTML
2. Use or knowledge of JavaScript is not required to create basic iPhone pages
3. Ability to handle phone orientation changes
4. Provide a more "iPhone-like" experience to Web apps (on or off the iPhone)

Dynamic Content Sites

Do you have programming ability or resources which you can utilize to push out your content from your organizational and institutional databases? You can probably use the aforementioned tools in conjunction with dynamic server side languages, but you might want to look into the following options to make your life easy.

1. ComponentOne iPhone Studio – ComponentOne’s studio is a rich set of ASP.NET Server Controls which is beyond compare when it comes to giving you a competitive advantage in creating dynamic applications fast. Some of the included server controls are : Calendar, ViewPort, CoverFlow ( Like the iTunes record browser ), and MultiView ( like the Photo explorer in the iPhone Camera application ).

2. iWebKit for Grails – This plugin provides integration with iWebkit, a powerful User Interface Library for Safari development on iPhone. By using this plugin, the grail developer will have an iphone web app skeleton (CSS and javascript) but also a extended tag library helping in creating iphone web pages in an easy,clean and fast way. If you are a Java developer or your company has them, and have gotten the hang of Groovy, this might be the path for you.

3. iUI with Asp.NET – iUI is very simple and some people have taken some steps to create their own integration for ASP.NET and iUI. This page points you to some third party resources which may be helpful for you in creating dynamic iUI applications.

Possible Scenarios and Tips

How can you capitalize on the iPhone and iTouch user? Here are some ideas which may work out for you.

1. If you have a Calendar of events, you can add iCalendar format links which can let users download the event data and add it to their iPhone Calendar.

2. If you have a location or event search which requires an address or a zip code, you can use W3C’s Geolocation API which is supported by the built-in Safari browser on iPhones.

3. If you have a member’s only directory, you can create an interface which can list people’s information as well as publish their contact info in the vCard format so that they can add it to their contact lists.

Accessibility is always in the front of our minds when we embark on a Web project. But as we start to consider our features, accessibility starts to slip by the way side. “As long as a screen reader can read it, we’ll be fine, right?” Not really.

Disability does not equal blind. “Works in a screen reader” does not equal “accessible,” even for users of screen readers. Designing for a screen reader will help you hit many accessibility points, but you won’t hit them all.

(more…)

A few years ago, it seemed most of the new technology buzzwords were music to the web accessibility guru’s ears. Words like standards and XHTML compliance helped developers compose more accessible Web sites.

But what about this new generation: Web 2.0, AJAX, RIA? Well, to the web accessibility specialist, it’s like seventeen car alarms going off at once. With so many moving parts, how can screen readers and other assistive technologies keep up to ensure a user-friendly experience to those with disabilities?

Well, let the music play, because now we have ARIA.

(more…)

Ah, the frenzy of a site launch. You’re templates are in. The CMS is ready. And so now it’s a race to enter your content. You’re copying and pasting left and right. You’re putting in your links. Entering place holder content where you need it. You’re jamming away in the WYSIWYG editor. Everything moves at a breakneck pace.

And some things get forgotten.

Perhaps there’s a placeholder link that was never replaced. Maybe one of your content editors didn’t realize the importance of alt tags in your images. And the WYSIWYG editor added empty paragraph tags with reckless abandon.

CSS to the rescue.

(more…)

We all want to do our best to make sure our Web sites and applications are used by the entire Internet-loving world. But organizations small and large are often limited by time, software, and/or budget when it comes to making Web sites that are accessible, especially for the blind community using screen readers. Screen reader software can be prohibitively expensive and limited to installation on one computer. So testing for screen reader compatibility will have you chained to the QA lab.

In comes the University of Washington to the rescue. The Department of Computer Science and Engineering recently publicized the Alpha Release of WebAnywhere. WebAnywhere is a free, Web-based application that allows you to hear your Web site. Go to the web, enter your Web site’s URL, click go, and listen.

WebAnywhere is not nearly as sophisticated as its more expensive counterparts. All your Flash and Rich Text Applications, accessible or otherwise, may not be accurately interpreted. If your Web application has an accessibility mandate, you still need to spend the time and money to make sure your site is in compliance. But, with WebAnywhere, you can get a good sense of how a screen reader may interpret your site, which basic accessibility items may have been missed (alt tags, anyone?), and which portions of your site may be troubling to those using screen readers.

It’s no small task to wrangle a website and its resources in one language – let alone multiples.  If you’re taking the time and making the effort to post multilingual content, you’re creating potentially valuable assets for your users around the globe.  You want to make sure that the content is represented accurately and is accessible. 

Recently one of  our clients asked us to weigh in on the presentation of multi-lingual content on their site – an organization with members around the world that produces publications, trainings and other web-specific content in a number of languages. The client wondered how to present the information in an accessible and useful way to their users.

While not an exhaustive list, these points can serve as a backbone for your multilingual content presentation.  The first distinction to make is whether the site is fully mirrored in multiple languages or if it is presenting a limited number of pages.

If the full content exists in multiple languages, providing tabbed navigation to each language (with the full built-out resources under each) is an effective presentation. The International Center for Journalists’ IJNet site does a good job of this. When you click a language tab, the entire page content and all navigation swap out to the language you’ve selected. You don’t want to promise more content than you can deliver, though, so be careful of setting up a parallel nav structure and re-directing users back to English content for non-translated content.  The effect is jarring and, frankly, inconsiderate.   

If your multi-lingual content is limited, you want to make sure you don’t portray the fact that when you click on a language, you’re getting the same content in another language. Presenting a limited number of resources is best handled by directing users to “Resources in…” (or Pages in or Materials in – whatever works best for the audience). A user can then click through to a landing page that aggregates the non-English content by type.

Link placement on the page is critical. Links to multilingual content (even if it’s not a full parallel site) should be displayed prominently and placed above the fold. Providing content in multiple languages takes a significant investment of time and resources. And if you are making the investment, you most likely want to showcase the international consideration and reach of your organization. What you don’t want to do is force users looking for non-English content to hunt around the homepage to find the link, effectively negating the time and energy you’ve put behind developing these resources.

The visual and functional treatment of links is vital as well. The easy one first, you don’t want to use as the visual representation of languages. While they may provide a dash of color, flags represent countries, not languages. What flag would you use to represent Portuguese language content – Portugal or Brazil? Don’t even get me started on the options for Spanish language content.

Another bad idea… including a drop-down menu with language choices. This treatment does save space within your page layout but it creates a challenge for languages that are character-based such as Chinese, Japanese and Korean.

While listing out each of the language options in their “native” spelling may take more space, it allows non-English reading users to identify their preferred language easily. Also, displaying each content language also serves to showcase your organization’s commitment to international audiences.  InfoComm currently does this on their site.    In addition, to ensure they appear correctly you should use images for the nav items, as opposed to text based labels, to ensure that the labels display as intended. Most computers can handle all language characters but some cannot.

Where should limited multi-lingual resources live on the back-end? I’d suggest they live in the file structure with the parallel English pages. That way, the file structure makes sense in terms of linking and, if (when!) the content grows to a level where a parallel or sub-site can exist, it will be easy to find & identify the resources.

If you are presenting multilingual content, Kudos!  If you’re considering it, bahati njema, Bonne chance,  Buena suerte, Danke, Good luck, Lykke til, Sretno and Желаю вам удачу!

Call me a Luddite or a libertarian nut, I only share my cell number with those deep in the “inner circle.” Until recently, I had never shared it with a Web property. Until Epicurious.com convinced me the value of sharing was greater than my privacy concerns.

The quick backstory: Our home Internet connection went down. 10 guests coming for dinner in 3 hours. Printed recipe for seared scallops had gone missing. Panic.

A quick search on my Treo yielded dozens of recipes. And every one of the first 7 taps took me to Web sites that were a usability nightmare on my Treo. Even my favorite – Cooks Illustrated – failed my “this is too much of a hassle on my Treo test.” (Ok you iPhone users, no need to comment on that one, I know your gadget is superior!)

Then enter Epicurious. I tap their link on Google, they detect I’m on my mobile, reroute to a WAP version of their site and serve up a simple login screen that fits my window:

Please enter your mobile to unlock your recipes, create a shopping list, search and more.

Hmm. Why do I need to enter my phone number? (more…)

Whenever someone wants to build an accessible Web site, I always try to conceive the design from the simplest elements on up, rather than most complicated pieces on down. That usually means some more intricate components, like a Flash application, are usually out. Yes, I know it’s a generalization. Yes, I know you can make Flash accessible. But it’s not always easy, especially if you’re making more advanced applications. Even the Adobe site gives us caution:”Creating this kind of content may require guidance for novice developers.”

But if you’re not ready to give up your Flash application or your site’s accessibility, you still have some options. But you need to plan for it. You can’t make the Flash application now, and then decide to make it accessible later. And for your more advanced applications, you need a competent Flash developer who will work with you and understand your accessibility needs.

Flash actually offers some elements that make it more accessible than standard HTML web content. Two that are of note:

• Vector images. With vector images, someone with low-vision can zoom in on their screen and the Flash content will remain crisp.
• Key-stroke enabling. You can create interactive Flash applications that do not require mouse interactions.

Using these features, the following tips, and some common sense, you can have your Flash and accessibility too.

(more…)

With accessibility being more and more important these days, particularly for organizations that are required to be Section 508 compliant, there’s been a lot of discussion of “How accessible is too accessible?” This generally involves questions of how much instruction to include, whether to use accesskeys, and to what extent it’s important that a site look good when text size is increased, at the cost of how it looks when the text size is normal.

But one area that’s rarely discussed is when and when not to use Alt tags, particularly in email. Alt tags, the captions that appears when the image does not, or when hovering over an image, are particularly handy for describing to screen readers what the included images are. They can also improve site search engine optimization and act as a place to put copyright info.

But they can wreck havoc on emails, when messages like this arrive in your inbox:

More below the fold on why Alt tags like this are unnecessary and why it’s important to consider your teaser when writing an email.

(more…)

There was an AP piece out recently, discussing the problems and challenges of CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart – yeah, it’s a stretch, but most of the good acronyms were taken), and proposing, as a possible solution, a webcam that continually takes pictures of a variety of subjects and asks users to identify them. It’s rooted in the problem that unless you have a truly gigantic database, spammers will eventually just add your pics to their library and be able to break through. By using a webcam of, as the article suggested, a kitten bouncing around a room, there would be a continual stream of new photos for users to identify – presumably, you could have multiple kittens and ask how many were in a shot or what color the one currently on screen is or something that would change but be easily identifiable by people.

While this is an innovative, not to mention fun, approach to CAPTCHA, it brings up a chance to discuss the merits of using it at all. Let’s take a look at three areas where CAPTCHA is causing debate online: blogs, webforms and email.
(more…)

In an interesting post, Web Designer Mike Cherim wonders what damage we can do to the accessibility of Web sites by overdoing it with accessibility features. I’ve been thinking about this myself and find that I agree with Mike when he says that some accessibility features are either so misunderstood, poorly implemented, or unknown that they are probably best steered clear of (Access keys) or used in moderation.

In related news, Web Content Accessibility Guidelines version 2.0 is open for comment. You have until June 29 to submit your comments on the working draft and make your voice heard. There is also a summary of changes since the last draft avialable for you to review.

Recently, we had two different clients ask us for assistance in finding mass email tools that have built-in support for multiple languages. They were specifically interested in sending out Arabic and Chinese emails to their supporter list.

If you dabble in the area of internationalization (i18n) in tech tools, then you would agree with me when I say that it is particularly difficult to find a technology solution that can fully support languages like Arabic and Chinese. Generally, tech tools are really good in supporting languages that have a Latin-base (ex. Spanish). They are not that great with a non Latin-based language like Chinese. They are downright poor when it comes to a non Latin-based language that also reads from right-to-left (RTL) like Arabic. And, don’t even get me started on RTL languages that share most characters but not all (Arabic & Farsi/Persian).

Before we delve into the multi-lingual mass email support issues, here is an over-simplified version of the technically complex process of creating emails:

Email written up or “encoded” in a language (i.e. Arabic, Chinese, etc.) –> Sent out by bulk mailer –> Received by email server –> “Decoded” for view or display in your email client.

Side note – Problems in the decoding end of things require a separate post, so I will ignore it for now.

Most email solutions including < insert most eCRM and email marketing tool names here > do not go beyond Spanish for their multi-language support line item in the features list. So, no multi-lingual support, no encoding, no sending out, no nothing.

A small number of vendors and solutions support multi-lingual emails, but it ends up being an interim solution. In the encoding process, they create HTML emails where letters are represented by their numeric character references. This is somewhat akin to using & in HTML code to indicate &. All HTML-enabled email clients display this fine for the recipient to read. Most email clients, including the browser-based ones like Google and desktop-based ones like Outlook, are HTML-enabled these days. So, most recipients would have no problems with this solution.

The issue with this approach however is what happens in the back-end. This approach means that you can send out only HTML emails and not plain-text ones. If you viewed the source in these emails, you will see a string of these numeric character references. This means that many of the functions that depend on actual letters instead of numeric references (ex. search) will not work. Sort of reminds one of those Hollywood studio sets that look grand from the outside. :)

This approach runs out of its usefulness if your organization wants to (or is mandated by its mission to) provide the full-spectrum experience to your supporters, donors, and advocates who speak other languages. This is becoming an important need. As I mentioned at the beginning of this post, we recently had TWO clients ask for bulk email tools supporting multiple languages. So, hopefully things would change soon. But, much of this innovation will probably originate from regions where multiple languages are the norm rather than the exception.

A note in the “somewhat related” category – European Union has 23 official languages and India has 22. Conflict of interest or disclaimer or something of that sort – My native language is one of those non-Latin-based languages, so I may have “vested” interests.

A note in the related category – If you are developer, here is a slightly dated, but still relevant article on email, MIME, Content-Transfer-Encoding header, etc: http://www.eveandersson.com/arsdigita/asj/mime/

There is an interesting discussion following an AlistApart.com article entitled Where Our Standards Went Wrong, in which the author, Ethan Marcotte discusses two sides of the web standards debate. In the article, Ethan tries to refine the message we as standards advocates are delivering.

Yet while the benefits of valid code may not be glamorous, we can�??and should�??talk about them. Validation isn�??t an end result or a final deliverable; it�??s an ongoing process that continues long after a site launches. If we don�??t put the proper tools and commitment in place, our work will start looking like a late �??90s throwback, and if we don�??t provide guidance and education on validation, the polished, perfect pages we produced will be snapped into software that�??ll produce tag soup in seconds flat.

Ethan also discusses some of the problems with Content Management Systems (and their often third-party) text editors, which are often central to the standards issues we face when deploying web sites for clients. In the discussion following the article, several people touch on this aspect, and even (gasp) offer some solutions.

It’s a question that comes at some point in nearly every design project we do: “Should we stick with 800 pixels as our maximum width when designing the site, or push it up to 1024 pixels?” Unfortunately, there really isn’t a cut-and-dried answer that fits all situations. As a result, the question will generate debate and discussion as if it were the first time it was asked.

It would be great if it were really so simple as to just pick a width and go with it. That’s often what is done, but there are issues that make the question worth taking a deeper look at. Issues that can vary from client to client.

Simply having more space to work with is often a designer’s purpose for suggesting a wider layout, while clients are often motivated by a desire to fit more on each page. Not surprisingly, these two goals can often end up colliding into each other after the design goes into a production environment.

Unfortunately, regardless of your reasons for wanting more space to work with, it’s not simply a design question. There are accessibility and usability questions as well.

Although the percentage of users browsing the web with a screen resolution of 800×600 is decreasing (between 10% and 30% depending on whose stats you’re looking at), those that do so may be using the lower resolution (and even increasing the font size further from there) because they have trouble reading the smaller text-sizes at today’s higher screen resolutions. To not take this group into consideration violates accessibility standards. That’s not to say that we have to stay with 800×600 layouts, it just means that we have to make sure we consider the impact of any layout.

Why choose? Why not use a liquid, or expandable, layout? Liquid layouts have been around forever but continue to make up the minority of sites that we build. Why? There are a few reasons, but with the increased importance of accessibility as well as the growing number of alternative devices (Cell phones, PDAs, smaller laptops, tablet PCs and other devices) used in the U.S. and, even more so, in the developing world, our need for more flexible layouts is increasing.

Liquid layouts are a bit trickier to code, but the issue that usually trips us up is one of control. By this, I mean the perception of control that we often feel we have, or need to have, over the layout of a page.

In the design phase of a project we work with static images depicting how the page should look. Sometimes we pass these static images (or ‘comps’) back and forth for weeks, tweaking and adjusting spacing, color, layout and imagery. Since we are unable to make “fluid” design mock-ups we start to develop a sort of tunnel vision with regard to the design at hand. We start to internalize the structure of the designed page as well as the design elements, and when confronted with the prospect of how the page may stretch and resize when coded with a fluid HTML template, we back quickly away from the lack of control over the design that, to date, we’ve had pixel-perfect control over.

Perhaps the problem stems from the static representations we work with during the design phase. Are there any options?  Do we need to start presenting design comps that show the same layout as it will appear at several different resoltions (including handhelds)?

We need to let go a little bit of our need for absolute control over our page layouts. It’s been said before and should be said often: The web is not print. While this is overstated quite often, it is certainly true.  If people could easily modify layout, font sizes, column counts, etc. in print, then they probably would. Browsing applications and devices give average users exactly that level of control over what they view; And they use it.

Whatever the solution, we will continue to be confronted with the question every time we design a site. And to reduce the question to one of design alone may be causing more problems in the long run than we foresee.

As I code pages for Web sites, I’m always working on ways to improve accessibility. The online tools for evaluating a site really just don’t cut it alone. It’s fairly easy to code a site that passes tests like the one found at The HiSoftware Company CynthiaSays portal (a very popular and accurate accessibility test) but that is still utterly unusable by someone using a screenreader, unable to use a mouse, suffering color blindness or any other disability that means they are using your site in any number of different ways. That’s not to say that online tests are not incredibly valuable, just that running your pages through a single test and thinking the job is done may not cut it.

Accessify.com has provided some incredibly useful tools and wizards to help build and test accessible Web sites. There are wizards for creating accessible HTML code (forms and tables), browser plugins for testing pages, even a set of Dreamweaver objects that increases the accessibility of your code by adding additional options to dialogs for creating tables, images, acronyms, etc.

For testing usability for people with different vision needs, I love GrayBit which renders your page in grayscale so that you can visually evaluate the color contrast of your site. Another really cool color tool is Color Schemes which not only helps you develop a color palette, but also lets you preview your palette approximating eight different types of color blindness.

When you get right down to it, though, there really is no substitute for having differently abled users test your site. They’ll let you know better than any test out there what needs to be improved. Just testing with average users who are unfamiliar with the site will go a long way toward exposing usability shortcomings, which often translate to accessibility issues.

Remember: an accessible site is also a more search engine friendly site! As if you needed a selfish reason to strive for accessibility.

There is another interesting article on A List Apart about accessibility. This one focuses on user testing and how assumptions that many of us have made, regarding how differently-abled people use sites, often do not play out in real-life tests. There is some specific comment on how, since there seems to be no actual data to support many of their guidelines, simply following the WGAC recommendations does not guarantee an accessible site.

We often make something a law just because it’s been repeated over and over again. User testing is really the only way that we can prove, or disprove, our ideas about how websites shouold be built.

Some excerpts:

But more than that it turns out that while size matters, boldness also matters. In fact, a bigger text that is not bold, is less readable than a text of the same size that is bold.

and:

In short, we need less discussion and more user research. Especially when our guidelines form the basis of national laws, we need to ensure that they�??re founded on real user experience.

and finally:

I asked a reputable member of WCAG-WG what kind of user research WCAG 1.0 was based upon. He answered that �??WCAG are based on many things,�?� which sounded good, but didn�??t really answer the question. Exactly what were those �??many things�?�?

It’s a short article, and certainly worth the read.

If you haven’t seen Google’s Accessibility Search you should stop what you’re doing right now and take a look at where your site stacks up against the rest in your industry. Please note that at the moment this search engine is concerned with accessibility to the visually impaired only. I’m sure others will follow.

If you don’t see your site at the top of the search results page don’t worry. It could be something as minor as the term you searched, which may not be a META Tag or META Element in your HTML. This happens more often than not.

But it could be something major like not enough use of CSS or just plain bad code. If this is the case you’ve probably had the same Web site design for years and are just about ready to redesign.

Only this time you’ll have a tool to help you make certain your site’s on top of accessibility. :)

Cheers!