Christian Heilmann

You are currently browsing the archives for the firefox category.

Archive for the ‘firefox’ Category

WebVisum.com – crowdsourcing accessibility

Monday, July 14th, 2008

It is quite interesting to see that several products right now try to crowdsource accessibility. IBM released their social accessibility project and another project caused quite a stir in the accessibility world: WebVisum.com.

The latter is a Firefox3 extension that ties in with Screen Readers to allow users to enhance pages they have problems with by adding the correct meta data while surfing the page. The more controversial feature of WebVisum though is that they also provide a CAPTCHA recognition service in the tool.

I’ve caught up with Marc Dohnal from WebVisum and asked him a few questions about the product:

An attempt for a more accessible edit-in-place solution

Friday, January 4th, 2008

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.

So what is the deal with the new gmail crashing my Firefox (or stalling it)

Tuesday, November 6th, 2007

I am a big fan of gmail (and a lot of colleagues scowl at me for it). With the massive amount of emails I get daily and me working on 3 computers there is just no other way to get around them.

Until the latest update of gmail though. Now my two laptops (both Windows) get stuck and I have to shoot down Firefox 5 times a day to be able to work. Sorry Google, but what happened? I turned off Firebug as you asked me to and yet it messes up. I also tried switching to the “older interface” but my setting does not get stored (yes, cookies are enabled).

I also tried to turn off sounds of the chat inside gmail but yet it keeps crashing. Don’t make me change because of superfluous bells and whistles, I have too many good contacts in your system.