First and foremost, we managed to fix a whole range of bugs related to focus reporting. For more details, please read this post.

In Linux, the caret position is now correctly updated again when using atk_text_set_caret_offset is used.

Accessibility now supports the list attribute on inputs and the datalist element of HTML5. An indication is given that this input supports autocompletion and that it has a list. Pressing DownArrow will put you in a list of choices, enter will allow you to accept the selected item and put it in the entry.

Info about the map tag is now being reported correctly.

The feature to read highlighted text via the Mac OS X speech feature under the “Edit” menu has been fixed to work properly in Lion. This also applies to Thunderbird where this issue was first reported to us.

Telemetry has been updated to report the use of the iSimpleDOM interface by assistive technologies. It also now reports if depricated IAccessible2 methods are still being used by any AT out there. For more information on what telemetry is and how we use it, please read my post on this subject.

If a table has the datatable attribute’s value set to “0″, we now always treat it as a layout table and set the object attribute for the table accessible accordingly. The algorithm to determine whether something is a layout table has been enhanced so that it no longer picks up data table elements from nested tables.

We fixed a few issues having to do with accessibleRelation exposure for select elements that are nested inside labels, and with xul:tree elements and their children.

All in all, we almost reached the 50 fixed bugs mark in this cycle in the Accessibility APIs component alone. Congrats to the whole team and all external contributors who also helped with a number of these!

When I wrote the original blog post, what we had was very basic content rendering to VoiceOver or Accessibility Verifier. And I mean really basic. We had just crossed the point where loading a second page, or opening a new tab, would actually tell VoiceOver what content there was. Previously, it would not even take notice of the new content and still show the old stuff. Also, the web area was just now then being announced as “HTML content” by VoiceOver, like in Safari.

Since then Hub:

• got headings to be announced.
• got tabs to count correctly, and all roles to be spoken.
• got dialog texts and other text to speak completely.
• got links to be pressable through VoiceOver.

Pretty amazing, eh?

Of course, there are still quite a number of things left to do. To name a few:

• Navigating by character, or interacting with, the text in the awesome bar does not speak the character.
• Firefox doesn’t tell VoiceOver when a page has finished loading.
• password entry fields not identified as such, entering password does not generate typical audible click.
• VoiceOver does not see form fields that are nested inside label elements
• VoiceOver says “text” after each chunk of text it reads inside paragraphs, does not do that in Safari.
• Various form element states not communicated to VoiceOver
• WAI-ARIA landmarks are not communicated to VoiceOver.

As you can see, we still have quite some work ahead of us, and we’ll undoubtedly find more along the way, and with your help once I announce a build that has less known bugs than this above list.

Recently, we also started to incorporate statistics about the way the accessibility features of Firefox are being used.

Our newest addition to this feature is the collection of data about which screen reader is being used with Firefox on Windows. For Linux, there is only one screen reader that’s widely used really, so we primarily concentrated on Windows, since there are a variety of screen readers and screen magnifiers out there that Firefox is being used with.

So, to get a better idea about what our user base is using Firefox with, we’d like to call out for assistance in gathering this data! Let me stress once more that this is purely voluntary, but that this will help us improve our over-all support even more focused once we know better what assistive technologies are the most used. Moreover, this is anonymous data, so there is no way we can link a particular screen reader to a particular user. Which assistive technology you use is and stays your private matter. You’ll only be contributing to an over-all picture of usage statistics.

So how do you turn this on? In Firefox:

1. go to Tools/Options.
2. With the arrow keys, navigate to the list item called “Advanced”.
3. Tab once to set focus to the tab page selection.
4. Select the “General” tab using the left and right arrow keys.
5. Tab through the dialog until you reach a check box called “Send performance data”. Note, instead, you can also press Shift+Tab a couple of times to get there faster, since this is the very last checkbox before the “OK” button.
6. Press Space to check it if it is unchecked.
7. Tab once to get to the “OK” button and press Space to close the dialog and save your changes.

Firefox will now send anonymous usage data to us and inform us about any relevant performance like memory usage, screen reader in use (if any), or whether accessibility is instanciated at all.

Note that part of this feature is currently only in the Nightly development builds of Firefox. If you use a regular release like Firefox 9.0.1, this checkbox will not have any effect for screen reader usage data yet. But for other data such as the memory consumption, you can still enable it. Once you get upgraded to Firefox 12 in 3-4 months, you’ll start sending us data about your screen reader usage automatically.

If you’re on the Aurora channel, you’ll get this feature with the next big uplift that will happen early February.

To all who enable this feature, thank you! Your helping us improve Firefox even more is appreciated!

And to those of you who do not wish to send us your anonymous information, that’s perfectly fine, too! No grudges will be held against you.

Hub Figuière, a new member of the Mozilla accessibility team who started in November, has taken on the task of bringing our support of Apple’s Universal Access up to speed. Work on this support had initially started some time in 2006, but stalled for a number of years despite a pleas for help on this blog in 2009. However, demand for it has always been there, every Firefox release I’m being asked when Firefox will finally become accessible to VoiceOver.

Well, the time isn’t here just yet, but we’re on a very good way!

And in the next couple of weeks, we’ll be announcing the availability of builds for those who are willing to help us test accessible Firefox on Snow Leopard or Lion! They will be builds off our hot development branch, so nothing for the faint of heart. They will have problems, some of which we may have found internally, but undoubtedly many we will not have found yet. And if you feel like you can help us make sure the accessibility of Firefox on the Mac is good, join the fun and provide feedback! How that can be done, I will announce in a separate blog post. If you already know your way around the Mozilla community, you’ll be able to find us easily right now and can follow this meta bug for progress.

In the meantime, you are invited to show your support, be it in testing or good morale, by leaving a comment here!

