Archive for July, 2008

Some random thoughts

Thursday, July 31st, 2008

I’m currently attending the Mozilla 2008 summit in Whistler, British Columbia, Canada. Among all the good sessions we’re having, there are a couple that I definitely want to blog more about over the course of the next few days, but wanted to share a few thoughts right now so we all kind of know what to expect:

  • One of the big themes here at the summit is the effort at Mozilla to bring the Gecko platform to mobile devices. There are many ideas floating around, and it’s certainly going to also be an accessibility field. I have some ideas that I need to get formulated properly which I’d like to bounce off the community to get some feedback.
  • The Thunderbird and Calendar teams have done some great progress in their respective fields, and now that Thunderbird has moved to Gecko 1.9.1, and Calendar will follow after its 0.9 release, and then get integrated with Thunderbird 3, we’ll have some interesting times ahead getting the calendar controls accessible. ARIA is going to help a lot with that, and I’m looking forward to help formulate proper exposure of information to ATs for these.
  • Aaron’s and my talk about accessibility API and standards support in Firefox 3 stirred quite some interest, and I believe it helped quite a few people understand better how the different pieces connect to one another.
  • Speaking of ARIA, there have been a few people even asking outside sessions about it, and I’m hoping to be able to connect with Ray and John tonight at the bbq so we can finally talk a bit about jQuery and Amo and all the cool stuff surrounding it. So Ray, come and find me! :-)

On a more organizational side, rumour has it that the rock slide that blocks the main highway from Whistler to Vancouver should either be cleared, or a good alternative route be found until we depart on Friday, so no change in travel plans is necessary. Let’s keep our fingers crossed for that! And let’s also hope that nobody got hurt in that rock slide.

Posted in Uncategorized | 1 Comment »

Support for text attributes and spell checking is coming in Firefox 3.1!

Thursday, July 17th, 2008

For those of you on the bleeding edge, namely on the Firefox 3.1a1pre nightly builds, the Friday’s nightly build will include one big new feature in accessibility for 3.1: Text attributes and spell checking support!

This means that assistive technologies now have access to the attributes of any text run on a page via the IAccessibleHyperText::getAttributes or ATK/AT-SPI equivalent API calls.

For example, running today’s nightly build of Firefox 3.1a1pre on Windows, visiting my blog’s main page, bringing up Accessibility Probe, and navigating to the link below the Heading Level 1 that says “Marco’s Accessibility blog”, a call to IAccessibleHyperText::GetAttributes on the link accessible will get you this result:


getAttributes(1) = NULL

Not very fancy, huh?

Tomorrow’s build, however, will yield a completely different result:


getAttributes(1) = org.eclipse.actf.accservice.core.win32.ia2.IA2TextSegment[text=font-style:normal;language:en-US;text-align:center;font-size:40px;background-color:transparent;font-weight:bold;text-indent:0px;color:rgb(255\, 255\, 255);font-family:'Trebuchet MS'\,'Lucida Grande'\,Verdana\,Arial\,Sans-Serif;text-underline-style:underlinesolid;,start=0,end=26]

So, not only do you get information about the font-family, style, color and backgroundcolor, you also get the language this text is in, the underline style, the font-weight etc.

Also when editing, and you misspell something, as soon as you hit spacebar and the red underline appears, the attributes of that word will change and will include “invalid:misspelling;”, indicating that this word is invalid in that it is misspelled. Of course, an according IA2/ATK event will be fired accordingly! Note that the denotation of this may change if the IAccessible2 and ATK groups decide on a different notation for misspellings. Right now, it follows the aria-invalid convention, and we hope that this will be accepted by the groups.

Over the next few weeks, we’ll fine-tune this feature to be a bit more performant and also iron out any last details that might come up.

But if you’re an assistive technology vendor and you’ve been waiting for us to finally expose these text attributes, now is the time to try them out and provide feedback.

Note that Thunderbird and other projects that will be moving to use the Gecko 1.9.1 platform will also get this feature. This means that inline spell checking notification can also be supported for those apps soon!

[Update]: This patch made it into Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008071803 Minefield/3.1a1pre just fine. So go take a peek!

