Well, now there is a new standard from the W3C called WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications)

The simplest definition of ARIA is adding UI semantics via HTML element attributes. Simply, you add things like ‘<div role="nav">‘ or ‘<form role="search">‘ to specific HTML elements to give screen readers a better understanding of your content.

The ARIA spec is huge (160 pages), so I won’t go over every part of it in detail. The four areas I will focus on are landmarks, required, invalid and live regions.

ARIA Landmarks

Today, when a blind user encounters a website, navigation between elements of the page can be difficult because there is no established method of marking areas of the page as navigation, content, footer, etc. Luckily with ARIA, we can.

Here’s some example markup of a typical webpage:

<div id="header">
    <h1>My Awesome Website</h1>
    <form> </form>
</div>
<div id="content">
    <ul id="nav"></ul>
    My website rocks!
</div>
<div id="footer"></div>

And here’s what it looks like with ARIA Landmarks:

<div id="header" role="banner">
    <h1>My Awesome Website</h1>
    <form role="search"> </form>
</div>
<div id="content" role="main">
    <ul id="nav" role="navigation"></ul>
    My website rocks!
</div>
<div id="footer"></div>

What I’ve done is add ARIA roles to certain parts of the page (header, nav, search form, primary content). Because the roles are a defined spec, screen readers can parse the page for roles and allow a user to jump to each part without having to navigate through all the content.

ARIA Required & Invalid

Another part of the ARIA spec is the attribute ‘aria-required’ and ‘aria-invalid’. These attributes are for communicating to screen readers that a particular form field is required and/or invalid without requiring the user to look for asterisks or other text near the field. The screen reader would alert the user to this information. Here’s an example:

<form id="searchform" role="search">
      <p class="error">You did not enter a search term</p>
      <input name="query" value="" aria-required="true" aria-invalid="true" />
</form>
 

The above code has the ‘aria-required’ and ‘aria-invalid’ attributes set to true. When a screen reader encounters this code, it will read aloud ‘required’ and ‘invalid’. This is a lot simpler for a user than attempting to find error messages and/or asterisks in the page.

ARIA Live

A particularly difficult area of accessibility is dealing with AJAX. How can you communicate to a screen reader that content is loading or has changed? Thankfully, with ARAI Live Regions, it is quite simple. Here’s an example:

    <div id="sidecontent" aria-live="polite"> AJAX content goes here... <div>

Adding the ‘aria-live’ attribute to an element alerts a screen reader that content will change in this region and to read it aloud when it does. The aria-live attribute has ‘politeness’ levels, which allow you to specify how polite the updates should be. The four levels are

• off - updates are not communicated
• polite - notify of changes only when the user is not doing anything
• assertive - announce as soon as possible, but not interrupting the user
• rude - which will be read aloud immediately

The various levels of politeness allow for different situations where users would need to be notified immediately of important information or for content that is not as important.

Summary

This is just a quick overview of ARIA and its uses, but I’m really excited about the possibilities it creates. We can communicate the intent of our content much more explicitly. There’s also a lot of other aspects to ARIA including widgets (slider, checkbox), application structure (alerts, log, progressbar) and document structure (article, grid, definition) that are exciting.

Further Reading

• Longer ARIA overview
• ARIA Spec
• Setting up a screen reader
• Accessible widgets with ARIA

In short, even the simplest sprite images can eat up massive amounts of system memory — 50MB to even 100MB per page or more. Perceived speed for your site is important but you should always be concerned about how sprites and other hacks can affect user experience.

More info:

• Rob Sayre - Sprites
• Vladimir Vukićević - To Sprite Or Not To Sprite

• Promote technology related volunteering between Mozillians and their local communities
• Promote idealist.org and other existing websites that make it easier to connect and change your world
• Inspire your participation during Sept 14-21 through pledges and stories

Start today

Check it out and pledge some hours. You can refine your pledge over time. Be sure to tag your various items with mozservice09.

