Posts Tagged ‘Mozilla’

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

Monday, April 20th, 2009

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!

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

Monday, March 2nd, 2009

This is the first in an ongoing weekly series where I’ll highlight items that the accessibility team has been working on over the last week. I’ll be reporting on fixed bugs, or will also call out on items that we might appreciate your help on.

Since this is the first issue, and my last update on a concrete new feature/major change has been a while, here’s a broad overview over what we’ve been up to over the past two months or so.

Automated tests on all three active Firefox development branches

Since December 18, 2008, all three Firefox branches that are under development run accessibility mochitests. These branches are:

  • Gecko 1.9.0, off which Firefox 3.0.x is being released. These tests actually have been running since roughly the Firefox 3.0.4 timeframe in October.
  • Gecko 1.9.1 AKA Firefox 3.1. This is the branch Firefox 3.1 will be released from.
  • Mozilla-central. This is the development branch where the next major release after Firefox 3.1 is being developed, with new features going in and more experimental stuff is happening right now.

The most interesting of these is definitely the mozilla-central branch. Both Gecko 1.9.1 and 1.9.0 receive back ports of important features/bug fixes from this branch. The number of tests that run in the accessibility code has surpassed the 2,000 mark two to three weeks ago. We started in December with about 1100 tests.

ARIA 1.0 compliance patches

David has been working on ARIA 1.0 compliance patches and started to put in some good infrastructural stuff as well. Interesting items are:

Alex implemented the ARIA spec’s name from subtree calculation algorithm. Of course, despite all the tests, a regression had to creep in, but after that’s fixed, I believe we’re in good shape. The visible result, especially for authors of ARIA-enabled we bapps, is that the Firefox 3.2a1pre nightlies should now always behave according to spec when calculating the name from those elements/widgets that call for its subtree to be aggregated as its name.

As a side note for those interested in the effect our automated tests now have: When Alex tried to land a fix for bug 463645, it clashed with the above mentioned name from subtree bug in an unexpected way, causing an immediate orange flag on the unittest tinderboxen. We’re looking for a solution to that problem right now. Hadn’t we had these tests in place, it would have taken a while for this regression to creep up in manual testing. This way, due to an immediate backout of the offending code, no nightly build ever saw this happen.

New for text attributes

David implemented the conversion to pt algorithm that IAccessible2 calls for on Windows. This change is also in Firefox 3.1.

Alex implemented a faster way of retrieving text attributes,a nd he and I teamed up on better better test coverage for this area.

Accessible relations improvements

Alex worked on better accessible relations support, allowing for a relation to have multiple targets. This will allow assistive technologies to get at aria-labelledby relations correctly. As a sequel, 1:1 relations between tabs and tabpanels were also implemented, allowing ATs to better identify which tab a tab panel belongs to.

Proper reorder events

Alex, our man for big patches :-) , also created a fix for a long-standing bug involving reorder events on DOM mutation changes. Several screen readers need these events to keep track of dynamic changes on web pages to keep their virtual buffers up to date. Some recently inconsistent behavior that often required the user to refresh their virtual buffers manually, should now work much better. This change also is included in the Gecko 1.9.1 branch already, waiting to debut in the upcoming beta 3 of Firefox 3.1.

Thunderbird 3 reading panes

The Thunderbird 3 reading panes received a fix to the way they expose the “from: ” etc. header information. When tabbing through these header fields, one now immediately hears which type of header this is with a compatible screen reader.

This fix was done by Yuen Hoe, a student at the University of Singapore, as part of the NUS Mozilla students project. He picked this bug specifically. Thanks Moofang!

Because this patch relates very closely to SeaMonkey, it was ported there as well, however users can’t take full advantage of this yet in SeaMonkey because of a keyboard navigation issue in the message reading panes.

Better accessibility in SuMo’s live chat

SuMo, Mozilla’s support community, offers a live chat facility that alows users to get help quickly. This live chat was previously not very accessible.

However, Gijs Kruitbosch, the mastermind behind ChatZilla’s accessibility features, worked on a fix, which will see the light in one of the next Sumo updates.

I know this is not strictly the Gecko Accessible module, but nevertheless very important to the over-all Mozilla eco system, and that’s why I’m mentioning it here.

On other fronts

I’m currently working through some of the earliest test files to make them use the common accessibility retrieval and events structures that were implemented more recently. This will help maintainability and make sure that if we add new features to these common functions and classes, every test will benefit from them.

