To content

Alexander Skogberg

UX, Web & Writing

Two Braille keyboards up close

Facebook for people with deaf-blindness

In 2013, the Swedish Post and Telecom Authority (PTS) set out to make an accessible version of Facebook for people with varying degrees of visual impairment and deaf-blindness. I was a member of a small team in which I designed, developed and usability tested an HTML prototype. This prototype that was later turned into the final website titled Fejjan För Alla.

Background

PTS had learnt that Facebook wasn’t accessible for people with varying degrees of visual impairment and deaf-blindness.

Neither Facebook’s websites or apps for Android and iOS worked well with screen readers, Braille keyboards and other types of assistive technologies and tools.

My former employer HiQ got to help them. The team I was apart of also had a project lead and two full stack developers.

Goals

PTS set out to create an accessible version of Facebook for people with these types of disabilities. Their core belief was that poor eyesight or hearing shouldn’t stop someone from communicating with their friends, family and loved ones online.

Design process

We constructed our design process like this.

Choosing technology

For reaching as many users as possible, the decision was made to develop a website instead of native apps for iOS and Android.

This website would use Facebook’s APIs to replicate the Facebook experience on a separate website, where PTS and HiQ could have full control over the design and codebase.

Meeting users with deaf-blindness

Apart from an introductory course in website accessibility I had taken, the rest of the team had no major experience in accessibility.

Therefore, we set up meetings with a user with deaf-blindness. The goal was to learn and understand the challenges of using Facebook and websites in general using different assistive technologies and tools.

Developing an HTML prototype

For usability testing with people using screen readers and Braille keyboard, you must use an HTML prototype since screen readers read HTML well.

Based on best practises for website accessibility, I developed an HTML prototype with made-up Facebook content such as:

  • Wall posts with comments
  • Friends with their own profile pages
  • Different kinds of groups
  • Friend requests, event invitations and message threads
  • Private events

Usability testing the HTML prototype

Together with the entire team we usability tested the HTML prototype over several sessions. Our project lead did most of the organising and planning while I put together the questions and was in charge of the testing sessions. Our developers took notes and helped the participating users when needed.

To each session we invited four to five people with varying degrees of visual impairment and deaf-blindness. They got to perform basic Facebook tasks like:

  • Writing posts
  • Commenting on posts
  • Sending a friend a message
  • Searching and joining groups
  • Accepting or rejecting friend requests
  • RSVPing to events

The feedback from each session was used to improve the prototype for the next round of usability testing, to which the same participants were invited back. The participants were fantastic in giving feedback. They were polite, but didn’t hold back at all. If we had screwed up, we got to hear it loud and clear.

It was remarkable to see how even the slightest adjustments to the HTML markup and copywriting could greatly improve (or completely break) the prototype’s usability.

Great accessibility is something that takes a lot of time to get right and almost no time at all to screw up. This is something I learned while working on this project.

In total four group sessions were held, but some testing was also done during two home visits to one participant. Two other participants did more testing at home and answered questions over email.

A user browsing Fejjan För Alla using a Braille keyboard.

A user browsing Fejjan För Alla using a Braille keyboard.

More testing before launch

Once we were satisfied with the HTML prototype, its code was reused for the final website. With actual Facebook content in place, we conducted one more usability testing session with the participants before launching the website. It went well!

Solving the challenge: Working with the Facebook API
The Facebook API wasn't made to create Facebook outside of Facebook. As expected, this became a huge struggle for the developers. For some of features we were obligatred to implement we had to get clever. For example: The API did allow us to retrieve unread messages, but not marking them as read. Hence, we simply listed the latest active message threads. It wasn't perfect, but it was good enough and it tested well.

Result

Fejjan För Alla was released in February, 2014 and was met with fantastic feedback.

Users we talked to said Fejjan För Alla was the easiest way to use Facebook, by far. Some of them could now do things they couldn’t do before.

In December, 2015 it was sadly taken offline due to new API restrictions from Facebook. The needed features would no longer work and couldn’t be done any other way.

Article on svt.se about the website

Fejjan För Alla made national news in Sweden when it was released. Photo taken from article on svt.se.

How it made me feel

I had taken accessibility seriously before, but working so closely with people with these type of visual and hearing impairments had a profound effect on me. It made me realise how important design is and how much I’ve taken for granted. How being able to do even basic things using social media can enrich one’s everyday life so much.

After this project, great accessibility is always a top priority for me in every project I’m working on. It also made me start giving talks on the topic.

This was the most humbling project I’ve ever been apart of.

Technology

I developed the prototype using HTML, Sass for writing lean and maintainable CSS and jQuery for writing basic Javascript simple interactivity like form validation. Much of the code I wrote was reused by our developers for the final website.

Much responsive Many CSS Very breakpoint So media query Such HTML Wow