Twitter now has a dedicated accessibility team

Ever since I joined Twitter in March of 2008, at my first CSUN under the Mozilla banner, Twitter’s own web presence was always a bit, or even a lot, of a challenge to use for me as a screen reader user. While the initial version was still pretty straight-forward, as time went by and Twitter added more features and turned their web presence into a web app, the interaction became increasingly cumbersome. Fortunately, there are clients on various platforms that allowed me to access the service without having to rely on the web site. Even after the more strict API 1.1 roll-out a year ago, this situation hasn’t really changed for me.

A few months ago, I learned that Todd Kloots had joined Twitter. I knew Todd from when he was still at Yahoo! doing awesome things for web accessibility there. As time went on, members of the accessibility team at Mozilla, the NVDA developers, and Todd discussed various aspects of web accessibility, making it apparent that something good was happening at Twitter!

A few weeks ago, after a couple of tweets by Todd and others, I tried out the Twitter web app for the first time after a long while. And as was hinted in the tweets, the J and K keys suddenly started working much more nicely with the various browser/screen reader combinations I tried.

Yesterday, now, a post was published on the Twitter blog detailing some of the recent changes in accessibility of twitter.com, and an official accessibility team Twitter account was also announced. You can find the team at @a11yteam, and they welcome suggestions for further improvements.

If you are blind and want to try things out, you can do so right away by logging onto Twitter and reading your timeline. J and K will move you up and down through the timeline. Further keystrokes are available if you press the ? (question mark) key. Just remember, if you’re on Windows, you’ll have to turn off virtual cursor mode to be able to properly use them, as they will most likely be captured by the quick navigation key system of your screen reader otherwise. If you’re on the Mac, you do not need to do anything special.

I hope that Twitter will also pay equal attention to detail in their mobile web app, so the app you can get from the Mozilla Marketplace for both Firefox for Android and Firefox OS will be equally accessible. First signs of improvement are there, with tabs and buttons properly labeled nowadays. In addition, starting in Firefox 25, we have improved the way we execute touch events from within TalkBack and Firefox OS, so interaction should be just smooth!

This is exciting news, and I wish the Twitter accessibility team all the best in their future work on the web and native applications! As far as the web and mobile web presences are concerned, we at the Mozilla accessibility team will be here, ready to help wherever needed!

Advancements in the accessibility of Facebook

In December 2011, I wrote this overview of the accessibility of social network sites and apps, and I had to paint a rather sad picture about most of the accessibility experiences. As time went by, some things improved here and there, others stalled.

One social network that caused some excitement in the community when they announced a dedicated accessibility team, however, was Facebook. And since then, the team has made some great leaps forward in over-all accessibility, and also listening to feedback from users on both their official Facebook accessibility page and Twitter.

I left Facebook in June 2012, but recently returned for various reasons, and now think it’s time to review a few things that now work much better, especially for screen reader users. I’ll be taking a look at both desktop and mobile sites as well as the iOS and Android native clients.

Disclaimer: I’m neither employed nor paid by Facebook for this review. This is purely my personal opinion and an attempt to highlight what good can be done if any company put a dedicated accessibility team in place.

Desktop site

What most people will probably be using first is the standard desktop site of Facebook. I used both NVDA and Firefox on Windows, and VoiceOver and Safari on OS X, to do my testing.

The sign-up process still requires a CAPTCHA to be solved. Since the audio CAPTCHAs have become unintelligible over-all, trying to solve the visual CAPTCHA in Firefox with the WebVisum extension, or getting sighted help, are the only viable options to get signed up.

Once the sign-up process has been completed, filling out one’s profile information works much better over-all than it used to. Auto-complete suggestions, keyboard focus handling and the over-all consistency when showing or hiding sections of the profile editing process provide a smooth experience. There are some quirks when filling out employment life stations, because Facebook has the tendency to fill in employers from friends one might have added already. While this might be a good idea in general, pre-filling the text field once it gains focus without waiting for the user to type, is not the best usability idea, IMO. But this happens to people without assistive technologies, too, so this is not an accessibility-specific issue per se, but it causes a bit of confusion.

In many areas, Facebook’s keyboard navigation and focus handling have improved. When posting a status update, sharing a link, adding a friend and adjusting the friend settings, in chat, dealing with notifications, all have improved significantly. Dialogs now behave modally, and the tab key is trapped so one cannot navigate outside of the dialog’s controls.