I am looking for an RSS reader for my Mac. Because I’m blind, I have to use VoiceOver to access the screen contents. VoiceOver is a screen reader for the blind. If you have a Mac, press Cmd+F5 and listen to what happens! (That same keystroke turns ift off, BTW.)

If you run Linux and the GNOME desktop, you have the screen reader Orca built-in. If you run Windows, you can get a free and non-intrusive screen reader called NVDA. These can be used to test applications for accessibility. And oh yes, websites, of course, too, if you use a compatible browser for the platform.

Anyway since this was a question specifically directed at Mac OS X users, I got several replies recommending Reeder. I then asked those who had recommended it, if Reeder is compatible with VoiceOver. One of them did a quick test and found out that it isn’t. The feed table doesn’t read, for example, and possibly other stuff that doesn’t work as well.

I just saved €7.99 because I was able to ask the community for help in testing whether an app is compatible with VoiceOver. And unfortunately for the app developer, they just lost a sale because of the fact that their app is not compatible with assistive technologies.

And here’s the message for you app developers out there, web or native: Not being accessible costs you sales! Because not only will people who have to deal with the inaccessibility of applications or web apps not buy your stuff, they will also tell their friends and co-workers about it. And news travels fast around the blindness or other disability-related communities

Likewise, if you make an effort and become accessible, and tell someone about it, good news travels through the relevant communities equally fast! Because we’re not just a bunch of naggers, we are also equally cheerful if we find out, or are told, that there’s more stuff that we can use to broaden our horizons and lower barriers in the world we live in. And this, in turn, will increase sales and is good for business reputation!

There are tons of resources out there on the web, in developer documentation for your platform of choice, how to make your applications more accessible. For web developers, I wrote an article on how to test your web sites for accessibility a good while ago.

And if you’re in doubt, find beta testers, find community members to help out with testing and feedback! I can also be contacted of course, although I cannot provide testing for each platform, but I might also be able to give some general advice.

Happy accessifying!

Unfortunately, what all these have in common, is a great number of problems when it comes to accessibility. This is not just for the blind and visually impaired, but also considering people with other kinds of disabilities. The less good the markup in general, the less assistive technologies of any kind will work, and the less likely people with varying disabilities will be able to use them successfully to interact with others. Remember, all of these call themselves “social networks”. But if you try to apply the term for people with disabilities, the concept often falls over quite badly. Let’s have a look!

Twitter

Twitter relaunched its web offering a few months ago, calling it “New Twitter”, and frankly, pissing off a lot of folks with it, disabled or otherwise. Many of the items are not properly marked up or keyboard accessible. Put your mouse away and try to reach all the options. I guarantee yo you will encounter problems. Some of the stuff is only reachable by hovering the mouse over an item. Others are marked up in a way that is totally inaccessible. For example, with New Twitter, I can no longer block or report an offending account for spam. All I can do is follow. Mouse users have some sort of funky button at the top right somewhere they can do these things, but no matter how hard I tried, I couldn’t get to it via any accessibility means at my disposal.

There are other problems, for example I often hear people complaining that they miss out on direct messages sent to them because the Twitter site doesn’t properly notify them. This is not an accessibility so much as a usability issue that affects everybody.

Compared to the old site, it’s a huge step backwards in accessibility. Tweets are also no longer put into a list, so jumping from tweet to tweet using the “jump to next list item” feature most screen readers offer, no longer works, making reading tweet timelines via Twitter really really cumbersome.

Clients

Fortunately, there are a lot of accessible clients out there that allow access to Twitter. The Twitter app for iOS is coming to be accessible more and more. The iPhone version is almost completely accessible, the iPad version still leaves a lot to be desired, but has come a long way since its initial release, which offered no VoiceOver output whatsoever. If Twitter stick to this path, they’ll eventually manage to make it fully accessible there, too. [Update Dec 9, 2011: Actually, version 4 of the iOS twitter app came out a few hours after I posted this article, and it turns out it is not only a big step back in usability for the more advanced user, but also a big step backwards in accessibility on the iPhone. The iPad UI, not yet changed to the new usability concept, has become more accessible, but is still not useable efficiently.] I am not an Android user, so I am not certain how well the Android version of Twitter fares with Talkback or other Android accessibility aids. [Update December 9, 2011: From what I gather from various sources, the newest version, published a few hours after I posted this article, has been rendered completely unusable for Talkback users.]

There’s also a web client called Easy Chirp (formerly Accessible Twitter) by Mr. Web Axe Dennis Lembree. This one is marvelous, it offers all the features one would expect from a Twitter client, in your browser, and it’s all accessible to people with varying disabilities! It uses all the good modern web standard stuff like WAI-ARIA to make sure even advanced interaction is done accessibly. I even know many non-disabled people using it for its straight forward interface and simplicity.

For iOS, there are two more Apps I usually recommend to people. For the iPhone, my favorite Twitter client is TweetList Pro, an advanced Twitter client that has full VoiceOver support, and they’re not even too shy to say it in their app description! They recently even added such things as muting users, hash tags or clients, making it THE Twitter client of choice for me for all intents and purposes.

Another one, which I use on the iPad for its native interface, is Twitterrific by The Icon Factory. Their iPhone and iPad app is fully accessible, the Mac version, on the other hand, is totally inaccessible. On the Mac, I use the client Yorufukurou (night owl).

A similar picture can be painted for Echofon. The Firefox extension and desktop clients are largely inaccessible, the iOS version is.

Oh yes and if you’re blind and on Windows, there’s only one client available for you, which is becoming the successor to Qwitter, Twitmonger. It’s designed specifically for the blind with hardly any visual UI, and it requires a screen reader or at least installed speech synthesizer to talk.

In short, for Twitter, there is a range of clients, one of which, the EasyChirp web application, is truly cross-platform and useable anywhere, others are for specific platforms. But you have accessible means to get to Twitter services without having to use their web site.

Facebook

