Looking at the accessibility of the IRCCloud service

In recent months, I’ve started using the IRCCloud service for all my communication via Internet Relay Chat (IRC). We use IRC at Mozilla, and many other open source projects as well as the W3C use IRC for their instant communication needs.

Previously, I had been using typical IRC clients such as Adium for OS X or ChatZilla as an add-on to Firefox. But that caused a lot of problems when working from multiple machines, like not being able to easily switch fron one to the other without losing and having to rebuild context, or logging in with two separate nicknames etc.

A while ago, IRCCloud started appearing at the peripherals of my filter bubble. It is a cloud-based IRC client with a few extras. And in the spring, I decided to finally check it out myself. We’re running an instance of the Enterprise Edition at Mozilla. So I got an account, and off I went.

What is it?

Here is what the team says about the service. IRCCloud is offered as both a web application and native apps for iOS and Android. The native apps offer push notifications for nickname mentions as well as keyword highlights, meaning one can react to things even on the go without sitting in front of the computer. IRCCloud comes in two flavors: One instance that is hosted at irccloud.com, which allows individuals and teams to connect to IRC via IRCCloud’s hosted service, and the Enterprise Edition, which is usually self-hosted by the organization purchasing the annual subscription. The latter is what Mozilla is using, but I have been looking at both instances by now, since they differ slightly. The instance at IRCCloud itself is usually newer, has the latest and greatest features, while the Enterprise editions can lag a bit behind.

IRCCloud works like this: You log onto the service, and from there, manage your different IRC server connections with nicknames, registered nick passwords etc. The paid accounts offer you an unlimited number of connections. The free edition allows for two except the one to irc.irccloud.com. The Pricing page has more information and details.

Once connected, the connections are permanent. IRCCloud keeps you logged into all your IRC servers and collects incoming chats even when you are currently not logged into the IRCCloud service. But when you come back, either through the web site or mobile app, you can review everything that has happened in your absence. This includes private messages that wait for you just like on any other instant messaging service.

The accessibility

When I first started using our Enterprise instance, I found the web application to be very accessible. All the options were easily reachable with the NVDA virtual cursor in Firefox, or also Safari or Chrome + VoiceOver on OS X. IRCCloud supports the standard IRC commands that start with a slash / character. The entry happens in a standard multiline text area, the output in a part of the web page right above that text area. Adding servers, channels and starting private conversations were all manageable through controls present on the web page. Also the nice additions like paste bins for multi-line text, uploading of images, embedding of tweets etc. all worked nicely.

However, with a redesign in September of 2015, the web app hosted on irccloud.com lost some of this accessibility due to things now being hidden behind mouse hovers, or elements turning from semantic links to non-semantic text clickables. At first, I didn’t make the connection, but at some point it dawned on me that, if Mozilla pulled in these changes at some point, I and other current and future visually impaired or blind Mozilla employees would lose that functionality as well. So I decided to contact the IRCCloud team.

Over the past week or so, I worked with James, one of the founders of IRCCloud, who works on the front-end portion, to resolve the (for me) most urgent issues in the IRCCloud instance. This is already live, and anyone can try it out. The things we covered were:

  • Clickable text that should be buttons were made buttons via WAI-ARIA.
  • Those items that expand to a multitude of options such as the account e-mail address or the Options buttons, indicate their states via aria-expanded. Those that open to a non-modal pop-over such as every nick name anywhere in chats and private messages, will have a sub menu indicator. Those sub menus aren’t really sub menus, but rather pop-overs with a multitude of options such as being able to directly send a private message, finding out who that person is etc.
  • The channels and servers as well as each private message nickname are now announced as tabs. This seemed to us the most appropriate mapping, since only one channel, server output or private message is usually visible at a time, but radio buttons didn’t seem really appropriate to use. James kept the heading structure in place, so that every server instance starts with a new heading.
  • Things that were previously hidden behind mouse hovers such as the Options button for an individual IRC server entry are now shown when the server name is focused via the virtual cursor or other browsing mechanism. With NVDA, this will cause the virtual cursor to land on the Options button once the button becomes visible, with the server name moving down one line in the virtual buffer.
  • Options in the individual server settings, accessible from the above mentioned Options button, are now toggle buttons if they are toggleable. Other buttons remain normal buttons as appropriate. But now, the state is clearly communicated whether an option such as embedding social links etc. are on or off.
  • In channel views,  if there is a series of status messages that are collapsed, the button to expand these into individual entries is now accessible, and it indicates whether the status messages are currently expanded or collapsed.

