Progress on Mac accessibility work in Firefox

Posted on April 13, 2012 by Marco

This is an update for all who are interested in our Mac accessibility implementation.

After I blogged about this topic last time, we entered into a bit of a rough time having to do with the text interface of the Universal Access protocol. If you want to read the full details, look at this epic bug.

After that was finally done, which added the capability to interact with text using regular VoiceOver commands, and an associated children caching bug was also fixed, work has now picked up pace again in implementing the finer points of web content accessibility:

  1. Password fields are now accessible, as well as many other types of edits.
  2. Labels are now properly exposed. This includes that input elements nested within labels are now being seen by VoiceOver.
  3. List items on web pages will very soon be exposed properly.

With these all out of the way, I believe it’ll be very very soon that we can offer you all a build to test.

A few known issues we will be working on next:

So the list is down, and I actually don’t deem any of these bugs critical in blocking a release to a wider audience. But I am not the one making that decision here, so this is not an announcement. ;-)

Stay tuned to this blog for further information if you’re interested in testing out a Firefox build on the Mac that has VoiceOver support enabled!

flattr this!

Posted in Accessibility, Apple, Firefox | Tagged , , , | 6 Comments

If you use the WAI-ARIA role “application”, please do so wisely!

Posted on February 6, 2012 by Marco

This goes out to all web developers out there reading this blog and implementing widgets and other rich content in HTML, CSS and JavaScript! If you think of using the WAI-ARIA role “application” in your code, please do so with caution and care! And here’s why:

What is it?

“application” is one of the WAI-ARIA landmark roles. If you’d like to read up on landmarks, please go here. It is used to denote a region of a web application that is to be treated like a desktop application, not like a regular web page. In other words, if you use something that is not part of standard HTML, like a mashup widget, and your page has no resemblance to a classic document in, roughly, over 90% of its content, “application” is for you. If you, on the other hand, make up a user interface solely of elements that are part of standard HTML like selects, check boxes, text boxes etc., and in addition use only common compound widgets and lots of document-like content like hyperlinks, you will most probably not want to use “application” because browsers and assistive technologies provide a standard interaction model for these already and don’t need special support from you in that.

Why use it at all?

Traditionally, assistive technologies like screen readers for the blind convert a page’s content into a format that is easier for a person with a disability to comprehend. A two-column newspaper style text, for example, is reformatted so that the text flows from beginning to end like it would in a single-column document. Multi-column layouts of pages are streamlined so that there’s a structured flow a person who, for example, cannot see the screen, can understand.

For this, screen readers especially on Windows have adopted a two-part user interaction model:

virtual cursor or browse mode
This is the mode screen readers especially on Windows operate in when the user browses a web page. The term virtual cursor has been used since its inception in 1999 because this feels to the user like a document in, for example, WordPad or MS Word. The user walks the document using the arrow keys and has the text to them read via the speech synthesizer. In addition, semantic information is spoken to indicate whether a particular piece of text is a link, graphic, form element, part of a data table structure, list etc. In addition, several keys are captured by the assistive technology and are not processed by the browser. These allow navigation by headings, lists, links, tables, form elements and others. Usually, these are done via single letters. The visual focus may or may not follow the virtual cursor onto focusable items, depending on the assistive technology in use and its settings.
Forms mode or focus mode
This is a mode where the user interacts with elements that accept a form of data entry. This may be via entering text, checking a check box, selecting one of several possible radio buttons, or making a selection in a select element. This mode is either invoked by putting the virtual or browse focus onto such an element and pressing a key (usually Enter), or by the assistive technology switching to this mode automatically when the virtual focus encounters such an element. Others may only activate this mode automatically when specifically using the tab key. In this mode, all keys are passed through to the browser. It is as if you were sitting in front of your browser using it with the keyboard, and don’t have a screen reader running. Likewise, if the application focus leaves such an element that supports or requires direct keyboard interaction, if it was switched on automatically, it will be switched off and the user returned to browse/virtual mode. Note: Some elements like buttons and links do not require the user to switch into focus or forms mode, because for efficiency, screen readers allow activation of these elements directly from virtual/focus modes.

The challenge is that you may be creating widgets that require you to force the user into direct interaction with the browser. You know that your widget can best be used via the keyboard if the user is not in virtual mode. In addition, you know that you have no classic document content to display, but only use widgets and provide all necessary context through them. This is what role “application” is for. It is under your control whether the user is being thrown into focus mode once your widget gains keyboard focus. Also, contrary to standard focus mode, if an assistive technology encounters an area that is marked up with role “application”, it is usually not so easy to manually exit out of that mode to review the surrounding content in browse mode.

So when should I use it, and when not?