Facebook recently rolled out a big design update, with something called a FB timeline and other visual goodies or baddies, depending on who you talk to. And while the previous version took step by step to become quite accessible, this new design takes it all away again. It pops open stuff in locations somewhere in the middle of the HTML code (and therefore the middle of the virtual documents screen readers create), without setting keyboard focus there and allowing straight interaction. The timeline that can update by the second is a beast to try and keep track of things. Missing heading structure makes it hard to find things or organize one’s usage patterns. As it stands now, I cannot even answer friend requests using the standard interface. I have to resort to the mobile version to do this. This version is, however, so stripped down in functionality that it is very cumbersome. And the mobile stuff behaves as if folks at FB think mobile phones have never heard of JavaScript before. Everything you do triggers a full page load and therefore is slow as hell.

For the rare occasions I use that social network, the stuff I have to do like answering friend requests has become even more cumbersome, because depending on what I need to do, I have to switch between the standard and mobile interfaces now. Even more annoying than before!

Clients

Well, I know of only one client, really, the iOS one also published by Facebook. I know there’s an Android client, too, but have not used it. The iOS app has problems on and off with accessibility on the iPhone. On the newly released iPad UI, there are even more problems. You cannot post a status update if you have to use VoiceOver, from the iPad, for example.

Facebook Messenger has even more accessibility problems, lots of unlabelled buttons, and the messages themselves aren’t read, only the names and time stamps.

For chat, I am using Adium with the Jabber interface to Facebook chat.

Google Plus

Google Plus was THE most hyped thing of the summer hole, and as fast as summer went, so did people lose interest in it. And you know what? That’s well deserved! The Google Accessibility team said at launch that “accessibility was considered up-front” in Google Plus. Guess what? Consideration was mostly what there was to it, hardly any deeds had been following those considerations. Adding people to circles, posting a status update and choosing the circles to post to… It was cumbersome, it was in large parts unuseable with the keyboard, much less a screen reader. I became so frustrated with it that I deleted my account after 3 weeks, and I won’t be coming back. If you are interested in a more thorough review, find Kevin Chao’s posts in the “Accessible” Google Group where he talks about the problems of Google Plus and their iOS app, which also fails accessibility.

Yammer

Yammer is an enterprise social network we at Mozilla and in a lot of other companies use for much internal communication. It also has some serious accessibility issues, but also has a responsive Twitter account where I quickly came in contact with a person to talk to about the problems I’m having. Right now, for example, I cannot post status updates myself since that widget isn’t keyboard accessible.

iOS client

The iOS client for this web app also has problems. There, I can post, but I cannot read any other’s posts. The VoiceOver support doesn’t include the actual text of a post in any of the views. But again, the team who produces the iOS app also belongs to Yammer, Inc., so hopefully we’ll be able to resolve these soon!

identi.ca

identi.ca from Status.net is a microblogging service similar to Twitter. And unlike Twitter, it’s accessible out of the box! This is good since it does not have a wealth of clients supporting it like Twitter does, so with its own interface being accessible right away, this is a big help! It is, btw, the only open-source social network in these tests. Mean anything? Probably!

Conclusion

Out of all the social networks I tested, only the last one, the open-source identi.ca service is accessible up-front. All the others have issues right away, or introduced severe issues upon relaunch/UI update.

In looking for reasons why this is, there are two that come to mind immediately. For one, lack of knowledge or gaps in the test coverage. If all testers or developers of web applications would put the mouse away or disable their track pads for just five minutes and test their own stuff with just the keyboard, they’d be surprised at how many issues, most of them super simple to fix, they’d find! This knowledge can be refreshed. There is a wealth of information out there on accessible web design. And there’s a community that is willing to help if pinged!

Another reason is the common misconception of many managers or other business decision makers that accessible web design is far more expensive than just leaving it out. You’re only right on that count if you continue to consider accessibility as an after-thought only, having to build it on top when asked, complained, getting bad press or even getting sued. If you decide to allow your developers to put in accessibility up-front, making inclusive design decisions, you’ll still find that it requires a bit more testing, but won’t require nearly as many resources as it would to build in accessibility after the fact.

Another suggestion: Look at what others are doing! Learn from them! Don’t be shy to ask questions! If you look at what Yahoo! have been doing for the last three years, building inclusive design patterns into all of their web apps including the latest Yahoo! Mail update, you’re seeing an example of that it can be done, rich in functionality and visual esthetics, but still fully accessible!

I know that it isn’t quite New Year’s Eve yet, but my hope for 2012 would be that more social network makers would take the word “social” in their business slogans more seriously and start thinking inclusively rather than excludingly!

The premise

The base for my talk is my third easy ARIA tip, where I enhanced a form with some basic local form validation to help users fill it out and avoid errors upon submission. If you are not or no longer familiar with what I did there, stop reading here and go read that post again as a recap. If you are caught up, let’s move on!

From WAI-ARIA to HTML5

Since then, a lot of time has passed, and we’re now much better equipped with native markup magic that HTML5 supplies us. Thankfully, Firefox and also other browsers implement most, if not all, these features now, so we can move ahead with our changes. To remind you, WAI-ARIA is there to enhance, not substitute, native markup, so whereever possible, we should use native markup when available. These changes are:

1. Strip all JavaScript: Let’s start clean and see how far the new native markup stuff gets us!
2. Throw out all aria-required="true" instances and replace them with the HTML5 required attribute. This gives us automatic flagging of a required field not only via accessibility APIs, but also through visual indicators. Also, a required field is automatically flagged as invalid if it is empty.
3. For the field ‘name’, add a pattern attribute containing a regular expression that defines a valid name consist of some characters, one space, and some more characters. This will cover most cases, and if you’d like something more complex, consider me giving you some homework.
4. The field “email” gets the type “email”, the field “website” gets the type “url” set. This gives us proper validation of e-mail addresses and URLs respectively right upon entry. Moreover, on mobile devices with a virtual keyboard, the most common extra keys are usually provided right out of the box.

