It is quite fascinating to me that the newest article on dev.opera.com entitled ‘Stop using Ajax!’ is such a big thing right now. Tweets, shared bookmarks and Google Reader items are pouring in and people seem to consider it an amazingly daring article.

Here’s the truth: James is right. He also was right when he more or less gave the same information as a talk at Highland Fling last year following my presentation on progressive enhancement and JavaScript.

However, there is nothing shocking or daring or new about this. All he says is:

• Don’t use any technology for the sake of using it
• Consider the users you want to reach before using a technology that may not be appropriate
• Make sure your solution is usable and accessible
• Build your solution on stuff that works, then enhance it.

This is what I consider to be a normal practice when developing any software or web solution.

However, the real question is now why we are at this state – how come that we see this information as daring, shocking or controversial, and how come a lot of comments are still “I don’t care about accessibility because it is not needed for my users”? How come the assumptions and plain accessibility lies are prevailing while the good stuff remains unheard of?

Well, the truth is that we have been preaching far too long to the choir. I’ve been in the web accessibility and standards preaching community for a long time and whenever I asked what about enterprise development and CMS I was told that it is not worth fighting that fight as “We will never reach them”. Well, this is where the money and a lot of jobs are and it is a fact that both accessibility and standards activists in a lot of instances don’t even know the issues that keep the stakeholders in these areas busy. My Digital Web Article ‘10 reasons why clients don’t care about accessibility’ and the follow-up Seven Accessibility Mistakes Part One and Part 2 listed these issues and the wrong ways of how we try to tackle them 3 years ago. My talk at the AbilityNet conference last week Fencing-in the habitat also mentioned this attitude and problems.

Here’s where I am now: I am bored and tired of people fighting the good fight by blaming each other’s mistakes or pointing out problems on systems that are within reach. When people ask for accessibility or Ajax usability advice you’ll get a lot of bashing and “go validate then come back” answers but not much information that can be used immediately or even questions that ask what lead to the state of the product. You’d be surprised what you can find out by asking this simple question.

We have to understand that large systems, frameworks and companies do still run the show, even when we think that bloggers, books on webdesign and mashups push the envelope. They do, but so far they are a minor discomfort for companies that sell Ajax and other out-of-the-box solutions that are inaccessible and to larger parts unusable for humans. When was the last time you used a clever expense or time tracking system in companies that are not a startup or a small web agency? When I was at the AjaxWorld conference in NYC earlier this year I heard a lot about security, ease of deployment and scalability but only a little bit about accessibility (the Dojo talk and the YUI talk, actually). People are a lot more concerned about the cost of software and the speed of release than about the quality or maintainability. It is cheaper to buy a new system every few years than to build one that is properly tested and works for all users. Does your company still have systems or third party solutions that only work on IE/Windows? I am sure there is at least one, ask the HR or finance department.

It doesn’t help to coin another term and call an accessible and usable Ajax solution Hijax, either. As much as I like the idea of it I have to agree with James’ comment – we don’t need another word, we need a reason for people to not just use things out of the box without thinking about them or – even better – offer help to the companies that build the solutions on assumptions in the first place. When I ranted about a system by a large corporation some weeks ago on twitter their marketing manager for EMEA starting following me and I am starting some talks with them.

I have heard numerous times that my ideas about progressive enhancement and accessibility are just a “passing fad” and “that in the real software market you don’t have time for that”. Challenging this attitude is what makes a difference – by proving that by using the technologies we are given in a predictable and secure way does save you time and money. However, there are not many case studies on that…

I cannot change the world when I don’t know what obstacles people have to remove to do the right thing. Deep down every developer wants to do things right, in a clean and maintainable fashion and be proud of what they’ve done. Bad products happen because of rushed projects, bad management and developers getting so frustrated that they are OK with releasing sub-par just to get the money or finally get allocated to a different project.

This is the battle we need to fight – where do these problems come from? Not what technology to avoid. You can use any technology in a good way, you just need to be able to sell it past the hype and the assumption that software is developed as fast as it takes to write a cool press release about it.

