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) {
     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

An Introduction To Making Firefox OS Apps Accessible

Hello! This is a first post in a series that will outline the challenges and remedies for making an accessible app in Firefox OS.

First you may ask, accessible to whom? Good question. Accessibility is a very broad term. There are many reasons why Firefox OS would not be available to an individual. In this series we will focus on making apps that are accessible to blind users.

Secondly you may ask, how does a blind person use a Firefox OS device? They can’t. At least not yet. The accessibility team at Mozilla is focusing on bringing together the right tools and integrating them into Firefox OS to make that happen. Namely, we are working on a screen reader.

Thirdly you may ask, how does a blind user use a touch screen smartphone? Very efficiently. When the iPhone 3GS was introduced, it came with a screen reader. Today, iOS devices are very popular among blind users. With a few simple gestures, the entire feature-set of a smartphone becomes available to visually impaired people. This video highlights how that is done with the iPhone:

In Firefox OS we are working on a screen reader with a very similar interaction model to both iOS and Android’s solutions. The main design principal is to allow the user to explore the display with their touch without directly affecting the state of the underlying apps. To interact with an application, for example to activate a control, the user first finds the control by “feeling around” on the screen and then double-taps to activate it. In addition to exploring by touch, the user could flick left or right to advance through the UI in a linear fashion. That is the basic idea, there are many more features and gestures that a user could learn. But if they got the basics, they are good to go.

Fourthly you may ask, if there is no screen reader available on Firefox OS, how do I test my app to assure it works for blind users? There are two answers here.

Screen Reader Simulator Extension

If you work on Gaia with desktop Firefox, there is an extension that is automatically downloaded when you make with DEBUG=1. You can also use the extension, outside of Gaia, in a standalone fashion with Nightly. It is available here. This extension adds a devtools panel simply called “Screen Reader”. It has an “Enable” button. Once that button is toggled, the content view will have our screen reader applied to it. If you hold your mouse button and drag it along the screen, you will notice an orange rectangle highlighting different items. You will also notice that the main area of the devtools panel starts to populate with text. This is a log of what a blind user would hear as synthesized text. The extension has additional toolbar buttons, the “Navigation” buttons are there for you to easily navigate through the content, if you press the center button the highlighted item will be activated, for example a link would be clicked. The “Scroll” section allows you to scroll the currently active view. This is useful since the touchscreen gesture for scrolling is a two finger swipe, which is hard to do on most desktops. Here is a silent screencast of the extension in action.

Enabling The Screen Reader On The Device

You should only do this if you understand how the screen reader works. It could be hard to undo if you don’t, and you may end up needing to clobber your Gaia profile to get your device back. But if you are OK with all that, it is easy. You just need a build off of master (version 1.3), go to the Settings app, and drill down to the developer settings (Device Information->More information->Developer), under the Accessibility header is a checkbox for the screen reader. Enable that. That is it, you should have a talking device!

An Introduction To Making Firefox OS Apps Accessible