In addition, for a better error message, I am using the non-standard x-moz-errormessage attribute on the “name” field to tell users that the name was entered wrong rather than the standard “patterns don’t match” error message the browsers usually throw at users in the instance of them having entered a wrong value.

In addition, the name field contains (already in the ARIA example) a title attribute that tells users that a name must consist of at least two words.

Filling out this form now gives us validation upon submission. Firefox sets focus back to any invalid field it finds when users press the “submit” button. In addition, an error message is displayed describing the problem.

…and back

Our original example, however, was better in that it provided validation right at the point when an entry lost focus. Since this is a dynamically created alert box that is not yet a native HTML5 element, we have to resort to WAI-ARIA again to make this work the same, but using the HTML5 validation benefits. So, let’s enhance our example:

1. Bring back the first two functions from the original ARIA version unchanged. These remove any existing alert box, and they create a new alert with the given message.
2. Adjust the function that is called in the onblur handler of the “name” and “email” fields (see below):
   1. First, we have to adjust the function name to something that doesn’t clash with a reserved word. I used testIfEntryIsValid.
   2. Now, get rid of the search string and error message parameters. These are no longer needed because the validation is done by the browser, and we simply use the HTML5 form constraints API to ask the browser for the relevant info. Also, the browser provides us with the appropriate error message, so no need to generate one ourselves here.
   3. In the if clause, simply ask if the call to the checkValidity() method of the element we obtained in the line above gives us a “true” or “false” result. If true, simply remove the old alert. If false, create an alert and use the element’s validationMessage property as the message parameter. The browser will handle the rest for us.
   4. Remove the lines that set aria-invalid. These are no longer needed, since the browser’s constraint validation will provide the invalid or valid states automatically.
3. For the “name” and “email” fields, add back onblur handlers pointing to the above function and simply pass in the field’s ID.

Testing this example, it shows that we’ve got our original functionality back. In addition, if we ignore the intermediate error messages, the browser’s validation mechanism will throw us back to any of the wrongly filled out fields upon a submission attempt. Note that not all browsers do this last step. Safari on the Mac, for example, will submit the form even if it contains invalid entries.

In summary

The new version of our form is much improved over the version we had originally. It still contains some WAI-ARIA where it makes sense, since there is no native HTML5 alert box yet. But the rest is HTML5. The JavaScript code is a bit less bloated since we don’t have to do our own validation any more, and we benefit from all the builtin constraint validation mechanisms.

Feedback is welcome! But before you throw things at me for my sloppy JavaScript, please keep in mind that this is just a proof of concept. If you would like to re-use this technique, I encourage you to put your best knowledge to use and put in better handling of events or such, appropriate for your web application.

The example pages can be found (in English and German) at this address. Happy hacking!

First and foremost, the emphasis in this release was on performance and stability. We fixed a number of lingering crashes and inconsistencies on both Windows and Linux that may have impacted some users in Firefox 7. An example of this is inconsistent behavior when printing in Linux and using assistive technologies.

We fixed a bug that would sometimes cause iframe content not to be properly loaded into the virtual buffers of screen readers under Windows.

On Linux, access keys are now included in ATKAction information.

A state change event for elements having the “mixed” state (e. g. a tri-state checkbox) is now fired also for elements that aren’t in focus.

If you decide to opt into sending data to improve Firefox, we’ll be told if you have accessibility instanciated. This is most likely the case when you have a screen reader running, but may also be instanciated by some password entry assistants (like finger print scanners) or some anti-virus software, esp on Windows.

And once again the note that, due to a technical change introduced in Firefox 4.0, you have to make sure to load your screen reader before Firefox or Thunderbird, or virtual buffers may not work correctly. Also if you are one of those people running multiple screen readers, make sure to shut down Firefox and/or Thunderbird before shutting down one screen reader, and loading the other screen reader before restarting Firefox and/or Thunderbird. This is true for Firefox 4 onwards and also includes Firefox and Thunderbird 8.

Happy browsing!

Among the improvements this rework introduces are bug fixes to some long-standing problems we were having, but could not solve in an easy-to-do manner because of the previously used architecture. For example, handling of focus inside of html:select elements whose size attribute has a value of 2 or greater, has been greatly improved. Now, one knows immediately which item is selected, if any, or even if multiple items are selected if the control supports it.

Also, entering the menu bar or context menus when inside a multi-line edit field AKA html:textarea element, has been improved, and focus is no longer stuck when coming back out of those menus and tabbing or shift-tabbing around the page afterwards. Also, some inconsistencies when entering some edit fields has been fixed for assistive technologies that use IAccessible2.

Handling of autocomplete popups has been improved as well. Assistive technologies now get proper events for the popup’s selected autocomplete item and other associated information.

There’s more, but these are the most user-facing ones.

Users of NVDA and Orca should notice improvements immediately, although both projects told me they’re looking at the builds and see if they need to rework/remove any workarounds they might have had to put into their sources for our lack of proper events/states. Other supporting assistive technology vendors will be contacted by us and urged to do the same for their end users so the user experience will be much improved for everybody.

If all goes according to our rapid release cycle, this will be in Firefox 10, the first release coming out in 2012. If you’re on the Nightly builds and testing the most cutting edge stuff, you already have this code running if you’re on the 2011-09-29 build or later. If you’re on Aurora, you’ll be getting this in mid November when we merge the next time. This code will hit beta in late December.

If you’re running the nightly build now and would like to tive us feedback, please feel free to do so! We’re always interested in your findings and welcome any and all feedback on this you might have. If you’re noticing any inconsistencies, we wanna know about them so we can address them in due time!

First and foremost, we participated in the improvements to memory usage and speed. More accessibility classes participate in our garbage collection mechanism, reducing the memory consumption greatly. Long sessions with a screen reader running should no longer result in huge amounts of memory being consumed. This is especially evident if you run with multiple tabs and open lots of pages.