On Windows, all active branches will be more correct in what service IDs they accept when calling the QueryService function. This insures better compatibility with Windows 7, among other things.

Thanks for sticking with me until now! The next reports will be shorter, I promise! :-)

Of course, we welcome your feedback on this kind of post, or on specific areas. So feel free to comment here!

A job opportunity in Mozilla accessibility!

Monday, August 25th, 2008

The Mozilla Corporation has the following job opportunity available:

The Mozilla Corporation is looking for a full time engineer to develop accessibility in its software.

The job will involve working with a small team to develop support for a wide variety of 3rd party assistive technologies such as screen readers, screen magnifiers, on-screen keyboards and voice dictation software on a variety of operating systems.

The candidate we are looking for will be an excellent C++ programmer, with experience in COM or XPCOM, as well as working on OS X and either Linux or Windows. Previous experience with the Mozilla codebase is a plus. The candidate should be interested in developing solutions which improve how users with disabilities interact with the web.

Mozilla Firefox already has a strong foundation in this area. However, as the web progresses to provide ever more interactive and complex applications, interesting challenges continue to present themselves. For example, users with significant visual or physical impairments need to be able to interact with applications as complex as online word processors and spreadsheets, as well as content which includes technical information such as diagrams and mathematics. These users will be interacting with the content using text-to-speech, Braille displays, on-screen keyboards, voice input software, and other interesting technologies.

The candidate should be passionate about improving the Mozilla platform and be interested in pushing forward in a truly challenging and interesting area, which improves the lives of users with disabilities by removing barriers to participation on the web.

Some of the standards we will work with include HTML 5, SVG, MathML, WAI-ARIA, OS X’s AXAccessibility API, ATK/AT-SPI and IAccessible2. The team will assist the candidate in becoming more knowledgeable with respect to accessibility topics and the APIs involved.

Occasional travel will be part of the job, such as to disability-related conferences like CSUN and Mozilla project events such as on-sites and summits.

If this sounds interesting to you, get in touch and send in your resume!

Share your success stories with Mozilla Accessibility

Friday, May 16th, 2008

Aaron Leventhal posted a great summary of the impact of Mozilla Accessibility to the mozilla.dev.accessibility newsgroup.

Have anything to add? Any success story to share where the accessibility in Mozilla product had an impact on you? Either comment here on the blog, or go to the thread and reply there!

We want to hear from you!

Firefox integration into Linux also sounds native to the platform

Thursday, January 10th, 2008

Michael Ventnor, a Mozilla intern working on the Linux integration of Firefox 3, just posted a great summary of the work that has been done for Firefox 3. For those of you who can see, he also has a bunch of screen shots that show Firefox nicely integrating into the Gnome Desktop on Ubuntu.

I’d like to add a few items that a blind user who uses Firefox 3 with Orca will notice.

Aside from the obvious, the web browsing itself, great attention has been paid to make dialogs such as the Preferences dialog behave like dialogs in other Gnome apps: The Cancel button comes before the OK button while tabbing through the dialog. The dialog itself is found under the Edit menu, as is usual for other Gnome apps, and it’s called “Preferences”, not “Options” like on Windows.

The Location Bar is an AutoComplete, a widget type not found on Windows, but used natively on Linux.

The Places Organizer tree tables are native tree tables, displaying hierarchical information in multi-column view.

As you would expect, the Open File, or any kind of Save As dialogs are the native Gnome dialogs, so if you’re used to using GEdit, OpenOffice etc., you’ll feel right at home, Firefox is not requiring you to learn something new here.

One inconsistency I found–and I’ll have to find out whether a fix for this is planned– is the fact that above mentioned Tree Tables cannot be navigated like, for example, in Nautilus: In Nautilus, you expand a collapsed item using the + key, and collapse it using the - key. Pressing Right Arrow moves you one column to the right, Left Arrow moves you one column to the left. This does not yet work in Firefox (or Thunderbird, for that matter). There, Right Arrow expands, Left Arrow collapses an expandable node, and moving between columns isn’t possible at all currently. So this is typical Windows-style still, but within that, consistent across platforms.

All in all, I expect the browsing experience with Firefox 3 on Linux to be a great one. The Orca team is putting hard work into making Orca work well with Firefox, and the past month alone has brought an emense boost in speed, as discussed here.