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!

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!

I still exist. Looks like this blog does too.

Beach House

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.

The last post seemed to get some attention. I also think it has been misunderstood. So I would like to briefly reframe it.

It wasn’t a rant about GNOME Shell or about design driven development. Neither was it a dismissal of the urgency for a strong developer story. I like the fact that we take risks and innovate in design. I also think that our developer workflow is broken, and fixing it is a priority.

To sustain a healthy project and community, we need a mission. This is not news, and we have articulated our mission in the past. But I think it should be re-evaluated all the time, and tested against the real world. When we choose our mission, I think we could do better than blindly chasing the elusive User to the next frontier. I think we could re-evaluate our role in this ecosystem.

New magic gadgets are coming out every day. They have large screens that let you directly interact with the content displayed on them. Did I say magic yet? They are truly magical. They are very good at hiding all the nitty details. In fact, they do a really good job at that. Too good.

When I was first introduced to the web in ’94, I thought “Cool the Louvre has a virtual home. I want one too.” I was able to sit at that same computer where I witnessed that wonder and create “Eitan’s Slime Pit”. We are not far from a reality where a kid would look at the world through their tablet, enjoy their magical digital life, and have no means to truly create their own presence on the web or to author their own app.

This is where I think we should be. We should be a free and accessible environment that enables creation. I think that is an important and critical mission in the Free Software Movement.

I wanted to give my one cent about the GNOME project, and where I think it could be successful. It would be two cents if I were actually involved in any constructive manner, but I am not. So it is one cent.

Ever since I started contributing to GNOME, the looming questions have been mobile, web, and social. Every keynote at GUADEC has tugged us in that direction, or promised to “reboot” the effort. If it is Big Board and Mugshot, Pyro Desktop, Telepathy and the collaboration it was supposed to bring, the countless OpenedHand and Nokia innovations, etc. We have all been running around like a chicken with its head cut off ever since I remember, trying to capture the essence of these new trends and remain relevant.

We failed.

Apple revolutionized not just mobile, but reinvented the mainstream computing form factor. Facebook made “social” ubiquitous, and Google is doing what it is doing to the web. In the meantime, I never gained any following on Last.fm from all those years of scrobbling music with Rhythmbox and Banshee, I never got an opportunity to use Telepathy tubes with any real live person, and apparently my Mugshot profile is gone. My eyes also got tired of squinting at XTerm on my N900.

Last year in Berlin, the lack of direction was apparent. Almost every keynote that I remember was given by one kind of designer or another. Somewhere along the line we confused design with leadership. At least there wasn’t as much self delusion about our bright future on mobile.

But there is a way out of this rut. And it requires acknowledging our weaknesses and exploiting our strengths.

Our weak areas are apparent: We are not mobile and we are very far from it. We will never achieve any significant social critical mass, we have had limited successes in embracing web technologies, but the web will always be a better web. Deploying “apps” is a nightmare.

Our strengths are pretty obvious too: In the last few years we successfully refreshed the desktop work flow and our entire framework. We support many productivity and authoring tools. We created a distraction free environment that lets users get work done. We run on commodity hardware. We are free. We have a windowed multitasking environment. We work really well with a screen, mouse and keyboard (not to be taken for granted, look at all the awkward Android tablet keyboard combos out there). More than one web browser supports us. There is a more than fully functional office suite that works well with us. Etc.

So instead of aspiring to be in every consumer gadget out there, I think we should aspire to be the work horse of choice for every content creator out there. This includes mobile/web developers, graphic designers, artists, bloggers, video bloggers, authors, journalists, podcast producers, and every other kind of content creator that makes the mobile web and social such a vital space for the rest of the world. We need to refocus on the desktop.

Let’s leave the mission of bringing free software to mobile and the web to others. Other groups are doing a great job there. They are in their element; let’s remain in ours. We should focus on the production end of the New Media pipeline.

Projects such as The GIMP, PiTiVi, Anjuta, Blender and Libre Office should be our bread and butter. We should strive to stay ahead of the curve on the authoring end. We should document and support Android and Unity development. The Wacom tablet support that landed recently is a good example of what we could be doing.

It feels like GNOME is being maintained by a skeleton crew, and a shrinking set of corporate stakeholders. I think it is time to be realistic about what we could excel at, and go there. We don’t have to be on every existing form factor to achieve world domination. The cloud, and all these cheap new gadgets have lowered the barrier to access. We could lower the barrier of authorship, and enable people to create new and rich content.

Follow

Get every new post delivered to your Inbox.

Join 298 other followers