Accessible Rails Apps – Rails Links, REST and JavaScript Hidden Forms

Posted by Brian in Accessibility, Rails, Usability (July 1st, 2009)

This is the first in a series of articles on developing accessible Rails applications. Accessibility is really important to me as I spend a lot of time working on web sites and applications that need to adhere to Section 508 guidelines. Making web sites accessible is also the Right Thing To Do.

JavaScript and Accessibility

When developing Rails applications, I try really hard to develop the entire application without using JavaScript, since a lot of users who rely on screen reading software can experience problems with AJAX, so these people tend to disable scripting. Using a screen reader is a lot like looking at a web page through a paper towel tube. You can’t see the whole thing at once, and it’s not likely that you are going to see something changing on the screen, and I’ve never come across screen reading software that can really let you know when a section of the page has been replaced. It might tell me that the content has changed, but I have to make it read the whole page back to me again and figure out what happened. Popup advertisements add to the problem, so people tend to just turn of the JavaScript completely.

Accessibility doesn’t just mean the users with disabilities, though. It can also mean those BlackBerry users who have horrible JavaScript support. So, what we’re really talking about is the age-old idea of “progressive enhancement.” Make a low-tech version work first, then spice it up.

Rails and REST

When you develop Rails applications and you’re working to keep your applications adhering to a RESTful design, certain URLS can only be accessed by certain methods. For example, to delete a record, you’re supposed to send a DELETE request to the destroy action of the controller.

Web browsers can only do GET and POST requests. GET requests are only supposed to read data, and POST requests are intended to change data. You POST to create something. Rails uses hidden form fields to emulate the DELETE and PUT methods.

However, Rails allows you to build links that can do other types of requests, like the DELETE request that’s planted in the default scaffolding. Honestly this is one of the single biggest mistakes the Rails core team has ever made. Here’s why:

This code:

  <%=link_to "Delete", project_path(@project), :method => :delete %>

actually produces a hidden HTML form. When you click this link, it actually submits the hidden form. This requires JavaScript to run and also mixes behavior with HTML markup. It’s a truly ugly situation that really should never be used.

A simple solution

The simple solution is to use the button_to helper instead. It generates the same form, but requires no JavaScript to activate it.

  <%=button_to "Delete", project_path(@project), :method => :delete %>

But I don’t want a button!

You don’t have to have one. As Tore Darell points out on his blog, the appropriate way to handle this is to do the opposite of what Rails was doing. You build the form yourself using button_to, but use unobtrusive JavaScript to replace the form with a link, by simply hiding the form, adding an observer to the newly created link which submits the form.

Add this to your application.js file to replace all of your button_to instances.

document.observe('dom:loaded', function(){
      var link = new Element('a', {href:'#', 'class':'button-to'});
      link.observe('click', function(e){

Tore got it right, and the Rails team got it wrong. This solution is great because

  • It’s accessible. With JS disabled, the buttons will work and perform the appropriate actions.
  • It’s clean. The JS is unobtrusive. It’s not intermixed with your code, and it doesn’t use DOM Level 0 “onclick” which, in some instances, is considered deprecated or invalid markup.
  • It makes it look like a link without the need to resort to crazy CSS antics.
  • A single fix replaces all occurrances. You’re not generating duplicate JavaScript code all over your views like you would with link_to :method => :delete.

Replacing a single instance

You can replace button_to instances that contain a specific class if you simply wrap the JavaScript code in a simple if... block:

   <%=button_to "Dismiss", user_message_dismissals(:message_url =>, :class=>"dismissible" %>
    if(form.descendants().any(function(element){ return element.hasClassName("dismissible")})){
         var link = new Element('a', {href:'#', 'class':'button-to'});

And I’m sure there are better ways to do that, too.

That’s it for now. I welcome your comments and suggestions on this topic and others.

2 Responses to ' Accessible Rails Apps – Rails Links, REST and JavaScript Hidden Forms '

Subscribe to comments with RSS

  1. on November 20th, 2009 at 11:36 am

    Also a rails fan. And think there is indeed an alternative solution to the ‘javascript needed’ problem I bumped into this as well way back when playing with rails for the first time here

    Not sure if it still applies basically you add an extra href option to the link tag:
    { :action => :delete_from_cart, :id => cart_item.product } ,
    :href => { :action => :delete_from_cart, :id => cart_item.product }

    Apart from that I really enjoyed your rails tips and insights as much as Ryan Bates advice, keep up the good work!
    Soon I will try to post how to do a proper upload progress bar with jQuery & mod_progress for apache in a rails app. You can see the demo app here :


  2. Johannes said,
    on March 23rd, 2010 at 2:05 am

    Thanks for the tip! I use jQuery in my project, so I wrote an equivalent to your Prototype script:

    $(“form.button-to”).each(function () {
    var form = $(this);
    var input = form.find(“input[type=submit]”);
    // “button-to” class is not added here, you might want to do that
    var link = $(‘‘);
    link.attr(“href”, form.attr(“action”));
    // html options specified in button_to will be added to the input element
    link.attr(“class”, input.attr(“class”)); (function () {
    return false;

    Maybe someone finding this can make use of it, too.

Leave a reply

:mrgreen: :neutral: :twisted: :shock: :smile: :???: :cool: :evil: :grin: :oops: :razz: :roll: :wink: :cry: :eek: :lol: :mad: :sad: