Here’s a summary of what’s currently happening in Mozilla-funded accessibility-related projects. Most of these surfaced over the past quarter, or last half a year.

NVDA

In early August, it was announced that the Mozilla Foundation would renew its funding for the NVDA project. Mick posted a summary of the goals to the NVDA blog.

The project is well underway, en route to their 2009.1 release with improved support for WAI-ARIA landmarks, a totally revamped list of elements, support for 64 bit operating systems and much more!

Spearheaded by the Mozilla Foundation, who were the first to fund NVDA starting in 2007, Microsoft, Yahoo! and Adobe have since joined in supporting this open-source screen reader for Windows, offering a compelling alternative to commercially available assistive technologies on this platform.

For more news such as winning the Vision Australia Making A Difference award, check out their blog.

Audio and Video accessibility

Frank already detailled much of this in his blog post above, and Silvia Pfeiffer just recently published a progress report on the grant.

Silvia also gave me some demos to test, and if you use JAWS or NVDA or Orca, I suggest you try them out yourself to see how cool they are!

This work has the potential to involve a lot of volunteers in helping make more movies, songs, and other material accessible to a large number of people with varying disabilities. Talk about crowd-sourcing!

Firebug UI accessibility and the Firebug accessibility testing extension

There are currently two grants happening in regards to Firebug, the web development tool of choice for many thousand web workers.

One is the work the Paciello Group is doing to make the UI accessible. I posted about the Firebug 1.4 release already, but the work doesn’t stop there. The next alpha release of Firebug 1.5, 1.5xa25, will include accessibility of the net panel, a component that was still missing in 1.4. The documentation has already been updated with information on how this will work. I gave this a whirl this week using a custom build I received from Hans (the developer in charge), and it works as advertised! So keep your eyes on the Firebug release cycle to not miss this cool update!

The other portion is work the University of Illinois UIUC is doing to develop an extension that will allow web developers to test whether they’re using correct accessibility-compliant markup. The extension will honor the WCAG 2.0 guidelines and WAI-ARIA specifications. Development has started recently, and I will be testing an early version soon to see how it fares! Keep your eyes on this blog for more info as it becomes available!

Once this work is completed, Firebug will be a solution for web developers to do testing of accessible web pages with an accessible UI. It means that Mozilla will be able to offer, directly or indirectly, a full range of testing and usage tools starting from the browser itself, the screen reader, and the testing and development side, all in an open-source fashion, driving the accessible web standards effort forward in thus far uncharted territory.

So, let’s boldly go!

Also, Apple entered the same field during the Mac OS 10.4 Tiger timeframe and offered the VoiceOver screen reader as part of the operating system. This is not new, since Mac OS X has since moved on to Leopard 10.5. But I recently had the first chance to play with it, and I must say I am deeply impressed! Once you turn on a Mac that you just bought, it prompts you that if you can’t see the screen, you can press Cmd+F5 to turn on VoiceOver. From that point on, it talks you through the Setup Assistant using a clear, very intelligible voice named Alex. This speech engine is built with a “breathing” algorithm making it sound even more natural than other current TTS engines. Once I had mine set up, I was wirelessly connected and ready to go.

For the fun of it, I also booted from the DVD. This boots a copy of the operating system and automatically launches the installer. However, even here you can press Cmd+F5 to get instant VoiceOver speech and full access to the installer and other utilities such as the Disk Utility that Apple offers for maintenance.

By comparison, on Windows, only part of the installer is accessible, and then only on English language versions of the operating system. And, it uses a voice called Microsoft Sam on Windows XP, and an only slightly better sounding female voice whose name escapes me right now for Vista. The part of the installer that, even under Vista, still runs in text mode, is not accessible at all. So disk partitioning, formatting etc., are all without speech support. The alternative way many of us use is an answer file that sucks in all the information and then lets the installer run automatically.

On Linux, the story can be slightly better depending on the distribution and the version of that distribution you’re using. Ubuntu 8.04 Hardy Heron was pretty good in that you only had to press a rather straight-forward series of keystrokes, but in right order, to get a talking installer. Ubuntu 8.10 made a huge lapse backwards unfortunately, again requiring the use of the command line, sudo, Ubiquity and the hope that you typed it all right while you had to quit Orca to get it running with administrative privileges.

I haven’t looked at the new Open Solaris, which is supposed to also have an accessible installer, so cannot comment on its story. Other distributions require other forms of blind-flying to get to a talking or brailling installer, which is nothing for the faint of heart.

Both Windows and Linux also suffer from the additional risk that the hardware in the computer you’re trying to install them on is not recognized. In worst case, the sound card won’t be recognized, leaving you completely in the dark. There, binding the operating system to specific hardware, like Apple does, has a clear advantage: They know what’s in their boxes and can make sure it always runs.

And again, nothing is as easy as pressing a single keystroke to get speech.

And the wwealth of applications that is already accessible on Mac OS X is breathtaking as well. Not only programs that come with the operating system or the additional applications package such as TextEdit, Mail, Safari, QuickTime and iTunes, but also third-party applications often used, or needed, by blind users are accessible. One is Skype, which is the preferred Voice-Over-IP application used by the blind community. Another is OpenOffice, which, starting at version 3.0, is a Cocoa application and has full VoiceOver support.

On Linux, Skype, for example, isn’t accessible yet. This is one of the most frequently asked-for applications, so it is hoped that with the migration from Corba to D-Bus for the accessibility infrastructure, this will become easier to do, but for now, the GNOME desktop accessibility story definitely misses out on this important application.

On Windows, Narrator is not even enough to get you to a point where you can download NVDA. So if you have to reinstall, make sure you put a portable version onto a USB pen drive before so you have good access to your system once it’s up and running.

In comparing these three platforms, it can be said that Apple took their time to come to the accessibility party, but what they came up with simply works great out of the box. In my opinion, this is a real alternative to Windows. So if you think about buying a new notebook or desktop computer in the near future, why not walk up to a Mac shop and take a look at the models there?

For the Mozilla story, this underlines that we better continue our effort soon to get Firefox accessible on the Mac so people can take advantage of things like WebVisum there, too.

If you’d like to listen to some demos of VoiceOver support on the Mac, there is a great three-part podcast series on Blind Cool Tech made by Mike Arrigo that is definitely worth the time listening to!

• 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.

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

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.