Posts Tagged ‘ARIA’

Last week in the “Accessible” module, March 30, 2009

Monday, March 30th, 2009

The last week was rather short, but no less busy.

First, on the off-code side, I attended the European Accessibility Forum Frankfurt (EAFRA) conference on Friday, March 27. Christian Heilmann from Yahoo! posted a great summary of the event and also caught my guide dog Falko sleeping while I talked. The videos will appear here.

On the code side, the action happened in the mozilla-1.9.1 repository AKA Firefox 3.5b4pre this time. Today, I checked in all the approved mozilla-1.9.1 nominated patches. From Tuesday’s 3.5b4pre nightly build onwards, Firefox will:

  • Expose font sizes in PT units instead of PX, as specified in the IAccessible2 spec.
  • Support the value of “undefined” on aria-checked/aria-expanded etc. attributes, as specified in the ARIA 1.0 spec
  • Drop support for aria-channel, container-channel, and aria-datatype
  • Support aria-expanded on more roles
  • No longer support role=”description”
  • Require aria-grab to be changed to aria-grabbed for drag and drop to work in the future
  • Expose non-editable documents as readonly, regardless of role
  • Expose the ‘checkable=”true”‘ object attribute

This brings Firefox 3.5beta4 very close to the ARIA 1.0 spec. We’ll take another look to make sure we don’t miss any details from the specification for implementation. Thanks to Mike Beltzner for not jumping our throats at these 10 or so approval requests we threw at him at once!

In other news, some progress is being made towards finding the leak that running the accessibility Mochitests on Mac OS exposes. It turns out that these same objects can also be leaked by other tests, which are not accessibility related, but ours are still the best bet at reproducing them. So our master of leak detection, Carsten Book AKA Tomcat has kindly agreed to help debug this beast.

Tags: , ,
Posted in ARIA, Accessibility, Firefox | No Comments »

Last week in the “Accessible” module, March 9, 2009

Monday, March 9th, 2009

Last week’s work saw quite some code cleanup.

Unification of role and finalRole

Previously, our nsI*Accessible interfaces exposed both role and finalRole properties. While role returned a preliminary role, finalRole always returned the finally determined role after all markup and ARIA processing had taken place.

It turned out that the role was hardly ever used, but everyone always asks for the finalRole. So, the decision came about to file bug 481357 and get rid of finalRole and make role do what finalRole did previously.

As a prequel to that, bug 482013 was fixed, refactoring all test files to use the common getRole and testRole functions in the testing framework. As a result, only one instance of .finalRole had to be dchanged to .role in the bug linked to above, to make all tests still work right.

This change will be exclusive to Gecko 1.9.2, since it will need some adjustments in DOM Inspector and other extensions that use our accessibility interfaces.

Crash fix in tree table code with some side effects

Alex also fixed a crasher in the tree tables implementation of getChildAtPoint/getDeepestChildAtPoint. After a fix for a leak that was uncovered by the test, the tests are still failing on Linux because of wrong coordinates we’re getting back. Investigation into this is still ongoing.

Originally, bug 471493 was also supposed to introduce crashtests specific to a11y. However, it appears that, once a crash test has turned on accessibility, that remains on for the remaining crash tests, and some of the others didn’t react well to that. A solution is under investigation.

Speaking of leaks

While investigating bug 420068, Alex found this memory leak. After he fixed that, the other bug seems to have been resolved, too.

Further test refactoring

I took on our table testing code and refactored it to use the new infrastructure. 4 more files that no longer use their separate implementations of retrievals of accessibles etc. That leaves 3 more files to go, and one of them is disabled right now because of bug 437980.

I also finally got the tests for aria-activedescendant refactor off my back. This one had been going on forever (or so it felt).

HTML 5 features

One thing I forgot to mention last week was that a few weeks back, the “indeterminate” property new to HTML5 was introduced to HTML:input @type=”checkbox” elements, effectively giving them the ability to be partially checked, for example as a master checkbox to dependent checkboxes. As expected, we didn’t expose the mixed state properly on these yet, so I took on that task. As a sequel, I’m currently working on exposing a proper action name for these as well. I’m having some trouble getting the tests to run properly, though. The tests go into an endless loop when I run them locally, so until I found out why, I’m hesitant to throw these at the tinderboxen. If anyone has seen this happen at all, suggestions are welcome. A sample log excerpt can be found here. The tests start running this test_comboboxes.xul file, then the whole a11y test suite starts running all over.

More text attribute fixes

Alex got the font-weight bug resolved, so font-weights are now properly exposed according to the visual representation and not through some seemingly arbitrary numbers.

aria-sort, aria-grabbed, and aria-expanded action exposure

David has been sinking his teeth into this one and has come up with a great idea to solve this. Since no desktop app ever exposed many of these things especially when it comes to a controlled drag and drop action from a screen reader’s point of view, this one requires careful thinking and design as well as good communication with AT vendors to get right.

Progress on plugging in accessible trees from plugins

Recently, community member Brad Taylor approached us with the question of plugging in accessible trees from plugins into our accessible tree on Linux, integrating third party plugin accessibility nicely with ours. A bug was filed, and Brad has been working on this, regularly communicating on the accessibility channel with David. A first WIP patch was posted on Friday.

That’s it for this week.

Tags: , ,
Posted in ARIA, Accessibility, Firefox, Testing | 1 Comment »

ARIA in Gmail #2: Enhancing the Chat experience

Wednesday, August 6th, 2008

This post continues a series on the implementation of ARIA (Accessible Rich Internet Applications) in Gmail.

On July 30, Orca team lead Willie Walker forwarded a message to the Orca mailing list titled Orca & gmail. The message is originally by Srinivas Annam, an accessibility web developer at Google. He describes a couple of enhancements that had been made to the Gmail user interface and were pushed live recently. I’m going to review each feature in turn so you get an impression of what accessibility improvements these changes actually brought about.

I tested with JAWS 9.0, Window-Eyes 7.0 Beta 1, NVDA snapshot as of Wednesday August 6, and Orca snapshot as of Wednesday August 6. Unless noted otherwise, all features are fully useable using Firefox 3.0.1 and these versions of the screen readers.

All of the below are in the Chat area of the Gmail interface. So after you’ve logged into Gmail, make sure to activate the “Chat” link to be able to follow the descriptions.

The “Set Status Here” label

This is the label right below the “Search, Add or Invite” textbox. Pressing Tab from that textbox focuses the label. You can press Enter to get another textbox where you can put in a personal status message that others will see when they have you in their chat lists. Note if you’re using JAWS, press JawsKey+3 (3 on the number row) to pass the key through to Firefox directly. Otherwise, JAWS will capture the Enter key and turn off Forms Mode when you don’t want it to.

The “Status” menu button

This follows directly in the tab order after the “Set status here” label. You can press Enter on it to bring up a context menu to navigate and set a predefined status. This button is also discoverable with the virtual cursor in all three Windows-based screen readers, and Enter works on all of them to open the context menu.

Inside the context menu, navigating the items with Up and Down arrow keys properly issues the focus events, making use of the aria-activedescendant attribute to indicate which of the menu items is active.

A known problem is that, when pressing Escape to close the menu, focus does not yet return to the menu button. Use screen reader navigational commands to return to where you left off.

The chat contact list

This is an ARIA listbox with list items. It follows the “Status” menu button in the tab order. The Windows-based screen readers allow navigating to it using their virtual cursors, and pressing Enter for Forms Mode/Virtual off/PassKey mode. With Orca, you can simply navigate or tab to the list. The list uses aria-activedescendant to indicate which item has focus.

Navigating inside the list is done using Up and Down arrow keys. Besides the contact’s name, the status is given “chatting”, “available”, “idle”, “offline”.

Pressing Enter will do one of two things. Note that if you’re using JAWS, again use the JawsKey+3 keystroke to pass the key through, or it will turn off Forms Mode.

  • If the contact is available or idle, a chat window will open. See the next section for features within this window.
  • If the contact is offline, a new mail message to it will be started, and the focus will be placed in the “Subject:” textbox.

Below the list is another menu button labelled “Options”. However, the menu that opens does not yet use the aria-activedescendant attribute. The result is that no screen reader follows the focused item within this menu yet. It is hoped that this menu be accessible soon since it contains a number of useful functions.

The chat window

If you’ve opened a chat window to one of your contacts, the focus is placed inside a textbox where you can type your message. Press Enter when done to send your message.

The chat output pane uses ARIA live regions to enable screen readers to speak incoming messages automatically. These can either be your own, or the ones your chat buddy types. A suggestion: The message output uses aria-live=”assertive”. The other portion that gives messages such as “xxx is typing” does not use live region markup at all yet. It would be good if this used aria-live=”polite” to allow screen readers to also speak this information. Since this message is not as important as the actual output, using “polite” here can help screen readers prioritize the speaking of these updates.

Currently, both Orca and NVDA support speaking of live region updates. This means that, when inside the chat area and a message comes in, both screen readers will automatically speak them. Additionally, you can turn off PassKey through mode in NVDA and navigate upwards to review the last messages. With Orca, simply navigate upwards to review the last messages.

Note: If you’re using JAWS, you should pop out the chat into a separate window. For some unknown reason, JAWS will not pick up the contents of the output window unless the chat is inside its own window. To do this:

  1. Press JawsKey+3, followed by Ctrl+DownArrow to focus the Chat window toolbar.
  2. Press Tab to move to the “Pop out” button.
  3. Press Enter to activate it. Note you might get a warning from your popup blocker that it prevented Gmail from opening a pop up, and an error dialog by Gmail itself that tells you how to disable popup blocking for Gmail. I suggest you do this to more easily open those pop outs.

The Chat window toolbar

You can reach this by pressing Control+DownArrow while focused inside the chat entry textbox. It places focus on an “Options” menu button. Press Enter to open it. Navigation inside it is just like in the “Status” menu, also works using aria-activedescendant.

Alternatively, you can press Tab to reach the “Pop out” button, allowing you to put the chat into its own window.

Finally, Ctrl+UpArrow will put focus back into the chat entry textbox.

In summary

With these enhancements in both keyboard navigation and ARIA semantics, Google have turned this portion of Gmail into a really useful tool also for blind and visually impaired users. With Firefox or another ARIA-capable browser and a compatible screen reader, you can now use this part just like your sighted buddies do.

With this, Gmail is not just web mail, it becomes a communication center as it already is for the sighted users.

I’d like to thank Google again for putting ARIA into Gmail in this fashion. It shows that the work Mozilla, IBM and the W3C, under the leadership of Aaron Leventhal, put into this spec is indeed usable in real-life scenarios and not just, as suspected by some, a nice geeky thing on the drawing board.

Previous ARIA in Gmail posts

Tags: , ,
Posted in ARIA, Accessibility, GMail | 15 Comments »

More ARIA in the news

Wednesday, August 6th, 2008

As I’m catching up with news after my return from Whistler, I have two suggested ARIA-related readings for you:

Gez Lemon of the Opera Developer community has posted an article titled Introduction to WAI ARIA. This is probably the most comprehensive, but easy to understand, introduction to WAI ARIA I’ve come across so far! Thanks Gez!

Victor Tsaran from Yahoo! has posted an article on the YUI blog titled Enhancing TabView Accessibility with WAI-ARIA Roles and States. It is a hands-on example that shows a lot of techniques outlined by Gez in action. There are both the final example to try out, and a screen cast to watch. Thanks Victor!

Happy reading!

Tags: ,
Posted in ARIA, Accessibility | No Comments »

ARIA in Gmail #1: Alerts

Monday, August 4th, 2008

Google have recently started to put ARIA (Accessible Rich Internet Applications) into GMail. This means that ARIA is now getting a lot more exposure than it used to, with GMail being probably one of the most widely used web applications today. It’s great to see that the hard work Mozilla, IBM, the W3C and especially Aaron Leventhal put into this standard recommendation is getting this prominent placement so soon!

As an appreciation for the work devs at Google such as Srinivas Annam are doing to provide better access to GMail, this post starts a series of articles on the subject of putting ARIA into GMail, either after I’ve been pointed to specific areas or by finding new features myself.

The first in this series of reviews of GMail ARIA features concerns a very simple, yet effective, one: Alerts. As I already mentioned in my Easy ARIA Tip #3, alerts are a great way to immediately notify users about important status updates, but without taking focus away from where you are currently working.

As I found out rather by accident, GMail now uses an ARIA landmark role of “alert” for the piece of the UI that pops up with an important status message for a few seconds after certain actions have been performed. It disappears again after a few seconds, but because this is an alert, screen readers pick it up and speak it automatically as soon as it appears. Alerts, in the assistive technology terminology, are important status messages that can pop up anywhere on the screen and should be spoken or otherwise indicated to the user immediately. Another example of an alert is the notification box that appears when Firefox asks the user whether they want to remember the password just entered. It is an important notification the user might want to act upon, but still less intrusive than a modal dialog.

Actions that cause this alert to appear are such ones as moving a contact from the “Recommended contacts” to “My Contacts”, deleting a label, sending an invitation to someone for Google Talk/Chat, adding a contact, etc.

This way, actions that previously used to only pop up a message now provide immediate feedback. There is no need to look for the message, and when one finds it, find out that it just disappeared after the timeout.

Tags: , ,
Posted in ARIA, Accessibility, GMail | 9 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 »

Two new ARIA related resources

Friday, May 30th, 2008

There are two new ARIA resources that recently entered the web which I’d like to point you to if you’re interested:

Paciello Group have started an ARIA tutorial.

Peter Thiessen of ATRC in Toronto, Canada, has started a blog on Live Regions.

Cool stuff, guys!

Tags: , ,
Posted in ARIA, Accessibility | No Comments »

Impressions from a German Web 2.0 accessibility conference

Monday, May 12th, 2008

Last week on Tuesday, I attended a German web 2.0 accessibility conference titled Einfach für Alle – Konzepte und Zukunftsbilder für ein Barrierefreies Internet, loosely translated “Simply for all – Concepts and Visions for an accessible internet”. The conference was organized by the Aktion Mensch initiative Einfach für alle. I was invited to participate as an expert on Web 2.0 technologies in a workshop titled “web applications – The software inside the browser”.

The workshop consisted of four experts, one moderator, and about 20 participants in the audience. In addition to myself, there was one other blind expert, Anna Courtpozanis of WEB for All, one web designer (Martin Kliehm of Namics AG Germany, and Dr. Carlos Velasco of the Fraunhofer Institut für angewandte Informationstechnik, and head of the BIKA Web Compliance Center. The workshop was moderated by Jo Bager, journalist and editor at one of the most widely used German computer technology magazines called C’T.

The workshop started out with the introduction of the experts and their statements for the workshop. Both Dr. Valesco and I put a strong emphasis on ARIA, both getting the point across that ARIA is the way to make Web applications accessible today and in the future.

Mrs. Courtpozanis emphasized that screen reader vendors and browser manufacturers should work more closely to ensure better accessibility for web applications, a point I definitely agree with! She also was of the opinion that accessibility in web applications becoming the common thing rather than the exception, is 10 years away still. I honestly hope that we can reach out to web developers and make this happen sooner!

Mr. Kliehm’s statements were all around sharing innovation and thus infusing progress, that this progress is going to be a community process, and that the W3C will be the over-all infrastructural framework for this progress to happen. As examples, he mentioned Yahoo and Google sharing their applications with everyone, therefore driving the web forward. I also see us at Mozilla in this context: We’re sharing the innovation with everyone, making it accessible and driving adoption through standards workgroups. Needless to say that this is definitely a community process! And yes, the W3C is the organization through which we also drive the standardization effort for ARIA, for example.

After we had finished our statements, the workshop discussion quickly turned into a Q & A session between mostly the web developer audience and the experts. There were many questions regarding interaction with screen readers, quite a number of questions surrounding ARIA (some of the web devs hadn’t even heard about it yet), and the state of support for these new technologies in Firefox and other browsers. We could help the audience understand some of the concepts ARIA is based on. We could also show them how they can use NVDA or Orca to test their sites for accessibility using Firefox 3.

Mrs. Courtpozanis and I also gave examples of web 2.0 applications that we can use, and also those we cannot yet use. One that we both use is GMail, one we both cannot access is Google Docs. Incidentally, the note taking took place in Google Docs on the Eee PC that the moderator had brought along.

In the end, we mutually agreed that the key is to teach and advertise the technologies to make web applications accessible in seminars, at conferences, through blogs and other means to raise the awareness among all web developers, not just those that already are sensitive to accessibility needs.

It was a good workshop, although it did have a Q & A session characteristic over periods of time, seeming more like web devs finally having a chance to ask the screen reader users all the questions they hadn’t had a chance to ask before. But the moderator managed to always keep us in check and not detour too much. :-)

I also visited a second workshop on that day, titled “Accessibility and Mobility”. The goal was to try and see how accessibility on the web 2.0 can also help mobility. The only expert was Mr. Jochen Hahnen, staff member of the competence center Kooperationssysteme des Fraunhofer-Institut für Angewandte Informationstechnik. He brought with him an application consisting of both a web portal and a mobile phone software that allow joggers or bicyclers to record a certain route they regularly take for trasining, and then upload that recording to the portal. That way, they can compare themselves to others using the same track, or see how their fitness develops over time. Incidentally, the web portal and mobile phone software were both not accessible, even though the usefulness for e. g. blind people or wheelchairers is imminently clear: This product could be used to upload good routes to use for wheelchairers, or information like a moving construction work facility for blind walkers. Mr. Hahnen clearly stated that this software is currently designed specifically for sportives, but could be further developed to also be a portal for visually impaired or wheelchair users.

The way this workshop was done leaves me with a bit of a mixed feeling. On the moderator’s side, there was nothing to complain about. He made the best of the situation. However, the expert invited for this workshop, or the product chosen to showcase, was off the mark. It has remained unclear whether the organizers simply didn’t know that the product is currently not accessible, or whether they wanted to give the Fraunhofer Institute an incentive to make it accessible. One thing was clear: Mr. Hahnen could not meet the audience’s expectations, and he was literally pounded on by some participants several times for the application not being accessible.

The over-all framework consisted of both a study conducted by Aktion Mensch on the use of web 2.0 offerings by handicapped people, and the start of the Biene award 2008. The Biene award has been given to German web sites that, in the given year, made a special effort to make their web presence more accessible. It is by now the most recognized award for accessibility in the German-speaking world.

On the inofficial side, I found that many participants already knew one another, and that I was sort of the new kid on the block, only knowing a handful of people from my previous job. In that sense, the conference also had a bit of the atmosphere of a family gathering. And I can say that I was welcomed very warmly into that family. There were several people there who expressed grattitude that Mozilla finally joined them through me.

I’d like to thank the Einfach für Alle team for the invitation! It was an enlightening experience!

Tags: , , ,
Posted in ARIA, Accessibility, Mozilla | 2 Comments »

