Web Accessibility – The Screenreader Experience Part One

Posted by Brian in Accessibility, Browsers, Usability (October 15th, 2010)

In order to help other developers understand accessibility and assistive technology, I’ve been working on a series of articles aimed at developers. As a slight change of pace, I invite you to experience Twitter through the “eyes” of a screen reader in this short video. You’ll hear what it sounds like when a screen reader reads the text of a page, and you’ll experience what a blind user might experience if he or she encounters a browser popup dialog. You’ll also get a chance to experience what happens when the browser experiences the “spinning beachball” on Mac OSX.
(more…)

Accessible Rails Apps – Images and Alternative Text

Posted by Brian in Accessibility, Rails, Usability (July 3rd, 2009)

Many types of users make use of alternative text for images. Users who use screen reading software rely on those tags to describe the images they can’t see. Mobile users with slow connections or ‘pay by the minute’ plans often times turn off images to speed up the process.

Rails does something a little crazy with the image_tag helper… it automatically generates the ALT tag, which is just a horrible horrible idea.

  <%= image_tag "rails.png" %>

generates

  <img src="/images/rails/png" alt="rails" />

This is an absolutely awful idea, and I presume this was done just to shut up the XHTML Transitional validator which will complain if you leave ALT text off of your image elements.

You shouldn’t be adding ALT text to images to satisfy a validator. You should be doing it because it’s The Right Thing To Do.

ALT text is designed to describe the image, to be an alternative to the image. So, when placing the image on the page, take a few seconds to describe what it is.

  <%=image_tag "rails.png", :alt => "The Ruby on Rails Logo"
  <%=image_tag "banner.jpg", :alt => "Awesome Consulting Services - We Make Websites" %>

And for goodness sakes, please don’t prefix your description with “An image of…”. Screenreaders and other devices will make it completely clear to us that the content is supposed to be an image.

Some images convey more information than the ALT may allow, and so we’ll talk about that next.

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(){
  $$('form.button-to').each(function(form){
      var link = new Element('a', {href:'#', 'class':'button-to'});
      link.update(form.down('input[type=submit]').value);
      link.observe('click', function(e){
        e.stop();
        form.submit();
      });
      form.insert({after:link});
      form.hide();
  });
});

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 => message.id), :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.

“Web Design for Developers” now available in Beta

Posted by Brian in News, Products, Projects, Usability, web (November 19th, 2008)

Web Design for Developers

My book Web Design for Developers is now available in Beta form.

You’ll learn how to design a web site from start to finish, and you’ll use many of the techniques and thought processes you’ve come to rely on as an application developer. You’ll learn some color theory, some typography basics, some XHTML and CSS, and how to incorporate Photoshop and Illustrator into a work flow that works for you, not against you.

You can buy an early copy and then contribute to the feedback cycle to help make this an even better book when it eventually ships. You can purchase the PDF and start reading now, or preorder the printed book which will ship after the beta process finishes up.

Why I’m using a Mac

Posted by Brian in News, Rails, Usability, web (May 9th, 2007)

I’m a Windows user. Anyone who reads this blog can pretty much figure that much out. I started this company in 1995, fixing computers and trying to put the “personal” in computer service.
Over the years, I’ve removed countless viruses, uninstalled lots of spyware, formatted hard drives, recovered files, and occasionally had to send a computer back to a customer as “unfixable” because
of some unknown hardware or software glitch. Windows is popular and well-known, and people who know it well can have some pretty good job security.

Shortly after I started this company, I shifted focus towards the Internet, developing web sites. I bucked the trend of my Mac-using
counterparts back then and did all of my design work on Windows. I even did video editing there. I embraced ASP, and when that got old, I started using PHP, but deployed on Windows.

When Ruby on Rails came along and I got involved in that community, I was determined more than ever to bring Rails to the Windows platform. I’m speaking about Rails on Windows at RailsConf 2007 this year, and I’ve just finished a book on
Rails for Windows users which will be published by O’Reilly.

But I started using a Mac for development this Spring and couldn’t be happier. Here’s why.

  1. Ruby runs faster.

    Ruby runs at least ten times faster on a Mac, which means my unit tests, Rake tasks, and anything else I do with Ruby take no time to run. On Windows, I pay at least a 15 second penalty just to start a task or a test. That basically means I either sit and wait for things to happen, or I just start neglecting my tests to save time. Not a good place to be if you’re trying to write good code.

  2. It’s Linux that runs Photoshop

    Many web-based languages like PHP, Python, and Ruby run extremely well on Linux. However, you can’t use industry-standard tools like Photoshop on Linux without a few glitches and a lot of work. I’ve done Photoshop on Wine and I am not impressed. On my Mac, I can use Flash, Photoshop, Illustrator, Dreamweaver, and anything else, because there are native supported ports of those programs for my system.

  3. I can run Windows apps too!

    I need Office, and I need to run IIS so I can support ASP, .Net, and other Microsoft-based technologies. My Macbook Pro has Windows XP installed as a second boot option, but I also run Windows XP on Parallels, a virtual machine that lets me use my Windows apps side-by-side with my Mac programs. Parallels can run pretty much any other operating system, so I also have Windows Server 2003 installed for testing.

    When I go to conferences, I only have to bring one computer.

  4. I can surf in peace

    No IE means no spyware. I typically use Firefox on Windows anyway, but the complete absense of IE on this machine makes me feel much safer.

  5. More time working, less time tweaking

    I don’t have to stop working in order to make something do what I want. The Mac’s OS gets out of your way and lets you work. It’s a little difficult to transistion from a PC to a Mac at first, but some of the built-in features are great. The Dashboard gives me quick access to GMail, my WordPress blog, the weather, my Backpack account, and even a color-picker.

    When I got my Macbook, I was using it and actually being productive with it in only a few hours. I haven’t used a Mac since I was a kid.

  6. Textmate

    Windows users have e, but I have TextMate, and I don’t need anything else. TextMate is more than just a text-editor; it’s an IDE. I can integrate with Subversion, I can run Rails generator commands, I can run unit tests, and I can have Prototype and Script.aculo.us methods auto-complete while I type. I can validate HTML, preview in a browser, and then upload it back to my repository.

  7. I can use more advanced tools

    I do most of my deployment on shared hosts with Mongrel and mongrel_cluster. I can run these on my Mac without incident. I also use the excellent load-testing program httper, which does not run on Windows. There are countless other tools out there too.

    I also get to use QuickSilver, which means I can chain commands and navigate through my files and programs much faster.

  8. Apple has awesome support

    I used my new Macbook Pro for gaming one night just to try it out. My games ran flawlessly when I boot into Windows XP via Bootcamp. While I was playing, one of my keys came dislodged. I called up Apple, and within 10 minutes I had them sending me a new keyboard. That’s cool. Try getting that from another company. I’ve worked with tech support offices for the last 13 years, and I rarely get service like that. Good luck getting that from some of the larger PC manufacturers unless you have an enterprise support contract.

  9. I can zoom.

    OS X has a built-in zoom feature that I use to not only enlarge the screen when I need it, but also to inspect images for artifacts and imperfections.

So there you have it, a long-time Windows user who is using a Mac for software development. If you’re going to preach to others about “using the right tool for the job” then you owe it to yourself to see what a Mac can do for you.

If you have switched, I’d love to hear your story. If you’re thinking about getting one, let’s hear what’s holding you back from taking the plunge.