A bug was fixed that caused large additions to xul:tree elements to hang for long times when accessibility was turned on. This could be observed in add-ons such as Adblock Plus on occasion.

If role="presentation" has been specified on an element and this element is made focusable, for example by setting tabindex="0" on it, the role of presentation is now ignored, and an accessible is created for the element nevertheless. This is to avoid situations where one would suddenly land on a focused item for which there is no accessible. This was the cause for some screen reader confusion.

On HTML table elements, the way the summary attribute and caption elements were handled has been switched around. Now, if the caption element is present, it becomes the primary source (ARIA not withstanding) for the name of the table. summary is now being converted into the accessible description, which is used to communicate additional information to users. Only if the caption element is omitted, summary will still become the accessible name’s source. Until Firefox 6, summary would always become the accessible name’s primary source. This brings Firefox in line with other browsers. Also, if assistive technologies query for the relation between the caption and table elements, the relation is now LABELLED_BY instead of DESCRIBED_BY.

In addition, some crash bugs were fixed that were found in earlier updates of Firefox, so this version is not only less memory-hungry and faster, but more stable, too. Happy browsing!

For my testing, I used the latest release of Firefox, version 6.0.2, and NVDA 2011.2 (the current release). I also found that it is a good idea to look in the Mail Accessibility help, and there especially the keyboard shortcuts.

First steps

Armed with this information, I logged into my Yahoo! mail account. First, I was prompted to switch to the new Yahoo! mail. Go ahead and do so if you haven’t done already.

I was then greeted with the What’s New tab of the new interface. This is a web document one can browse to find out the latest headlines, but at the top it also gives you the choice to switch to your inbox. It tells you how many unread messages you have, and how many in total.

The inbox

I went ahead and activated the link to go to the inbox. What followed was a switch to focus mode from the default browse mode. The reason became evident: i was no placed in the messages list, a rich widget that allows for navigation through the messages with the arrow keys up and down. Speech feedback is just marvelous, one gets all the relevant information one would expect to hear, just like one was in a desktop client like Thunderbird or Outlook.

Also, as can be seen in the above linked to shortcuts list, a lot of shortcuts that are familiar from desktop clients simply work in this e-mail client, too: delete deletes a message and provides great speech feedback, r initiates a reply, f forwards one. Yes, these are different from Thunderbird and Outlook, but hey, with each new program, you have to learn some new shortcuts, even when switching from Outlook to Thunderbird.

Reading a message

Pressing enter opens a message for reading. And here’s one of the beauties of this WAI-ARIA enabled e-mail client: The markup used is really being used in a sensible and intelligent way. While the messages list definitely needs to be treated in application mode, the message itself is a document and thus should make use of NVDA’s browse mode (virtual cursor). And this is exactly what happens. Without having to do anything, NVDA will switch to its browse mode and start reading the e-mail you just opened. If this is an ordinary e-mail message, there is a reply box right at the bottom, so one can answer the e-mail from here. There is no quote functionality, though, so if you want to do some fancy stuff, you’ll have to use the full e-mail dialog that you can reach by hitting r from the messages list.

Pressing escape brings one out of the message and back into the message list. It remembers the position, so one gets put right at the spot where one wants to continue browsing messages.

More to find

Tabbing around the main interface, one finds several tool bars. Again the keyboard navigation is very smart: Tab jumps from the higher-level items such tool bars to the next, while, when in a toolbar, one can inspect each available option within it using left and right arrow keys. So even if a tool bar contains 10 items, tabbing will only stop once on the tool bar. If you do not want to go through the 10 items, you don’t have to.

The Contacts tab works in a similar fashion as the mail tab, where you can manage your contact list, import from other accounts etc. The switch between application and browse modes is seamless as on the inbox tab, and information is presented in a very comprehensive manner.

Speaking of tabs: There are instructions given on navigation wherever something might work slightly differently from what one is used to from desktop applications. For example when focused on the tabs, one is instructed to navigate left and right, and that enter will actually make that tab active. In Windows applications, simply focusing different tabs already makes them active, so this is a slight difference between the interaction models which is clearly communicated. Very nice!

Social networks

The fourth of the default tabs is called “Updates”, and it allows you to connect your Yahoo! profile with those you have on Facebook, Twitter etc. While the tab itself is mainly for configuring those updates and for sending updates to the connected social networks, the reading updates app gets launched in a new browser tab. That one is a regular web site that gives you a good, and more importantly, fully accessible overview of your Facebook and Twitter timelines. While both social networks still have their accessibility issues to sort out, Yahoo!’s interface to these is fully accessible and hardly leaves anything to be desired.

Setting prefs

From the main navigation area, you can open the options/preferences for mail and other parts of the Yahoo! set of web applications. Especially in the mail preferences, you can set a few things to make your life a bit easier. One is to have messages displayed in paginated form, which gets rid of the preview pane and other stuff that might get in the way of accessibility. Also, you can set to have the inbox tab selected upon login automatically. This is something that I set since I want to do mail when I log into mail first.

You can also connect other mail accounts here. This is one of the few areas which irritated me: The link to add an account is at the very top of this virtual document, near the “Save changes” button, not down in the explanation of what adding accounts actually means, as I would have expected it to appear.

Third-party apps

One can include third-party apps in the Yahoo! mail interface. There is an app called “My social networks”, for example. These, as they are being developed and delivered by third-parties, are not guaranteed to have the same level of accessibility. Some may even be entirely inaccessible, because they use plugins such as Flash or Silverlight and may not adhere to accessibility standards within these platforms. But Yahoo! is not to blame for that. Instead, accessibility should be evangelized to those content providers that have the powers to make their apps accessible.

In summary