Mozillians have many “hi-tech” skills that they may not realize are valuable outside of our community. You don’t have to be a Firefox code contributor to do tech volunteering. You can help configuring routers, helping people setup a Wordpress blog, or teach a workshop on using social networks to promote causes. Anything from writing copy, doing data entry, or simply helping groups organize their information can make for a valuable service contribution.

There is a real spirit of service growing and it’s fun to chip in and Be The Difference. Cynicism is out and Participation is in!

Help Us Build

We’re launching early (and releasing often) to get this site into the community for early feedback. Most importantly we hope to prime the pump for volunteering opportunities. We are launching in English, but have built out i18n support and coordinated with the L10n-drivers team. Post Firefox 3.5, where our localizers are pouring their energy right now, we are excited to launch many locale specific versions of Mozilla Service Week. Our first non-english site will probably be mitmachwoche.de (German). Many other localizers have shown excitement for mozservice09 and localizing the site.

Of, for, and by the Web

We’ve partnered with Idealist.org for the English site to make it easy to find ways to help or to register your needs. With the mozservice09 site, we have taken a very de-centralized strategy, hoping to take advantage of the strengths of the web itself. Outside of Idealist.org’s framework, if you want to organize a project through your blog or website for a type of service that we haven’t begun to imagine, that’s great! Mozilla Service Week introduces no heavy-weight process or centralized control.

Just be sure to pledge, Tell Your Story and spread the word. We will feature many of these stories to inspire others to get involved.

Show us the code!

From a technology perspective, one interesting aspect of the site is that when you write a story, you can provide an image or video from another website. Examples include your blog, Flickr, Youtube or Vimeo. The entire website is of course open sourced and available now, but this JavaScript widget/PHP backend is available as a stand-alone library. I’m looking forward to your contributions to make it smarter about finding photos and videos from your favorite websites. An example would be support for dailymotion.com which will be added to the site shortly.

Credits:

It’s been a wild and fun ride building the site with the core team:

• Mary Colvig (Marketing)
• Jane Finette (Marketing)
• Stephen Donner (WebDev QA)
• Krupa Raj (WebDev QA)
• Jeremy Orem (IT)
• Peter Deitz (Social Actions)
• Austin King aka ozten (WebDev).

Many People have been involved with the project so far (and I hope I don’t forget any shout-outs): In roughly chronological order, Michael Morgan provided guidance and support. Axel Hecht, Pascal Chevrel provided l10n guidance with code review from Ryan Doherty and Fredrick Wenzel. Throughout the project Mark Surman and David Boswell from the Mozilla Foundation have helped us shape the vision. John Slater and The Royal Order of Design (Aaron Shimer, Tim Hogan, and Stephanie Bankhead) helped design the site and Craig Cook did an amazing job with the HTML and CSS. Ladonna Willems pitched in on the copy. Again on the L10n front Seth Bindernagel and Wil Clouser gave input. Stas Malolepszy contributed code for rewriting our gettext strings. Les Orchard wrote the Activity Feeder module. Alex Buchanan and Reed Loden prepared the promotional Badges. Our new intern Raymond Agbeame did a great job testing the site. and Jeff Balogh filed some good bugs. The rest of the webdev team also gave input and support. Additionally thanks to our partners idealist.org (Juan Cruz Mones Cazon, Ami Dar), betterplace.org (Tim Benke, Matthias Pries), and of course, the SocialActions team.

As we add more locales and partners, I look forward to volunteering with you, watching the hours pledged ticker go up, and reading your stories.

Before we deployed the new hardware, we had to take several steps to tame our voracious use of disk space. In the previous week, we removed the archived dumps from the database. They were rarely ever accessed but took up the lion’s share of our disk space. By migrating them to file system storage, we made a three hundred gig database migration onto new hardware into a migration of only sixty gig.

While there may be a need for tuning over the next week, Socorro users should have a much accelerated experience using the Socorro Web site.

Many thanks to aravind for shepherding this project through IT, chizu in IT for his db cloning/replication scripting/tweaking and jberkus from PostgreSQL Experts for his superior navigation skills and a steady hand at the PostgreSQL tiller.

From where I sat, it was a pretty amazing view. There were many people involved from start to finish who helped make the project a success and I felt this would be a great opportunity to give you an idea of what makes up a project like this at Mozilla.

