MySpace Layouts and Markup Quality

I have received an increasing number of advertising inquiries from MySpace layout sites. Apparently the term “MySpace layouts” is a very popular search term these days. Looking at the default MySpace layouts one can unserstand why. I am confident that they didn’t hire a designer to create the default MySpace look and feel. Looking at the MySpace HTML, they certainly didn’t hire a GUI developer. The markup looks like it was ripped from a teenage fan site from the early nineties:

  • There is no doctype declaration. Not that it would have mattered anyway…
  • The markup starts out nicely with divs and spans and then freaks out with some classic table layout. I though that went away in the nineties…
  • Inline styles are used all over the place.
  • Headings start at level 5. And continues to level 4…
  • Images are missing an alt attribute.

This contributes to making MySpace an inaccessible mess. What does it prove? That you can be successful with a crappy site? Maybe the laugh is on me.

New release of the Ruby Accessibility Analysis Kit and online interface

The current version has some minor bug fixes that will speed up testing. The online test interface has been updated to support direct input of markup. This is for those of you unable to install Raakt locally.

This means that there is no reason to skip basic accessibility testing of whatever you are developing! To find out more on how you can integrate Raakt in your testing framework check out the Raakt wiki which now has a lot more information.

A new version of the Ruby Accessibility Analysis Kit

This is to announce that RAAKT (The Ruby Accessibility Analysis Kit) has been updated. This release includes more accessibility tests and an initial mapping of tests to the Unified Web Evaluation Methodology (UWEM). Also, thanks to Derek Perrault RAAKT now uses Hpricot to parse the HTML document. This solves the problem where the previous parser (RubyfulSoup) declared a class “Tag” that was likely to clash with your local classes in Rails.

To install the new version simply type gem update raakt or gem install raakt if you have a previous version installed.

Changelog

Summary of changes from version 0.4 to version 0.5.1.

  • Example of how to use RAAKT in Watir unit tests.
  • Tests for area element alt attribute.
  • UWEM mapped in comments for relevant test methods.
  • Test to check that input fields of type image have an alt attribute with text.
  • Refactoring of some methods for more compact syntax. Patch by Derek Perrault.
  • Added test to verify that fieldsets have legends.
  • Fixed alt_to_text that needed to check element type before attempting to read attribute value.
  • Fixed language attribute check (downcased value). Added iso language code list.
  • Applied patch from Derek Perrault (better use of Hpricot features).
  • Fixed check for lang attribute (now requires a value as well).
  • Test for charset mismatch in http headers and document meta element.
  • Switch to Hpricot. Patch by Derek Perrault.

An article on the value of, and how to integrate basic accessibility tests in your development process is in the works for standards-schmandards.com. In the meantime check out the Raakt wiki.

If you are using Watir it is very simple:

require 'watir'
require 'raakt'
require 'test/unit'

class TC_myTest < Test::Unit::TestCase
	attr_accessor :ie

	def setup
		@ie = Watir::IE.start("http://www.peterkrantz.com")
	end

	def test_startPagePassesBasicAccessibilityCheck
		#set up the accessibility test and pass html to raakt
		raakttest = Raakt::Test.new(@ie.document.body.parentelement.outerhtml)

		#run all tests on the current page
		result = raakttest.all

		#make sure raakt didn't return any error messages
		assert(result.length == 0, result)
	end
end

Why Accessibility in Rails is a Non-issue

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 why:

As long as the developer has control over the view code (HTML and CSS) it will always be possible to create an application that is accessible. What happens if you remove that control? Microsoft tried to remove that control in the first incarnations of ASP.NET with the result that some really crappy (and inaccessible) HTML was genereated on the server.

Potential risks?

DHH presented an upcoming plugin: simply_helpful. This plugin will provide convenience methods to create markup in your views. Currently it provides an excellent support to do standard stuff. As long as this plugin doesn’t go haywire with regards to semantics Rails will continue to be an excellent framework for accessible applications.

Could something be made better in the current version of Rails? If scaffolding should be a way to show best practices in accessibility there is a small detail that could be changed right now. Add a lang attribute to the html element (lang=”en”) to indicate the natural language. But, I guess it is up to me and other accessibility advocates to submit as a patch.

Maybe it could be the smallest patch (9 bytes) ever submitted?

Speaking at RailsConf Europe

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”. Accessibility often becomes a burden or is simply ignored.

In this session I will try to improve your skills with regards to accessible web interfaces. We will have a pragmatic look at why and how you increase accessibility. Without getting into too much theory we will have a look at some demographics and then move quickly into some scary examples of how you can fail miserably. I will show you how to use RAAKT (the Ruby Accessibility Analysis Kit) in your Rails testing framework (to make sure your team does the right thing) and how to fix some of the more commonly found accessibility issues. Thus, this session is for experienced Rails developers as well as beginners.

If you have any specific areas you would like me to cover, please create a comment below and I’ll try to fit it in.

Testing Google’s Accessible Search with the Ruby Accessibility Analysis Kit

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?

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:

[source:ruby]
def assert_basic_accessibility
rt = Raakt::Test.new(@response.body)
result = rt.all
assert result.length == 0, result.collect { |msg| “n” + msg.text + “n” }
end
[/source]

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.