What Yahoo! are delivering here is a really outstanding example of putting the WAI-ARIA and other HTML accessibility techniques to very good use. WAI-ARIA has previously been deployed mainly in some enterprise/intranet or specialized public sections and gained limited exposure. Yahoo! mail is the first mainstream web application to put this technology to use and deploy it to a wide range of users worldwide.

Personally, I can even see myself switching to a web client away from a desktop client for the first time since this is the first instance of a web e-mail client that I found I can use as productively as my favorite desktop client. Other examples like the big G are far to inefficient, and for my work, the Zimbra web interface is totally inaccessible, so I have to use a desktop client for these.

Yahoo! Mail, along with the very accessible rich search interface, is a very good example of an all-inclusive, accessible, web application approach that puts others to shame that suggest to turn off their standard interface and use a basic one if one uses a screen reader. Needless to say, that basic interface is then severely limited in functionality. Or the same company that suggests to turn off their instant feature if one uses a screen reader, or search results might no longer be really accessible. Yahoo! are taking an inclusive design approach here that to my knowledge is unparalleled among big stock holder web app companies.

Of course, there are still some small kinks to work out here and there. if one uses the German version of Yahoo! Mail, for example, closing a tab requires a different keystroke than the English Ctrl+\. Unfortunately, the German version of the Mail Accessibilit yhelp topics don’t seem to have been translated yet. Searching for Barrierefreiheit didn’t yield any results, and searching for Zugänglichkeit only gave a general page about My Yahoo! accessibility, but nothing specific to mail. But I am sure these are things that will be fixed/documented in a timely manner so people whose first language is not English can benefit from the features in the same way.

I applaud Yahoo! for their newest version of the mail interface for its inclusive design principles and good accessibility for everyone! Keep up the good work!

If you’d like to read this article in German instead, here’s the translation on my German blog.

Non-Visual Desktop Access (NVDA) is the best free screen reader solution for Windows and an open source project. It provides feedback via synthetic speech and Braille and enables blind or vision impaired people to access computers running Windows for no more cost than a sighted person. The NVDA developers work closely with Mozilla to ensure a great user experience with every Firefox release. Over the past few years, the projects have joined forces numerous times to drive new web technologies such as WAI-ARIA forward and into the hands of blind people so these could participate in the open web just like their sighted counterparts.

Its because of this close, ongoing link with NVDA that Mozilla has awarded a $80k grant to NV Access, the non-profit group overseeing NVDA. The grant will enable NVDA to improve the rich text editing and viewing experience as well as make general improvement over the next year.

You can help accessibility for the web by getting involved with the NVDA or Mozilla projects, or even coming on board at Mozilla Co!

As this was a bigger update, it is time to also point out the new stuff to watch out for in accessibility. One thing I already blogged about is the HTML progress element, so I won’t cover that here. Some of the other things to be aware of are:

Seamless plugin accessibility integration on Linux

One feature that’s been baking in a bug forever, but which finally got its final push and made it into code is plugin accessibility for Firefox on the GNOME Desktop on Linux! There is only one plugin currently called Moonlight that actually uses this, but if other plugin authors want to, they can now plug into Firefox and expose their accessible content to Orca and other assistive technologies.

The Windows magnifier and the writing caret

There is a problem in Firefox 4 and 5 that will prevent Windows Magnifier and possibly other low-vision products from tracking the writing cursor properly when on the URL bar or in some other places. We were able to fix this in Firefox 6.

Improvements to the notification popup

The new notification popup that asks, for example, whether you want to save an entered password, has been improved a great deal. For one, it now announces itself to assistive technologies as an alert like the old notification bar did, which means that the text that the user is to be notified about is automatically being read by NVDA, JAWS and others. Secondly, we made the “Close this message” button tabbable again. One thing that we didn’t manage to solve in time is the inconsistency with the menu button that, when SPACE is being pressed on it, doesn’t actually do much, but you have to tab to a secondary regular button with the same label to get the actual function. We’re working on a solution to improve keyboard accessibility for these menu buttons in general, and the notification popups will benefit from this as we do.

ARIA support

In regards to WAI-ARIA, there are a number of changes/additions:

• aria-sort now fires attributechange events when its value is being changed.
• aria-selected is no longer being ignored for ARIA tabs.
• aria-busy now properly fires statechange events.
• ARIA documents children can now properly be queried via accChild API methods.

Others

Other noteworthy fixes are:

• The Untrusted Connection page is again accessible via the virtual cursor in screen readers.
• When deleting text from edit fields, the wrong text was reported through at-spi. We fixed that problem.
• We got rid of the bogus pref accessibility.disableenumvariant.
• The About… dialog is more readable than it used to be.

This means that web devs can use the progress element in web applications, and we will now no longer expose the alternative text enclosed in the opening and closing tags, but the actual visual representation of a progress meter. The accessible object for the progress meter will expose the AccessibleValue interface for all relevant platforms (e. g. ATK and IAccessible2), so that assistive technologies can query for not only the value string but also the float values for:

• the current value
• the minimum (always 0)
• the maximum (if not specified, the default is 1 as in the specification)

By default, NVDA will expose the current percentage as you can test in this example with a current version of NVDA.

Note that there were no changes required on NVDA’s side to support this. So if your screen reader currently supports WAI-ARIA progress meter elements, and the screen reader does not do any funky stuff with their own HTML parsing here, this should just work.

Another note: While we were here, we also fixed a few things regarding XUL:progressmeter elements that were buggy in the past, but were not really uncovered until now. The user visible impact will be minimal for this, but for our code this was definitely benefitial, as we’re now dealing with the proper maximum value for xul:progressmeter elements, which differs from the default max for html:progress.

For Firefox 5, however, the focus has been on polishing and stabilizing what we delivered in Firefox 4.

To that effect, the very first builds of what we call the Aurora channel are now available. The above linked post has more details.

For those of you interested in the very technical details, we have several bug fixes for crashers, inconsistencies when building the accessibility tree, and other not so obvious fixes in that improve performance and stability.