Are Ajax and Accessibility mutually exclusive?

Tuesday, April 29th, 2008

Peter of ATRC and an a11y community member, pointed me to a blog post titled “Stop using Ajax!”, written by OperaDev community member James “Brothercake” Edwards.

My initial reaction was “Oh no! Not another one who uses accessibility as the sole argument to rant against a technology he doesn’t like!”

And while that outraged feeling has diminished somewhat, I still disagree with his article in large chunks. His point, despite the captivating title, is not to stop using Ajax in its entirety, but to stop using it when you don’t need it.

However, this brings up several questions. Whether you need Ajax to accomplish something is a totally subjective issue. I agree that sometimes, it is more worth to use native HTML widgets. But some examples simply horrify me, like a full page refresh when all you want to do is show or hide a quick help text in response to a user entry. Full page refreshes are one of the most terrible things you can do to screen reader users. Today’s screen readers are fully capable of handling dynamic page updates in supported browsers. You usually don’t even lose your virtual cursor reading position when such updates happen. There are obviously desired exceptions to that rule, such as pressing Enter on a link that moves focus to an anchor on the same page. In such cases, the reading position is expected to change.

He also mentions Twitter. I use Twitter myself sometimes, and I find it very handy to find out how many characters I have left when typing a Twitter update. This is one of those examples that could benefit from some ARIA-empowered live region support so Orca and other screen readers could pick it up and speak it automatically.

But first and foremost, we have to face reality: Ajax, although still pretty new, cannot be stopped. Whether we like it or not, it will continue to spread across the web. So his call to stop Ajax when you don’t need it may be several months, if not years, too late.

So what about the accessibility? I agree that some applications are real challenges right now. Google Calendar is one of those, gmail a similar one in some areas. However, Google Maps is not so bad. Since it talks about “maps”, I do not even expect to be able to see the map it brings up. But it is still accessible enough that I can type in my street address, and give the resulting link to someone sighted so they can see where I live.

And there is ARIA. The proposal for Accessible Rich Internet Applications has been evolving for several years now, has been in Firefox 2.0 and is more complete in Firefox 3, and is a way to make all these Ajax apps accessible.
And there are Ajax toolkits out there that already implement ARIA support, making any Ajax application accessible that uses them. One example is the Dojo toolkit, which is being used in the standard AOL freemail frontend, for example. Other toolkits such as Jquery are implementing, or planning to implement, ARIA in the near future, making even more Ajax widgets accessible with browsers and screen readers that support ARIA.

Granted, there is still a big userbase out there who use, or have to use, browsers that don’t support ARIA yet.

But frankly, instead of hiding away in a corner and whining about Ajax being so inaccessible, I prefer going out to web developers, educating them about ARIA and the possibilities it offers, and educate corporate deciders to make the right choices when they decide to implement Ajax. In addition, if I can, I’d like to help other evangelists like Steve Lee who spread the word at a UK Web 2.0 conference recently.

In addition, there are other bloggers like John Resig who are showing how easily it can be implemented, and how a few attributes already can make a major difference.

So, BROTHERCAKE, I invite you to get up to speed on ARIA and what it can do. Get in touch with me or other ARIA developers, learn, and then spread the technology yourself with projects you support. I strongly believe that you’ll be helping the accessibility community much more in that fashion than ranting or giving out hopeless calls like “Stop using Ajax”.

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

Putting final touches on Firefox 3 accessibility

Wednesday, April 23rd, 2008