The search at the top of the page is a delight to use, the auto-completion and navigation by arrow keys work very well with both screen reader/browser combinations. What I found was that VoiceOver and Safari don’t read the checked/unchecked state of some menu items, like when adjusting if a friend is an acquaintance or a close friend. However, since NVDA and Firefox read these states just fine, it is a bug on the VO+Safari side, which I also notified Apple about through official channels.

There are some rare cases where dialogs don’t work as consistently as others, or get confused by unexpected keystrokes. However, as the monthly updates from the accessibility team indicate, this is an area that is constantly being improved, so these quirks should become less and less of a problem.

In summary, it can be said that the difference to when before the team started, is a difference between night and day! The experience has become much more user-friendly, and therefore more efficient. Low-vision users will also be delighted to hear that the FB Access team is constantly improving the high contrast experience as well.

Mobile site

A probably even bigger difference is what happened to the mobile version of the Facebook site over the last year. I used both Firefox for Android on a Nexus 4 running Jelly Bean 4.2.2, and VoiceOver and Mobile Safari on an iPhone 4S and an iPod Touch 5th generation running the latest iOS 6.1.3.

To recap, the last mobile experience I checked was a set of static pages that were loaded and unloaded constantly. It was very stripped down and hardly contained any semantic information other than links and inputs. No headings and other really useful stuff.

Well, that has changed drastically. The mobile sites look very much like the native app counterparts, and they also now use a lot of good semantics, both HTML and WAI-ARIA, to communicate. As on the desktop, the notifications for friend requests, messages and other notifications are present and can have pop-overs displayed or hidden when tapped. On the iPhone, these were announced quite nicely, and for Firefox for Android, a bug was just fixed for the Firefox 24 Nightly builds that now also causes TalkBack to speak the fact that these buttons have pop-overs.

When displaying the main menu on the left side of the mobile screen, information is nicely accessible. Status updates have headings, so it is easy with quick navigation gestures to jump through them to get an overview. The status update widget is also accessible, including the buttons above and below the actual text entry, and the rest of the page is nicely hidden from view so it doesn’t clutter up the screen reader view. Note that for Firefox for Android, you need a June 1 or later nightly build or the 24 release to take full advantage of this widget. Part of my using Facebook regularly was finding those bugs in our implementation and helping fix them.

I found that with Firefox for Android, I can navigate the mobile news feed just as efficiently as the native Android app.

There still seems to be a bit of a problem on the Messages page. At least in Firefox for Android, i am unable to re-open the main menu. On the iPhone, it works, so it’s probably a glitch in our accessibility support which needs investigating.

Other than that, one can reach most common things. I can use the friend suggestions, events, notes, and other stuff just fine in both browsers.

A note about tablets: On both my iPad Mini and a Nexus 7, I got the desktop version of Facebook, maybe with some tweaks, but in general, it looked a lot like in Safari on OS X, or Firefox on the desktop. Again, techniques used work just fine, and most, if not all, stuff is spoken by VoiceOver and TalkBack. So on a tablet where there is more screen estate available, the experience is nicely scaled up to give the user the advantage of the bigger screen.

The native clients

Both iOS and Android offer native Facebook apps. Both are largely accessible nowadays. There are some problems with the iOS app where if you double tap an entry that has a photo or link attached, that photo or link are opened straight away instead of the actual Facebook entry. So commenting on these is difficult, in case of a link even impossible. The Android version does not suffer from this limitation, because all tapable items in the main timeline can be explored or swiped to. This means a little more swipes per entry, but the extra granularity also has its advantages. The Facebook app for iOS should definitely be changed to open the actual entry and allow the user to view the link or photo from that detailed entry view. The UIAccessibility protocol makes this possible.

I found some unlabeled buttons in both the iOS and Android apps, but as the May accessibility team update states, they’re constantly looking for these and fix them.

On iOS, there is also the separately available Facebook Messenger app, an app that only contains the Messages part of Facebook. Its accessibility has become quite good over the last year. I’ve set it up so it can push me new messages, whereas I did not allow the main Facebook app to do that. This way, the dedicated messenger app works just like an SMS alternative like WhatsApp.

Facebook Messenger for Firefox

End of last year, Mozilla introduced what we call the Social API, allowing social networks to offer parts of their services as always-present side bars in the browser, without the need to always keep a tab open with the whole site working in the background. First ones to take advantage were Facebook with the Messenger for Firefox add-on. Unlike other add-ons, you just activate it from this page. If you’re logged into Facebook already, everything is being taken care for you. A new side bar, which you can switch to via the F6 key, presents you with very recent updates, your list of online contacts, and some settings. If you navigate to one of those contacts and press Enter, you’ll be taken to an ordinary text area where you can type your message. Enter will send it, and if you press Escape in NVDA to turn off virtual cursor, you can navigate upwards to follow along what your contact is writing, then press e again to move back to the text area, press Enter for focus mode, and type away your reply.

