Who You Calling A Jesse?

Shortly after I started working in the Higher Education web space (2001) I came across the brilliant post by Jeffrey Zeldman on A List Apart that lead down all sorts of paths towards web standards and accessibility. I wasn’t alone. I think many web folks that were dealing with the internet bubble bursting were inspired by Zeldman’s call to arms to change things and many had the time to explore the possibilities. I did what I could in my position to influence the University of Waterloo web space and in 2004 we had a XHTML/CSS layout that was clean and accessible which was finally let loose on campus in early 2005.

Things changed on campus and I spent more time on usability testing and meeting with the few students that relied on adaptive technology. I wasn’t put off by the fact only two people might notice the enhancements as I knew UW was doing the right thing by fixing things. However, all of the applications students and staff rely upon were not going to be fixed or changed with even the course management system saying it was section 508 compliant but that version was even less usable than the main user interface. A problem that I have observed is that accessibility laws or regulations seem to force people under the covers in the HTML to make things work in screen readers (sometimes) but people ignored how usable the content or the application actually is.

It gets stranger by the day, developers demand unit tests they can meet to make the app accessible but there aren’t any… I don’t think. Laws and guidelines just compound the problem by giving people a false sense of compliance. In the case of learning environments most aren’t even all that usable but golly gee they are 508 compliant. It starts to drain hope.

Blame technology or developers?

A developer most certainly should make browser based apps (HTML/JavaScript/CSS apps) ‘professional’ grade by using semantic HTML, unobtrusive JavaScript, and sensible colour contrasts. That checks off a lot boxes in terms of Search Engine Optimization, re-usable code, dealing with rendering fun, and accessibility. There are different ideas of what it takes to make a web app or page accessible however, and I am not sure a developer should kill a load of time on certain things (that change with the project) like zoomable layouts—especially when browsers are implementing features that make that time wasted.

I am not sure that is inline with that Derek brings up in his post When is the right time for accessibility? as I think some (or a lot) of the things that are generally seen as making HTML as ‘accessible’ really should be the responsibility of a different team of developers (mainly those that make web browsers). I don’t disagree with the strategy of implementing accessibility later based on need and I think Derek’s post offers a bit of an olive branch to developers. You shouldn’t be expected to be all that accessible until you actually know that (a) people will use your product and (b) knowing how people will use your product.

What is my problem?

Honestly I don’t know. Call it a long winter, annoying problems repeating themselves for years, and new experts making the same mistakes.

I started this post sometime after I saw the small torrent of comments about a JavaScript framework which was summed up in Drew’s post The Cost of Accessibility. Drew is on that fence of innovation needs to take into account the reality of the web browser right now and I am not sure I agree.

At the same time I got into a few insane conversations about making the new job system for co-op on campus accessible and IE6 isn’t dead (like we had hoped) for an important 5% of our user base. Our development process makes it insanely difficult to spend time testing, fixing, and tweaking for accessibility (application is hiding behind a VPN and has a few other features that make it hard to access outside of our network). We use jQuery wisely, CSS, and HTML to the browser. AJAX is sprinkled in parts but nothing should depend on it. For a first version that isn’t really ready for user testing it has some good fundamentals but someone pulled the ‘yes but you are missing x’ and I just got deflated.

The problem, in my mind, goes back to the way people think about accessibility. The whole issue is an Art not a Science and certainly not engineering. Engineers have left us with this problem, with HTML, a stateless browser, and a crippled feature set that forces hacks, short cuts, etc. They are doing their part, slowly. Code artists like Derek Featherstone and Drew McLellan help spread the word and lower the barriers through simplified approaches and keeping the dialogue going.

HTML 5 gives me hope even if the Engineers aren’t too quick to drop it in our browsers! I am not really cynical ;)

Interesting conversation today that started off with (edited for dramatic effect):

• me: “I am pretty sure what we are doing is not going to be accessible and is going to cause us grief” (me went on about Ontarians with Disabilities Act, University’s commitment to accessibility, etc)
• softeng1: “What will? AJAX? I am sure it can be made accessible” – goes to google, pulls up an article from Juicy Studio
• softeng2: “What exactly is not following the law?”