Over the past weeks the developers and I have been spending time putting the final touches on Firefox 3 accessibility. Here are some of the things worth noting:

  • On Linux, the Library dialog will be working correctly in the upcoming RC1. We had a problem with tree tables changing content which we weren’t handling correctly.
  • In an image accessible’s attributes, we’re exposing the SRC value, starting in today’s nightly. This will allow screen readers to use the ATK/IA2 APIs and not have to rely on the older iSimple* interfaces any longer that previously exposed this information.
  • Also with images, there is a change in the pipeline that will enhance the name finding for an image in the form that, if the author specified an ALT attribute with an empty string as content, but also specified a title, the title is being used even though an alt is present. Screen readers such as JAWS and Window-Eyes apply this magic by themselves right now, and we’re helping out to give the image accessible the proper name in most, if not all, thinkable circumstances.
  • Through triage of sent in crashes from beta 5, we were able to find and fix a couple of crashers that, though rare, could cause some grief on some pages. This again demonstrates that sending in crash reports is very very useful for us, especially since these were all crashes we didn’t catch before. People use software in different ways, and this helps us get prepared for most cases.
  • A few final touches on the ARIA implementation give Firefox 3 a really all-round appearance.

We’ve come a long way since I started to contribute to Firefox 3 accessibility QA as a community member, and I am really happy with the way Firefox 3 is turning out.

Tags: , ,
Posted in ARIA, Accessibility, Firefox | 4 Comments »

A follow up to my Easy ARIA tip #2

Tuesday, March 25th, 2008

Community member Ben Millard has pointed out in a recent blog post that roughly the same as shown in my example can be achieved using regular HTML 4 by embedding the input into the label. Thanks for that info, Ben! It is very useful and shows that some of the techniques that have been available for years escape even us gurus sometimes. But then, we don’t dig through every W3C doc on a regular basis, either.

However, the implementers of Firefox accessibility have done their homework: Ben’s examples work nicely with Firefox 3. The association is made properly, the label accessible is built up fine, and the input accessible gets its accessible name defined correctly. I also tested with that other browser that came with my Windows XP, and users there are less fortunate: IE does not properly make up the accessible name for the label and also does not correctly associate the accName of the input type with the label’s full content.

So, does Ben’s example now completely obsolete the need for the aria-labelledby and aria-describedby attributes? Most definitely not! There may always be cases where nesting the input into the label is impractical/not wanted, or where the description cannot be so nicely densed into the label as Ben shows using my example. For those cases where you explicitly need to specify something to become the accDescription, you definitely can still use ARIA. You can even use aria-describedby inside an input that’s nested within a label. :-)

Tags: , , ,
Posted in ARIA, Accessibility | 2 Comments »

Easy ARIA tip #2: aria-labelledby and aria-describedby

Sunday, March 23rd, 2008

Sorry it took me so long to get back to it, but here it is, my second tip on the usage of some easy ARIA markup to make your sites more accessible.

Imagine this: You have a form where you ask your user a question, but the answer is actually part of the sentence the question is made of. A classic example we all know from our browser settings is the setting “Delete history after x days”. “Delete history after” is to the left of the textbox, x is the number, for example 21, and the word “days” follows the textbox, actually forming a sentence that is easy to understand.

If you’re using a screen reader, have you noticed that, when you go to this setting in Firefox, it actually tells you “Delete history after 21 days”?, followed by the announcement that you’re in a textbox, and that it contains the number 21. Isn’t that cool? You do not need to navigate around to find out the unit. “Days” could easily be “months” or “years”, and in many ordinary dialogs, there is no way to find this out other than navigating around with screen reviewing commands.

Well, we have to thank Aaron and all the other great people who invented ARIA, for this capability! The solution is in an ARIA attribute called aria-labelledby. Its parameter is a string that consists of the IDs of the HTML or XUL elements you want to concatenate into a single accessible name. Yes, you read right, this not only works in HTML, but in XUL, too!

A second attribute that works very similarly is called aria-describedby. It can also take IDs of one or more elements to make up an additional description. In Microsoft Active Accessibility, this is converted into the AccDescription of the element. Some screen readers like NVDA pick this description up and speak it automatically after the name and type of the control, assuming that this information is giving the visually impaired user additional information that a sighted user also gets.