The HTML Facebook renders for this add-on does not yet have all the accessibility features known from the built-in Chat on the Facebook site. I’ve notified the team of that, and since this is all coming from Facebook, as soon as they improve that, you should see an improvement right away without having to update anything on your end. You can close your Facebook tabs, navigate and browse around, and the side bar will keep you online and available to others for chatting.

In Summary

Accessibility has come quite a long way over the past year on Facebook! Yes, there are always areas where it can still improve, but especially the vast improvement in mobile browsers and on the desktop site are really worth highlighting! The native apps also have improved significantly over what was there a year ago.

The one remaining really big annoyance is the CAPTCHA that bites users not only at sign-up, but can also hit if Facebook thinks the IP address one is connecting from is so unlikely that it can’t be you. Happened to me twice in my past Facebook life when I was at my employer’s place or the hotel we were staying in. Still burdening the user with these unreadable and unintelligible CAPTCHAs in 2013 when there are many better methods of user verification that run on the server side, is not a good way to treat your honest users. I sincerely hope this will soon be a thing of the past!

I’d like to give the Facebook accessibility team a shout out for the work they’re doing! Keep it up, you’re definitely on the right path!

And to all users of Facebook, no matter which assistive technology you use: If you find problems with Facebook, let them know! There is a link on the Facebook Access page linking straight to an accessible feedback form allowing you to send your problems and suggestions straight to them. It is difficult for the team to try and catch everything by themselves, especially since everybody uses Facebook in a slightly different, and sometimes unexpected, fashion. If you speak out, you can be helped and the site improved to fit your use cases!

Happy facebooking!

Are web apps accessible enough to replace desktop applications any time soon?

I know, reflections on things usually happen at years-end time, but to be honest, this blog post has been in my head for the last two-and-a-half years, and has thus “seen” a number of year-ends, so I felt that it’s now finally time to put it in writing.

I’ve been with Mozilla since December of 2007 and have seen quite a number of things happening since I started.

  • I was there when Firefox 3 came out, a huge leap forward in providing accessibility for modern, ARIA-enabled web content.
  • I saw the birth of Canvas accessibility and how it finally saw the light in Firefox 13.
  • NVDA has matured into a true free and open-source alternative that can be used in productive and home environments around the world.
  • Accessibility on mobile devices has grown from a very niche market with only a handful of devices to one that is being spread all over the world on millions and millions of devices via iOS and Android, and soon, Firefox OS as well if I have any say in it.

But has all this really managed to revolutionize the way we use the web if we require accessibility to do so? Has the web really grown to become a full desktop application replacement?

It saddens me to say this, but no, it hasn’t, at least for me.

A few examples

And why is that? Because of the efficiency I can get work done in desktop and even mobile applications over that of their browser-centric counterparts. Let me give you a couple of examples:

E-Mail

Despite my bang-up review of the Yahoo! Mail upgrade and its truly desktop-like touch and feel, I haven’t switched to it, primarily because I use so many e-mail accounts from other providers with folders/labels and what not, that I didn’t want to switch it all to pop-mail and thus lose the easy access to them from all my devices. Aside from Yahoo! mail, there is no compelling web mailer that I could conceivably imagine using. GMail is by far not ready for productive use for a person using a screen reader and keyboard only, except maybe if you want to tie yourself to Chrome and ChromeVox and deal with the hassle of switching back and forth between that and your screen reader which you need to turn off for this to work seamlessly. The web mailer of my self-hosted domains is not even close to being called a web app, with everything loading as a separate document and such. And don’t even get me started on the web mailer that’s driving my Mozilla.com e-mail address! That thing was coded in the early 2000s, when there was no ARIA around, and hasn’t been upgraded ever since. And every web developer knows: Crafting accessibility onto something in the aftermath is always a lot harder and more costly than implementing it right from the start. So should there ever be a re-write of the Zimbra webmail interface, I sincerely hope it’ll be done with accessibility in mind from the start!

For E-Mail, which is still the primary source of business communication, for me there simply is no alternative to a native desktop or mobile client. Everything else simply takes too long to get to and to use in a productive manner.