You do not use it if a set of controls only contains these widgets, that are all part of standard HTML. This also applies if you mark them up and create an interaction model using WAI-ARIA roles instead of standard HTML widgets:

  • text box. This also applies to password, search, tel and other newer input type derivates
  • textarea
  • check box
  • button
  • radio button (usually inside a fieldset/legend element wrapper)
  • select + option(s)
  • links, paragraphs, headings, and other things that are classic/native to documents on the web.

You also do not use the “application” role if your widget is one of the following more dynamic and non-native widgets. Screen readers and other assistive technologies that support WAI-ARIA will support switching between browse and focus modes for these by default, too:

  • tree view
  • slider
  • table that has focusable items and is being navigated via the arrow keys, for example a list of e-mail messages where you provide specific information. Other examples are interactive grids, tree grids etc.
  • A list of tabs (tab, tablist) where the user selects tabs via the left and right arrow keys. Remember that you have to implement the keyboard navigation model for this!
  • dialog and alertdialog. These cause screen readers to go into a sort of application mode implicitly once focus moves to a control inside them. Note that for these to work best, set the aria-describedby attribute of the element whose role is “dialog” to the id of the text that explains the dialog’s purpose, and set focus to the first interactive control when you open it.
  • toolbar and toolbarbuttons, menus and menu items, and similar

You only want to use role “application” if the content you’re providing consists of only interactive controls, and of those, mostly advanced widgets, that emulate a real desktop application. Note that, despite many things now being called a web application, most of the content these web applications work with are still document-based information, be it Facebook posts and comments, blogs, Twitter feeds, even accordeons that show and hide certain types of information dynamically. We primarily still deal with documents on the web, even though they may have a desktop-ish feel to them on the surface.

In short: The times when you actually will use role “applications” are probably going to be very rare cases!

So where do I put this thing?

Put it on the closest containing element of your widget, for example the parent div of your element that is your outer most widget element. If that outer div wraps only widgets that need the application interaction model, this will make sure focus mode is switched off once the user tabs out of this widget.

Only put it on the body element if your page consists solely of a widget or set of widgets that all need the focus mode to be turned on. If you have a majority of these widgets, but also have something you want the user to browse, use the role “document” on the outer-most element of this document-ish part of the page. It is the counterpart to “application” and will allow you to tell the screen reader to use browse mode for this part. Also make this element tabbable by setting a tabindex value on it so the user has a chance to reach it. As a rule of thumb: If your page consists of over 90 or even 95 percent of widgets, role “application” may be appropriate. Even then, find someone knowledgeable who can actually test two versions of this: One with and one without role “application” set to see which model works best.

NEVER put it on a widely containing element such as body if your page consists mostly of traditional widgets or page elements such as links that the user does not have to interact with in focus mode. This will cause huge headaches for any assistive technology user trying to use your site/app.

Some examples

The behavior that originally prompted me to write this is the newest version of the layout of Gmail. It looked to me like Gmail treats the whole thing as role “application”, causing the user to tab a zillion times before actually getting to the inbox message table. It turned out to be a bug which has been haunting us for a few months now, where parts of the accessible tree (the thing we create from HTML and CSS) gets detached from the rest, causing a very similar behavior in screen readers like role “application”. If virtual cursor was still active, the users could press t in their screen reader once and jump to that table right away instead of tabbing 30 or 40 times. A temporary solution to this problem seems to be this: Google provide us with keyboard shortcuts j and k. These can be disabled in the account settings of Gmail. That makes the bug disappear. Had Google used role “application” here, it would have been inappropriate. Gmail is, below the surface, still strongly document based and thus many traditional interaction modes do apply here.

An example where roles “application” and “document” are really used wisely is the current Yahoo! mail web interface. The table where the messages are being displayed in a list is marked up to be an “application”, because the arrow keys are used to navigate between messages, enter opens one etc. Once a mail is being displayed, everything around the actual mail header and text is an application, but the mail header and text are a document, so role “document” is used and initial focus is put there so the user can immediately start reading their mail in a familiar browsing fashion.

funny disclaimer: Yahoo! do not pay me for constantly calling them out as a good example of an accessible web app. They just did a bang-up job, that’s all! :-)

Closing comments

If you have questions about this, feel free to post them here on the blog, I’ll do my best to answer them and also incorporate answers to updates to this post. You can also find the Google Group free-aria and discuss questions there with other web developers, standards experts and users. This is an important topic that, if done right, can provide all your users with a rich and pleasant experience, but if done wrong, can also cause headaches, complaints, and cause your web app to be less likeable by a sizeable number of users.

So use role “application” only if you absolutely have to, and tests show that this provides the better interaction model! Use it wisely when you do it, it’s worth the effort!

Update February 7

