WCAG 2.0 applies broadly to more advanced technologies; is easier to use and understand; and is more precisely testable with automated testing and human evaluation.

W3C WAI recommends using WCAG 2.0, instead of WCAG 1.0.

Most Web sites that conform to WCAG 1.0 will not require significant changes in order to conform to WCAG 2.0, and some may not need any changes. To help you move to WCAG 2.0, WAI is developing:

• How WCAG 2.0 Differs from WCAG 1.0
• Comparison of WCAG 1.0 Checkpoints to WCAG 2.0
• How to Update Your Web Site from WCAG 1.0 to WCAG 2.0

WCAG 2.0 has 12 guidelines that are organized under 4 principles: perceivable, operable, understandable, and robust. For each guideline, there are testable success criteria, which are at three levels: A, AA, and AAA.

For a short summary of the WCAG 2.0 guidelines, see WCAG 2.0 at a Glance.

The best place to start working with WCAG 2.0 is the How to Meet WCAG 2.0 (Quick Reference).

Remember we are here to help so any questions about your site being accessible let us know and we can give you a complete evaluation.

I was one of the applicants and wrote my post on Tracking Flash Interaction with Google Analytics. The goal was to not only give the readers an enjoyable article but also real tools that can be used on their site for free and back that up with an actual example.

So we only have one week to vote, below I have the link to all the guest posts and the link to vote. All the applicants did a great job! I encourage everyone to read all the articles and vote for who you think should be the next .eduGuru blogger.

Read All Guest Posts

Vote For Your Favorite

Voting closes Midnight Saturday November 29th.

If you are not familiar with microformats the goal is to use plain HTML and embed through classes and Semantic HTML information about the content. Similar to XML to describe content but in plain of HTML so an additional document is not necessary. Recently Yahoo released Search Monkey which takes advantage of microformats to mesh search results with the information on the result pages.

Support for hCalendar is on both the event listing page and the individual event pages. Below are some screen shots of the pages and what can be pulled from them.

As of right now we don’t have any plans to implement a Search Monkey app just yet but this is the first step for us or the community to pull from these events. Especially since the Academic Calendar is now in the events calendar.

This is just a small change to the calendar but it shows our contuned support and drive to support web standards and initiatives.

I created a screencast to show how we in the Web Communications department of Wayne State University create forms quickly, consistently and accessible using an open source framework I created and that we maintain. The framework is PHPSimpl and is hosted on Google Code, it is not meant to be a full blown MVC framework but more or less a helper for common tasks.

This is the first screencast I have ever created so bear with me as I adjust to talking to a computer instead of a room full of people. Also ignore any technical issues which I am still trying to work through. I created it with just a Mac Book Pro, Snapz Pro and the internal mic, so the sound might not be the best.

The video is best viewed at full screen to see the detail in the text. I am playing with the flash video encoder options to find the optimal compression for quality and size. If anyone has any suggestions on the settings or screencast recorder feel free to comment.

In case you are wondering the form is being created on an Apache server running PHP5 and MySQL.

Hope you enjoy it and it helps you out.

The Solution

The solution is pretty simple, but not easily found online so I wrote my own. Twitter provides you with links to two JavaScript files within their auto-generated code. The first included javascript file provides you with two functions. One is the callback function that is used to display the json feed using HTML. The second function is used to convert the time stamp to relative time to keep with Twitter look. Rather than continuing to use the include from twitter.com I localized the two functions so I could edit the callback function and get some markup around those links.

My changes are fairly simplistic and make use of regular expressions to replace obvious plain text links with a marked up version of the links so the end users will be able to click the links.

The code to replace plain text URLs with their marked up version:

var tweet = "Some tweek with a link to a site: http://wcs.wayne.edu/";
var pattern = /(HTTP:\/\/|HTTPS:\/\/)([a-zA-Z0-9.\/&?_=!*,\(\)+-]+)/i;
var replace = "<a href=\"$1$2\">$1$2</a>";
tweet = tweet.replace(pattern , replace);