Side note: Even Apple still thinks this way. Why else would they have included a new feature in OS X Lion that, once you sign into certain web sites using Safari, offers you to set up e-mail, calendar, instant messaging, and contact accounts for this particular log in automatically?

Twitter

If you follow my Twitter account, and you watch the applications I tweet from, you’ll hardly ever see “Web” in the applications. Instead, you’ll see Mac and iOS clients, and sometimes the EasyChirp web client, which is a fully accessible web interface for Twitter. And why do I use these native desktop and mobile apps so much more than EasyChirp or even the Twitter web interface? Again because of efficiency. In Yorufukurou, which is the only current accessible Mac client, it takes me exactly one keystroke from the list of tweets to either reply to a tweet or start a new one, and a press of Enter to send off that tweet to the world. In the first case it’s Enter, in the second it’s Tab. Reading a tweet is simply one key press away in the up or down direction. On iOS, my primary mobile OS, it’s a swipe left or right for the previos/next tweet, a double-tap and hold, plus the chosing of an action to start a reply, and the simple tap and double-tap of a button in the upper right-hand corner of my tweets window to start a new tweet.

In Firefox using EasyChirp, the sequence is as follows. This is assuming I have EasyChirp in a pinned (or app) tab which means it automatically loads when I start Firefox:

  1. I have to sign in first. EasyChirp does not sign me on, and it doesn’t keep a Twitter-provided authorization for more than half an hour. Signing in goes as follows:
    1. Either find the “Skip to sign in” link, press enter, then DownArrow, then Enter again to activate the Sign In link. Or: Use NVDA+F7 to open the list of elements, find the sign in link by typing s and i, and pressing Enter to close the dialog and activate the link. Or: Press NVDA+F to open find, type sign in, and press Enter, hoping to land on the actual sign in link, not the skip to sign in one. Press Enter again to activate once you found the right one.
    2. Page loads.
    3. Either sign into Twitter, which involves finding the edit box for the user name, typing it in, tabbing, typing in password, pressing Enter to sign in. Or, continue with next step.
    4. If auto-signed in or just signed in, press B, which is a quick navigation key to find the next button, which takes me to the “Authorize app” button, and press Enter or Space to activate.
    5. Another page load.
  2. Now we’ve arrived in the timeline. Posting a tweet involves these steps:
    1. Press E to go to the next (first) edit box on the page, which happens to be the “What’s happening?” field.
    2. Press Enter to enter focus mode, in other screen readers also called “forms mode”. This is a technical necessity and annoyance having to do with the way browsers have to interact with screen readers on Windows in the most efficient manner possible.
    3. Type my stuff
    4. Because this is a textarea, I have to Tab to the “Post” button and then press Enter or Space.
  3. If I want to read the timeline, it’s a combination of using the H and Q quick navigation keys. Every new tweet area starts with a heading that contains the user name, but the actual tweet text is then contained within a blockquote element, so I go H to find out who wrote it, and then skip over the user avatar graphic by pressing the BlockQuote key to hear what they were tweeting.

Anyone kept count? 🙂 And this is with an accessible web application! And it doesn’t even take into account that it doesn’t really keep your reading position. In other words, If I come back three hours later and have to re-sign in and the timeline comes up, there’s no way to get back to the point where I left off reading the newest tweet to read back in chronological order. My desktop app can simply sit there, collect the new tweets while I do something else, and when I come back, I can simply arrow around to read the tweets in a chronological order. My mobile client uses the TweetMarker service to remember where I left off and can start from there upon next launch.

News feeds

I very recently became a big fan of FlipBoard for reading my daily news items on the iPhone or iPad. There is, I believe, no web app that can even come close to providing me with that level of comfort. I’ve tried various feed reader extensions for Firefox, I even tried coping with Google Reader, but this, again, only works well if you’re willing to use Chrome and ChromeVox, other browser/screen reader combinations are limited by the techniques they’re using which appear to be specifically tailored towards Google’s own offerings. BTW: There’s not even an app on Mac or Windows that gives me such a reading and usability comfort as FlipBoard does.

Web forums

I am currently switching a community from a privately run mailing list to a web forum. I want to get rid of the ugliness that is the Mailman archive for that mailing list, to a properly threaded and manageable way of organizing that community. But to allow easier access from iOS and Android phones, my forum supports the apps Forum Runner and TapaTalk. Why? Because reading a web forum in a mobile browser is usually not much fun. With all the browser UI in the way, and all the baggage forums keep around, it’s hard to focus on the important. Those apps give a much cleaner, less fragmented and thus more efficient user experience to the forum than any current web offering could provide the user base, myself included.