• Initiation and Design — Mary and Nobox worked hard to come up with an awesome idea, concept and design. They continued to provide insight and direction throught the entire process.
• Development and Implementation — Ryan Doherty (Webdev) and Jeremy Orem (IT) worked hard to deliver the system to support streaming download counts as well as the programming necessary to make the project happen — database design, PHP, map overlays with accessible alternatives, HTML, JavaScript and CSS. Jacob Potter and Brian Krausz (both Webdevs) helped with stats and mailing lists.
• Localization — Our international community helped us localize our web application by providing translations.
• Testing and Deployment — Stephen Donner (QA) verified and tested all working parts of the site. Legal helped us make sure we were handling information responsibly. Our IT group helped us deploy the application onto our web infrastructure.

As I read Mary’s post, I thought of how this project was a great example of teamwork between multiple moving parts within the Mozilla ecosystem. Not just within a growing company with many different groups, but between different community contributors — from translators to pledges to downloaders.

I am amazed at the level of participation, passion and effort that goes into our projects. We are all proud of these awards. They are a testament to the cooperation and teamwork that happens in the Mozilla community every day.

The following image is a screenshot of geolocation plus Google maps. If you’re running Firefox 3.5, we’ll replace that with a real map showing your current position.

Geolocation finding me at the Mozilla office.

First, we should check that the browser supports the Geolocation API:

if (!navigator.geolocation) { alert('Get a better browser'); }

Now that we’ve cleared out the riff-raff we can dive in to the new feature:

navigator.geolocation.getCurrentPosition()

I love the simplicity of this API; that’s all you need to know to get the user’s position! To do something useful, we’ll need a function to handle a successful positioning call:

navigator.geolocation.getCurrentPosition(function(position) {
    alert(position.coords.latitude + ", " + position.coords.longitude);
});

Since it takes a few seconds to gather location data and send it up to the geolocation services, we must use an asynchronous callback instead of a return value.

The Position object has two fields: timestamp and coords. position.coords holds all the position and velocity information, with the two most interesting (on my stationary desktop) being latitude and longitude. The motion information will be a lot more fun on mobile devices, especially in conjunction with navigator.geolocation.watchPosition.

This blog goes over the most basic usage of the geolocation API, but I have a slightly more involved example available at http://people.mozilla.com/~jbalogh/geo.html. If you view the source you can check out geolocation, -moz-border-radius, and -moz-box-shadow in action.

NOTE: due to a bug in the current Firefox 3.5b4, the geolocation services may fail on repeated calls. The bug has been fixed, but we’re stuck with it in the current release.

That’s the situation that we’ve got in Socorro right now. Each time we catch a crash coming in from the field, we process it and save a “cooked” version of the dump in the database. We also save some details about the crash in other tables so that we can generate some aggregate statistics.

It’s that cooked dump that’s causing some concern. The only time that we ever access that data is when someone requests that specific crash using the Socorro UI. Considering that these cooked crashes take up nearly three quarters of the storage needs of our database, there’s not a lot of value there for the effort. They inflate the hardware requirements for our database, make backups take too long and complicate any future database replication plans that we might consider.

We’re about to migrate our instance of Socorro to new shiny 64bit hardware. Moving these great drifts of cooked dumps would take hours and necessitate potentially more than a day of down time for production. We don’t want that.

It’s time for a great migration. All those dumps are going to leave the database. We’re spooling them out into a file system storage scheme. At the same time, we’re reformatting them into JSON. In the next version of Socorro, when a user requests their dump by UUID, it will be served by Apache directly from a file system as a compressed JSON file. The client will decompress it and through javascript magic give the same display that we’ve got now.

There’s some future benefits to moving this data into a file system format. Think about all of this data sitting there in a Hadoop friendly format waiting for a future data mining project. We’ve nothing specific planned, but we’ve got the first step done.

We’re hoping to get the data migration done within the week. New versions of the processing programs will have to be deployed as well as the changes to the Web application. Once that’s done, we can proceed to the deployment of our fancy new hardware.

