Some do’s and dont’s we gathered from making the Firefox OS UI more accessible

In my last post, I mentioned that we learned a few things from making the Firefox OS UI, code-named Gaia, more accessible over the past few months. This produced quite a few questions about what these things were. So rather than adding them to that blog post, here’s a dedicated one to just that topic.

First, a big thank you to Yura and Eitan for their input on this. It is mostly their patches that I learned these things from, I only played with some of the code myself and gave up when I was notified how much of the CSS broke by my code changes. 🙂

Use buttons or links, not clickable divs and spans

Should be pretty obvious, but you would be surprised at how many clickable divs and spans there can be inside a single web app. Why that is, escapes me really. And despite what Google’s accessibility evangelists say in their videos, the rest of the accessibility community agrees with me that clickable spans and divs instead of buttons or links are not good practice!

Especially buttons are no longer hard to style to one’s liking nowadays. Moreover, buttons are focusable by default, they respond to the “disabled” attribute and are taken out of the focus order, and you get the onClick mechanism for free that usually responds to mouse, keyboard and touch. Moreover, if you just add the type=”button” attribute to a button element inside a form, it no longer is a submit button.

Second preferred thing should be links, however links don’t respond to the disabled attribute and may be harder to style. But there are places where they are definitely the appropriate thing to choose and should not be replaced by anything else.

Don’t use WAI-ARIA roles in CSS selectors

Although technically possible, this is extremely bad practice in our experience. First, WAI-ARIA markup has a very specific purpose. it is there to make HTML elements accessible to screen readers when these are used in a way they were not originally designed for. An example are tabs. HTML has no tabs widget, so compound HTML blocks must be used to simulate them. There is a very specific path to follow for these. If CSS selectors were now based on that markup, and that markup needs to change, suddenly a whole bunch of CSS needs to be touched to, or the layout will break.

In our case, WAI-ARIA roles had been inserted without actual knowledge of what they were meant for, and CSS selectors were based on that. Moreover, other parts of markup then used those CSS selectors by making simple rows of buttons inherit some of the tab styling, which made those buttons expose totally inappropriate semantics to screen readers.

So whatever you do, do not use WAI-ARIA roles or attributes as selectors for your CSS. Keep the visuals clearly separated from the screen reader-intended markup!

Hide inactive content properly

If your app is made in a way where every screen gets its own HTML page, you’re out of the woods. If, on the other hand, several screens are put within one HTML file, you need to absolutely make sure that content is hidden properly. Like the sighted user, you want to trap the screen reader user on one particular touch screen at a time. All touch-screen-supporting screen readers support a sequential method of going through available items on a screen. If you don’t hide the inactive/invisible parts of your app from the screen reader user, they are now suddenly able to move to parts you don’t intend them to go. They might even try to activate items in parts that are currently not appropriate, potentially breaking your app’s logic. We found three methods to work best when hiding content:

  1. Use styling like display: none; or visibility: hidden; for those parts you don’t want shown. That is the most reliable method to hide content, since screen readers don’t ever expose such content. There is a more thorough explanation of the mechanisms and things to consider is described in another post on this blog.
  2. If the above does not work for you for some reason, because you may encounter performance or reflow issues, resort to using aria-hidden. Hide everything except the active screen.

Use common accessibility practices

Most accessibility practices you’ve learned for desktops also apply for mobile. Use alt text, or if that doesn’t work out for some reason, aria-label for images, form labeling techniques as usual, and make sure you have a logical order of your HTML, because on mobile, too, screen readers infer the reading order from the order of the elements in the document object model.

As if on queue, the BBC accessibility team have published their mobile accessibility guidelines today. And although tailored towards the BBC primarily, all of the techniques and examples found there are valid for any mobile web app and its accessibility. I strongly recommend you check them out! If I was your teacher, I’d say: Mandatory read! 🙂

Five years at Mozilla

Exactly on this day five years ago, on Monday, December 3, 2007, I started work at Mozilla as the QA engineer for Accessibility. I’d like to take this small anniversary to look back and look ahead.

When I started, Mozilla Messaging had just been formed to drive and oversee the development of Mozilla Thunderbird. Mozilla Messaging has been folded back into the main Mozilla entity, and Thunderbird has just seen its last major release.

