But now, make sure to exhale. Start thinking about what you need to do if/when the ADA does apply to your Web site. Because “don’t panic” doesn’t mean “don’t plan.”

• Brush up on the basic tenets of accessibility. WebAim is a great place to start.
• Review your online transactions and find the accessibility shortfalls. Knock out the easy ones now.
• If you find inaccessible code output by a vendor’s product, start talking to to that vendor now about what they are doing to make sure that when the time comes, the product will be compliant with the ADA.

Thinking ahead of time might just keep us all sane.

The following isn’t legal advice, but thoughts on some of the alarms the announcement caused, a few calming words.

All Web sites will need to be Section 508 compliant – and therefore be very ugly.

This isn’t about Section 508. It’s about ADA. If a ticket-purchasing site fails to put an alt tag on the dreamy picture of Justin Beiber, it’s not Section 508 compliant. But if a user with a disability can buy a ticket, then the site would likely be considered ADA compliant.

My non-profit’s site will have to be ADA compliant.

The ADA applies to organizations offering goods and services. So if you sell something on your Web site, then yes, you will have to be compliant. What is a bit murky is whether or not accepting donations online will be considered a good/service. But a site that touts how awesome your work is will not likely be covered under the new rules.

I’m going to have to do a lot of work to make my site ADA compliant.

ADA compliance for non-profits is going to be all about transactions – eCommerce, Event Registration, and maybe even donations. But most organizations don’t build these themselves – they hire a vendor. So vendors do have their work cut out for them. But most non-profit staff will be spared a lot of the pain.

I need to make my site 100% accessible right now!

No new laws were enacted over the summer. We’re probably years down the road from any major changes to ADA as it affects the Web world.

This is all a bit excessive

People said the same thing when ADA was first passed. But now, I don’t think many of us can imagine going to a store/restaurant/museum/concert venue that doesn’t have ramps, elevators, and other services for the disabled. Twenty years from now, we will look back at this time and say “can you believe there was a time when Web sites weren’t accessible to everyone?”

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

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.

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.

Never mind what the knowledge is built with. Let’s examine very briefly the trend of tagging and keywording content. “Tagging” or “keywording” existing content can help web site users browse through indexes of such tags or keywords similar to how a book may be indexed by the editors and publishers. What was the first representation of such archaic systems on the Internet? Search Engines. Search engines were of two varieties. Directories such as Yahoo or Excite and Search Indexes such as Alta Vista. Both had their place. If you wanted to browse through a human edited directory, you had good reason to. People had taken the time to classify and organize the websites using their God given intellect. If you wanted to search, you also had good reason to.

Since the computer was able to search all of the content in a set of knowledge automatically, search indexes could be created using complex algorithms. One of the reasons Google succeeded in the search indexing industry was because they figured that relevant pages would link to each other and the more relevant websites would have higher density of connections. Similar sites around similar sets of knowledge would coalesce using the network effect to create centers of knowledge. Further more, content that is properly tagged and keyworded can heighten the quality of the search because the search engine has the power to correlate keyword usage and the keywords themselves.

What is OpenCalais?

The Calais Web Service:  The Calais web service automatically attaches rich semantic metadata to the content you submit. Using natural language processing, machine learning and other methods, Calais categorizes and links your document with entities (people, places, organizations, etc.), facts (person “x” works for company “y”), and events (person “z” was appointed chairman of company “y” on date “x”). (OpenCalais 2009)

Now that you have a bird’s eye view of how knowledge is stored and sought online, let’s talk about OpenCalais. OpenCalais is a toolkit that can be used by Content Management systems to automatically find the best set of keywords to represent a particular piece of content. Instead of having to pour your blood, toil, sweat, and tears, you can have a machine do it for you. OpenCalais is not for consumers and must be integrated into an existing piece of online content management software, or be integrated into a custom solution.
If you have a 5-10 page website, you probably don’t need to use OpenCalais. If you have a catalog of any kind, be it books, products, article, or news you should look into integrating this tool so that your website becomes easier to search and navigate on your website as well as through external search engines. OpenCalais looks at your content and finds out if there are references to people, cities, companies, industry terms, and a number of other existing knowledge centers.

A test using the OpenCalais Document Viewer

To demonstrate what OpenCalais can extract from your content, I submitted the content of this article above this sentence to get this screenshot. I’m only showing the highlight of one found term. Similarly, the other terms that were found are connected to vast amounts of knowledge already exist intent on the internet. Those knowledge centers have relevant information and hence if your content is relevant, it is given a high content relevancy rating for each word that it finds. Apparently, my article on “Online Knowledge” only gets a rating of 35%. It’s better than nothing. I’ll try again next time. You can try yourself using their Document Viewer. If you want help in implementing this great tool, let us know by contacting us through our website’s Contact Us page.

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.

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.

