New approaches to Flash and Java accessibility in the browser on Windows

Posted on October 2, 2009 by Marco

Mick and Jamie from NV Access, the organization behind the free and open-source NVDA screen reader for Windows, are taking new approaches to accessing accessible Flash and Java applets inside the browser.

Traditionally, Adobe Flash content is being rendered into the virtual buffer in Windows screen readers such as JAWS. Over the years, this has proven to cause several issues:

  • Dynamic content frequently updating causes the virtual buffer to either get out of date, or to update so frequently that reading the content is close to impossible.
  • Accessing content can be cumbersome if Forms Mode or similar concepts are not properly handled.

For these and other reasons, the WebAIM screen reader survey taken last year ranked Flash as the technology posing the most accessibility obstacles on the web for blind users. 71% of all participants found Flash to be difficult or extremely difficult to use. Inaccessible Flash applets, which take up the vast majority of Flash content out in the wild, are doing the rest to strengthen this view.

With Java applets, things get even more complicated. For one, one has to install the Java Access Bridge from Sun Microsystems, to get Java to be accessible at all, inside the browser and elsewhere. Once that hurdle is taken, Java applet content is not rendered inside the virtual buffer, but is present somewhere within the browser window, and one usually has to try to tab to it and get focus to it that way, outside the context of the virtual buffer. Accessible Java applets are very rare and currently hardly play any role when considering accessibility on the web. If at all, they’re viewed as obstacles and something to be avoided.

However, this could change with the approach the NV Access team is taking. In their latest snapshot build, they are introducing an interaction model that is remotely similar to what blind Mac users have come to know and appreciate from Apple’s VoiceOver screen reader. What you do is this:

  1. You load a web page that contains Flash content. For example, take any YouTube video.
  2. You navigate to a spot that says “embedded object clickable” with the normal virtual buffer navigation methods. For easiest access, NVDA provides the quick navigation key o to get to embedded objects.
  3. Press Enter.
  4. What this does is zoom in on the embedded Flash object and give it focus. Now, use Tab and Shift+Tab to navigate around the Flash app. Other keys such as the arrow keys also will perform differently now, for example left and right will scrub through the video on YouTube.
  5. When done, press NVDA+Space to leave the embedded object and zoom out, returning to the parent web page. Your virtual buffer navigation will now function the same way as it did before you zoomed in on the Flash.

One note of caution: I fell into the trap that I thought the content would be rendered in the virtual buffer, as is traditionally done with Windows screen readers. To be honest, I didn’t read the note on this feature before I played with it. :) But if you don’t tab after pressing Enter, you will immediately leave the embedded object and continue navigating with the virtual cursor. This is because Flash does not focus any particular object inside the applet by default when the applet itself gains focus.

When I tried this on YouTube earlier, I had the feeling I had never seen so many details of the YouTube player before! :)

One more thing: The above technique will work in Firefox 3.5.x and the latest Minefield nightly builds, and it will also work in the 3.6b1 that’ll be available some time soon, but is not going to work in the 3.6alpha release we issued beginning of September, due to a regression that only recently got fixed in the 3.6 codebase.

With this new, in my opinion more user-friendly approach to accessing Flash content and Java applets, making sure your Flash or Java applets are accessible is becoming even more important than it already is, since blind users will be able to interact with applets more seamlessly than before.

And while we’re at it, the better support in NVDA for Flash should also be an incentive to Adobe to make Flash accessible on other platforms such as Linux and Mac. For the Mac, maccessibility.net have a petition to Adobe for making Flash accessible on the Mac. If you haven’t already done so, I encourage you to show your support by signing that petition!

Posted in Accessibility, Firefox, NVDA | 22 Comments

Recent happenings in accessibility-related projects financially supported by Mozilla

Posted on September 25, 2009 by Marco

For several years now, Mozilla has funded varying projects in the field of accessibility development. Projects like Orca’s support for WAI-ARIA live regions, GNOME Accerciser, NVDA, or more recently, audio and video accessibility work and Firebug accessibility, are, in whole or in part, being funded by the Mozilla Foundation and other Mozilla resources to help fulfill the Mozilla manifesto and the Mozilla Accessibility Strategy.

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

NVDA

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

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

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

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

Audio and Video accessibility

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

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

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

Firebug UI accessibility and the Firebug accessibility testing extension

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

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

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

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

So, let’s boldly go! :)

Posted in Uncategorized | 11 Comments

The current state of accessible Firefox on the Mac, your help is appreciated!

Posted on September 22, 2009 by Marco

I’ve been asked time and time again about what the current state is of the possibility of an accessible Firefox on the Mac that interacts with the VoiceOver screen reader. Well, let me recap what the current affair is.

First of all, the bad news is that getting the remaining quirks out of Mac accessibility is not going to happen this or next quarters.

The main reason is that our code currently needs to be made ready for future enhancements. Our recent work on the IAccessibleTable2 interface showed us that painfully: The refactoring and reorganization needed took much longer than we had estimated and required us to touch much more code than we had hoped. We also have some nasty event firing problems that have been a pain in the neck for those ATs supporting us that we desperately need to attack these now.

However, the good news is that since early May, the accessibility unit tests (Mochitests) have been running mostly successfully on the Mac on both the mozilla-central and mozilla-1.9.2 branch tinderboxes. Those tests had been running successfully on Windows and Linux since December already. They’ve been intermittently showing some flakiness (what we call random orange) in especially the events area, which is what we’ll be working on in the immediate future anyway, but otherwise been quite stable.

On top of that, at least investigating and driving the Mac accessibility effort forward has been sort of a pet project of mine all the while, even though Mac a11y is no longer part of our team’s official goal set for this year.

What I’ve been doing is build Mac builds with accessibility enabled on my MacBook and test them whenever I had some cycles. On Mac OS X 10.5 (Leopard), VoiceOver and the Firefox builds played terribly together, with lots of sluggishness and delayed responses that made it impossible to get any really useful testing done.

This, however, has changed with Snow Leopard. Without consciously changing things on our end, a build done under Snow Leopard is much more responsive with VoiceOver. We’re nowhere near the good performance blind people have come to appreciate from Safari yet, but we’re doing much better now. Whether it’s the improved VoiceOver or the fact that we’re now building against the MacOS10.5 SDK, or both, I don’t know.

The following are what I’d consider the most pressing issues before we could even think about sending this off to a bunch of voluntary testers:

  • VoiceOver is not speaking most accessible roles of UI and web page elements. Strangely enough, when pressing a button, it will say “Press button” and the like.
  • VoiceOver skips over plain text on pages, and the text is also not visible in VoiceOver’s Obbject Chooser menu.
  • Other inconsistencies having to do with roles like VoiceOver not recognizing our HTML area as such and not automatically starting to read pages etc.
  • Performance problems: Right now, navigating from one element to the next takes about half a second, which is unacceptable.

And this is where you might be able to help us! Are you a developer who is fluent in Objective-C, and (as a bonus) versed in Apple’s accessibility APIs? We could use your voluntary help in trying to nail this down!