When I started, Google Chrome wasn’t even in existence yet. Today, Firefox is reaffirming its second place in the worldwide browser rankings again, after having struggling a bit in the adjustment period following the long awaited Firefox 4 release and the switch to a six week major release cycle in early 2011. I can certainly feel the Mozilla comeback myself!

When I started, Windows Vista was becoming Microsoft’s big failure. I struggled with it on more than one occasion, and stuck with Windows XP for my main development and testing work until Windows 7 was released in October 2009.

In the last five years, NVDA, whose core developers had just started to implement in-process (fast) virtual buffers, has grown into a real free and open alternative to commercial screen readers in many use cases, and their momentum is still carrying forward! The continuing collaboration between Mozilla and NVDA has led, by testimonials from many users given to me in written and spoken form, to the most rock-solid web surfing experience in Microsoft Windows for blind users. The NVDA team was also never afraid to take chances, question approaches to how certain content should be rendered and interacted with, and innovate on those ideas and questions.

The GNOME desktop was a promising alternative to Windows desktops, and distributions like Ubuntu had the potential to become real end-user alternatives, not just aimed at nerds who weren’t afraid of the terminal. Unfortunately, non-cohesive strategies in the various groups have led to much confusion and frustration, over-all weakening the Linux desktop for end users a lot, distributions changing designs in a major fashion with every release, etc.

The Mozilla accessibility module had no automated test coverage when I started. With the help of other Mozillians, Alexander Surkov and I worked very hard for the first year to lift a mochitest suite off the ground, and shortly before Christmas of 2008, we succeeded, and since then, accessibility has had major, and always improving test coverage on Mozilla’s build machines. It helps to catch accessibility regressions not only in our module, but also in other Gecko code that might negatively impact us.

And then, there was the mobile story, which, when I started, was hardly a story yet. At my first work week in Mountain View, with Mozilla’s headquarters still located in buildings K and S of 1981 Landings Drive, I wrote a blog post about what I thought mobile accessibility might look like in the near and not so near future. Reading this article today, it is very clear that I am not going to be a fortune teller anytime soon. 😉 The actual development played out a lot differently than I had anticipated. But let’s take a look at what the Mozilla mobile story has been since then:

I first saw mobile Firefox in action at the Mozilla Summit 2008 in Whistler, BC, Canada. It ran on Nokia N800 devices on a mobile operating system called MAEMO. MAEMO was Nokia’s parallel effort at a smartphone operating system based on Linux and KDE. Their other strong smartphone arm, based on Symbian, never really played a role here. Today, Symbian is history, more or less, and MAEMO is just having a resurrection attempt somewhere else. Nokia is building Windows Phones now and struggling to survive.

The struggle Nokia was going through with the smartphone operating system business also didn’t leave Mozilla unaffected. They changed the name once or twice until they duck away in hiding some time in 2010. Mozilla has since abandoned MAEMO and its cousins I believe.

Later, there was also a Windows Mobile 6.x version of Firefox, which never saw an actual release, and was discontinued when Microsoft announced Windows phone 7 and its major changes in architecture, which made it apparent that Mozilla couldn’t do anything useful with it afterwards. With the release of Windows 8, this changes again, at least for the X86 part of the story.

And then, there’s Android. It rose at the same time as iOS gained momentum. Both of them totally turned the tables on mobile operating systems over the last four years. And so did Mozilla’s efforts. Firefox for Android has been in development since some time in late 2009, and it saw its first, not very well received, releases.

Our struggle with Firefox for Android, always being very slow to start and very sluggish to use, took a massive turn for the better when the team took chances and decided to completely throw away the XUL-based UI and replace it with one written in native Android widgets and Java. The only view that is not Android is the one that’s displaying the important bits: The web content. After all, everything Mozilla does is about the web, and the surrounding UI is just the necessity to enable everyone to enjoy it.

As I wrote earlier this year, this opened up the possibility for accessibility for Firefox for Android. All previous efforts described had no, or only a little, chance to become accessible. But since the rewrite, since October 2011, the accessibility team, with the help from the mobile team, has managed to make Firefox for Android accessible to blind and visually impaired users on all versions of Android we support, including Android 4.1/4.2 Jelly Bean, with the recent release of Firefox 17 to the Google Play Store.