I’ve incorporated comments that were posted to the original version of this blog post into the post, making the statements even stronger hopefully. Thanks to Jamie for pointing out a couple of very important points that make the point against using role “application” in most cases even stronger!

Update Feb 9, 2012

Google’s accessibility team contacted me, stating that they actually don’t use role “application” in Gmail. After further investigation, it turns out that this seems to be another case of a bug we’ve been hunting for months, but which the main person who can fix it, cannot reproduce. I’ve thus updated the example section with the appropriate info. Thanks to Google for getting back to me and providing these details!

flattr this!

Posted in Accessibility, ARIA | Tagged , , , , | 26 Comments

New in accessibility in Firefox 10

Posted on January 31, 2012 by Marco

Firefox 10 has just been released. Here is a recap of the things that were fixed in accessibility for this release.

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!

flattr this!

Posted in Accessibility, Firefox | Tagged , , , | 6 Comments

Accessibility on the Mac: Progress report Jan 30, 2012

Posted on January 30, 2012 by Marco

After my blog post about the accessibility of Firefox on Mac OS X ramping up stirred up so much interest (thanks again to everyone who commented!), I thought you’d like to hear a bit about the progress we’ve made since then.

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:

Pretty amazing, eh?

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

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. ;-)

flattr this!

Posted in Accessibility, Apple, Firefox | Tagged , , , | 8 Comments

Would you like to show us what assistive technology you use Firefox with?

Posted on January 26, 2012 by Marco

For a while now, Firefox has had the ability to collect anonymous usage data. Internally, we call this telemetry.

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. :-)

flattr this!

Posted in Accessibility, Firefox, NVDA, Testing | Tagged , , , | 6 Comments

Accessible Firefox on Mac OS X – things are ramping up!

Posted on January 17, 2012 by Marco

This is to announce that work on a VoiceOver accessible version of Firefox for the Mac OS X platform has been gaining some attention recently, and that very promising progress has been made in the last month!

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!

flattr this!

Posted in Apple, Firefox | Tagged , , | 22 Comments

If you’re not accessible, you lose sales and reputation

Posted on January 16, 2012 by Marco

Did I ever mention that I love the community, and I love operating systems with truly inclusive design?! Well, now you know! Here’s a little story that took place in the last half hour:

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!

flattr this!

Posted in Accessibility, Apple, Firefox, NVDA, Orca | Tagged , | 3 Comments

Quick tip: Handling the sub menus in the WordPress 3.3 admin area with a screen reader

Posted on December 20, 2011 by Marco

This is a quick tip to show how to use the new sub menus in the admin area of WordPress 3.3 with a screen reader. For this, I’m using NVDA 2011.3RC, and Firefox 9.

The new sub menus are a way to more quickly access items in the sub menus of “Dashboard”, “Posts” etc. without having to reload the page with the menus opened. Instead, the menus are opened and closed dynamically by either hovering the mouse over the item that is, by NVDA, announced as “sub menu link”, or by executing a press of the enter key on such an item.

The problem arises from the fact that screen readers on Windows capture the enter key and many others and execute functions based on their functionality inside the virtual documents/browse mode documents. For example pressing enter on a link usually clicks the link.

In this case, a click on a link is not what we want, since that would indeed reload the page. The menu would still be opened, but we’d lose all advantages of the more dynamic, time-saving approach that is made possible in 3.3.

Instead, what we do is the following:

  1. Position NVDA’s virtual cursor on the desired sub menu item.
  2. Press NVDA-key+F2 to invoke the function to pass the next key press straight through to the application.
  3. Press enter.
  4. Navigate down with the virtual cursor to find a newly expanded sub menu with links we can click.

Your preferred screen reader offers the same functionality, no doubt. Be aware, however, that some screen readers do not set focus to focusable items under the virtual cursor automatically, so an additional key press before step 2 may be needed to route the system focus or PC cursor to the item the virtual PC cursor is pointing to.

This way, we can easily access the dynamic menus. It requires an extra keystroke, yes, but this is still quicker than having to wait for a page load and looking for the new items starting from the top of the virtual document.

Happy blogging!

flattr this!

Posted in Accessibility, NVDA, WordPress | Tagged , , , | 6 Comments

Social networks and accessibility: A rather sad picture

Posted on December 8, 2011 by Marco

In recent months, several popular social networks relaunched or updated their services, and one new player came out onto the plain field that, initially hyped, now is hardly talked about any more.

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!

flattr this!

Posted in Accessibility, General | Tagged , , , , , , , | 19 Comments

From WAI-ARIA to HTML5 and back…or maybe not?

Posted on December 5, 2011 by Marco