aria-labelledby and aria-describedby are both specified within the element that is to be labelled, for example an html:input or a xul:textbox. In both cases, the label for/label control bindings that may also exist, are overridden by aria-labelledby. If on an HTML page you provide aria-labelledby, you should also provide a label for construct to also support older browsers that do not have ARIA support yet. With Firefox 3, your blind users will automatically get the better accessibility of the new attribute, but the users of older browsers are not left in the dark this way.

And here is an example I made up for demonstration purposes:

minutes
Allows you to specify the number of minutes of inactivity after which your computer should shut down.

A Note for JAWS 8 users

JAWS 8.0 has its own logic to find labels, causing it to always override the accessibleName the textbox of an HTML document gets. With JAWS 8, I have not found a way to get it to accept the label from the example above. But NVDA and Window-Eyes do it just fine, and Orca on Linux also has no problems.

Previous Easy ARIA tips
  1. aria-required

Tags: , , , , ,
Posted in ARIA, Accessibility, Firefox | 6 Comments »

Easy ARIA Tip #1: Using aria-required

Friday, February 29th, 2008

Inspired by a conversation I had with Aaron the other day, I’m starting a mini series about easy accessibility improvements you can accomplish using ARIA, but which do not require you to implement a whole widget. Some ARIA attributes also work on plain old standard HTML elements and can easily improve accessibility within supported browsers and screen readers. On browsers that do not support these attributes (yet), they are ignored and do not break your page just because that attribute is there.

The first attribute I’d like to cover is called aria-required. It is one of the universal aria attributes, which means, as stated, that it can be used on any conventional HTML element such as input or select.

Let’s look at this sample excerpt:


In this excerpt, both the firstName and lastName input elements have the aria-required attribute set. Note that in normal scenarios, you’d also stype them or their label differently, or put an asterisk “*” after the label.
However, if you cannot or do not want to put an asterisk on the label, but only style it with bold text or the like, screen readers usually cannot pick up the information automatically that this is a required field. If you use the aria-required attribute as shown above, modern screen readers will indicate that this is a required field automatically, if used together with Firefox 3.
Screen readers that already support this feature are NVDA, JAWS 9.0, and Window-Eyes 5.5 or higher. JAWS 8 does not support this attribute yet. Also, ORCA does not seem to pick this attribute up yet, at least my testing showed that Orca did not indicate the required state to me when tabbing through that form.

On the browser side, Opera 9.5 is going to include ARIA support, so this technique is not limited to Firefox. Also, as this technology spreads, more browsers will pick up on it, and your sites will automatically be compatible and more accessible once these other browsers also support ARIA.

This is the first of a couple of examples that demonstrates how easily you can use ARIA without implementing a whole widget to improve accessibility on your web sites. Start using it today, and you’ll make sure that you help insure good accessibility for people using modern browsers and screen readers!

Tags: , , , , ,
Posted in ARIA, Accessibility, Firefox | 24 Comments »

Yahoo! demonstrating wai-aria roles and states with their YUI Menu Control

Monday, December 24th, 2007

Victor Tsaran, accessibility guru at Yahoo!, just posted to the mozilla.dev.accessibility newsgroup that they implemented wai-aria roles and states into the Yahoo! UI’s menu control. You can find the blog post here. To try it out:

  1. From within the blog post, open the link “new YUI example”.
  2. From the article that opens, open the “View Example in new window” link.
  3. On the page that appears, arrow to the first item that starts with “text/html”, and press ENTER on it. This will turn on Forms Mode (in JAWS) or your relevant navigation mode.
  4. Use Left and Right Arrows to navigate the menu bar, use DownArrow to open the menu, just like you would use any ordinary menu.

I tested it, and it works great! Good work, guys!
Note that you need Firefox 3 beta 2 and JAWS 8 or later, or Window-Eyes 6 to take full advantage of this.

Tags: , , ,
Posted in ARIA, Accessibility, Firefox | 1 Comment »