Tags: , , , ,
Posted in Accessibility, Firefox, Mozilla, SeaMonkey, Thunderbird | 15 Comments »

Easy ARIA tip #3: aria-invalid and role “alert”

Wednesday, July 16th, 2008

I know, I know, it’s been a while since I posted my last Easy ARIA tip. But I’m hoping that this one will find you all excited and willing to play with it some more!

The problem: You have a form, a contact form, for example, that you want to put some accessible error checking into. Common problems are e-mail addresses that are not valid, or a name that does not contain at least a first and a surname.

The form

Let’s start out with a simple form.

<html>
<head>
<title>Contact form</title>
</head>
<body>
<form method="post" action="post.php">
<fieldset><legend>Please enter your contact details</legend>
<label for="name">Your name (required):</label>
<input name="name" id="name" aria-required="true"/><br />
<label for="email">E-Mail address (required):</label>
<input name="email" id="email" aria-required="true"/><br />
<label for="website">Website (optional):</label>
<input name="website" id="website"/>
</fieldset>
<label for="message">Please enter your message (required):</label><br />
<textarea name="message" id="message" rows="5" cols="80" aria-required="true"></textarea><br />
<input type="submit" name="submit" value="Send message"/>
<input type="reset" name="reset" value="Reset form"/>
</form>
</body>
</html>

Straight and simple, but we’re not here to win beauty prices anyway. :-)

Checking for validity and notifying the user

Checking the validity and notifying the user consists of several steps:

  1. Checking if the e-mail address or entered name are valid. To keep it simple, we’ll check whether the e-mail address contains the “@” symbol, and if the name entry contains at least 1 space characters ” “.
  2. Setting the field’s aria-invalid attribute and giving it a value of “true”.
  3. Notifying the user via an alert that the value entered was incorrect. Instead of using an intrusive dialog box created by the JavaScript ‘alert’ function, we’ll use a simple WAI-ARIA widget to do it. This notifies the user, but lets them continue interacting with the form without any interruptions.

All of this happens when the input loses focus, meaning in the “onblur” handler.

The JavaScript code I wrote looks like this, inserted above the closing “head” tag:

<script type="application/javascript">

  function removeOldAlert()
  {
    var oldAlert = document.getElementById("alert");
    if (oldAlert)
      document.body.removeChild(oldAlert);
  }

  function addAlert(aMsg)
  {
    removeOldAlert();
    var newAlert = document.createElement("div");
    newAlert.setAttribute("role", "alert");
    newAlert.setAttribute("id", "alert");
    var msg = document.createTextNode(aMsg);
    newAlert.appendChild(msg);
    document.body.appendChild(newAlert);
  }

  function checkValidity(aID, aSearchTerm, aMsg)
  {
    var elem = document.getElementById(aID);
    var invalid = (elem.value.indexOf(aSearchTerm) < 0);
    if (invalid) {
      elem.setAttribute("aria-invalid", "true");
      addAlert(aMsg);
    } else {
      elem.setAttribute("aria-invalid", "false");
      removeOldAlert();
    }
  }

</script>

The checkValidity function

The core is the checkValidity function. It takes three parameters: The ID of the input that is to be validated, the term to search for to ensure validity, and the error message to be inserted into the alert.

To see if it is valid, the function checks whether the indexOf the input's value is anything greater than -1. A value of -1 or less is returned if the index of the search term could not be found within the value.

If invalid, the function does two things:

  1. It sets the element's aria-invalid attribute to "true", which will indicate to screen readers that there is invalid content in here.
  2. It will call the addAlert function to add the alert with the provided error message.

If the search term is found, the aria-invalid attribute is reset to "true". In addition, any alert that still might be around is removed.

The addAlert function

This function first removes any old alerts. The function is simple: It looks for an element with id "alert", and if found, removes that from the document object model.

Next, the function creates a div element to hold the alert text. It gets an ID of "alert". And it gets a role set of "alert". This is actually ARIA-inspired, even though it doesn't say "aria" in the attribute name. The reason is that role is based on the XHTML role attribute module that was simply ported to HTML for simplicity.

The text is added to the div element, and the div element is added to the document.