Now my regular expression skills are far from great, so it’s likely this can be optimized. It’s also possible I forgot some URL safe characters within the pattern. This code basically searches the tweet for anything that looks like http://i-am-a.link/cool/link.ext?okay=yes&fine or whatever the link might look like. I think it could be expanded to search for links that do not include the http:// as well, but I didn’t have a need to do that at this time. Here is the full modified twitter JavaScript code incase you want it.

The result is tweets with working links on http://wayne.edu/current/.

The problem was in the logout

When logged in we wanted to be sure that the user was actually the same person who originally logged in. This level of authentication guarantees the user already has access to the account with the given accessid. However, since we can’t guarantee that a user will properly log out and we can’t make sessions expire too quickly, we had to figure out a way to log the user out even if they just closed the window.

And so I found the DOM event “beforeunload”

Also known as onbeforeunload and mistakenly thought to be IE only; when attached to the window, the beforeunload event is triggered when the page is unloaded. This, however, includes a link being clicked, a form being submitted, and any other event that will cause the page to go away, including closing the browser window. Without further ado, here’s some code (using some jQuery to make things simple):

First, we bind the startup routine to the load event on window:

$(window).bind('load', function(e){
  close_window = true;
  logged_out = false;
  $("a").bind('click', function(e){
    if(!$(this).hasClass('clickable'))
      close_window = false;
    });
  $("form").bind('submit', function(e){
    close_window = false;
  });
  if (window.addEventListener) {
    window.addEventListener('beforeunload', message, false);
  } else {
    window.attachEvent('onbeforeunload', message);
  }
});

The load routine binds submit and click events to anchor tags and forms so we can ignore those exit cases. Then the beforeunload event is attached to the window in 2 different ways to account for the differences in the big 3 browsers.

Here is the message function triggered by the beforeunload event:

function message(ev) {
  if(close_window){
    if (ev.stopPropagation) {
      ev.stopPropagation();
    } else {
      ev.cancelBubble = true;
    }
    if (ev.preventDefault) {
      logout();
    } else {
      logout();
      ev.returnValue = "Leaving?";
    }
  }
}

And finally the logout function which makes an ajax call to a php script that cleans up any sessions, database info, and cookies:

function logout(){
  if(!logged_out){
    $.ajax({
      type: "GET",
      url: '/chat/inc/logout_connector.php',
      data: "logout=true",
      async: false,
      cache: false,
      success: function(msg){
        console.log("Ajax Repsonse: "+msg);
        logged_out = true;
      }
    });
  }
}

Here’s a quick summary of what is going on, if you need it

When the page is loaded, the close_window variable is set to true. The message method requires the close_window flag to be true, otherwise its routine isn’t run. We’re binding the submit event and click events to forms and anchors respectively then setting close_window to false when those events are triggered. This way the beforeunload event’s code will be skipped when the user leaves the page with those events. When the window is closed, the beforeunload code is run and makes an ajax call to a php script that will clean up the session, cookies, database, etc to assure a clean logout.

This code is currently supported by Firefox 2, IE 6, IE 7, and Safari 3. Opera is the only browser I tested that doesn’t support it.

It’s possible that a jQuery plugin is in the works to do this more easily in the future. If I get the chance to write it, and get it done and working, I’ll make another post about it then.

Last week we sent out one of these emails, it was purely information regarding litter and cigarette butts on campus. Since there was no immediate action from the user it was difficult for us to track how effective the email was. So instead we measured how many users actually opened the email and viewed the images.

The reason for gathering these stats was mainly to advocate or deter from using HTML emails in the future. Most students on campus read their campus mail using the online interface which has a scary warning about viewing HTML images and we wanted to know how many students would get past the warning. Students also have the option to forward their email to another address, we were also interested to see where most students were forwarding their mail for better HTML email support.

What we did was setup mod_rewrite and a PHP script to upon loading a URL record the filename, timestamp, referrer and user agent. Then return back the image requested.

.htaccess

RewriteEngine On
RewriteRule ^([a-zA-Z0-9]+).gif$ /email/index.php?image=$1.gif [L]

Example URL of image:

http://wayne.edu/email/header.gif

We then would pull out the records from the database and created the same log format as a web server, run it through a web log statistics program to get the results. This is what we came up with.

Total Sent: ~45,000 users
Total Viewed Images: ~8,300

Visitors by Day:

Hours of the Day:

Referring Sites:

Conclusion:
Most people who received the email did not open the image, only 18% viewed the images. Of those 18% only 45% opened the email in the webmail interface or in a desktop email client. The top three most popular forwarding addresses are Gmail, AOL and Comcast. And the most popular reading time is between 9-11 am and 9-10 pm. Although these statistics are only from 18% of the emails recipients, it goes to show nothing beats plain old text when you need to get important information across via email. Images should only be used for fluff and should not contain any necessary information.

Basically it comes down to IE rendering pages in three modes, the “old mode”, the IE7 half standards mode and IE8 full standards mode. It makes sense to be nice to the web developers who refuse to keep up with their profession, their pages will work forever in future version’s of IE, and be nice to the leading edge developers who painfully hack their way into IE.

As a web developer myself at first I did not have an opinion on the topic but the more I read the more scared I get. This is going to introduce yet ANOTHER variable into the development world. Making developers working on new projects forced to keep up with these three modes and possibly in three years still be working in the “old mode” when they could have been in full standards mode two years ago and help out the end user. Instead it is advocating laziness (ignorance) and old code on the web.

The web is an always transforming place, the landscape has changed from a page-to-page static world to a fully asynchronized ajax environment. These three modes will just slow down the advancements on the web and ultimately make the end user suffer. The graph included is wayne.edu’s IE usage IE7 has taken over IE6’s lead and 7’s growth continues to climb, browsers come and go and developers know this. Soon IE7 will be gone and IE8 will have the largest percent of Microsofts browser share.

Not to mention if no other browsers pick up the idea (I really hope they don’t), IE will yet again become the corporate browser of its predecessors and the “lock in” continues. IE’s goal should be to unify the web and if some sites get broken in the mean time so be it, if enough people like the features (forced update via windows update) and end up using IE8 the non-compliant companies will get on board the standards wagon and won’t look back, their business will depend on it.

My stance is firm, the meta rendering mode is a negative not only for the web development community but the web users as a whole. Breaking the already broken end of the web may not be a bad thing in the overall scheme, just imagine in two years or so when they eventually deprecate the “old mode” rendering engine, it’ll be a much tougher fight than if they never implemented it in the first place.

Update: 01/24/2008 6:30 am EST:

After reading an article by John Resig and the HTML 5 DOCTYPE my fears of this meta switch have eased.  It turns out IE will only use the meta tag for doctypes which are already established and widely used. HTML5 and beyond will not need the switch to render in fully standard mode.  And IE8 will support DOCTYPE switching for all new DOCTYPES.

This changes the whole situation, it awards the developers who code to standards with  an actual useful browser and lets the lazy developers keep their routine.

Current code in footers:

<address class="vcard" id="wsu_copyright">
  <a href="http://wayne.edu/" class="url fn org">Wayne State University</a>
  <span class="adr">
    <span class="locality">Detroit</span>,
    <span class="region">MI</span>
    <span class="postal-code">48202</span>
    <span class="country-name">United States</span>
  </span>
  © 2007
</address>

Microformats are important to us as a university for a few reasons. First they are the right thing to do, since IE hates XML its difficult to describe the content on web pages. POSH helps but it only goes so far, the relationships and descriptions of the items being represented are missing. Microformats jump right in, they offer a way to describe content on a page while still being standard compliant.

Secondly as a higher ed institution we are here to bring knowledge to everyone and publish our research. Microformats help with people and services discovering and sifting through all the information we provide.

Our microformat initiative starts with these vcard footers, the events calendar is next and then profiles. Eventually we hope to use all microformats where necessary.

We choose twitter mainly because of its simplicity. The idea of having a full blown facebook application with no street credit seemed unnerving to us. Sticking to short titles and links gives us the ability to talk about anything Wayne State and not be locked into a certain user action or have to maintain a code base that maybe 10 people interact with.

Items will be posting as they come up, we are not setting a schedule or pattern. We don’t have any followers at the moment but we have not posted its existence other than here. We hope it will become a tool for people interested in the university can use to keep up with while keeping up with their friends. We will also be posting deadlines and important date as they approach and occur.

Follow Us
http://twitter.com/waynestate