This is by far not meant as a full audit, nor was it meant to be a full consulting service. I pointed out to James the most low-hanging fruits that made working with IRCCloud difficult for me after the redesign. James was super responsive in adding the appropriate attributes and also adding his own ideas and asking good questions about details here and there. What we did not at all tackle, were issues for keyboard-only, non-screen reader users or low-vision users. I do not, for example, know if contrast is good in all places. But what we did can certainly be viewed as a starting point for dealing with other issues that might cause headaches for some users. Interest and willingness to fix these issues is definitely there, so don’t be shy if you want to use IRCCloud and run into problems!

The iOS app

Even before working with James on the web app, I contacted the team with some problems I had found in the pre 2.0 version of the iOS app. The iOS app had, for example, a problem with not updating VoiceOver content with the new loaded content after switching channels. However, since buttons were labeled and other attention to detail had been given, I was sure this was only an oversight. Sam, the IRCCloud team member responsible for the mobile apps, came back with a very fast response, and we worked together throwing back and forth observations and new beta builds, and within a day, in time for the recent 2.0 release of the iOS app, the problems were solved and some more improvements were made. Now, the iOS client which runs on both iPhone and iPad is very accessible. In fact I am not aware of any area of the app right now that I cannot use.

Wait, what about the Android app?

Sorry, I didn’t look at that one. I currently use Android only for testing Firefox, not as aproductive device of any kind, so looking at that had no priority for me among all the other things I have to take care of in my day to day job at Mozilla.

What about Slack or Gitter?

Gitter is a chat service built around the Github eco system and is very developer-centric. Its accessibility on the web is limited, and I know nothing about the iOS or Android apps. It offers an IRC bridge, so one can interact with one’s rooms on Gitter via IRC.

Slack is also an enhanced chat service that offers team collaboration and embedding of many kinds of media, file transfers etc. I tested Slack when I wanted to join the a11y Slackers, but was very unhappy with the service. The web service is all non-semantic clickables. The iOS app seemed to have a problem in that it showed me the chat history in a seemingly random order. As I only found out much later, the Slack iOS client has a twist that isn’t immediately obvious, but it is accessible. I ended up using the Gitter to IRC bridge and my Mozilla-hosted IRCCloud instance to connect to it and am now always-on there.

Both these services are centralised, proprietary messaging services unlike IRC, which is an open, distributed system of different networks that don’t depend on one another. So even when IRCCloud should suffer an outage, not the whole system becomes unavailable at once, and you can always use an alternative client as an emergency backup to connect to your favorite IRC servers. IRCCloud does offer additional features like file storage, embedding of social links, pastebins and (if you want to) videos, bringing it up to the level of other proprietary solutions. And some parts of IRCCloud are even open-source!

Disclaimer

Some might think that this post contains a lot of information that could be conceived as marketing. I am not associated with IRCCloud in any other way than that I use their service, and I do not receive any compensation for writing this post. This post purely reflects my own opinion about their service. Their responsiveness to accessibility issues and fixing them in a speedy fashion is commendable. I like this service, that’s all. 😉

And I hope this post helped you in understanding it a little better and maybe trying it out yourselves! After all, you never know what happens to some other IRC clients in the future. With some major changes coming to Firefox next year, the ChatZilla add-on may be rendered unusable for some time, for example. So it’s always helpful to know about accessible alternatives.

Have fun exploring! And happy chatting!

Updates

  • 11-01-2016: Updated my statement regarding the Slack iOS client.

Social networks and accessibility: A not so sad picture

This post originally was written in December 2011 and had a slightly different title. Fortunately, the landscape has changed dramatically since then, so it is finally time to update it with more up to date information.

Social networks are part of many people’s lives nowadays. In fact if you’re reading this, chances are pretty high that you came from Twitter, Facebook or some other social network. The majority of referrers to my blog posts come from social networks nowadays, those who read me via an RSS feed seem to be getting less and less.

