Maybe a better title for this post would be “Why Accessibility in Rails is Currently a Non-issue”. Last night was the core team panel discussion at RailsConf and there was a question about what the core team was doing to increase accessibility in Rails. Someone in the core team answered rather vaguely (or maybe I misunderstood the answer) how they had used Rails in a project that required high accessibility. My view is that for the Rails framework accessibility is currently a non-issue....

Here is a cool thing which I didn’t hear of until today. Amazon provides a service where you can upload a machine image (think VMWare), deploy it to as many instances you need and pay Amazon 10 cents for every hour you use it and 20 cents for each Gb data transfer. This will allow you to instantly scale an application if your demand temporarily increases. With the risk of sounding like an Amazon marketing droid here are some highlights of what you get for those 10 cents:...

Stefan Kaes is at it again with some interesting code to optimize Rails template helper methods. I have always wondered about some of the helper methods e.g. “< %= end_form_tag %>”. Why would you need that when it is easier to write “”? Anyway, Stefan has shown that there is a cost to using many of the helper methods and that optimizing them may give you a performance increase. Methods involving routes are the worst performers....

There have been a number of issues with Rails popping up yesterday and today. First there was the announcement that Rails 1.1.4 had a security issue. Discussions emerged on why the core team did not disclose the details of the vulnerability. Evan Weaver had a quick look at the diff between 1.1.4 and 1.1.5 and described the problem: It looks like, for example, that if your Rails installation is in /www/rails/, passing a string such as /www/rails/....

I received an interesting email from the organizers of the european Rails conference yesterday. My talk proposal “Building Accessible Web Sites on Rails” was accepted and I will be giving a talk with the following description: As an agile Rails developer you are expected to know a bit of everything in the MVC paradigm. The V (View) is typically considered the least attractive area as it is “only HTML” and is best taken care of “by someone else”....

Recently Google Labs released Google Accessible Search - Accessible Web Search for the Visually Challenged. Running the search page (http://labs.google.com/accessible/) through RAAKT (using the online version) yields three errors and the search result page is using tables for layout. Maybe I am missing something here, but how hard can it be for Google to make sure their search page is using best practices and avoid basic accessibility pitfalls?

When I studied social antropology a couple of years ago I never thought that it would influence my future programming endeavours. At that time we looked at theories on how things in our surroundings influence thought processes. One theory is called the Sapir-Whorf hypothesis. It states: “…there is a systematic relationship between the grammatical categories of the language a person speaks and how that person both understands the world and behaves in it....

A couple of days ago I released RAAKT - The Ruby Accessibility Analysis Kit gem (I know, it really needs a better name). RAAKT is a gem that can be used independently of Rails and my plan was to make a Rails plugin that would add a custom assert method that did the check. It turns out that it only takes five lines of code so there is no need for a plugin....

At RailsConf in Chicago I realized that it would be a good idea to port PAAKT to Ruby and make sure it can be used for automatic accessibility tests in the Rails testing framework. Work has begun and I hope to release it at the end of this summer if all goes well. The project is registered at Rubyforge. Now, all I need is a good name. Maybe RAAKT? Suggestions are welcome....

In an article over at Dancingmango Marc McNeill writes about how new web development frameworks such as Ruby on Rails will have an impact on usability testing practices (“What’s the point of usability testing”). The only real reason to test a mockup instead of a real application is of course that it used to be more expensive and time consuming to create an application. With Rails there is no such barrier anymore and usability tests can (and should) be using the real application instead....