You’re welcome to try out these builds and give us feedback as always! Aurora builds are more stable and feature-frozen builds that get stabilized in the weeks leading up to the next Firefox release. The next Firefox release will be Firefox 5, expected at the end of this quarter.

Enjoy!

This is a major update that brings a lot of new features and enhancements as well as loads of stability and performance fixes to your browsing experience. And of course it is accessible!

Some recent posts on the subject by me:

1. New in Accessibility in Firefox 4
2. New support for HTML5 elements and attributes, with a lively discussion and some revamping going on for a very near future update esp to the landmark piece

If you’re a user of NVDA, Orca, JAWS, Window-Eyes, Dolphin SuperNova, Serotek System Access or Baum Cobra, you’ll be good to go with current versions of the products! Please make sure to update to the latest revision for your screen reader that you can access before using Firefox 4, as it was reported to us that some early revisions of JAWS 11, for example, cause problems invoking the virtual buffer.

We expect all screen magnifiers that worked in Firefox 3.6 to work in 4, too. Same goes for speech recognition and other assistive technology programs on Windows and the GNOME Desktop on Linux.

The problem was that the nightly build beta 11 was based on arrived late in my day so I had already gone off-line and didn’t see it until build candidates for beta 11 had already started. When I came to my desk early the next morning, downloaded the nightly build, I immediately noticed the problem on sites like the Google homepage where suddenly, NVDA would no longer see the search textfield. On other sites, images, separators and other parts were also missing.

Had we shipped Beta11 with this bug, we would have left users with a largely unusable beta release and would have lost valuable feedback.

My first action item was to talk to Alexander Surkov, the accessibility module owner, about this problem. He then filed the bug since he immediately found what was wrong.

An hour later, he gave me a patch to try. I started a local build based off of the current code base, with the patch applied, and within 90 minutes, was able to confirm that this patch fixed the bug.

I then ran that local build, whose build configuration was very close to what comes out of Tinderbox for releases and nightlies, for the remainder of that day to make sure the patch didn’t introduce any negative side effects. Also, the patch had to get proper reviews and approvals.

In parallel, I wrote an e-mail to the release drivers and QA mailing lists explaining the problem and its severity, and asked for permission to take this patch on the beta11 release branch and respin beta11 with a third build candidate. Luckily, this was a very contained fix that didn’t invalidate any of the other QA testing that had already gone on. I assured juanb about this fact as part of this process. In addition, the patch had unit tests that now properly covered this area of the code so a likelyhood of this regression being reintroduced is now minimized.

Fortunately, we could take another obvious fix, a crash fix, as a ride-along which would have given us false crash data otherwise of a crash that was already fixed.

After the release driver crew had evaluated my proposal, I got approval to land the fixes on the release branch for 4.0Beta11.

I checked in the code myself and pushed to the Mercurial repository, in effect taking responsibility for keeping the tree green or breaking things.

Well, as you all have seen over the past weeks, the tree didn’t break, and you all got Beta 11 early the week after, with NVDA perfectly being able to read Google.

As a post-mortem, I then explained how it happened that this bug slipped me initially.

All in all, this was a very good team effort: From finding the problem, analyzing it and then making sure we could deliver the fix to users at the lowest possible risk, it was a good experience taking charge and driving this forward, working with people from different teams such as a11y, QA, release engineering etc. to get the fixes landed in an orderly manner and without having to re-test everything that had been done already. The delay was minimal, but the gain was extremely high!

Landmark elements mapped to WAI-ARIA landmark roles

We are mapping the following HTML5 landmark elements to accessibles with WAI-ARIA landmark role semantics:

In a second small patch landing the next few days, we will also map the html:aside element to the “complementary” role. This was a small oversight on our part in the first patch.

Both NVDA and Orca will pick these changes up without any additional action required on their parts. Other screen readers will hopefully implement or pick up the support ASAP so web authors can use these new elements without having to worry about support or lack thereof.

The placeholder attribute

This attribute can be used on form elements to predefine text that disappears as soon as the field gets focus. It#s a visual indication of what is expected in the field. If, and only if, the field has no label otherwise, this placeholder text will be used to generate the AccessibleName, the name the screen reader speaks for the field when it gains focus. If the field has a label provided by the label element or an ARIA construct, the placeholder text will be ignored.

Proper events being generated when required/invalid/disabled states change

For a few weeks now, we have had support for the disabled, required attributes and the invalid state evaluation of patterns. Now, if any of these conditions change, we now generate the proper StateChange events to notify screen readers and other assistive technologies.

API support

Most of the changes are under-the-hood changes that do not have API changes as a consequence. There is one new addition that helps get around the now absent window hierarchy, see this post for details and bug numbers if you’re interested.

However, there are a few enhancements that one should be aware of:

Speed

Improving speed was one of the major goals for Firefox 4 in general, and also for the accessibility APIs. A couple of highlights:

• A site like BlindCoolTech, when loaded into the virtual buffer by NVDA, took approximately 6 to 6.5 seconds when loaded with Firefox 3.6.x. With Firefox 4, we’ve managed to cut this time down to under 1 second!
• We also support the very performant Lazy Frame Construction in a very speedy manner so an accessibility-induced lag should hardly be noticeable.
• When calculating meta data for big data tables, we’ve improved the speed by a huge factor. While Firefox 3.6 sometimes would hang for over 5 minutes while calculating data for a 20,000 cell table, this takes only a few seconds now.

New HTML5 elements

We have support in place for the following HTML5 enhancements of Firefox 4:

• The html:output element is supported. We expose it as a text frame, and if it is being controlled by a form or form element, we also properly set the AccessibleRelations. In addition, it receives the implicit attribute. Screen readers will therefore read text inside the output element automagically.
• We have support for the required attribute by setting the ‘required’ accessible state flag on the accessible.
• We’re also working on getting the invalid state supported for the final Firefox 4 release.
• New HTML5 input types like email, number etc. have basic support and are all viewed as text fields currently.

