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

5 thoughts on “Firefox OS App Accessibility Workshop Part 1: Labels

  1. Is there a reason why you didn’t simply add text to the button? There’s nothing wrong with using aria-label in this example, but the first rule of ARIA is to not use it when there is a standard alternative. So the other option would be to include text, but hide it visually with CSS as you add the background image.
    I’m wondering if there is a limitation in FirefoxOS that would make aria more preferable than hidden text ala http://developer.yahoo.com/blogs/ydn/clip-hidden-content-better-accessibility-53456.html

  2. I’ve recently been given two Philips alarm clocks that incorporate SAD lights to review on Amazon. On first sight they’re very similar, but the more expensive one has three wakeup sounds and an FM radio. Their cases actually differ quite a bit, given that they obviously roll off the same production line. The cheaper one has four mechanical buttons on the front that do almost all the day-to-day settings, and (as a sighted user) you don’t need to read the instructions, although it is quite beneficial if you do.

    The more expensive one has nine buttons on the front that are not mechanical, you just touch them. They are hard to see unless activated and some have a corresponding light display that looks like a button but isn’t. This is initially confusing. You definitely need to read the manual.

    One weird thing is that the turn-the-radio-on button is an outline drawing of a radio with an aerial, but when I looked at it before reading the instructions I hadn’t got a clue what it meant, even though I knew the device contained a radio.

    With experience it’s almost as easy to use as the simpler one, but other members of the family who haven’t read instructions can’t use it. They need to learn how to turn off the alarm, for example. I think that turning off an alarm needs to be particularly intuitive.

    The reason I’m writing is twofold – based on my experience with these Philips devices the challenge of creating an icon on an alarm clock that is totally intuitive, and the function of which exactly matches the expectation of the user is tricky. I guess your real advantage with an app is that you never make it mechanical so you have a lot more flexibility. The second thing is contrast levels. The more expensive Philips device is ridiculously un-contrasty when the buttons haven’t been activated. I think people who have failing eyesight or one of a range of visual disabilities are the big victim of this subtle school of design. The Snook colour contrast tester is really helpful and it does help you focus on the size of text (or, I suppose, icons too) as well as their colours and contrasts that let you accommodate a range of types of colour blindness.

    Finally, I wonder whether you’ve actually tried sitting with a blind person while they test your app? We found this to be invaluable when making our content management system work in JAWS – we had a friendly CMS user who could give us direct feedback and through a few iterations of testing and fixing learned a lot of things that a sighted person testing with JAWS would have no real understanding of.

Comments are closed.