What would need to change to make this experience better on the web?

There are a lot of things that are in the way of a good user experience especially for keyboard and also for screen reader users. Let me highlight a couple of them:

The web is a very mouse-driven place

All the above examples showed one thing clearly: The web is a mostly mouse-driven place. You can get very far with little effort if you only consider mouse users in your design approaches. As soon as you take keyboard users into account, things become much more complicated. For one, you need to think about a sensible tab order. Second, you need to make sure keyboard focus is always visible so users know where they are. And with the keyboard, it’s less easy to ignore the surrounding browser UI, because keyboard focus may sometimes be there, not in the web content for one reason or another.

Implementing proper accessibility for screen readers is not trivial in many cases

Yes, that’s right! While there are quite a number of things to easily get right, like making sure your images have alternative text, or providing proper labels for inputs by correctly associating labels with the inputs via the for/id combo, there are other things that can go wrong very easily. This ranges from properly hiding content from the view port that you want the screen reader to read anyway, to very complex tasks like making rich widgets accessible via HTML, JS, ARIA and CSS.

And here’s one of the big problems: The matter is so complex that not even those who create the standards get the specs done easily. ARIA 1.0 has been in last-call review state three times I think, and it is still not at final 1.0 state. HTML5 accessibility is going through morphs, removed and added-back elements, heated arguments and what not, and is a very hard matter to get one’s head around, especially if you want to get involved. There are historic design choices that stick with us like a basic MS_DOS kernel sticks with current versions of Windows, which make web developers’ lives unnecessarily complicated. Recently, I was asked why, for example, the primary source for an image has to be the alternative text (alt-attribute), if using the title-attribute would have the benefit of providing sighted people with a visual queue to what a particular item means as well. Guess what: I had no good answer for him.

Providing accessibility for native iOS and Android apps is much easier

That’s right! Providing accessibility for those mobile operating systems is, in many cases, a piece of cake. Apple, and lately Google, too, have crafted their native widgets with so many features that it makes it very easy to provide a visually compelling, yet fully accessible user experience. Take the above mentioned FlipBoard as an example. If you watched the iOS Accessibility track at WWDC 2012, you will have seen that the presenter made a game fully accessible that requires one to drag “weapons” to moving targets on a playing field, with little more than twenty(!) lines of code. TWENTY lines!

Side note: Mac accessibility, if done with COCOA widgets and custom views derived from them, is not much harder to make accessible.

On the other hand, like with many other pieces of the puzzle, web developers have to deal with different implementations of accessibility features across browsers and even some assistive technologies on all platforms. The web is, despite all efforts, a very incoherent place, not only, but also, in accessibility matters. And this, I believe, is one of the primary reasons that the WebAIM screen reader survey #4 still shows no significant increase in people’s perception that the web has become a more accessible place over the past three to four years. There are just so many stepping stones and loopholes that often leave web developers frustrated. Others, although this number is shrinking, aren’t even aware of the different web accessibility efforts and need to be taught from the ground up.

Technical limitations between screen readers and browsers

This primarily applies to Windows, where the accessibility API architecture requires two modes: One for browsing, one for direct interactions with web content. Users have to remember to switch between these modes in many cases, and the browsing mode usually nukes out all custom keyboard shortcuts that the web site may define for other keyboard users.

There is a role for such web content called “application”, but this is better used cautiously, as this blog post and the comments below it show.

So….Any good news?

Yes! Despite all this demise, there have been improvements. jQueryUI is continually adding accessibility to their widgets. Yahoo’!’sYUI has had improvements added for years, too. Dojo Toolkit was the prototyping project for many ARIA-enabled widgets. CKEditor is a fully ARIA-enabled WYSIWYG editor. All these have emerged or vastly improved since I started working at Mozilla in December of 2007.

One of my projects over the next couple of months is to make sure that the Firefox OS UI and the building blocks for app developers for Firefox OS are accessible, so whatever apps that are built from standard UI components, will have accessibility built-in.

I will continue to provide advice, articles and views on the topic of web accessibility and the way it may, or may not, evolve to become a true desktop replacement platform for all users. As I recently said to David Bolter, I love my job. I could see all the above as demotivating factors and think all web accessibility efforts are in vain. But I’m not that kind of person! I, instead, take this as motivation to help drive efforts forward, home in on issues and fix them, and make the web a better place for everyone if I can. And that’s a promise!