The moment this happens, Firefox will fire an "alert" event to assistive technologies when this div appears. Most screen readers will pick this one up automatically and speak it. This is similar to the Notification Bar in Firefox that prompts you whether you want to save a password. Our one does not have any buttons to press, it just tells us what's wrong.

Adding the magic to the "onblur" event

All that's left now is add the event handler. We need to change the two inputs for e-mail and name for this:

<input name="name" id="name" aria-required="true" onblur="checkValidity('name', ' ', 'Invalid name entered!');"/><br />
<input name="email" id="email" aria-required="true" onblur="checkValidity('email', '@', 'Invalid e-mail address');"/><br />

Testing the example

I've put up the above as an static example page for you to try it out. If you use Firefox 3 and a current supported screen reader, try the following:

  1. Enter only your first name as the name. When tabbing, you'll hear an alert that tells you you've entered an invalid name. You can then shift-tab back and correct the error.
  2. Enter an e-mail address that has no "@" symbol. When tabbing out of this field, you should hear a warning that says you didn't enter a valid e-mail address.

In both cases, when returning focus to the field in question, your screen reader should tell you that this field is invalid. JAWS 9 supports this, but JAWS 8 does not, so this may not work in all versions of the screen readers supported.

A few questions that you might have

Why did you put both "(required)" in the label text and the aria-required attribute on some of the inputs?
Because if this were a real live form, and the site was being visited by a browser that does not yet support ARIA, we'd still want to give an indication that this is a required field.
Why don't you set focus back to the invalid field automatically?
Because this is not allowed by at least the Windows API specs and possibly others. Also, letting the focus jump around without real user interaction too often is not a nice thing to do in general.

In conclusion

Personally, it is my hope that websites would include such techniques more often in the future when filling out forms. There's nothing more frustrating than filling out a form with 20 or so fields, submitting it, only to find that field 3 was invalid, and having to go through all fields again to make sure the values were retained, or supplying some information redundantly.

This is one of those examples where, in my opinion, more direct accessibility and user-friendliness can be achieved by explicitly using some JavaScript in combination with ARIA.

I hope you found this little tutorial of some use! I'd welcome your feedback as always!

And of course, you're welcome to enhance this little example as a "homework" to also check whether something valid was entered for the "message" textarea.

Previous Easy ARIA tips
  1. aria-required
  2. aria-labelledby and aria-describedby

Tags: , ,
Posted in ARIA, Accessibility, Firefox, Uncategorized | 25 Comments »

WordPress 2.6 brings a lot of accessibility improvements!

Wednesday, July 16th, 2008

I just upgraded this blog to WordPress 2.6.

This version brings with it a number of accessibility enhancements.

One thing you might have noticed already is that there is now a default language set. Default English blogs should now always cause screen readers that support language switching to use the English variant of their default speech synthesizer.

Also new: Whereever possible, there are now labels properly associated with the corresponding form controls. This means that now also screen readers that do not do their own HTML processing should pick up the labels fine.

One more addition that the WordPress team has embraced is the inclusion of some WAI-ARIA markup. Whenever you comment on my blog now, and soon hopefully many others, and you use a compatible browser such as Firefox 3, and a compatible screen reader such as NVDA or Orca, you’ll hear that the text fields also textually marked as “required” in their labels, now are announced as “required” fields. The WordPress default theme now uses aria-required to denote such fields as required, giving even more accessibility to WordPress!

I’d like to thank the WordPress community to embrace ARIA! It is really amazing that ARIA is now finding its way into such a widespread mainstream piece of software!

Tags: , , , , ,
Posted in ARIA, Accessibility, Firefox, Orca, WordPress | 14 Comments »

Review of the WebVisum Firefox extension

Thursday, July 3rd, 2008

Today, a post announcing the WebVisum Firefox extension was posted to the mozilla.dev.accessibility newsgroup. The things talked about in this post and on the WebVisum homepage almost sound too good to be true. Among the features are:

  • Ability to tag graphics, form fields, links, and other page elements. While some or all of these features have been available in some screen readers already, this feature is unique in that it works across platforms. It also sends the data back to the WebVisum web service so other members of the community can benefit from the labels someone provided.
  • Optical Character Recognition (OCR) to try and identify those images that absolutely won’t tell us through their SRC what they’re all about.
  • Visual page enhancements such as a high-contrast profile.
  • Suppression of automatic page refreshes or Flash content
  • And most astonishingly: CAPTCHA solving!