So let’s look at some of the well-known social networks and see what their state of accessibility is nowadays, both when considering the web interface as well as the native apps for mobile devices most of them have.

In recent years, several popular social networks moved from a fixed relaunch schedule of their services to a more agile, incremental development cycle.. Also, most, if not all, social network providers we’ll look at below have added personell dedicated to either implementing or training other engineers in accessibility skills. Those efforts show great results. There is over-all less breakage of accessibility features, and if something breaks, the teams are usually very quick to react to reports, and the broken feature is fixed in a near future update. So let’s have a look!

Twitter

Twitter has come a long way since I wrote the initial version of this post. New Twitter was here to stay, but ever since a very skilled engineer boarded the ship, a huge improvement has taken place. One can nowadays use Twitter with keyboard shortcuts to navigate tweets, reply, favorite, retweet and do all sorts of other actions. Screen reader users might want to try turning off their virtual buffers and really use the web site like a desktop app. It works really quite well! I also recommend taking a look at the keyboard shortcut list, and memorizing them when you use Twitter more regularly. You’ll be much much more productive! I wrote something more about the Twitter accessibility team in 2013.

Clients

Fortunately, there are a lot of accessible clients out there that allow access to Twitter. The Twitter app for iOS is very accessible now for both iPhone and iPad. The Android client is very accessible, too. Yes, there is the occasional breakage of a feature, but as stated above, the team is very good at reacting to bug reports and fixing them. Twitter releases updates very frequently now, so one doesn’t have to wait long for a fix.

There’s also a web client called Easy Chirp (formerly Accessible Twitter) by Mr. Web Axe Dennis Lembree. It’s now in incarnation 2. This one is marvellous, it offers all the features one would expect from a Twitter client, in your browser, and it’s all accessible to people with varying disabilities! It uses all the good modern web standard stuff like WAI-ARIA to make sure even advanced interaction is done accessibly. I even know many non-disabled people using it for its straight forward interface and simplicity. One cool feature it has is that you can post images and provide an alternative description for visually impaired readers, without having to spoil the tweet where the picture might be the punch line. You just provide the alternative description in an extra field, and when the link to the picture is opened, the description is provided right there. How fantastic is that!

For iOS, there are two more Apps I usually recommend to people. For the iPhone, my Twitter client of choice was, for a long time, TweetList Pro, an advanced Twitter client that has full VoiceOver support, and they’re not even too shy to say it in their app description! They have such things as muting users, hash tags or clients, making it THE Twitter client of choice for many for all intents and purposes. The reason why I no longer use it as my main Twitter client is the steep decline of updates. It’s now February 2015, and as far as I know, it hasn’t even been updated to iOS 8 yet. The last update was some time in October 2013, so it lags behind terribly in recent Twitter API support changes, doesn’t support the iPhone 6 and 6 Plus screens natively, etc.

Another one, which I use on the iPhone and iPad, is Twitterrific by The Icon Factory. Their iPhone and iPad app is fully accessible, the Mac version, on the other hand, is totally inaccessible and outdated. On the Mac, I use the client Yorufukurou (night owl).

Oh yes and if you’re blind and on Windows, there are two main clients available, TheQube, and Chicken Nugget. TheQube is designed specifically for the blind with hardly any visual UI, and it requires a screen reader or at least installed speech synthesizer to talk. Chicken Nugget can be run in UI or non-UI mode, and in non-UI mode, definitely also requires a screen reader to run. Both are updated frequently, so it’s a matter of taste which one you choose.

In short, for Twitter, there is a range of clients, one of which, the EasyChirp web application, is truly cross-platform and useable anywhere, others are for specific platforms. But you have accessible means to get to Twitter services without having to use their web site.

Facebook

Facebook has come a long long way since my original post as well. When I wrote about the web site originally, it had just relaunched and completely broken accessibility. I’m happy to report that nowadays, the FB desktop and mobile sites both are largely accessible, and Facebook also has a dedicated team that responds to bug reports quickly. They also have a training program in place where they teach other Facebook engineers the skills to make new features accessible and keep existing ones that way when they get updated. I wrote more about the Facebook accessibility changes here, and things constantly got better since then.

Clients

