Changing Gecko Git Mirrors

You may have read the news that Ehsan will be end of lifing his github gecko mirror.

Having a current mozilla-central mirror on git has contributed to my mental health, and has generally allowed me to be a better human being and not drown in self pity and misery. So thank you Ehsan.

Luckily, the RelEng team has picked up the baton, and have a git mirror of their own running. So go clone it. Unfortunately the commits do not share the same SHA1 as Ehsan’s repo. So you can’t just switch the remote URI. Also, after you clone, you will need to migrate your branches over. There might be ways to do this in a bulk-ish way, but I only have one branch that I really care about, and I will keep the old clone around for a while if I need to pick something up from an obscure branch. So I did this off the top of my head:


[eitan@mozbox Mozilla]$ cd mozilla-central-old/
[eitan@mozbox mozilla-central-old]$ git checkout a11y
[eitan@mozbox mozilla-central-old]$ git format-patch master..a11
0001-Bug-942991-Updated-virtual-cursor-navigation-sounds.patch
0002-Bug-942994-Introduce-clicked-sound.patch
0003-supress-error-when-trying-to-activate-invalid-access.patch
0004-hide-visual-cursor-when-vc-is-null.patch
0005-some-cursor-control-tweaks.patch
0006-start-of-new-dialog-focus.patch
0007-Only-blur-focus-if-new-pivot-position-is-not-focused.patch
[eitan@mozbox mozilla-central-old]$ cd ../gecko-dev
[eitan@mozbox gecko-dev]$ git checkout -b a11y
[eitan@mozbox gecko-dev]$ git am ../mozilla-central-old/000*.patch
Applying: Bug 942991 - Updated virtual cursor navigation sounds.
Applying: Bug 942994 - Introduce clicked sound
Applying: supress error when trying to activate invalid accessibles.
Applying: hide visual cursor when vc is null
Applying: some cursor control tweaks
Applying: start of new dialog focus
Applying: Only blur focus if new pivot position is not focused.
[eitan@mozbox gecko-dev]$

Tada!

Changing Gecko Git Mirrors

Firefox OS App Accessibility Workshop Part 2: Analog Clock

This is a second post in a series about making Firefox OS apps accessible to blind users. You could read the intro here, and a post about labels here.

The Gaia Clock App has a pretty analog view, with ticking hands. You can stare at it and wonder how generations past were able to divine the time of day from a few muted lines. The analog clock should serve the same purpose for blind users as it does to sighted users: It should tell time. In this post I’ll give an overview of the steps I needed to take to make the analog clock view useful.

Analog View in Clock App

If you are a blind user,the screen reader won’t even bother telling you about the analog view. The view is composed from a collection of empty div elements. Since they don’t contain anything besides some special styling, the screen reader skips them and does not bother the user with some arbitrary nested divs. For a good reason, the entire Internet is a collection of redundant nested divs!

To make the screen reader display the view to the user, we need to give the view an appropriate role. This will tell the screen reader’s heuristics that the view is an item of interest. I chose to use the img role, since this is a graphic that describes time. There are other roles that would also be appropriate, such as marquee. But I chose img.

I applied this role on the clock’s container:

...
         <div role="tabpanel" id="alarm-panel" class="active panel">
           <div id="clock-view">
             <div id="analog-clock">
-              <div id="analog-clock-container">
+              <div id="analog-clock-container" role="img">
                 <div id="analog-clock-face">
                   <div id="analog-clock-hands">
                     <div class="analog-clock-hand" id="secondhand"></div>
...

When I tried the screen reader with this change, I found that I was able to land on the analog view. The screen reader would say “graphic”, which is not very useful, but it is something. Now the user knows what is taking up all that space on the screen.

The next step is to label the graphic with the current time. This was done in Javascript. Every time the clock hands are updated, we update the ARIA label as well:

...
   updateAnalogClock: function cv_updateAnalogClock(opts) {
     opts = opts || {};

     if (opts.needsResize) {
       this.resizeAnalogClock();
     }
     var now = new Date();
     var sec, min, hour;
     sec = now.getSeconds();
     min = now.getMinutes();
     // hours progress gradually
     hour = (now.getHours() % 12) + min / 60;
     this.setTransform('second', sec);
     this.setTransform('minute', min);
     this.setTransform('hour', hour);
+
+    // Update aria label for analog view.
+    var time = Utils.getLocaleTime(now);
+    this.container.setAttribute('aria-label',
+                                time.t + (time.p ? ' ' : '') + time.p);
+
     // update again in one second
     this.timeouts.analog = setTimeout(
       this.updateAnalogClock.bind(this), 1000 - now.getMilliseconds()
     );
   },
...

Another round with the screen reader, it now says “11:20 AM, graphic”. That is a lot better!

Screenshot of Screen Reader Emulator showing the analog view correctly.

Firefox OS App Accessibility Workshop Part 2: Analog Clock

Followup On Unlabeled Widgets

After my previous post, about labels, @ted_drake commentedIs there a reason why you didn’t simply add text to the button?” which is a good question! The short answer is, we don’t want to render the text in the button. Instead we want to keep it a graphical icon.

But this question demands an emphasis:

WAI-ARIA is a last resort, it is designed to be a stopgap that augments conventional HTML markup. As HTML evolved, many of the problems ARIA solves have been eliminated. Often, if you are using ARIA you are making a mistake. As Ted continues to say: “…the first rule of ARIA is to not use it when there is a standard alternative.

So back to the issue of labeling controls and elements; aria-label is a last resort. The best option is rendered text, so the visual display is consistent with the accessible naming, for example <button>Press me</button>. After that there are two attributes that can be used, title and alt.

An image may have an alternative textual description, that is what the alt attribute is for. Almost any element may have a title attribute, which will provide a human readable name for the given object.

In fact, I was wrong in the earlier post. Instead of using aria-label, title would have sufficed. The only times aria-label should be used is when you don’t want a tooltip with the text to be visible on desktop, and for naming more complex composite widgets.

I just learned something new, I hope you did too!

Followup On Unlabeled Widgets

Firefox OS App Accessibility Workshop Part 1: Labels

This is the first post in a multi-part series where I will walk you through all the steps I took to make the Gaia Clock app accessible. Now, as of this posting, these changes have not been merged into Gaia, not even reviewed. You could follow the entire effort to make the app accessible in bug 921201

In this post, we will cover the most cliché web accessibility topic, and that is properly labeling controls and elements.

Screenshot of Clock app

When I started testing the clock app with a screen reader, I quickly stumbled upon a control that the screen reader describes as “button”. Sighted users have a good clue as to what this button does. It has an image of a bell, and a plus sign. The active tab below says “Alarm”, so a sighted user would likely assume this button will allow them to add an alarm setting. And they would be right. A blind user will hear “button”, and won’t have the vaguest idea as to what this button does.

The solution is straightforward. We need to add a label. The aria spec gives us the aria-label attribute just for that purpose:

...
 <!--  create new alarm icon -->
-<button id="alarm-new"></button>
+<button id="alarm-new" aria-label="New alarm" data-l10n-id="newAlarmButton"></button>
...

Of course, when you add human readable strings, you need to make it localizable, the l10n.js script should do the trick along with the data-l10n-id attribute above. We will add the string to the locale properties files:

...
 editAlarm             = Edit alarm
+newAlarmButton.ariaLabel = New alarm
...

It’s that simple. We just took the first step to screen reader friendliness.

Next post we will dig deeper into other accessibility challenges and solutions, stay tuned!

Firefox OS App Accessibility Workshop Part 1: Labels