So if you’d like to help improve Firefox on the Mac and have an idea about what might be going on here, go grab the source and build it! In order for accessibility to be turned on, in addition to all the stuff you need to put into your MOZCONFIG file, you need to add the following line:

ac_add_options --enable-accessibility

With this exception, commence as described in our docs.

Once you’ve got Firefox built, you can press CMD+F5 to turn on VoiceOver. A friendly male voice named Alex will start talking to you immediately and give you feedback on your actions through your Mac’s speakers. CMD+F5 is a toggle, so the same keystroke will turn VoiceOver off and leave no trace of it having been active.

Once VoiceOver is running, the following is a list of hot keys that can be used to navigate. Note that VO refers to the VoiceOver modifier, which is both Ctrl and Option held down.

Key Description
VO+Arrows Navigate in all 4 directions. Left and Right from item to item sequentially.
VO+Shift+DownArrow Interact with the currently spoken item. Interacting is examining an item in more detail. For example, interacting with a table will expose the individual cells to VoiceOver and restrict navigation inside this container.
VO+Shift+UpArrow Stop interacting and return to the parent level of navigation.
VO+Space Press or activate the current item. This will perform the default action, which is usually identical to clicking the mouse.

More information is available on Apple’s accessibility site. A Key commands chart (PDF) will give you more keystrokes, and the linked-to bugs above will give exact steps to repro the bugs themselves.

Since Firefox is not a native COCOA application on the Mac in the sense that we implement all our UI elements ourselves, we have to expose the whole accessibility contract and are obviously doing some things wrong there. The initial work that was done was done by a Mozilla Foundation grantee back in 2006, but this project was never finished and the project had been in limbo since then.

If you are willing to help, feel free to connect with me through e-mail (available from my About page) or via IRC on the #accessibility channel. I’ll be glad to assist with getting involved. The accessibility team definitely would appreciate it, and so would many community members I’m sure!

Posted in Accessibility, Apple, Firefox | 20 Comments

You’re a table, and I don’t care what lies underneath

Posted on September 11, 2009 by Marco

Over the past couple of weeks, Alex, David and I have been hard at work refactoring, discussing, and implementing better support for accessible tables in Gecko. Some of this has seen the light in Firefox 3.6alpha, but the heart of the work is currently only in mozilla-central (AKA Firefox 3.7). Update: As of October 29, these changes have also been ported to the Firefox 3.6 AKA the Gecko 1.9.2 branch and will be in the final release of Firefox 3.6. It will not yet appear in the upcoming release of Firefox 3.6b1, since that was branched off before we landed the IAccessibleTable2 support.

The goal was to:

  1. Refactor our code to become more maintainable.
  2. Expose the same kind of interface to assistive technologies regardless of what lies underneath is a true HTML table, an ARIA table, an ARIA data grid, a XUL tree table etc. There are so many commonalities that ATs should be able to expect similar, if not identical, information from any of these table types.
  3. Implement the IAccessibleTable2 interface that was defined within the IA2 group over the summer.
  4. Get rid of many “todo” items in our Mochitest unit tests.

For The Minefield (Firefox 3.7a1pre) nightly build that will come out today, Friday September 11, the patch that implements IAccessibleTable2 has landed. All header/table cell relations are now defined through proper method calls rather than special forms of accessible relations. This was a big patch with almost 550 kb in size. A quarter of this were IDL changes for IA2, but the rest was all code that had to be reviewed and super-reviewed. It’s definitely the biggest patch I’ve been working on so far since I started working for Mozilla.

Over the past few weeks, Alex also refactored our XUL tree exposure to better meet our goal. With 235 KB, this was the second biggest patch I have been working on so far.

Other changes that went in concern selection of cells, rows, unselecting parts of tables etc. Some of these have caused our long “to do” item list of around 80 items to drop to a mere 7 throughout the whole a11y test suite. The table tests were among the first written when we started doing automated tests on a11y some 20 months ago, and it’s cool to finally see this area of the code properly addressed!

With these changes, our number of passing tests is now at 10205 and a total of 7 to-do items.

And this is where you come in! If you’re an accessible tables junkie, know a lot about HTML table make-up, or know of very weird tables out in the wild, go download the latest nightly build and throw the tables at it! Let us know your results, for example by commenting here on the blog, and if you find something that definitely isn’t exposed right, file a bug! We appreciate any and all help you can give us here!

If you’re an AT vendor and plan on implementing support for IAccessibleTable2, here’s a model you can use!

Finally, I’d like to thank all the cool people (module peers and super reviewers) who helped us accomplish what we’ve accomplished so far! With their knowledge and wisdom about the inner workings of Gecko and their respective modules, they helped make our code faster, better and more robust. Keep on rockin’!

Posted in Accessibility, ARIA, Firefox | 16 Comments

Use CSS3 transforms, makes your pages more accessible!

Posted on August 19, 2009 by Marco

If you’re one of those types who likes to visually twist, rotate or tweak some text, in previous years the only real choice was to use pictures to achieve such visual effects. However, thanks to CSS3 transforms, supported in Firefox 3.5 and later, Safari 3 and later, and Opera 10 beta, it is now possible to use plain text and rotate, twist and tweak its looks via CSS. The big advantage: Screen readers will still read the text OK because their reading order is not influenced by the visual appearance of the text. So even text rotated by 45 or 90 degrees will appear correctly in a screen reader’s virtual buffer.

There even is a workaround for IE, but it doesn’t work in IE 8. To quote a friend from Germany: “Maybe IE 17″. :)

Posted in Accessibility, Firefox | 19 Comments

Blind web devs, jump on the Firebug train!

Posted on July 16, 2009 by Marco

Late yesterday, Firebug 1.4 was released. Firebug is the web development and debugging tool for Firefox, with a huge user base worldwide.

As JJB mentions in his post, UI accessibility was provided for many of the Firebug features by Hans Hillen of the Paciello Group. The Mozilla Foundation funded the first of this work, and the Mozilla Corporation is now continuing funding to finish the remaining UI pieces like the “Net” panel, fix remaining issues, and also to work with the University of Illinois to develop Firebug features that will help web developers check their sites and applications for accessibility and fix issues in that area.

I am not going to iterate over the features one by one, since the documentation on the accessibility features is very comprehensive. I urge all developers wanting to utilize these features to RTFM (read the fantastic manual) in its entirety before starting to use accessible Firebug.

Once you are up and running with it, you’ll find that all of the described features work as advertised in the documentation. And even more: The documentation currently still states that the script panel’s source code viewer cannot be read with NVDA. However, Hans, Jamie from the NVDA team, and I managed to fix that problem shortly before beta 1 of Firebug 1.4. I notified Hans to update the documentation.

Compared to Firebug 1.3, Firebug 1.4 offers a wealth of accessible web development tools. Firebug 1.3 was effectively not accessible, Firebug 1.4 is, with a few small exceptions, fully accessible, which is an almost 100% leap forward within a single version number increment!

This opens up whole new opportunities for blind developers. To my knowledge, the development tools offered by the Redmond browser do not offer this wealth of features. In testing I did while fixing my example form to also work in IE 8, I found the tools to be unreliable and shaky in many areas. Firefox 3.5 and Firebug 1.4, on the other hand, together with NVDA, which currently best supports the former, are a vehicle to open up new job opportunities! With Firebug, a blind person has full control over the styling and layout of a web application or page. For example, taking my example form from the Easy ARIA Tip #3, and looking at the label and input elements for the “name” entry, I can immediately be told that the label is to the left of the input, and how many pixels there are between the two. I can make sure they’re visually at the same height. The box model of the Layout sidepanel of the Firebug HTML panel is fully accessible and gives me a feel for a page I’ve never had before!

Communication of search results within the HTML panel, or when encountering a breakpoint, is just awesome! Being able to inspect the DOM or a single element’s properties, being able to in-line edit properties and immediately be able to test the effect a certain ARIA attribute might have on your screen reader output is just productivety at its best!

What Hans accomplished here is done almost entirely through WAI-ARIA, and by implementing very intelligent keyboard navigation mechanisms. Through ARIA, such widgets as the log rows for the console, when you enter something such as document;, or dir();, are pushing the boundaries of known desktop widgets. The fact that tabs have popup menus attached to them is being communicated to the user by NVDA straight away, thanks to a very open and flexible architecture that does not assume certain facts about traditional static desktop widgetry such as “tabs never have menus attached to them”. The pure visual box representation of the Layout side panel of the HTML panel is another great example. This even blew David Bolter away when I showed it to him during the Mozilla all-hands in late April, and David is a long-standing and accomplished a11y guru!

Implementing some of these features in desktop applications usually requires very customized implementations of the platform’s accessibility APIs. ARIA, however, is so open and flexible that it can be easily applied to make such visually complex tools like Firebug accessible without ever touching the Mozilla core codebase. Firebug is a mix of XUL (the Mozilla UI language) and HTML+CSS.

So, Victor Tsaran of Yahoo! is already firebugging, and so am I. When are you?

Posted in Accessibility, ARIA, Extensions, Firefox | 17 Comments

The WAI-ARIA Windows screen reader shootout

Posted on July 1, 2009 by Marco

Firefox 3.5 has been released, and now it’s time to take a look at what features of WAI-ARIA are being supported by which Windows screen reader. Competition is healthy in this market, and two new screen readers have started supporting Firefox during the 3.5 development cycle: Dolphin’s Hal/SuperNova and Serotek’s System Access (including the free SAToGo offering). So to document the current state of affairs, I’ve taken each one of the following screen readers running on the Windows platform on a tour through some WAI-ARIA implementations that are out there for everyone to use. I’ve chosen not to do a widget-by-widget walkthrough of the Dojo DIJIT Toolkit or some other JS library already including WAI-ARIA, but instead concentrated on stuff users will actually encounter while surfing the web under non-clinical conditions.

The following are the candidates:

The scoring is simple: For each important feature that is fully supported, each screen reader gets 1 point. A particular web app may have more than 1 feature, so it is possible to score multiple points for web apps.

Note that, even if WAI-ARIA support is not explicitly documented, it is still possible to score points because Firefox exposes many widgets through MSAA and IAccessible2 that are not standard HTML widgets. The interesting question here is: Are the various forms of Forms/Focus mode flexible enough to deal with these?

Landmarks

WAI-ARIA landmarks are one of the most widely used features of the spec already. They allow another means of navigating a web page, finding things such as the banner, main content, search, complementary or footer information. The newly relaunched Mozilla Add-Ons website uses them now, as does this blog.

NVDA
No.
JAWS
Yes. Landmarks are announced, they can be navigated to using the Semicolon quick navigation key, and there’s a list of landmarks available through JAWSKey+Ctrl+SemiColon. 1 point
Window-Eyes
No.
SuperNova
No.
System Access To Go
No.

So after the first round, JAWS is in the lead with 1 points.

Contact form from my Easy ARIA tips

The example contact form I created for my Easy Aria tip #3 offers several features that can be incorporated without having to create widgets, and which have appeared in some form or another on pages throughout the web already:

  • Does the fact that the Name, E-Mail and Message fields are required get indicated by anything other than the label saying “required”?
    • By navigating the virtual buffer
    • When in forms/focus mode and tabbing around
  • When entering an invalid name by just entering the first name:
    • Does the alert get spoken when tabbing away?
    • When tabbing back, does the field get indicated as having an invalid entry?
    • Does the fact that this field has an invalid entry get indicated when navigating in the virtual buffer?

In total, there are 5 points to score for this test.

NVDA
NVDA indicates the field as being required in v cursor mode and when tabbing around. 2 points. It speaks the alert. 1 point. It indicates the invalid attribute both when navigating the virtual buffer and when in focus mode and tabbing around. 2 points. Total: 5 points
JAWS
While the label gets spoken in virtual cursor mode, when JAWS switches to forms mode automatically when hitting the entry field, the plopping sound drowns out every indication of attributes such as required or invalid. Only when deviating from default settings and turning AutoFormsMode off one will hear those attributes in V cursor mode. No points for these two. The alert gets spoken. 1 point. When tabbing around, the attributes such as required and invalid do get announced with the default settings. 2 points for these. Total: 3 points
Window-Eyes
The fact that the field is required gets spoken in both browse and focus modes. 2 points. The alert gets spoken. 1 point. The fact that the field has an invalid entry gets spoken in both browse and focus modes. 2 points. Total: 5 points
SuperNova
None of the asked for features work. Sorry, 0 points.
System Access To Go
The alert gets spoken. 1 point. None of the attributes are spoken when navigating or tabbing. Total: 1 point.

After round 2, NVDA and Window-Eyes take the lead with 5 points each, JAWS follows on third place with a total of 4 points, System Access has 1 point, and SuperNova has 0 points.

Yahoo! Search

The new Yahoo! Search is an interactive widget allowing browsing of possible search terms and related concepts that fit the currently selected search term. It uses a whole range of WAI-ARIA widgets, properties and states, live regions etc. When performing a search, the following things should be working:

  • When focusing the textbox:
    • Does the screen reader speak the name “Search query”?
    • Does the screen reader announce the description “Use the up and down arrow keys to select suggestions, or press down and then right to explore concepts.”?
  • When typing, does the screen reader announce that search suggestions are available?
  • When search suggestions are available, does pressing DownArrow properly announce that focus shifted to the list of suggested search terms, and what to do to get back to the search field?
  • Does pressing RightArrow announce the shift to the “related concepts” list and the selected item?
  • When arrowing through either list, does the highlighted/focused item get spoken, and does the search that will be performed when pressing Enter get announced by the screen reader?

So, there are 7 points to score for this one.

NVDA
It speaks the “Search query” label. 1 point. It speaks the “Use the..” description. 1 point. When search suggestions are available, the fact is announced. 1 point. When pressing DownArrow, the transition to the list of suggested terms is announced along with the full instructions and the selected item. 1 point. When arrowing left and right to the related concepts and back, each focus transition is properly announced and the highlighted item read. 1 point. When arrowing up and down through either list, the newly highlighted search term is announced, and the search that is going to be performed is announced automatically. 2 points. Total: 7 points
JAWS
When focusing the search field, the “Search query” label is announced. 1 point. The “use …” description is not announced automatically. It is also not being announced when pressing JawsKey+Tab or Insert+F1. The only way to get to it is to use their HomeRow utility functions and cycling to the “Description” item with HomeRow+F10 and then listening to it with HomeRow+F9. For this almost non-discoverability I can’t give a point, sorry. When search results are available, this gets announced. 1 point. When pressing DownArrow, the transition to the list is announced along with the prompt. 1 point. When RightArrowing, the transition to the “Explore related concepts” list is announced. 1 point. When arrowing up and down, the newly highlighted item is not announced, and neither is the search that is going to be performed. One can get the currently focused item by using Insert+Tab, but the description is once again burried in HomeRow. I’m willing to give half a point for this one since initially it will be confusing to users that they don’t hear anything when arrowing up and down. Total: 4.5 points
Window-Eyes
The label “Search query” is announced. 1 point. The “Use…” description is announced. 1 point. The availability of search results is not announced. The transition to the search term suggestions is partially announced: The focused item is, but the prompt is not. Half a point. The transition to the “Related concepts” and back is announced partially: The newly focused item is, but the prompt isn’t. half a point. When arrowing up and down, both the search suggestion and the search that is going to be performed are being announced. 2 points. Total: 5 points.
SuperNova
Announcing the “Search query” label works. 1 point. But unfortunately, that’s where the fun ends. The description is not announced, the availability of search term suggestions is neither. And the rest of the functionality of this widget is broken. DownArrow is captured by SuperNova and will not fall through to the widget, getting one stuck inside the textbox. Tabbing around will only get up to the “Submit your site” link, but the search terms aren’t reachable. SuperNova will say “bottom”, and no further can one go. Total: 1 point.
System Access To Go
The picture is roughly the same as with SuperNova. The label “Search query” is spoken. 1 point. The description is not spoken. The availability of search term suggestions neither. DownArrow gets you to the “Search” button instead of the list of search terms. In fact, this virtual buffer also ends at the “Submit your site” link. Total: 1 point.

At the end of this round, NVDA leaps ahead with 12 points. Window-Eyes is second with 10 points, followed by JAWS with 8.5 points. System Access scores a total of 2, and SuperNova got their first point!

GMail Chat

GMail has an integrated Google Talk widget that I talked about before. The following should be working:

  • Ability to activate the “Set status here” label by pressing Enter on it to input a personal status message.
  • Ability to activate the “status menu” and navigate inside it with speech output.
  • Navigate inside the list of buddies and hear their names and status.
  • Inside the Chat window, announce typed and incoming messages.
  • Track going to the Chat window toolbar.

Once again, there are 5 points to score. Let’s see how everyone fares!

NVDA
Pressing Enter on “Set status here” works fine, and one can input a status message. 1 point. Activating and navigating in the status menu works fine. 1 point. The list of buddies talks fine. 1 point. Chatting works fine. 1 point. Trying to access the toolbar items by first going out of focus mode with Escape made NVDA hang each time I tried it. It somehow has a conflict with the chat widget. Sorry, no point for this one. Total: 4 points
JAWS
The label to input a status message is not activable by pressing Enter. It can only be activated using the JAWS cursor emulation. Since this is a well-known workaround, I’m giving half a point. The Status menu is activable and works fine. 1 point. The list talks fine. 1 point. The incoming and typed messages are spoken in the chat output. 1 point. The chat toolbar to pop out the chat into its own window is accessible. 1 point. Total: 4.5 points.
Window-Eyes
Accessing the label to input a status message works with workaround of routing WE cursor to element, then mouse to WE cursor, and clicking with the mouse. However, I cannot input a status message afterwards, even though I hear the prompt for it. a quarter of a point for that. The status menu cannot be activated through any means. The list talks fine. 1 point. The chat window works with restrictions: It can be activated and typed in, but incoming messages are not read. half a point for that. Trying to access the toolbar items of the chat window sort of works by turning browse mode back on, and then searching, but since the last position is not retained, I can only give half a point for this one. Total: 2.25 points.
SuperNova
Activating the “Set status here” works. I can input a new status. 1 point. The status menu button does not work, cannot be activated or found through other means. The list of buddies talks. 1 point. Activating a chat with a buddy does not work. Consequently, since the chat window never comes up, the toolbar items for the chat window obsolete themselves. Total: 2 points.
System Access To Go
The “Set status here” and Status menu items are not accessible. The list talks fine. 1 point. Activating a chat works. 1 point. Finding the toolbar buttons is not possible, because the cursor gets stuck within the textbox of the chat window and there’s no way to move it out. Total: 2 points.

…and the winner is…

Congratulations go to the NV Access team and their screen reader! In this WAI-ARIA shootout, you scored 16 points.

Number 2 is JAWS by Freedom scientific, scoring a total of 12.5 points.

Window-Eyes by GW Micro is third with a total of 12.25 points.

Fourth place goes to Serotek with their System Access screen reader product line, with a total of 4 points.

And SuperNova by Dolphin receives 3 points.

In summary

This was a close match, although there is clearly a dividing line between the three screen readers that have been supporting Firefox for a longer period of time, and those that came on board fresh within the past year or so.

I hope this little competition encourages each of the vendors to better themselves for the benefit of the users. We’re here to help each and everyone of you with technical advice and discussion on how things should be implemented.

Keep on rockin’!

Posted in Accessibility, ARIA, Firefox, GMail, Yahoo! | 44 Comments

New accessibility features in Firefox 3.5

Posted on June 26, 2009 by Marco

Firefox 3.5 is fast approaching, and it’s time to list all the user-visible changes to the accessibility support in this new version!

Support for text attributes, formatting and spell checking

Firefox 3.5 exposes text attributes such as bold, underlined, and color information through the AT-SPI and IAccessible2 attributes properties of their respective AccessibleText interfaces. Information about formatting such as left aligned, centered etc., is also provided. In addition, in rich editing and other text entry environments where the spell checker is enabled, when a word is misspelled, this information is also provided so screen readers can pick up and notify the user. Since my original blog post on this subject, Orca 2.28, NVDA 0.6p3 and JAWS 10 have added support for this feature, allowing a seamless proof reading of entered text in both Firefox 3.5 and the upcoming Thunderbird 3 release. This works also when writing a message in GMail or other rich editing environments, not just textboxes or textareas.

Better compliance with WAI-ARIA 1.0

We’ve made sure that the WAI-ARIA 1.0 spec is adhered to to the most extent possible, removing attributes that are no longer in the spec, and adding/changing those that were agreed upon in the progression towards finalizing ARIA 1.0, which is currently in a late review stage. One of the most significant attributes added is aria-label, which allows any text to be associated with a widget that doesn’t appear anywhere else within the web app. For extension devs: This also works in XUL, not just HTML. One project that makes heavy use of this is Firebug 1.4 in the accessibility UI enhancements that Hans from the Paciello Group has put in. This is also the reason why Firebug 1.4 works better in Firefox 3.5 than 3.0, what accessibility is concerned, since Firefox 3.0 doesn’t support this new attribute.

Also, aria-expanded can be used on all elements now, allowing better exposure of states for buttons that drop down a list of items, for example.

Support for the exposure of embedded HTML 5 audio and video controls

As recently announced, we’re also supporting the exposure of the embedded controls of the HTML 5 audio and video elements to assistive technologies.

Better event firing in dynamic web applications

We fixed a significant issue with firing proper events when nodes get hidden or made visible through JavaScript or Ajax calls. This should allow a much better experience with accurate visibility of nodes within virtual buffers of various screen readers.

And a ton of bug fixes for stability

Of course, each cycle also goes with a ton of bug fixes that improve stability and accuracy. These are mostly under the hood and often deal with edge cases, but these are no less important to our user base.

When Firefox comes out, I encourage everyone to upgrade as soon as possible, since it will provide an even more rich experience when browsing the web than Firefox 3.0 already did. Probably the most important extension for blind users, WebVisum, already works with this release, so you won’t lose anything on that front! Also, other extension devs are working hard to make their projects work with Firefox 3.5.

Enjoy!

Posted in Accessibility, ARIA, Firefox | 34 Comments

My first experience using an accessible touch screen device

Posted on June 22, 2009 by Marco

Yes, you read correctly: An accessible touch screen device! This morning, I went to a retail store carrying mostly Apple products and had a look at the new iPhone 3G S that was released in Germany on Friday. Apple revealed during the WWDC keynote two weeks ago that it would have a built-in screen reader named the same as is included in Mac OS X: VoiceOver. This is a feature not available on the regular iPhone 3G, as its hardware capacity is insufficient.

I was not at all sure what to expect. From reading a bunch of posts on the VIPHone Google Group, I knew that people were going through a learning curve, a steep one at times. Up to now, something usable via a touch screen or touch-only keys would always mean a dead-end to me and other blind people. The iPhone 3G and the iPod Touch are not usable for me. Likewise, elevators that have keys you only need to touch, not press, to get toa different floor, are a real challenge. In fact I once tripped an alarm while trying to use such an elevator, alone int he cabin and touching the emergency button accidentally.

When I arrived at the store, I had already made arrangements with them to be allowed to take an in-depth look at the 3G S. As we went over to the iPhone stand, one of the sales assistants already knew how to turn on VoiceOver. Apple are documenting this in the regular iPhone user’s manual, no special docs needed. The assistant helping me turned it on, and a clear crisp voice came out of the built-in speakers. She was a bit confused by the changed gestures. I had done some reading, and took over from there.

And I must say this was an amazing experience! My fingers definitely need to get used to gestures such as flicking or tapping, or using a rotor. But having an iPod Nano 4th generation helped with that, since moving the finger over the screen like on a dialer felt most like tracking around the iPod’s click wheel. Even the sound the rotor makes is the same. :)

Responsiveness to gestures was amazing. I own an Nokia N82, which is to date probably the handset that reacts fastest to keyboard commands with the Talks or MobileSpeak screen readers, but the responsiveness on the iPhone beats that by lengths!

Finding my way around the iPhone’s UI took some getting used to. Traditional mobile screen readers, also like most Windows or Linux screen reader solutions, give the blind user a filtered view of the world, by default constrained to the focus location. Only on demand can one explore the screen using mouse emulation or similar techniques. On the iPhone, you interact with the real thing right from the start. You touch the screen in the lower half, somewhere on the right, and you’re told that the Safari or iPod symbol is there on the Home screen. You move your finger to the left, and you’re told what’s right next to it. To interact with the menu bar of the Phone app, you need to move your finger down to the bottom and move from left to right to hear the options such as “Contacts” or “Phone pad”. Yes, there are VoiceOver gestures to explore the screen top to bottom, left to right. You do this by flicking left to right anywhere, and the accessible controls are being walked one by one. But the interaction model is very close to the actual screen layout most of the time. This tremendously helped when I walked through a couple of applications with the sales assistant standing next to me. She could literally point me to the correct spot, and VoiceOver would speak what I needed to hear. Or she could give me verbal directions, and my finger would find the controls.

Typing is probably going to take the most adjusting. It is nothing like typing on the number pad of my N82. James Craig’s typing tip for VoiceOver on iPhone helps a lot: You look for the correct key with one hand, keep your finger there, then tap somewhere on the screen with another finger from the same or the other hand, and the character is input. Gladly, the keyboard doesn’t change position, and after a few letters I had a very good idea where each letter should be, and my typing sped up within 10 typed letters already. In addition, one can turn on word prediction/completion, which is another accessibility feature that can also aid people with motor impairments make typing easier. It plays nicely with VoiceOver.

This is by far not a comprehensive review or comparison. I couldn’t use many of the features since the SIM card in that exhibited model was locked, and I don’t have my own model yet.

Apple are speeding ahead and breaking down conventions in accessibility, or as Mike Calvo of Serotek wrote: They’re getting to the future first. They’re the first to include a screen reader for the blind on one of their mainstream models. Google are going to do something similar with their G1 efforts. The API is there, and some basic console work seems to be working already, but this is by far not as comprehensive as what Apple are doing. RIM also have an accessibility API, but from what I’m told, the screen reading solution that has been hinted every now and then over the past couple of weeks is going to cost extra money, which Apple’s solution does not. The traditional mobile accessibility solutions on Windows Mobile and Symbian S60 all require an additional payment of $200 to $350 for a screen reading solution, or in some cases even proprietary hardware that then costs $2000 or even more.

And this, of course, opens up other possibilities for future implementations of touch screen use cases, not just by Apple, but by other companies as well.

And one more bit of info: The gestures and touchy interface also come to VoiceOver in Snow Leopard with compatible new MacBooks with the multi-finger trackpad. So whenever a colleague tells me to lok for something in the top right quadrant of the screen, I can do that once I have Snow Leopard running on my MacBook. I’ll just put my finger there and let VoiceOver tell me what’s there!

Now my only problem is to get an iPhone. It would appear that my current contract doesn’t allow me to upgrade, since I upgraded it only recently, but too long before I knew the 3G S was coming. We’ll see how I get my hands on a device, it’s not freely available without contract in Germany.

My first touch screen experience was an amazing one!

Posted in Accessibility, Apple | 103 Comments

Exposure of audio and video elements to assistive technologies

Posted on June 11, 2009 by Marco

This blog has been quiet recently due to me being away at the AEGIS forum and workshop near London last week (more on that to come soon), and us preparing everything for the Firefox 3.5 release.

If you’re using Firefox 3.5b4, you may already have been notified of the Firefox 3.5b99 update. This update brings exposure of the HTML5 audio and video elements through the MSAA/IAccessible2 and ATK/AT-SPI accessibility interfaces, further strengthening our commitment to Open Video.

What this means is that, using NVDA or Orca, you now have access to an HTML5 audio or video file embedded in a web page. If the controls attribute is specified within the audio or video tag, Firefox 3.5 creates its own set of playback controls. These are now exposed to screen readers using MSAA or AT-SPI to traverse our trees. Exposure through iSimpleDOM interfaces on Windows will come at a later stage (see this bug). Previously, these controls were unreachable. They did not appear inside the virtual buffer.

In addition, a keyboard navigation bug was also fixed allowing control of most of the functions of the embedded controls. Note that the individual buttons and sliders are not yet tabbable, we’ll be working on a good keyboard interaction model and hopefully improve the current model in a point release.

To test the video element, with NVDA as an example, do this:

  1. Go to this video.
  2. Using NVDA’s quick key b, find the Play button.
  3. Press Space.
  4. To interact with the audio/video element directly, press NVDA+Space to turn to Focus Mode temporarily, and Shift+Tab once to land on the video grouping.
  5. You can now use the following keyboard shortcuts:
    Shortcut Action
    Space Play/Pause
    right arrow and Left arrow Move through the video in 5 second intervals.
    Ctrl+Right Arrow and Ctrl+Left arrow Move through the video by 1 minute increments.
    Up arrow and Down arrow Increase and decrease the volume. This does not change the volume of your speech synthesizer!
  6. After you’ve finished interacting with the video controls, press NVDA+Space again to turn virtual cursor back on.

Note that the ultimate goal is to not require you to turn focus mode on and off with NVDA+Space, but to allow you to interact with each scrubber/slider using the regular Focus mode command Enter and Escape, however we’re not quite there yet (see the linked bug above).

BTW: the above keyboard shortcuts also work if you don’t have a screen reader running. You need to tab to the video element grouping and then use the shortcuts as described.

Note also that due to our not exposing the elements through iSimpleDOM yet, some screen readers may not see the controls yet. In that case, turn off your virtual cursor and tab to the video element to use the keyboard shortcuts to control your video playback.

Stay tuned for more updates as they come along!

Posted in Accessibility, Firefox | 4 Comments

Last weeks in the “Accessible” module, May 11, 2009

Posted on May 11, 2009 by Marco

Sorry for being a slacker in updating you guys regularly on what’s been happening! But we’ve been quite busy at getting some stuff finished and hopefully ready for inclusion in 3.5. I already posted about the return of the descriptions last week. So here’s what else happened since my last report:

Exposing HTML 5 audio and video elements

The initial exposure for the HTML5 audio and video elements to screen readers landed, causing a minor regression that was quickly fixed. In testing this with NVDA, I found that the button labels weren’t properly exposed and that the slider values were not really useful. The progress meters were showing the number of bytes downloaded, or the milliseconds elapsed instead of useful percentage values. Along those lines, Alex also added a bug to expose proper names for each progress meter, so a screen reader user knows which slider is for what purpose.

Except for the last patch, all others have landed on mozilla-central and will be available for testing starting with the 11th of May nightly build.

To make it clear: This is for those HTML5 audio and video elements that have the controls attribute set, indicating that the internally available controls should be used. Other forms of controlling the media playback, such as from external HTML controls/widgets, already worked in the past since these were not part of the actual audio or video element itself.

Tree view item rectangle exposure

We received a report that in Thunderbird 3 beta on Windows, the rectangles for tree view items were not exposed correctly. The rectangle was too small, not encompassing the whole item. Alex investigated this and fixed the bug, putting an optimization in as a second step for all platforms. This also landed on mozilla-1.9.1 after having baked on mozilla-central for a while, and is available since the May 9th nightly builds of Shiretoko, Thunderbird and SeaMonkey.

The ARIA live region background tab leakage

David has been taking different stabs at bug 444644, with some good results thanks to feedback from Roc and BZ during the Mozilla all-hands week. However, we’re still fighting a situation where the creation of virtual buffers by NVDA is causing the live region updates from background tabs to be spoken again. Investigation is ongoing

Other ARIA-related triage

David’s also been a busy bee clearing out some ARIA-related bugs, gathering feedback here and there, closing others as they’ve been solved by other bugs, etc.

Firebug accessibility

This is not strictly inside the “Accessible” module of the platform, but very closely related to the Mozilla eco system. Accessibility of the Firebug UI has been shaping up very nicely over recent weeks. I spent a fair amount of time last week pounding the different alpha releases to help make sure things stayed in shape.

On Friday, Hans from the Paciello Group, Jamie from the NVDA team and I also managed to get the biggest outstanding problem solved in a very productive meeting on IRC, and that’s the reading of the Firebug JS panel by NVDA. Watch this space for a review once Firebug 1.4 goes to beta!

That’s it for this week, thanks for the read!

Posted in Accessibility, ARIA, Firefox, NVDA, SeaMonkey, Thunderbird | Tagged , , , | Leave a comment

The descriptions are back!

Posted on May 7, 2009 by Marco

For those of you following along the Firefox 3.5 development cycle, you may have noticed a regression when dealing with HTML elements that have both screen text and a title attribute, such as the previous link in this sentence.

In Firefox 3.0.x, we expose the screen text, in this case the word “regression” as the accessible name. This is the piece that screen readers speak when focus lands on the link, and which usually also gets rendered into the virtual buffer.

If there is also a title attribute, in this case “@title attribute no longer exposed on accDescription”, this will be translated into the accessible description of the link object. This is additional information that can be spoken by the screen reader on demand. For example, in NVDA, focus the link or arrow to it in the virtual buffer, and hit NVDA+Tab. NVDA will speak first the name, followed by the fact that this is a link which is linked to something, followed by the description.

The one exception where we do not expose a description is when the screen text and title attribute contents would match. This is considered bad practice anyway, because it is redundant information, and thus we suppress it.

Firefox 3.5b4, and in fact all builds that date back to mid October last year, have a bug in that the title attribute is no longer exposed as the accessible description. Jamie from the NVDA team found this recently and notified us.

I’m happy to report that this functionality got restored in the Firefox 3.5b5pre nightly builds starting with the May 7, 2009 build. Sorry for any inconvenience this may have caused!

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

Last week in the “Accessible” module, April 20, 2009

Posted on April 20, 2009 by Marco

After the Easter holidays, pace has picked up again in the development of accessibility features and other work surrounding our eco system.

Actions for sorting and expansion/collapsing

After some minor setbacks, David’s patch on exposing actions for ARIA sort and expand/collapse attributes finally landed today. This means that:

  • An element that has aria-sort set, will expose an action of “sort” to assistive technologies.
  • An element that has aria-expanded set to “true” will expose an action of “collapse”, one that has aria-expanded set to “false” will expose an action of “expand”.

These can be used to exactly determine what action will be performed once it is being performed.

Exposure of the HTML5 audio and video element controls