This, along with the fact that the accessibility module has test coverage, are probably the two biggest goals I have helped the project to accomplish. There are many others, like the accessibility of Firebug, which are definitely worth mentioning, but these are the two I consider most valuable for the project. The test coverage helped us strengthen our over-all module so that it nowadays is rock-solid and can support all the platforms we need it to. The different platform-dependent layers are also getting stronger, with Windows and Android probably being the most stable, with Linux following close behind.

And this brings me to the one thing that I consider the most problematic part of my work: OS X. While it does have basic VoiceOver support now, since version 16 even enabled by default, it’s still not nearly as good as it should be, certainly not nearly as good as Safari is on the Mac. In the last five years, I managed to drive only small improvements. While each of these is a great success in itself, it still needs a lot of attention.

There are other things that worry me, too, but those are not under my direct influence, but take several organizations to complete. WAI-ARIA 1.0, for example. It was almost at a recommendation level when I started five years ago, and it still hasn’t reached the 1.0 stage yet. Things are dragging and dragging, and it sometimes feels like this thing will never see the 1.0 release. I’m convinced that it will, eventually, but this is probably the longest release cycle I’ve been involved more or less heavily ever!

In the last five years, i also ventured out into different other areas. In 2011, a dedicated accessibility team was formed at Mozilla, which now consists of six members in total. I moved from the QA team to this accessibility team, and while QA is still the most important part of my work, it’s not the only one any more. I am also overseeing which of our work needs backporting to the Aurora and Beta branches, and work with release management to make this as smooth as possible for everyone, communicating what is needed and why. With not everybody as fluent in accessibility as our team is, communication is key to success here.

Speaking of “accessibility literacy”: I’m happy to see that over-all awareness of accessibility requirements has spread widely throughout the Mozilla project. I’ve always been available across all teams for questions and input on accessibility matters. While in the beginning, this was mostly me being proactive in reaching out to others and plant the seeds, I’m nowadays being pinged from everywhere and anywhere within the massively grown organization on matters and projects. This is absolutely awesome!

As for the outlook on 2013, the one big exciting piece is going to be Firefox OS. This is a project that will be our companion at work for quite some time to come. And here, it’s not just going to be reactively adding accessibility to something that’s already there, but actively designing, implementing and testing new interaction models while taking the Mozilla platform to its own level of an operating system. I’m excited as hell, my brain is continually super-charged with ideas, and I can’t wait to talk about first results on this blog!

Also, Firefox OS work will involve a lot of evangelism with web app developers to make sure they have the right tools and documentation to deliver accessible Firefox OS aps and provide a seamless experience for all their potential users.

Let’s rock!

The future of mobile accessibility, a hopeful lookout

In case you haven’t read it yet: Nokia acquires Trolltech. DougT also posted a follow-up article on the future, or lack thereof, of Symbian S60/S40, which you can find here.

For accessibility, this currently provokes mixed feelings. On the one side, the S60 platform has been a very successful accessibility story, with Talks and Mobile Speak being the most prominent representatives of access to this platform. Blind and low-vision users have come to depend on accessibility to their mobile phone’s contacts, short messages, MP3 capabilities or even navigational aids. To a much lesser extent, this is also true for Windows Mobile-based smartphones, but like in the world of general customers, this has taken off much less than Symbian has.

On the other hand, this move to an open-source embedded solution for future generations of Nokia phones may become an even greater accessibility success story. With the Gnome Accessibility proceedings on a very good way to wide-spread adoption, KDE needs to follow, or they’ll fall by the wayside with government organizations sooner or later. While KDE’s accessibility efforts are, compared to Gnome, still in a rather limited state of development, QT has made some significant progress in that it has become accessible on Windows recently by using Microsoft’s Active Accessibility.

It is my hope that not only can Gnome and KDE agree on sharing a unified interface for AT vendors, as expressed in this early posting on AT-SPI, but that IAccessible2 and Mac Universal access will also join forces in an effort to provide compelling access to a wide range of technologies. With this in place, this could also be carried over to a wide range of embedded solutions, providing a solid accessibility architecture on which screen readers and other assistive technologies can be built. In addition, this would make it a lot easier for software developers to ensure the accessibility of their applications.