After my previous post, about labels, @ted_drake commented “Is 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!

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.

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!

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:
[youtube=http://www.youtube.com/watch?v=tVruB7I2G14&w=560&h=315]
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!

I still exist. Looks like this blog does too.

It has been almost 2 years since I joined Mozilla’s accessibility team. I haven’t been posting much, but it has been a fantastic and prolific period. We now have a great accessible Firefox for Android, with new features coming down the line every week. More recently, I have been working on making Firefox OS usable by blind folks. Marco made a great demo of the little bit we have to show for it.

The internet changes very quickly. When I first set up this blog, I hardly knew anyone personally who published any kind of personal update online. Today, I am flooded with everyone’s life details. This has made me a bit of an online recluse. But I am actually just lazy, and I should post more.