It is scary how some obviously bad practices refuse to go away and developers jump through hoops to defend them and make them work rather than using simpler alternatives.

My pet peeve is the “chess rules” select box (you touched it, it needs to move):

Yahoo

B3TA

Google

This is the most evil permutation of this interface idea. A lesser evil version is part of a large form that will change the rest of the form or – if we venture back into more evil lairs – submits it to reflect these changes.

The arguments for this interface are not many:

• It saves the user one step of pressing a submit button
• The action is immediate

(Ok, these are actually the same argument, comment if you know some.)

The drawbacks of the solution are immense:

• People that use a keyboard will submit the form or leave the page without having selected the right option.
• People that are dependent on using a keyboard for web access will possibly know that you can press the Alt+Arrow Down keys simultaneously to expand the whole dropdown before selecting with arrow up and down and enter.
• Most people won’t know this though and a lot of people use keyboards and tabbing from field to field to fill out forms.
• Forms are a terrible annoyance of our times – nobody likes filling them in. Most of the time we won’t keep our eyes on the screen but actually look up information on papers, our credit card or read up the fine print that – of course – is not on the screen but only in the letter we got sent.
• I have no clue how something like that works with switch access or voice recognition – probably not
• It is scripting dependent – no JavaScript, no service

The latter is actually a reason for some companies for using this from time to time. Too many links on the same page are bad for SEO - Google considers your page not content but a sitemap and ranks it lower. That’s why some companies start offering the first two levels of navigation as links and the rest as a dropdown in this manner.

However, that still doesn’t make them a good solution, it just means that you offer far too many options to your users to begin with.

Here’s what people do to make this work: Aaron Cannon on the WebAim mailing list

A coworker and I recently devised a way to make a slightly more accessible version of the onchange dropdown navigation box. Basically, using javascript, we determine whether they are using their mouse or the keyboard to select each item in the list. If they used the mouse, it works as usual, immediately taking them to the selected page. If however the selection was made by the keyboard, we display a spinner and delay x number of seconds. If the user doesn’t make another selection within that time, they are taken to the page they selected. If they do, the clock is restarted.

I am not attacking Aaron here, he probably was asked to find a solution no matter what and did his best to find a technical way. The big scare in this for me is “determine whether they are using a mouse or keyboard”. My guess is they check for the event type, but assistive technology like voice recognition must simulate clicks without being a mouse. The other danger signal is the timer and the spinner – this complicates the interface even further (“Is this loading?”).

I simply don’t understand why we constantly try to make things work because this is what the design spec says or this is what we saw somewhere else. How about really testing it with users and see what happens then?

Following the accessibility hack of YouTube I thought the same could be done for Flickr, and here it is:

Easy Flickr is a very basic interface to look for photos and click through them 20 at a time. It works with and without JavaScript.

Update: It seems there is some confusion as to how this interface works. The main photo is linked to flickr.com (as per API guidelines) and you can navigate up to 20 results by clicking the lower thumbnail to go forward and the upper one to go backward in the results list. This also works with a keyboard and in JAWS but I need to make it more obvious with a hover state and some labels for screen readersand I added some roll-overs and texts for screen readers to make it more obvious..

• Check out Easy Flickr
• Get the source code

If you want to host the interface yourself, you need a server with PHP and cURL, but that’s it. Simply unpack the zip file and change the look and feel by changing the style sheet.

Today I will try to find a more accessible way to provide an edit-in-place script. The solution described here is probably not ready for real life yet, please test it in different environments and provide fixes. It is licenced with creative commons share-alike, so go nuts!

I really like the idea of edit-in-place. Probably the most used example of edit-in-place is flickr which allows you to click any heading or description when you are logged in to directly edit it. The reason I like edit-in-place is that it makes it a lot easier for users to describe things, which hopefully results in more accessible and easier to find web sites (after all text is what gets indexed and what is available to everybody). The drawback of edit-in-place is that a lot of solutions are not very accessible. They add a click handler to elements that are not necessarily available to assistive technology and are not at all accessible with a keyboard.

A non-scripting solution attempt

Technically the easiest solution to create an accessible edit-in-place would be to use input fields with labels and use CSS to make them look like the other elements. The code could be the following:

<h1 class="editable">
  <label for="mainheading">Heading:</label>
  <input type="text" id="mainheading" 
         value="Otters in eastern Europe">
</h1>

And the CSS:

.editable label{
  position:absolute;
  top:0;
  left:-9999px;
}
.editable input{
  border:none;
  font-family:arial,sans-serif;
}

But alas! Is it more accessible? I am not sure, as the semantic goodness of a heading is disturbed. I am quite sure search engines will frown upon it and as screen readers work differently in forms mode than in reading mode it might even be more confusing. So let’s scratch that.

Making it work unobtrusively

The next step would be to use a normal heading and somehow connect it with a form field somewhere else in the document. The cool thing about this is that we have something like that in plain HTML: targeted links. For example:

<form id="editform" action="servermagic.php">
<h1 class="editable">
  <a href="#editheader">Edit me, wuss!</a>
</h1>
<p class="editable">
  <a href="#editdescription">Me as well, do it!</a>
</p>
<div id="editingsection">
  <p>
    <label for="editheader">Content of main heading:</label>
    <input type="text" id="editheader" name="editheader">
  </p>
  <p>
    <label for="editdescription">Content of description:</label>
    <input type="text" 
           id="editdescription" 
           name="editdescription">
  </p>
  <p><input type="submit" value="Save Changes"></p>
</div>
</form>

This works without JavaScript (but somehow my Firefox does not highlight the form field when you hit the link, does anyone know why? Please comment!). All it needs to turn it into a working version of edit-in-place is a JavaScript. What the script does is:

• find the section with the ID “editsection” and hide it from view
• find all elements with the class “editable” and add a click handler pointing to an edit function
• override the submit event of the form to point to a store function

The edit function should do the following:

• check if another element is already being edited and focus that if there is one
• Get the ID of the form element from the href of the targeted link
• set the value of the form element to the content of the element
• set an “edited” style to the original element to hide it
• show the form field where the original link was
• focus the form field
• tell the main script what element is currently being edited

The store function should:

• check if there is an element edited (to avoid overriding normal form submission)
• set the content of the targeted link to the value of the field
• move the form field back to where it came from
• set the focus back to the link
• store the content asynchronously (not implemented here)
• stop the normal form submission
• reset the edit state of the script to none

Following is the script that does exactly that. I am using the YUI in this example as I like to concentrate on writing scripts rather than worrying about browser problems. That said, notice that you need to wrap form field focus in a timeout in Firefox, what’s with that?

YAHOO.namespace('ch');
YAHOO.ch.editinplace = function(){
 
  /* Names and IDs used */
  var namesandids = {
    editsection:'editingsection',
    edited:'edited',
    hidden:'hidden',
    editable:'editable',
    form:'editform'
  };
 
  var YE = YAHOO.util.Event,YD = YAHOO.util.Dom;
 
  var edit = {};
  var editingsection = YD.get(namesandids.editsection);
  if(editingsection){
    YD.addClass(editingsection,namesandids.hidden);
 
    function doedit(e){
      if(!edit.target){
        var t = YE.getTarget(e);
        if(t.href){
          var fieldid = t.getAttribute('href').split('#')[1];
          var field = YD.get(fieldid);
          this.appendChild(field);
          field.value = t.innerHTML;
          YD.addClass(t,namesandids.edited);
          setTimeout(function(){field.focus();},10)
          edit = {target:t,field:field,id:fieldid};
        };
      } else {
        setTimeout(function(){edit.field.focus();},10)
      }
      YE.preventDefault(e);
    };
 
    function store(e){
      if(edit.target){
        edit.target.innerHTML = edit.field.value;
        YD.removeClass(edit.target,namesandids.edited);
        editingsection.appendChild(edit.field);
        edit.target.focus();
        // Ajax Magic here, you can used edit.id as the id 
        YE.preventDefault(e);
        edit = {};
      };
    };
 
    var edits = YD.getElementsByClassName(namesandids.editable);
    YE.on(edits,'click',doedit);
    YE.on(YD.get(namesandids.form),'submit',store);
 
  }
}();

Try out the solution and Download the example page with the script as a zip and tell me what you think!

Tested in Firefox, IE7 and Opera 9 on PC, please get me some more feedback on other systems and browsers.