This is my talk given at AbilityNet’s Accessbility 2.0 conference in London today. In it I am talking about how we try to sell accessibility and the mistakes we make while we do so.

After helping to fix the Yahoo search result pages with the correct language attributes to make them accessible for screen reader users I was wondering how this could be done with user generated content. The easiest option of course would be to ask the user to provide the right language in the profile, but if you are bilingual like me you actually write in different languages. The other option would be to offer me as the user to pick the language when I type it, which is annoying.

I then stumbled across Google’s Ajax Translation API and thought it should be very easy to marry it with for example the JSON output of the twitter API to add the correct lang attributes on the fly.

Alas, this was not as easy as I thought. On the surface it is very easy to use Google’s API to tell me what language a certain text is likely to be:

var text = “¿Dónde está el baño?”;

google.language.detect(text, function(result) {

if (!result.error) {

var language = ‘unknown’;

for (l in google.language.Languages) {

if (google.language.Languages[l]  result.language) {

language = l;

break;

}

	
}

var container = document.getElementById("detection");

container.innerHTML = text + " is: " + language + "";

}
	
});

However, if you want to use this in a loop you are out of luck. The google.language.detect method fires off an internal XHR call and the result set only gives you an error code, the confidence level, a isReliable boolean and the language code. This is a lot but there is no way to tell the function that gets the results which text was analyzed. It would be great if the API repeated the text or at least allowed you to set a unique ID for the current XHR request.

As Ajax requests return in random order, there is no way of telling which result works for which text, so I was stuck.

Enter Firebug. Analyzing the requests going through I realized there is a REST URL being called by the internal methods of google.language. In the case of translation this is:

http://www.google.com/uds/GlangDetect?callback={CALLBACK_METHOD}&context={NUMBER}&q={URL_ENCODED_TEXT}&key=notsupplied&v=1.0

You can use the number and an own callback method to create SCRIPT nodes in the document getting these results back. The return call is:

CALLBACK_METHOD(‘NUMBER’,{“language” : “es”,”isReliable” : true,”confidence” : 0.24716422},200,null,200)

However, as I am already using PHP to pull information from another service, I ended up using curl for the whole proof of concept to make twitter speak in natural language:

	

// curl the twitter feed

$url = ‘http://twitter.com/statuses/public_timeline.rss’;

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, $url);

curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

$twitterdata = curl_exec($ch);

curl_close($ch);

// get all the descriptions

preg_match_all(“/([^<]+)/msi”,    $twitterdata,$descs);

// skip the main feed description

foreach($descs[1] as $key=>$d){

if($key=0){

continue;

}
	
// assemble REST call and curl the result

$url = ‘http://www.google.com/uds/GlangDetect?callback=’ .

‘feedresult&context=’ . $key . ‘&q=’ . urlencode($d) .

‘&key=notsupplied&v=1.0’;

$ch = curl_init();

curl_setopt($ch, CURLOPT_URL, $url);

curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

$langcode = curl_exec($ch);

curl_close($ch);

// get the language

preg_match(“/”language”:”([^”]+)”/”,$langcode,$res);

// write out the list item

echo ‘
‘.$d.’
‘;

}

	
?>


	

Check out the result: Public twitter feed with natural language support

I will do some pure JavaScript solutions soon, too. This could be a great chance to make UGC a lot more accessible.

Thanks to Mark Thomas and Tim Huegdon for bouncing off ideas about how to work around the XHR issue.

I just finished my sesssion at BarCamp Brighton about making online video more accessible by allowing for sensible, time-based commenting which could become a poor man’s captioning in a second stage. In general it is just showing off my hack of the YouTube player using their API.

The lovely people at Paris Web just released all the videos of the 2007 conference on dailymotion. My talk is the only English one and deals with the topic of how following web standards helps your team to be more successful:

Slides:

The other videos are pretty interesting insofar as they cover accessibility and internationalization matters from a technical, social and legislative angle. My favourite was the IBM server that automatically transcribes videos by running voice recognition over the audio stream.