Limited Mobility . Could you use your web site without a mouse? Without a keyboard? If not, folks with limited mobility may not be able to browse your site. There are some high-tech options out there for those with limited mobility. But not everyone has them.

Low Vision . Low vision is not the same as non-sighted. With low vision, you see, but not well. Put a 10 pixel font with low-contrasting foreground and background colors in your graphics-based navigation, with proper alt tags, and your screen reader would be happy. But someone with low vision wouldn’t.

Color Blindness . We’ve come a long way from 256 web-safe colors. But those millions of colors are not available to everyone. Keys and legends can be frustrating. Imagine looking at a map and not being able to know the difference between a river and a county line. Of all the disabilities, this hits a large number – as many as 8% of all males have some sort of color blindness.

Seizure Disorders . It may sound strange that your site could be seizure-inducing, but it’s true. If your graphics flash like a strobe light, then your monitor is a strobe light. That’s not just annoying, but potentially dangerous.

Learning Disabilities . We may have all heard of ADD and dyslexia, but there are dozens more disabilities that could hinder web-browsing ability. They primarily affect memory and comprehension. Does your web site accommodate those who have memory issues? Is your content structured for maximum comprehension? Or do you require your users to do math. Many sites now use math problems as an “accessible” CAPTCHA . Accessible to screen readers, maybe, but not accessible to someone with dyscalculia .

The numbers are all over the place and never entirely accurate on what percentage of the population have these varying disorders. It’s 1% here, 3% there. But add them all up, and the numbers get pretty big. So when you keep accessibility in mind for your web site, make sure it’s accessible for all.

• WebAIM Low Vision Simulator
• WebAIM Seizure Disorders
• AssistiveWare Technology
• Vischeck Colorblind emulator

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.

ARIA (Accessible Rich Internet Applications) is not a programming language, but a kind of framework/guideline. Developers code their applications using these guidelines and most modern browsers and assistive technologies interpret them.*

You develop an ARIA-friendly application by adding a standard collection of roles, states, and properties to your HTML, JavaScript, and CSS. Assistive technologies understand ARIA markup and can react accordingly. So to create a dynamic tree menu, you make your container div have a role of “tree”, a folder item underneath it have a role of “group”, and each item underneath that have a role of “treeitem”. Here’s an example.

Now, in ARIA, the developer can identify content that changes as a “live region.”  The programmer can give directives on what should happen when this live region is updated. Live regions can be identified with a state of off, polite, assertive, or rude (my new semantic favorite). These parameters tell the assistive technology what to do if the content in the live region changes (with off meaning do nothing, rude meaning stop everything the user is doing and bring them back to this live region). Each assistive technology can cope in different ways. For example, a screen reader may make a “ding” if a live region changes and it is set to “polite”.

With all this great news, it is still important to remember that ARIA is not a replacement for good usability and design. And it doesn’t magically make your applications accessible. If you have dark gray text on a black background, no amount or role-coding will save you from the Accessibility police.

Here are some starter resources for ARIA:

• WAI-ARIA – The working group which gave us ARIA.
• ARIA techniques – From WebAIM
• JuicyStudio - A great blog for information on how to use ARIA.

*Unfortunately, one of those browsers that does not yet support ARIA is a biggie: Internet Explorer does not yet support Aria. But it will with the release if Internet Explorer 8. This does not mean you can’t use ARIA at all. You’ll just have to think of some alternatives for visual items in IE. Back to article

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.

From the mind of CSS deity Eric Meyer comes diagnostic styling. The concept is simple. Create stylesheet that points out, in glaring lime and fuchsia, mistakes in your code and missteps in your content entry.

You can view your site with the stylesheet without wrecking your live site by linking it up as a user-defined stylesheet. You should be fine in Firefox and IE7, but using it in IE6 can be problematic.

The stylesheet points out, among other things, hrefs populated with “#” (popularly used as placeholder links) and unpopulated paragraph tags. For strict coder-types, it knocks out deprecated elements and super-duper nested divs. For the accessibility mavens out there, find missing alt tags and inaccessible data tables. You can also customize the script to find other issues or mistakes that may be common to your site: If you did away with one of your CSS class IDs, you can use this to scan the site and make sure it’s gone everywhere. This is your stylesheet – add or remove items at your will.

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.