Changes in the WAI-ARIA support

We made changes to the WAI-ARIA support as the spec developed to the new last-call state. We removed features that are no longer supported in the specification. And we made the change that the aria-labelledby attribute now takes precedence over aria-label. When first implemented in Firefox 3.5, and for a long time in the specification, aria-label took precedence over aria-labelledby when used on the same element. Now, this is swapped around. If aria-labelledby is present, aria-label is being ignored.

Bug fixes

Of course, we also fixed a lot of bugs on the way, making the code more stable and secure. Some are part of the performance refactors, some specifically targetted. For example, there are HTML constructs that can cause bad hangs on Linux which we finally nailed down and fixed.

UI and keyboard navigation

There have been several visible UI changes, some of which also have consequences for keyboard users.

Tab strip moved to the top

The tabs moved to the top of the screen, now encompassing the URL bar and search field. Previously, these were not part of the active tab. As a consequence, the tab bar is now reachable by:

1. pressing Ctrl+L to go to the awesome bar
2. pressing Shift+Tab twice to land on the tab bar

So instead of pressing Tab twice when on the awesome bar, now it’s Shift+Tab twice. Other features like accessing the context menu for a tab by pressing Applications remain unchanged.

Pinned tabs

Pinned tabs are tabs that remain visible even when there are so many tabs on the tab bar that it needs to scroll. So your favorite tabs are always visible/accessible. For screen readers, there is currently no distinction between a normal and a pinned tab, but it is exposed nevertheless. And obviously, the context menu item is accessible.

The menu bar is gone, but not quite

The menu bar is no longer visible right away. Instead, a single popup menu, hidden behind the “Firefox” button, is replacing most of the menu bar’s functionality. However, as a keyboard user, you don’t really notice. Press Alt, and the menu bar reappears and you can use it right away again. In fact, I, being blind myself, didn’t even notice that the menu bar was gone because I was simply using the shortcut keys like Alt+F just as I did before. It was not until Surkov asked me whether the Firefox button was accessible that I noticed that there was a UI change.

Note that there is talk of mapping the Alt+F keystroke to specifically open the menu hidden behind the Firefox button in the future. So if Alt+F no longer brings up the “File” menu in the future, this is why.

Add-Ons Manager redesign

The Add-Ons Manager has been redesigned completely. It now also manages Jetpacks, search engines and much more. Moreover, it opens in a new tab instead of a modal dialog. This makes interaction much nicer, one does not have to alt-tab between windows all the time.

There are still some keyboard navigation quirks to be worked out, and some of this may come in an 4.0.x update, but the general functionality is there also for screen reader users.

New UI features that don’t work (yet)

Panorama

The new enhanced tab management feature Panorama, previously known as Tab Candy, is currently not very well navigagble using the keyboard, and hardly exposes any useful information to screen reader users. However, it is going to be possible to make these accessible, we just need a little time to do it. If you’re interested, you can follow the keyboard navigation and assistive technologies support bugs to watch progress.

It all started with Bug 130078, a sequence of digits probably everyone in the Mozilla platform team will memorize for a long time. What this patch essentially did was remove all but the most top level window from the window hierarchy so commonly used in Microsoft Windows. In Windows, every window (visible and otherwise) usually is associated with a window class, a string that loosely identifies what the window does. Experience having worked with a screen reader vendor for 8 years, however, has shown that this can also be quite bogus stuff. In the dark ages of Windows development, where there was virtually nothing else than screen scraping and some basic MSAA, this was the most reliable way for screen readers and other software to identify certain parts of the UI of an application.

However, times are better now, and have essentially been, since Firefox 3.0. There, we already knew that this removal of several window widgets with associated class names, would be upon us one day. So we started evangelizing with screen reader vendors to use newer, more future-proof methods of finding our accessibility information. But as time went by, this somehow got lost by the sideways, and suddenly, August 27, 2010, was upon us.

This was the day when Bug 130078 landed on the Mozilla-Central Mercurial repository. The August 28 nightly build was broken for all screen readers on Windows. Subsequently, I filed Bug 591874. In addition, the landing of Bug 589529 made things even worse for some of the screen readers, since now, no focus events or such were processed at all any more.

This, and David’s alert blog post, shook up assistive technology vendors, open-source and commercial alike, enough so they started to tell us what kept them from using the newer methods, or what additional things they’d require to be able to work without relying on the Windows widget information any more. Subsequently, Bug 592913 was filed, which, when fixed, did get NVDA back in working order. With some adjustments on their end, which are included in the recent NVDA 2010.2Beta1 release, they are now able to work with both Firefox 3.x that still has the window hierarchy, and also Firefox 4, which has the newer method for them to get all the information they need.

A second bug, Bug 594413 is going to land very soon, which should give all those assistive technologies still primarily using iSimpleDOM to also get all the required information without having to rely on Windows widgets.

As a fall-out from the above fixes, we had to deal with Bug 594775 and some fall-out from that as well, but believe we now have most things in order again. Most, if not all of this will be in Beta7, so the user experience should again be much better than it was in beta 5 and 6, and users can again experiment with the newest and greatest Firefox beta versions.

Also, the above quoted bug 591874 is fixed now, giving select older versions of commercial assistive technologies the benefit of an emulated window hierarchy, so users do not need to upgrade their screen readers at a fee to be able to use Firefox 4. However, it must be stated that this is not going to be there forever, so we strongly recommend that software that still relies on this window hierarchy use the better and more reliable methods to detect our accessible tree and get away from using things like MozillaContentWindowClass to rely on. We now turn this emulation on only for some commercial screen reader vendor versions, but strongly suggest to also backport the new solutions to older existing user bases as soon as possible. It will go away, but we haven’t decided yet when exactly that will be.

Talk to us, we’ll be glad to assist you!