Alexander’s patch to expose the embedded controls of the HTML 5 video and audio elements has landed on mozilla-central. With NVDA, one can now see the grouping where the controls are, and invoke the action on each of the buttons. One can even switch to focus mode on the sliders and use the arrow keys to manipulate them. Note: Due toa different approach in reading our information, JAWS does not yet expose these controls despite this patch. Other screen readers are pending tests.

There are a few problems still which will be addressed soonish: For one, the buttons don’t have text labels yet, and the slider percentage values reflect times rather than actual percentages, so we need to see how we’re going to expose this properly.

In other news

The team, along with a number of community members, has worked on a new high-level accessibility strategy document. Frank Hecker has a blog post explaining this in greater detail.

Spreading the good work of ARIA to mainstream open-source CMS

Peter Krantz, accessibility expert from Sweden, has started an effort to contribute WAI-ARIA landmark roles to mainstream open-source content management systems. If you know one of the CMS that don’t have patches yet, feel free to jump in!

That’s it for this week, see you next week for a new edition!

Posted in Accessibility, ARIA, Firefox, Mozilla | Tagged , , | 2 Comments

Extension tip, and feedback appreciated: Feed Sidebar

Posted on April 17, 2009 by Marco

The extension Feed Sidebar by Christopher Finke is a small extension that allows to view one’s Live Bookmarks in a sidebar, much like one would view history or bookmarks. It is not a new RSS feed management, but instead operates on the live bookmarks one has in the profile via the “Subscribe to this page” option from the “Bookmarks” menu.

In the version that is currently on addons.mozilla.org, there are several problems with missing label7control associations in the Options dialog as well as problems navigating the tree, and more importantly, opening a feed article via the keyboard.

Not too long ago, I contributed a patch to the project to fix these problems, and Chris has accepted it and put it into a recent beta version of Feed Sidebar. He also made it possible to access the sorting options from the context menu.

The latest beta brings a better updating mechanism that is less resource hungry.

For those of you who have asked me about a way to view feeds in a tree like structure, this is definitely worth a try! Go download the latest beta version here! I’ve found it to be very stable and accessible. Of course, feedback is welcome! You can either contact Chris directly of course, or leave a comment here, I’ll then forward it to him.

Enjoy!

Posted in Accessibility, Extensions, Firefox | Tagged , , , | 2 Comments

Article on how to use NVDA and Firefox to test web sites for accessibility

Posted on April 14, 2009 by Marco

I just published an article on how to use NVDA and Firefox to do website testing.

This article can be found on the front page of my blog under the “Pages” section, in the “Articles” sublist.

The article is meant as an introduction, not as a replacement for the NVDA user guide, and it is certainly not meant to replace other accessibility testing tools you might use for your website testing, just as an additional tool to help you get a feel for how blind users interact with your web sites or web applications.

I plan to update the article periodically as new versions of NVDA become available, features are added and other info relevant to the article might change.

Enjoy the read, and feel free to leave feedback!

Posted in Accessibility, Firefox, NVDA | Tagged , , , | 14 Comments

Why are web forums so unpopular with the blindness community?

Posted on April 7, 2009 by Marco

Last week, David Tenser, Kadir Topal, and I received an e-mail from Dirk, a moderator at www.BLINDzeln.net, a mostly German-speaking community which uses mailing lists exclusively to promote exchange between their members. These mailing lists vary in topics from cooking and gardening to some pretty advanced computer science, psychology and others. Dirk asked whether it would be possible to create German-speaking mailing lists pertaining to accessibility to give those who have switched to Firefox and/or Thunderbird, or those willing to do so, a common place to go. He also said that he and other moderators thought about doing this at BLINDzeln, but didn’t do it because they wouldn’t want to create an isolated island, but encourage end-user exchange by asking Mozilla to do it on our servers instead.

In the e-mail exchange that ensued, two positions became apparent:

  • On the one hand, it was stated that blind people prefer the exchange through mailing lists highly over any other means of exchange possible on the net today, and that this is the easiest to access medium. This has a lot of merrit, since to subscribe to most e-mail lists, you don’t even need a web browser. If you know the mailing list address, you can send a subscribe request and acknowledge that by only knowing how you compose and reply to e-mails in your favorite e-mail program. Forums, on the other hand, are often secured against spam bots by CAPTCHAs, and the display is considered by many to be highly inefficient for reading. Newsgroups are somewhere in the middle, with the strict insisting on the netiquette by “usenet cops” being what drives new users away from this medium mostly.
  • On the other hand, David and Kadir advocated for Sumo and the German firefox-browser.de community forum respectively, stating that support personell and volunteers and most community members frequent Sumo and other forums highly, but hardly any mailing lists. On IRC, Kadir and I talked about this as well, and others who chimed in even used words as strong as “hate” when it came to the topic of mailing lists.

I did some research, and found quite some diversity in who uses which medium. For example, among Mozillians, mailing lists, which are mirrored to newsgroups and Google Groups, are the most frequented way of doing development planning discussions, project-specific exchange etc. With mailing lists on one hand, and an almost forum-like display at Google Groups on the other, this is a very cross-over way of offering access to the groups. But one does not see many end users here. There are support-like newsgroups, but compared to the number of users we now have, the traffic is comparably low. The MozillaZine forums enjoy very high traffic by comparison.

In other areas, I found the same picture. The more end-user, the lesser techy, the more popular web forums are. The more techy, the more things take place in mailing lists rather than forums. Granted, most mailing lists have a web-accessible archive nowadays. But even that’s controversial: In the above mentioned IRC discussion, one person I’d consider to be rather technically versed mentioned that he hates mailing lists and the typical Mailman archive format on the web because it shows only one post at a time, requiring him to click constantly to read through a thread.

Interestingly enough, in the recent screen reader survey results published by Webaim, web forums were not mentioned in either list of web sites, neither particularly accessible nor particularly inaccessible.

So, what is it that makes so many blind people go to mailing lists instead of web forums, sort of contrary to most of the main stream on the internet today? Are web forums inherently inaccessible? Or, is this one of those things that sticks around while the actual picture has changed, but the blindness community simply has failed to notice?

Provocative questions, I know. One of the things that drives blind people away, and which also drove me away from forums for a long time, is the spaghetti-ish nature in which many, especially older, forum software displays threads. It is very hard to find the beginnings of posts, making it difficult to skip over a reply that is of no interest. As blind people cannot visually skim forum topics like sighted people can, this is essential to efficiently navigate and participate in forums.