A few days ago, I was approached by the WebVisum development team if I would consider beta testing their extension. So, I had a bit of a head start with this tool, and I was very surprised when I started testing some of the features.

The tests

From my main screen reader, I already knew the capability to label graphics or HTML form elements that have missing alt text or labels. Instead of using those techniques, I applied a few labels to the main navigation images on the CakeWalk homepage using WebVisum. After labelling the graphics from my Windows computer, I fired up my Linux box, installed the extension there and surfed to cakewalk.com. Orca immediately picked up the labels I had given the graphics and used them as the link text.

I then went ahead and labelled the Search combobox on the German Heise Newsticker site. Again, after visiting the page from the other computer, the label for the combobox was read aloud.

And then I actually tried a CAPTCHA. I chose digg.com as my first target since I know they also offer an audio CAPTCHA. Of course this is not a 100% satisfactory solution because deaf-blind people are still left dead in the water with this, but it gave me a good reference to compare the results. I went into the new account creation process on digg, and when it came to the CAPTCHA, I let WebVisum do its magic. Within less than 30 seconds, I got a result back, placed on my clipboard by the extension, ready to paste in. I compared it to what the audio CAPTCHA told me, and the results matched!

I repeated this step two more times because I had first chosen a user name that was already taken, and then goofed up something else in the form, and each time, the result was correct. Totally stunning!

I tried the same on Technorati who also offer an audio CAPTCHA, and got the same results: The CAPTCHA was correctly resolved.

As my third target, I chose MozillaZine, who, despite a couple of attempts on my part, still do not offer an audio CAPTCHA for registration or sending a reply to a forum without being logged in. Without this fall-back mechanism, this is a real-world scenario that visually impaired people are being faced with on an almost daily basis. And I’ll be darned, it worked out! I could register with the MozillaZine forums without any sighted assistance.

The conclusion

There are actually a couple of conclusions, concerns and questions that this extension raises.

The educational aspect

So here we are, having been trying to educate web developers all over the world to use W3C accessibility authoring guidelines, comply with section 508 and what not, and now an accessibility comes along that allows for labelling controls, providing alternative text for graphics, and even share this with the community. So did we do all this educational endeavor invain?

The answer can only be a firm and resolute: “No, we didn’t!” While this extension allows to correct for obvious mistakes like a missing alt attribute on an image, it cannot correct all the requirements there are to meet for section 508 compliance. And it should not! On the contrary: All mistakes one has to correct should be counted against a ranking on a “Wall of shame” kind of statistic that depicts the sites requiring the most corrections. Similarly to the Firefox “Report a broken website feature”, that in Firefox 3.0 also has a “Disability Access” component that allows to report an inaccessible web site, this data should be used to advertise for better accessibility in a future relaunch of that particular site.

Furthermore, there are so many websites that are part of the so-called web 2.0 that are not publically-owned or from a big company, but which are just as compelling to participate. These can usually either not be bothered or cannot financially make it to be 100% sec 508 compliant. Having the possibility to enhance these pages will make the web 2.0 a much more compelling place than it already is in the future.

The CAPTCHA solver

This is probably the most controversial feature. The fact alone that WebVisum is able to solve the CAPTCHAs will probably send shivers up and down the spine of many web developers, website administrators, blog owners etc. that have to fight spam every day. The fact that WebVisum can do it probably means that spambots will sooner or later also be able to do it. Even worse, some could argue that the WebVisum service may be abused by spammers to get CAPTCHA resolution for free.

The WebVisum developers assured me that they’ll make sure that only real people will be able to use their service. Furthermore, the number of CAPTCHAs that can be solved per day per site is limited.

While it is correct to advertise for alternatives to visual CAPTCHAs, the reality is that audio CAPTCHAs, which are the most common alternative, do not allow every person to use them. I already mentioned deaf-blind surfers. But also people who have a hearing impairment and have difficulty deciphering the distorted audio have trouble with this alternative. The CAPTCHA resolution feature allows to solve the problems of these people and also anyone who has trouble reading or hearing the text who is not visually impaired.