At this point I probably got annoying because the problem with accessibility is that it is an art over a science. Laws are vague for good reason—there is no black and white, if there was technology would make the law redundant quickly (thinking PDF being a ‘bad technology’ in Australia). I went into the fact screen readers have a heck of a time when things change and there is no page refresh and how stuff not working, at least a little, without js is a problem.

The conversation went on with the software developers insisting there is a software solution. Which is understandable but that is because I got annoyed with the brush off instead of going into the problem. Making a web application accessible isn’t only about using screen reader, I missed that but I am not sure that would have helped…

After the conversation dragged on for a bit we started talking a similar language although the focus was on fixing it with software and testing. I am all for testing but I certainly don’t want to go back and test it in a year and then fix it. I would much rather consider it now. Making a web application accessible is as much about a philosophy as it is the technical considerations.

This left me thinking, my approach was wrong for how these folks think and their experience. Plus I was annoyed by the number of JavaScript reliant things we have already. My concerns are that even though we are spending a lot of time on user testing and usability analysis, technical accessibility would be sacrificed. Are my fears warranted? Probably given the amount of JavaScript, however if we approach it smartly from start we should be ok—that means now.

I have run into a similar conversation quite a few years ago when the web developers on campus weren’t sure what to think about web accessibility. They were far more open to the problem though, not software engineers (or Computer Scientists) as they can build a fix—so they think. What is missing from their world is the appreciation for how annoying web browsers can be and how people interact with them. With software there is more control over presentation and the user expectations are different.

I will need to think about an approach to ensure that the issue of accessibility is more relevant to them. Taking away their mice as they navigate the app might be a good start ;) Or degrading its performance. Most web developers seem to get the problem now but they have likely spent time reading about in the context of the web. Curious as to how others have approached this situation with those that build software, not web apps.

First I think I need to get a few good nights of sleep. The lack of that lately does not help!

Next week (December 4th) sees two pretty exciting campus conferences happening. The first is WatITis – a one day conference for IT staff at the University of Waterloo. Would you believe there are just over 300 IT staff at Waterloo working in dozens of different departments? This will be the first year I am not presenting (current job’s stuff isn’t presentation ready yet) and I am not sure I will have time to attend… but it is a really good event.

The following day is the Power of IDEAS conference. This one is open to anyone for a really low price (below $100 for off campus folks, free to on campus people) and focusing on inclusive learning strategies, usability, and accessibility. Derek Featherstone did the keynote for the first one in the summer of 2006, this year he returns for the closing keynote. I will be presenting on building usable web applications and will offer a glimpse of what I am doing in the lower level of the TC as well as some reflection on other higher education home pages and other applications I have worked on over the years.

Keep an eye on the Power of IDEAS conference. Lead by the Office for Persons with Disabilities office, it will only grow (this year there are over 90 people from off campus registered, last year we had around 20). I think it is just great that a conference dedicated to promoting accessibility and usability.

My role at work has me looking at a UI for a fairly complex application (known as jobmine) that has three distinct audiences with three distinct reasons for using the web app. The web application is the primary business tool for the co-operative education process at the University of Waterloo. This process sees anywhere from 10-25K people using it at least a couple times every four months. Staff in the CECS department use it for their day-to-day activities.

What is a co-op system? My definition is based on being a student and now an alumni, it is no way the ‘official’ take. Co-operative education is an approach to education that gives students a chance to learn outside of the classroom (and in the case of UW, make some good money) and gain experience in the ‘real world.’ If you are a student you look for and apply to jobs, manage your resume/CV, and find out about interview times and locations, accept and decline job offers. For an employer you post jobs, sort through applications, arrange interviews, and offer jobs. For staff you make sure this all works by supporting both students and employers, generating reports, manage a massive amount of data. Generally speaking.

It would seem easy enough if you walked up to it from a user perspective. You have your role, an idea of what needs to get done, and off you go. The expectations aren’t a whole lot different than say Workopolis or Monster.com.

Post continues, click to read more...

James Edwards (brothercake) has posted an article on Sitepoint entitled AJAX and Screenreaders: When Can it Work? This article pretty much confirms what a lot of people were thinking: screen readers and AJAX don’t mix at the moment. Is that a reason not to use AJAX?