Like the web interfaces, the iOS and Android clients for Facebook and Messenger have come a long way and frequently receive updates to fix remaining accessibility problems. Yes, here too, there’s the occasional breakage, but the team is very responsive to bug reports in this area, too, and since FB updates their apps on a two week basis, sometimes even more often if critical issues are discovered, waiting for fixes usually doesn’t take long. If you’re doing messaging on the desktop, you can also integrate FaceBook Messenger/Chat with Skype, which is very accessible on both Mac and Windows. Some features like group chats are, however, reserved for the Messenger clients and web interface.

Google Plus

Google Plus anyone? 🙂 It was THE most hyped thing of the summer of 2011, and as fast as summer went, so did people lose interest in it. Even Google seem to slowly but surely abandon it, cutting back on the requirement to have a Google+ account for certain activities bit by bit. But in terms of accessibility, it is actually quite OK nowadays. As with many of their widgets, Google+ profits from them reusing components that were found in Gmail and elsewhere, giving both keyboard accessibility and screen reader information exposure. Their Android app is also quite accessible from the last time I tried it in the summer of 2014. Their iOS app still seems to be in pretty bad shape, which is surprising considering how well Gmail, Hangouts, and even the Google Docs apps work nowadays. I don’t use it much, even though I recreated an account some time in 2013. But whenever I happen to stumble in, I’m not as dismayed as I was when I wrote the original version of this post.

Yammer

Yammer is an enterprise social network we at Mozilla and in a lot of other companies use for some internal communication. It was bought by Microsoft some time in 2012, and since then, a lot of its accessibility issues have been fixed. When you tweet them, you usually get a response pointing to a bug entry form, and issues are dealt with  satisfactorily.

iOS client

The iOS client is updated quite frequently. It has problems on and off, but the experience got more stable in recent versions, so one can actually use it.

identi.ca

identi.ca from Status.net is a microblogging service similar to Twitter. And unlike Twitter, it’s accessible out of the box! This is good since it does not have a wealth of clients supporting it like Twitter does, so with its own interface being accessible right away, this is a big help! It is, btw, the only open-source social network in these tests. Mean anything? Probably!

Conclusion

All social networks I tested either made significant improvements over the last three years, or they remained accessible (in the case of the last candidate).

In looking for reasons why this is, there are two that come to mind immediately. For one, the introduction of skilled and dedicated personell versed in accessibility matters, or willing to dive in deep and really get the hang of it. These big companies finally understood the social responsibility they have when providing a social network, and leveraged the fact that there is a wealth of information out there on accessible web design. And there’s a community that is willing to help if pinged!

Another reason is that these companies realized that putting in accessibility up-front, making inclusive design decisions, and increasing the test coverage to include accessibility right away not only reduces the cost as opposed to making it bolt-on, but also helps to make a better product for everybody.

A suggestion remains: Look at what others are doing! Learn from them! Don’t be shy to ask questions! If you look at what others! have been doing, you can draw from it! They’ll do that with stuff you put out there, too! And don’t be shy to talk about the good things you do! The Facebook accessibility team does this in monthly updates where they highlight stuff they fixed in the various product lines. I’ve seen signs of that from Twitter engineers, but not as consistent as with Facebook. Talking about the successes in accessibility also serves as an encouragement to others to put inclusive design patterns in their work flows.

Your must read post for this week

This goes out to all my readers who are web developers, or who work with web developers closely enough to hand this to them.

It’s Monday morning, and for this week, I have a must read post for you which you will now bookmark and reference and use with every single web component you build! No, this is not a suggestion, it’s an order which you will follow. Because if you don’t, you’ll miss out on a lot of fun and grattitude! I’m serious! So here goes:

Web Components punch list by Steve Faulkner of the Paciello Group

Read. Read again. Begin to understand. Read again. Understand more. Read yet another time. Get the tools referenced in the post. Check your web component(s) against this list top to bottom. If even a single point is answered “no”, fix it, or get on Twitter and ask for help in the accessibility community on how to fix it. Listen and learn. And repeat for every future web component you build!

And don’t be shy! Tell the world about that your web component is accessible from the start, usable by at least twenty percent of people more than would otherwise! I kid you not!

Happy Monday, and happy coding!