Easy ARIA Tip #1: Using aria-required

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!

A lot of small but noticeable usability improvements

Beginning of this week, Aaron Leventhal, who is the module owner for Mozilla accessibility, and I met in Stuttgart, Germany to work on some hard to reproduce and nagging issues. Among one big issue having to do with how document loads are being processed, we also fixed a number of smaller, but no less important problems that vastly improve usability in Firefox 3 and Thunderbird 3 alphas.

The Doc loading stuff

This involved quite a number of complex issues having to do with loading of documents in Firefox, firing the correct events at the correct times, and not firing events when we shouldn’t. For JAWS users on Windows, the mosst visible change of this is that in Thunderbird, every message should now again come up and be read without you having to switch virtual cursor on and off all the time to get messages to read. For Orca users on Linux, Firefox now again fires correct document load finished events and helps Orca to correctly read web sites when it is time to do so.

Focus no longer getting fired on items in non-focused widgets

OK, let’s start with an example: Have you been in the Add-Ons manager in Firefox recently? if so, you’ve probably noticed that, when you switch tabs from Extensions to Themes and back, that when you return to Extensions, your screen reader tells you something about a highlighted Extension. Firefox tricks screen readers into thinking that focus actually shifted. However, focus did not shift, but a focus event was fired when the selection was shown on the list of extensions.
A different example is in Thunderbird, where if you were in Inbox, then went to another folder, then arrowed back up to Inbox, the screen reader would tell you that focus shifted to the message you had last selected in the Inbox folder. Again, focus actually does not shift, but an event is fired for the widget not currently in focus.
Aaron and I put a stop to that happening. As a result, reading should be much more consistent now when you work in both Firefox and Thunderbird. Screen readers should no longer get confused as to where the focus actually is.
By the way: This issue had been around since Firefox and Thunderbird became accessible in their respective 1.5 versions. It was annoying as hell to me, and I am very glad we finally got that one nailed and dealt with!

Tree items updating when they change

When a tree item changes visually on the screen, like a newsgroup or IMAP folder updating its number of total and unread messages in Thunderbird, assistive technologies were until recently not notified of these changes. One had to shift focus away from, and back to the tree view to get the correct picture.
Not any more! Alexander Surkov, one of the great developers working on the accessibility module, has fixed this problem and made sure that ATs can now update when there’s a change.
This again makes working in Thunderbird, but also when you deal with changing bookmarks in Firefox, much more convenient and fluent.

If you haven’t already done so, I would suggest you update to the latest nightlies of both Firefox and Thunderbird on your respective platforms and try out these great improvements!

What on earth are Places? :-)

A while back, on IRC, Mick Curran of the NVDA project posed an interesting question that led me to this blog post. Those of you who have been following the Firefox 3 press coverage have probably stumbled upon the term “Places”. Let me try and explain a bit about the concepts and accessibility implications.

So what are Places? Well, the satyrical answer to that is: it depends on who you ask. For some, it is a religion. For others, it is a philosophy. For QA people, it can be a curse because if a new Places checkin comes into a nightly build, it might cause regressions.

In all seriousness, though: Places is a technology built into Firefox 3 to store history, bookmarks, downloads and a bunch of other data in an SQLite database. In previous versions, Firefox would store the user’s bookmarks in one format, namely an HTML file, and the browser history in a different format, and these formats weren’t compatible to one another. Moreover, HTML is not a file format you naturally would store data in; It was meant for a different purpose. So this approach had severe limitations in extensibility and flexibility.
The new database-like format, on the other hand, allows for all kinds of interesting features to be implemented. For one, since the data is now stored in a relational database, one can perform database queries on it, allowing for very generic and flexible search and filtering capabilities.

So how does the user benefit from this change? The answer is: In a wide variety of ways.

The new Location bar, AKA the “Awesome Bar”

The first thing anyone who launches Firefox 3 will be presented with, aside from the default start page, is the new Location bar, also known as the “Awesome Bar”. Earlier versions of Firefox allowed you to type in addresses, and depending on whether you had already visited those addresses, would show you suggestions to auto-complete the address you had started typing. This capability is still there, of course, but it has been emensely enhanced. As soon as you start typing, Firefox will search for matches not only within the address (URL) of a page, but also within the titles of pages that it has in its storage. The auto-completion popup will offer items based on the search results, giving both the title and the URL of the found item, and visually highlighting where within the information the text you typed was found. For screen reader users, in each list item, the title will come first, followed by the URL. In addition to that, tags, and keywords for bookmarked pages will be searched. More on tags below.
Along with the title and URL, the search result will have different indicators depending on where the match was found:

  • If the page is bookmarked, it is indicated both visually and through accessibility.
  • If the match is a tag, it will be indicated.

In other words, once you typed in something you know you have in your bookmarks or browser history somewhere, you can use the auto-complete dropdown to actually find out whether you have the page bookmarked, or whether the term you entered is a tag that can be on multiple bookmarks.

Bookmark tagging

I mentioned tags in the paragraph above a couple of times. Tags are a new feature for Firefox 3 bookmarks. They allow you to categorize your bookmarks, and through the use of the Awesome Bar, retrieve all bookmarks belonging to that category. Some might say “I’ve my bookmarks sorted into folders, what do I need categories or tags for?” Well, I had the same reaction at first. Let me give you an example:

Say you want to collect information about IAccessible2, ATK/AT-SPI, and Universal Access. You have both reference pages for these, as well as links to mailing list archives. You can now sort everything IAccessible2 into one folder, everything AT-SPI into another, and everything Universal Access into a third folder. However, at the same time, you can tag each reference page with a tag of “reference”, and every mailing list archive page with “archive”.
Now, say you want to look for something in the references of AT-SPI and IAccessible2. What you can do now is to type in “reference” (without the quotes) in your new Location bar, and it will show you all bookmarks that have the tag of “reference” on them. You do not have to remember the title, nor do you have to dig through your bookmarks menu to find the bookmark for either IAccessible2 or AT-SPI. How cool is that!

The Library dialog

The Library dialog, which is called Show All Bookmarks on the Bookmarks menu, is where you edit, move and otherwise manage your bookmarks and tags. A very convenient and intuitive dialog which you should feel very familiar with once you get in there.

Adding a bookmark

The way to add a bookmark is to press CTRL+D on the page you want to bookmark. You can immediately press ENTER to save the bookmark, or you can edit tags, or the folder where to store the bookmark. If you press CTRL+D on a page you already bookmarked, you can remove the bookmark.

I hope this lifts some of the mysteries concerning the new Places system in Firefox 3!