Also, this allows access to those private sites and blogs that are under no pressure government- or image-wise to implement an audio CAPTCHA. It definitely lowers the barrier for participation in the web 2.0 world!

Aside from all that, CAPTCHAs only offer a false sense of security. There are much more effective ways of fighting spam than imposing these things upon everybody. My blog, for example, has no CAPTCHA entry for commenting, and still my spam fighting measures have kept this blog clean for as long as it has been in existence. But the sad reality is that CAPTCHAs are an “evil” we currently have to cope with, and WebVisum certainly helps a lot in circumventing these artificial barriers.

My hope is that the WebVisum folks manage to keep their user base spambot-free and that there won’t be any other way to abuse the feature for unsolicited activities.

A few wishes for the future

I see for this extension the potential to become much more than “just” a web helper for the visually impaired. For example, I can imagine this being enhanced to allow hearing-enabled people to provide a textual transcription of an audio clip for deaf surfers, sighted people giving a textual description of not just an image, but a video clip or the like, and other similar cross-impairment possibilities. After all, any hearing-enabled blind could provide such textual transcription of an audio clip for a sighted deaf person.

Aside from this larger-scale vision of mine, a few more basic features such as an undo feature that allows to revoke a server-submitted enhancement will hopefully make its way into near-future versions of the extension.

So: To be able to make up your mind for yourself, go check out the website and extension at www.webvisum.com.

Tags: , , ,
Posted in Accessibility, Extensions, Firefox, Mozilla | 45 Comments »

Extension developers: 5 things to make your extension more accessible

Tuesday, July 1st, 2008

After my first reach out to extension developers, Aaron and I have brainstormed and come up with the 5 most common things you as an extension developer should consider to make your extension more accessible. Here’s what we came up with:

  1. Make sure your extension is easily discoverable using the keyboard. A common pattern is to use an icon in the status bar or on a toolbar to launch an extension, but this is not possible to do when using only a keyboard, not a mouse. The easiest and most discoverable way is to add a menu item to the Tools menu to make sure keyboard users can launch it.
  2. Labels that are not associated with the control they’re labelling. As a result, screen reader do not know what a particular textbox, menulist, radiogroup etc. is for. Associate your controls with their labels by using the xul:label’s control attribute pointing to the id of the actual control. Works with xul:textbox, xul:menulist, xul:radiogroup and others and is an absolute accessibility must.
  3. Xul:page elements that are missing a title attribute. If you use xul:page elements in your chrome, make sure to give them a title attribute that is meaningful. That makes sure screen readers for the blind can properly pick them up and not read the chrome URL instead.
  4. Make sure any place holders are in the tab order by using 
    <a href="#">

    or

    <div tabindex="0" role="button" onkeypress="if (event.keyCode == event.DOM_VK_ENTER) { ... }"/>

    Any items that are put into a web page to enhance the user experience, and which allow interaction, must be keyboard accessible. A good example is what Adblock plus does with the ability to block certain elements like Flash animations.

  5. Make sure all event handlers react to both a mouse and keyboard interaction schema. In fact, you should always completely test your extension without touching the mouse. Some common problems are:
    • For opening context menus, use the oncontextmenu event handler or the context attribute. Do not code context menus to open specifically on the click of the right mouse button, since this will exclude the use of the keyboard. Both oncontextmenu and context will react to the operating system specific context menu triggers.
    • Provide keyboard equivalents for mouse-dependent functionality such as mouseover, mousemove, or ondoubleclick. For example in a listbox where one can double-click a list item to perform a certain action with it, also allow the Enter key or an equivalent keystroke to perform the same action. For Drag And Drop actions, provide context menu alternatives, Copy And Paste, etc.

I hope these are helpful hints for you to make your extension, XULRunner application or the like more accessible to everyone!

For more information, see the XUL Accessibility guidelines on MDC.

Tags: , ,
Posted in Accessibility, Extensions, Firefox, Mozilla, SeaMonkey, Thunderbird, Uncategorized | 7 Comments »