For the past couple of days I’ve been pondering our browser support chart that the Mozilla webdev team wrote up about a year ago. Since then, the browser ecosphere has changed considerably. Chrome burst onto the scene with no warning, IE8 was released and Safari 4 is up-and-coming.

One of the toughest parts of being a web developer is deciding what browser to support and how much to support each one. Should it be a binary decision, either support 100% or not? Support some browsers 100% and offer limited support for others? If you decide to gracefully degrade, how much and what features/functionality are considered essential?

And how do you decide which browsers to support? Do you choose via market share, cost/benefit, current/previous release, your website’s audience?

This is an especially tough decision when part of Mozilla’s mission is to promote openness, innovation and opportunity on the Internet. Not supporting a browser simply because a small percentage of users are using it and it’s difficult to code for goes against this mission. Websites and their content should be easily accessible for all platforms, browsers and devices.

It’s a constant battle when there is a distinct need to release early and release often, yet support as many browsers as possible. The added work of supporting more than the most recent browsers is not insignificant.

In the spirit of openness, I want to hear what the community has to say. What are your thoughts for browser support? What will promote Mozilla’s mission but also allow us to develop quickly?

Here’s an example sprite:

The purpose of this post is not to show how it makes a site faster, but cover some best practices when creating a CSS sprite.

Don’t wait until you are done slicing to begin spriting.

The problem with waiting until you’ve built the site is all your CSS and images have already been created. You will have to go back and re-write your CSS. You’ll also spend a ton of time in Photoshop attempting to fit 20-30 graphics into a sprite at once, which is extremely painful and tedious. It’s much easier to build the sprite step by step.

Arrange images opposite of how they will be displayed

This tip is a little confusing and I didn’t learn this until I was halfway through creating a large sprite. If an image is supposed to appear on the left of an element:

Put that image to the right of the sprite (see sprite image from above). This way when you move the background image via CSS, there is no possible way any other image will display next to it. A common problem when creating CSS sprites is positioning images so they don’t appear as part of a background for the wrong element.

Avoid ‘bottom’ or ‘right’ in CSS when positioning

When positioning a CSS sprite behind an element, it’s very easy to use background-position: bottom -300px; or background-position: right -200px;. This will work initially, but the problem with it is once you expand your sprite in width or height, your positioning will be wrong as the images are no longer at the bottom or right of the sprite. Using explicit positioning in pixels avoids this issue.

Give each image plenty of space

As you can see from the example sprite, many tiny images are given lots of space. Why not just cram them all together to make the sprite smaller? Because the elements they are used on will most likely have variable content and need that extra padding so other images don’t show up.

Here’s an example:

Each list item has a graphical number as a background image. If you look at the sprite shown above, you can see how the images were staggered so that if the content increased, no other images would show up.

Don’t worry about sprite pixel size

Chances are if your site is decently designed, you will have a lot of images to put in your sprite. And you’ll need a pretty large sprite to space the images out appropriately. And that’s fine. Empty space in a sprite does not take up much of a file’s size. The sprite used for addons.mozilla.org is 1,000×2,000 pixels and is only 16.7kb!

Got other tips? Leave a comment!

More Resources

• CSS Sprites Tutorial
• CSS Sprite Generator

Our UX Engineer Neil Lee has applied some simplifications to the query form. This redesign was focused on the homepage and global navigation.

Another new feature is that MTBF and Top Crashers By Signature can be exported in CSV format. In the future, as we want to slice and dice different reports, it should be trivial to add this feature to other reports.

In addition I’ve fixed a handful of issues:

• 428110 - Quick and dirty changes to speed up crash analysis
• 478043 - Make ‘is exactly’ the default choice
• 479256 - Clarify labels to be Date Processed
• 470524 - Crash signatures not indented
• 479460 - Bad Unicode in User Comments
• 479447 - report/list with no results has JS error

We would love your feedback. Check out some recently filed bugs or send us some feedback and file a new Socorro bug.

We’ve had some known issues around MTBF and Top Crashes by Signature in the last month and are working on fixing these issues. The upside is that SeaMonkey is now in MTBF.