Automated accessibility tests in Ruby on Rails

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. So let’s see how you can integrate accessibility checks into your current Rails application.

Install the RAAKT gem

This is a simple step. If you have installed rubygems all you need to do is gem install raakt. This will install the latest version of RAAKT (currently 0.3).

Add the custom assertion

Open the file test_helper.rb in the test folder in your Rails application. Add the following method to the class Test::Unit::TestCase:

def assert_basic_accessibility
rt =
result = rt.all
assert result.length == 0, result.collect { |msg| “n” + msg.text + “n” }

Make sure the raakt module is required by adding “require ‘raakt'” in the top of the file. No we can use assert_basic_accessibility in our functional tests (where view output is available).

Test your views

By adding assert_basic_accessibility to all functional tests that render a complete HTML document you can make sure you don’t create any of the fundamental accessibility errors that plague many applications.

Currently the RAAKT module will do the following tests on your markup:

  1. check_document_structure: Verify that headings are correctly structured (h1 -> h2 etc)
  2. check_tables: Verify that all tables have headers (th elements).
  3. check_for_formatting_elements: Make sure no font, b, i, blink or marquee elements have been used.
  4. check_has_heading: Verify that the document has at least one h1 heading.
  5. check_form: Verifies that all form input fields (except hidden fields) have a corresponding label element.
  6. check_link_text: Verifies that all link elements are unambiguous (two links with different targets should not have the same link text. Yes, that means all your “Edit” links). Use the title attribute to separate links.
  7. check_title: Verify that a non-empty title element is available.
  8. check_frames: If frames are used, verify that each frame has a descriptive title attribute.
  9. check_images: Verify that all images have an alt attribute.
  10. check_refresh: Make sure that no client-side meta refresh is present.
  11. check_for_nested_tables: Verify that no nested tables are present.
  12. check_for_language_info: Make sure the html element has a lang attribute indicating what language your document is in.

Sometime soon I will create documentation on each of the errors that you may recieve and what you can do to correct them. Suggestions and feedback are always welcome on the RAAKT project page.

Porting the Python Accessibility Analysis Kit to Ruby

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.

Rapid prototyping makes usability testing easier

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. It is likely that this will lead to a better understanding of how users behave in e.g. a task based system.

Coupled with the extremely short feedback cycle realized by using dynamically typed languages such as Ruby, Rails may have a deeper impact on software development practices than I previously thought.

Two additional problems for Rails: eat SOAP and connect to MSSQL

At the opening keynote here at RailsConf in Chicago Dave Thomas (of Pragmatic Programmer fame) presented three problems for the Rails community to solve. His idea was that these would help Rails become more popular in organizations. I would like to add two more: a SOAP library and an improved MSSQL-server driver.

Judging from the amount of Microsoft-bashing going on here I would venture to guess that these aren’t on the top of the list for most Rails developers. However, I believe they would make it a lot easier to implement Rails applications in the corporate world and increase the Rails adoption rate.

  1. A SOAP library that at least can consume other SOAP services (including bastardized interfaces returning .net datasets) would ease the adoption of Rails in internal CRUD applications. Rails isn’t alone in the world and while it is easy to say that other people’s SOAP interfaces are crap the reality is that they are there and there is little you can do about it. Changing existing web service interfaces is a tricky task as it may invlove a lot of other applications.
  2. The MSSQL driver is necessary to remove another obstacle in the decision process of selecting Rails. Most companies standardize on their production server platforms. This means they will typically have a cluster with a specific database engine somewhere which other applications share. Brian Hogan has done some excellent work in showing how Rails can be deployed in a Windows Server environment. From what I hear the current incarnation of the MSSQL-server driver for Ruby isn’t up to par with the rest of the pack.

I believe that being able to deploy Rails in your existing Microsoft environment using MSSQL-server would make it easier for managers to give a go ahead for Rails projects.

Improving Session Performance in Rails

Ruby on Rails includes some options for handling sessions (see overview by Stefan Kaes (PDF)). Unfortunately the default ActiveRecord session handler is relatively slow which may have a big impact on your application (sessions tend to accumulate quickly). Fortunately for all of us, Stefan has created an alternative MySQL session handler whith hard coded SQL statements. His version is much quicker.

If your application uses the standard session handler there is really no reason not to implement Stefan’s solution. However, to make it work with the default session table created by Rails 1.1.2 you have to do some minor modifications (at least in version 0.2):

  1. Download and install Stefan’s session handler files into your application’s lib directory.
  2. If you haven’t created the session table for your application, run “rake create_sessions_table”. The will add a new migration file in the db/migrate folder.
  3. Update the migration file to make sure the created_at column is included. You can append it by adding “t.column :created_at, :datetime”.
  4. Open lib/sql_session_store.rb and modify the SQL statements containing a reference to the sessid column. In Rails 1.1.2 this should be called “session_id”.
  5. Update your config/environment.rb by appending the following lines at the end of the file:
require 'sql_session_store'
require 'mysql_session'
ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS.update(:database_manager => SQLSessionStore)
SQLSessionStore.session_class = MysqlSession

Restart your web server and you have improved session performance a lot. For more details see:

Using Selenium for functional testing in Ruby on Rails

Update: There is now a nice demo of how selenium on rails works.

Jonas Bengtsson has created an initial version of a Selenium plugin for RoR.

I have been using Selenium for a while now and this certainly looks promising. There are some minor details in this release that need to be fixed such as coloring of completed test actions and test cases (mine are not highlighted). A nice addition would be if RadRails supported code completion of selenium actions.

Boosting RadRails performance by switching JVM

If you are using RadRails when developing your Ruby in Rails applications you will be interested in increasing performance. Christian Pelczarski has an interesting instruction on how you can boost performance of the Eclipse/RadRails combo by switching to the latest Sun JVM (version 6.0) for Windows XP.

You can usually get some extra performance by setting the initial heap size and the max heapsize to the same, thus bypassing the dynamic growing/shrinking of the heap.

Setting up the Interactive Ruby Shell (IRB) for non-english keyboards on Windows XP

For some reason it is difficult to use the [] and {} characters when using IRB with a non-english keyboard on Windows XP. To get it working together with tab completion:

  1. Create a new environment variable called “HOME” and set it to your user home folder (e.g. C:\Documents and Settings\peterk).
  2. Create a text dcument called “.inputrc” in your user home folder with the following content:
    "M-[": "["
    "M-]": "]"
    "M-{": "{"
    "M-}": "}"
    "M-\": "\"
    "M-|": "|"
    "M-@": "@"
    "M-~": "~" 
  3. Make sure irb.bat is using the –readline option (irb.bat is located in the bin folder of your ruby installation).

That’s it!