Here are some examples of forum post views that may give some clue as to where this resistance to use web forums amongst the blindness community may come from, and where it may also no longer be justified:

  • In this thread on the MozillaZine forums, each reply starts at a new item in the definition list that is used to display the topic. With the other lists inserted to encapsulate the “Reply…” and other info/action possibilities, simply jumping from list item to list item, as one would first expect, does not really get you quickly to the start of the next post within the thread.
  • This thread on the phpBB community forum shows a nice way to do things: Each reply starts at an HTML heading element, making it very easy to skip forward if one doesn’t want to read the rest of the current reply. Since both phpBB.com and MozillaZine use phpBB, this seems to be a question of theming the forum.
  • Also based on phpBB, but on an older version, is this example from the German DelphiPraxis community forums. This is what I referred to as the spaghetti view earlier that drives me and others away from forums. It’s a tabular layout, done with HTML table and descendant elements, and each post within the thread simply gets its own new row. Most screen readers do offer a way to navigate tables by row, but the keystrokes for doing so are much more cumbersome, requiring usually both hands to execute them than is good for casual reading or browsing. Table navigation is made for consciously interacting with data tables. I have seen similar table-based constructs in both VBulletin-based forums as well as the Carookee.com forum service.The German firefox-browser.de community forum uses a similar display right now, however this will probably change once they upgrade to phpBB3.
  • Looking at bbPress, the companion to the WordPress blogging software, they use a similar list-based display style as MozillaZine in terms of markup, but no intermingled lists, allowing to quickly skip ahead to the next post if the current one doesn’t interest me.
  • Lastly, the Sumo forum display shows a series of divs that are used to show the posts within a certain topic, but no special semantic markup to help navigate from one post to the next within an individual thread. It is similarly spaghetti-ish right now, with the difference being that it uses divs instead of layout tables.

Disclaimer: The topics chosen above and the comments made about the quality of the individual display styles is not meant to reflect on the quality of the forums themselves. They’ve merely been chosen for illustration purposes in the accessibility context of this blog.

As the display of the phpBB community forum post shows, there are possibilities to choose really accessible forum themes and create an attractive forum that also blind people might like to use. However, there’s also still a lot of forum software out in the wild that does not conform to any modern accessibility standards and thus offers a rather unattractive accessibility experience.

Also, one thing that I briefly mentioned are CAPTCHAs. Fortunately, with Firefox 3 and WebVisum, these are solvable for blind users. Or audio CAPTCHAs are spreading more and more, making this a barrier that is possible to deal with given the proper tools.

And now, I’d like to hear YOUR opinion on this topic! Do you prefer forums over newsgroups or mailing lists? Do you prefer to read on the web or in your e-mail client, in your RSS reader? Do you easily keep up with where you left off reading in a certain thread? What are the challenges you’ve faced dealing with forum software in the past or present?

On the other hand, if you’re a forum user and don’t like/use mailing lists, why is that? What do you find more attractive about forums that makes you not like mailing lists, or even hate them?

Welcoming your comments!

Posted in Accessibility | Tagged , , , , | 17 Comments

Updated ARIA-spiced form example to work in IE 8

Posted on March 31, 2009 by Marco

I updated my simple form example from the third Easy ARIA Tip to also work in IE 8. I had to explicitly state a doc type to put IE out of quirks mode into proper IE 8 mode, and I also had to change the type attribute’s value of the script tag to “text/javascript” from “application/javascript” for it to recognize the functions declared in the script block.

The example works visually, but has a number of accessibility issues which make testing IE 8 with it a not so pleasant experience:

  • Neither aria-required nor aria-invalid take any effect with either JAWS or NVDA. It’s as if the attributes weren’t set, yet the IE DOM exposes them correctly, as JAWS’s Element Info keystroke, Insert+Shift+F1, clearly indicates.
  • Neither JAWS nor NVDA see the alerts come up, and thus don’t speak them. The alerts appear visually, so the JavaScript is working, but the DOM mutation is not being picked up. Only after a refresh in the respective screen readers is the content of these visible in the virtual buffer.

For testing, I used the latest update to JAWS 10, build number 10.0.1142, and NVDA trunk snapshot 2828. And of course, the release version of IE 8.

For those of you doing web application development and testing, this is an indication that your best bet to get proper results is definitely the combination of a strong implementation of ARIA in Firefox and a supporting screen reader.

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

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

Posted on March 30, 2009 by Marco

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

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

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

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

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

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

Posted in Accessibility, ARIA, Firefox | Tagged , , | Leave a comment

Last week in the “Accessible” module, March 24, 2008

Posted on March 24, 2009 by Marco

As the accessibility team was at the 2009 CSUN Center on Persons with Disabilities conference last week, not much happened on the forefront that is visible to bug and code watchers. The only changes that landed were:

However, as David mentions in the above mentioned post, we took the chance to put our heads together and develop ideas for future features and also talked about some hands-on issues that need more immediate attention. Also, it was the first time David and I, and David and Alex met in person. I had already met Alex last year in Whistler at Mozilla’s 2008 Firefox+ summit.

Additionally, Ben Hearsum has been active in trying to get our accessibility Mochitests run on Mac unittest tinderboxes, but ran into some leaks that require further digging because we don’t use either class explicitly in the platform-independent or specialized Mac code. We’re probably uncovering a leak that’s hidden somewhere else. If anyone has any good suggestions off the top of their heads, please feel free to step in!

That’s it for this week.

Posted in Accessibility | Tagged | Leave a comment

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

Posted on March 16, 2009 by Marco

Last week, we focused mostly on some solidification on our code and test framework. We are having some strange problems with tests failing randomly or not being run at all. To that end, I fixed the loading of remote images in Mochitests, which is always a dangerous source of failure if an image can’t be loaded from the remote site. David also discovered and worked on protection against some failures in our doAction tests.

David also fixed a PRBool violation uncovered by code analysis. He also cleaned up our object attribute exposure code and added tests to make sure aria-sort gets exposed as an object attribute properly.

David also fixed exposure of mixed and checked states for ARIA and HTML 5. Mixed should not be checked at the same time, and vice versa. I helped out with tests on this one.

I refactored our nsAccessNode caching test. There are only 2 files left to refactor now, and one of those is currently disabled.

Alex cleaned up static casts to ATK roles. He and Ginn Chen from the Sun Microsystems China office also chased down one of our top crashers and Gionn found the root cause for this we believe.

David and I agreed to request that accessibility and the accessibility unit tests be enabled on the mozilla-central unit test tinderbox for Mac. This is the first step in getting Mac accessibility efforts moving again. We are currently anxiously awaiting test results from a run on the staging servers. Cross your fingers!

In other matters, David, Alex and I will be at CSUN in Los Angeles this week, so if you’re in the area, come and drop by our booth! We’re being joined by Frank Hecker of the Mozilla Foundation, Mick and Jamie from the NVDA team, Eitan Isaacson, a regular Mozilla grantee, and Aaron leventhal, without whom we’d probably not be sitting here today.

The venue opens Wednesday at 4 PM and runs through 7 PM, Thursday and Friday it runs from 9:30 AM to 5 PM, and on Saturday it runs from 9 AM to 1 PM. I’ll be holding a presentation on Friday at 12PM talking about what we’re currently doing, and planning to do in the future, with Mozilla accessibility, so if you can still get a seat, come on over and let’s have a chat!

See you all next week, where I’ll be reporting a bit about what the venue has been like. I’ll also be updating my tweets, so if you like, follow the hashtag #csun09 on Twitter for my and other people’s updates.

Posted in Accessibility, ARIA, Firefox | Tagged | Leave a comment