Over the weekend, I gave a presentation at the German Multimediatreff. I talked about how to make things more accessible by combining HTML5 and WAI-ARIA in smart ways, using HTML5 where available and appropriate, and enhancing the user experience where HTML5 still has gaps in the implementation. This is a recap of what I showed.

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!

flattr this!

Posted in Accessibility, ARIA | Tagged , , , , , | 1 Comment

What’s new in Accessibility in Firefox 8.0

Posted on November 8, 2011 by Marco

The newest update to Firefox has just been released to the public, and it’s that time again where we look at the user-facing and facing assistive technologies changes in this Firefox release. If not otherwise noted, these changes apply to Thunderbird as well, since it is built on the same platform.

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!

flattr this!

Posted in Accessibility, Firefox | Tagged , , , , , , | 21 Comments

Reworked accessibility focus handling now in Firefox nightly builds

Posted on October 4, 2011 by Marco

In the nightly Firefox builds, which are already at version 10.0a1, a big refactoring patch was checked in mid of last week that reworks how the accessibility code handles focus changes and setting of the focus and its associated states for screen readers and assistive technologies.

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!

flattr this!

Posted in Accessibility, Firefox, QA, Testing | Tagged , , | 2 Comments

Firefox 7 is released, new features in accessibility

Posted on September 27, 2011 by Marco

Firefox Update 7 has just hit the net, and while it’s still hot, I wanted to share a few items specific to accessibility that are included.

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!

flattr this!

Posted in Accessibility, ARIA, Firefox | Tagged , , , , | 18 Comments

Review: The all-new Yahoo! Mail web application

Posted on September 21, 2011 by Marco

Yahoo! recently announced the availability of their all-new mail web application. They also made announcements on the Yahoo! Access channels about the much improved accessibility of this new mail interface. Well, it’s time to look at it! So shall we?

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.

flattr this!

Posted in Accessibility, ARIA, Yahoo! | Tagged , , | 12 Comments

NV Access receives a Mozilla grant to further push accessibility on the web

Posted on June 24, 2011 by Marco

The Mozilla project is very committed to making the web available to all people. To further that goal, members of the Mozilla community actively work with Non-Visual Desktop Access and other accessibility initiatives to make sure everyone benefits from the web.

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!

flattr this!

Posted in Mozilla, NVDA | Tagged , , , , | 6 Comments

What’s new in accessibility in Firefox 6

Posted on June 1, 2011 by Marco

On Friday May 27, a bigger update was offered to everyone on the Aurora channel that brought them up to a revision 6 Firefox.

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.

flattr this!

Posted in Accessibility, ARIA, Firefox | Tagged , , , | 9 Comments

Firefox 6: html:progress element accessibility

Posted on May 18, 2011 by Marco

Recently, Mounir landed support for the HTML5 progress element on the Mozilla development branch (AKA “Nightly” channel). A few days later, after a concerted effort and another episode of “Marco and C++ are only partially good friends” ;) , accessibility support landed, too, and thus the progress element will be accessible starting in Firefox 6. For those of you on the “Aurora” channel, you should see stuff come through the pipeline with updates after the next Aurora merge, currently slatted for mid next week.

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.

flattr this!

Posted in Accessibility, Firefox | Tagged , , , | 7 Comments

Mozilla is launching the Aurora channel, bringing accessibility features to you more rapidly!

Posted on April 13, 2011 by Marco

As was just posted on the Mozilla blog, Firefox is moving to a more rapid release cycle from now on. This also means that accessibility features and fixes will be delivered to users more rapidly than in the past. And I’m not just talking about crash fixes or other minor changes that were previously possible in the point-releases of Firefox releases, but really new features!

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!

flattr this!

Posted in Accessibility, Firefox | Tagged , , | 5 Comments

Firefox 4 is here!

Posted on March 22, 2011 by Marco

Firefox 4 has finally hit the release channels and is available for download immediately!

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.

flattr this!

Posted in Accessibility, ARIA, Firefox, Mozilla, QA | Tagged , , , | 19 Comments

The WebVisum extension needs you!

Posted on March 3, 2011 by Marco

This is a shout-out to all interested extension developers who have some time to donate to the WebVisum extension project. As you can read in my review of the extension, it is one of the most important extensions for blind users, helping to improve web pages here and there by allowing to label improperly labelled graphics or form fields, and – more importantly – it includes the connection to a captcha solving service, which has allowed blind users to participate more equally in web forums, certain blog systems and other services that still require graphical captcha entry.

The problem is that the WebVisum developers do currently not have the resources to port the extension over to Firefox 4.

So if you are a skilled extension developer, please consider donating some of your valuable time to this extension and help port it to FX 4! You’ll be helping a growing part of the Mozilla community continue to participate in today’s web offerings!

flattr this!

Posted in Extensions, Firefox | Tagged , , | 16 Comments