To content

Alexander Skogberg

UX Designer in Stockholm

Hi, I’m a UX Designer based in Stockholm. I dig design systems, accessibility, and loud rock music.

Close up of two hands on a Braille keyboard

Facebook for people with deaf-blindness

September 2013 to February 2014


In 2013, the Swedish Post and Telecom Authority (PTS) hired my former employer to develop a website through which people with visual impairment and deaf-blindness could use Facebook. I worked as a UX designer on this website titled Fejjan För Alla (Facebook For Everyone).

Quick Summary

The team and I shipped the website Fejjan För Alla in February 2014. Upon its release, it got national news coverage and great feedback from its users. People with deaf-blindness and visual impairment told us it was the easiest way to use Facebook by far! A lot of them could now do things they never could do before.

I was a member of a small team consisting of a project lead and to full stack developers. I designed and developed a HTML prototype of the website, which I also usability tested with people with deaf-blindness and visual impairment. It was incredibly humbling and educational.

Unfortunately, Fejjan För Alla was taken offline later in December 2015 due to upcoming API restrictions by Facebook. Too many must-have features would no longer work and couldn’t be implemented in any other way.


Background

After extensive user research with the accessibility community in Sweden, PTS had learned that Facebook wasn’t accessible for people with different degrees of visual impairment and deaf-blindness.

At this time, neither Facebook’s website nor apps for iOS and Android worked well with screen readers, Braille keyboards, and other types of assistive technologies.


Goals

PTS decided to create a way for people with these types of disabilities to use of Facebook. Their core belief was that poor eyesight or hearing shouldn’t stop someone from communicating with friends and family online.


Design process

I was a part of a multi-disciplinary team at HiQ that consisted of a project lead and two full stack developers. Here’s how we put together the design process.

Choosing technology

For reaching as many users as possible, we decided to develop a responsive website instead of native apps for iOS and Android. Since the project had a very tight budget, this was the only realistic option.

The website would use the Facebook API to replicate essential Facebook features. Since HTML works well with assistive technologies such as screen readers and Braille keyboards, we felt confident in providing an accessible solution this way.

Meeting users with deaf-blindness

Apart from an introductory course in website accessibility that I had taken, the rest of the team had no extensive experience of accessibility. We knew we needed to learn much more.

With help from organization Förbundet Sveriges Dövblinda (FSDB), we set up meetings with a user with deaf-blindness. The goal was to learn and understand the challenges of using Facebook and other websites using assistive technologies.

The meetings were both educational and inspirational, especially for the developers in the team.

Designing an HTML prototype

For usability testing with people using assistive technologies, we needed to develop a prototype using HTML. Technologies like screen readers read HTML well, but can’t interpret prototypes done in apps like Figma and Sketch.

I developed the prototype using HTML, Sass for CSS, and jQuery for basic interactivity (like posting comments and replies).

Apart from following best practices for website accessibility like WCAG 2.0, I also wrote detailed content including:

  • List iof friends including their profile pages
  • Friend requests and event invitations
  • Profile osts with comments
  • Different kinds of groups
  • Message threads
  • Private events

Writing realistic and detailed content took more time than I had thought, but proved to be necessary for the usability testing sessions. We wanted to create the illusion that the participants were actually using Facebook but through someone else’s account.

Usability testing the HTML prototype

The entire team and I then usability tested the HTML prototype. Our project lead was in charge of the time-consuming task of planning the sessions. I was in charge of the actual sessions and putting together all tasks the participants were going to perform. Our developers helped by taking notes during the session and assisting the participants when needed.

A room packed with people sitting around a long table.
Users with their assistants and colleagues at HiQ during one of our long and intense usability testing sessions.

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

  • Writing posts
  • RSVPing to events
  • Commenting on posts
  • Sendings friends messages
  • Searching and joining groups
  • Accepting and rejecting friend requests

We used feedback from each session for improving the prototype for the next session, to which we invited the same participants back.

The participants gave fantastic feedback! They were respectful but didn’t hold back at all. If we had screwed up, we got to hear it loud and clear!

It was humbling to learn how even the slightest adjustments to the HTML markup and copywriting could improve or break the usability and accessibility of the prototype. We learned the hard way that we had to be thorough with this for not wasting valuable time in the sessions.

In this project I learned that great accessibility takes a lot of time to get right and almost no time at all to screw up.

In total, we held four group sessions. However, I also made two home visits to one participant for additional testing. Two other participants also did more testing at home and answered detailed questions over email. They were keen on helping us, which was lovely.

A user browsing Fejjan För Alla on a laptop 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, we reused much of its code for the final website. With actual Facebook content in place, we performed one more usability testing session with the same participants before launching the website. It went very well.

Struggles working with the Facebook API
The Facebook API wasn't meant to create Facebook outside of Facebook. As expected, this became a huge struggle for the developers. For some features that we were obligated to implement we had to be clever. For example, The API did allow us to retrieve unread messages, but not mark them as read. Hence, we simply listed the latest active message threads in descending order. It wasn't perfect, but it was good enough and tested well.


Result and impact

Fejjan För Alla was released in February 2014 and got great feedback. Using Facebook had just become much easier for the 2,500 deafblind and 100,000 visually impaired potential users in Sweden.

Users told us Fejjan För Alla was the easiest way to use Facebook by far! A lot of them could now do things they never could do before

Unfortunately, Fejjan För Alla had to be taken offline later in December 2015 due to upcoming API restrictions from Facebook. Too many must-have features would no longer work and couldn’t be implemented in any other way.

Article on svt.se about the website
Fejjan För Alla made national news in Sweden when released. Article in Swedish on svt.se.

How it made me feel

While I had taken accessibility seriously before, working closely with people with visual and hearing impairments had a profound effect on me. I realized what a huge effect good and bad design can have on someone’s everyday life. I stopped taking a lot of things for granted.

Fejjan För Alla was the most humbling project I’ve ever been a part of. It also felt great doing pure public service.

After this project, great accessibility is always a top priority for me in new projects. It also made me start giving talks on this topic. It’s my favorite thing to talk about.

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