…unless a way can be found to notify screen readers of updated content, AJAX techniques cannot be considered accessible, and should not be used on a production site without a truly equivalent non-script alternative being offered to users up-front.

Is Flash the UI that could be accessible and AJAX is missing? Flex is looking good given its Flex-Ajax that allows you to expose Flex or an empty SWF’s scripting in the browser. I tend to think for the short term Flash based applications might be the better way for some things if done properly.

Flex has a decent list of accessible components to take a look at but even those have some issues – a lot of the ‘widgets’ work though. Take a look through the Flex accessibility pages and decide for yourself. I am not saying I think Flex has anymore actual use than AJAX (do we really need that much dynamic stuff?) but if you are trying to build a site and an experience, it might be better than AJAX with regards to accessibility for the short term.

I will have to wait until there is an OS X version of a Flex builder to find out for myself :(

update: Read Joe Clark’s take on accessible AJAX from his Ice Web 2006 presentation. Also check out his usability test results.

It could be the fact that I just hate writing reports but pulling together the data from the testing we did in the fall isn’t as fun as I thought it would be. For internal audiences we ended up with 24 participants, 12 students and 12 faculty and staff. What stands out right now is how bizarre all you people are ;)

External audiences don’t you worry. You will be tested, just wait. Once this report is done the focus will be on devising an effective way to automate this testing and allow you to do it from home for a nice little reward.

You could be asking why, in April, am I just getting at the data now and I should have a good excuse. But I don’t. The motivation now is getting this report done so all the time I will be spending on the 50th Anniversary won’t mean this report is never finished. Expect to see a draft report the end of next week.

Malicious spiders can be the reason for spam emails. Any email address given out in the standard user@domain.com is vulnerable. One website where I’ve addressed this issue is the Newsrelease website. This page is especially vulnerable since email addresses of different contacts are published here.

When spam-proofing emails, ideally the following should be satisfied:

• the email should not be easily retreivable from the source HTML
• the email should be accessible visually
• the email should be accessible contextually, ie clickable
• the technology used in the process should not completely exclude browsers which don’t support the technology or have it disabled, ie offer these visitors an alternative way to read/access the email address

I used the method of spam-proofing the emails offerred in the comments section here. The idea is simpe:

1. Use javascript to hide the email address inside the source by concatenating parts of the email addresses and then outputting it to the browser using the document.write function
2. Account for the browsers which don’t support javascript or have it disabled by displaying a phonetic email address

You can see it in action here. This is however a static page and I did not have any trouble with it. You can see that the source does not have the email address in the form user@domain.com. I used two different methods for the two emails so that it can serve as an example of how to do the same thing in two different ways using the php script.

More troublesome were the actual news articles which are dynamically generated such as this one and this one. Because of the way news.php works, I also had to change the way the function that generates the javascript snippet to make it work with changing emails in a huge text block. The actual code can be easily examined in news/news.php, news/reach.php and the function itself in the php include: news/inc/printEmail.php .

Worth a mention outside of just listing links since Derek Featherstone is a UW Alumni. Derek has a post on his blog that clarifies some points in his presentation this past week at the @media 2005 conference. JavaScript and Accessibility is a good read even if you didn’t go to the conference. After SXSW 2005 and doing a guest instructor gig at the Knowbility’s Accessibility University, he now is offering classes in the UK.

Derek was featured in the Alumni e-newsletter in Feb 2004 – check it out if you want to know who this guy is ;)

If you have a few favorite design blogs I would bet you have heard of South by Southwest Festivals. It is one heck of a conference that brings together some of the more interesting minds in web design, development, etc. One panel had a UW Alumni sitting on it – Accessibility: Can’t we all just get along – Derek Featherstone. Upon reading Joe Clark’s coverage of the panel I just had to share. If you go to his home page you will get a decent idea of the accessibility topics discussed at the conference.

For photos, And all that Malarkey features some links to Flickr galleries. If you are wondering, Derek has a nice photo on the couch with Andy Budd who also has some great coverage of the event. If you go through the coverage of SXSW (which there is a lot of considering all the bloggers) you see some scary faces ;)

Notes from folks that were there:

• Dave Shea
• Wow
• Mike Davidson
• Accessify.com
• Design Eye for the Idea Guy
• Stopdesign – capturing SXSW