To content

Alexander Skogberg

UX / UI Designer

UX / UI Designer based in Stockholm. I dig design systems, accessibility, and loud rock music.

Close up of two hands on a Braille keyboard

Making Facebook accessible for people with deaf-blindness and visual impairment

Timeline: September 2013 – February 2014
Allocation: Full-Time
Role: UX Designer


From 2013 to 2014 I helped the Swedish Post and Telecom Authority develop a website that significantly improved the accessibility of Facebook for people with deaf-blindness and visual impairment.

Quick summary

“Fejjan För Alla” was a website that made using Facebook accessible for people with deaf-blindness and varying degrees of visual impairment. It was a project by the Swedish Post and Telecom Authority and was released in February 2014. It immediately got national news coverage and praise from its users.

Users told us this website was the easiest way to use Facebook by far! A lot of them could now do things online they never could do before.

As the only designer in a small team at HiQ, I met with users with different degrees of visual impairment, hearing loss, and deaf-blindness. With their help I designed, developed, and usability tested an HTML prototype of this website. A lot of code I wrote was later reused for the final website.

Note: “Fejjan För Alla” was taken offline later in December 2015 due to upcoming Facebook API restrictions. Too many essential features weren’t possible to maintain.


How it came about

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.


Goal set by PTS

PTS decided to provide an accessible way to use Facebook for people with these types of disabilities. Their core belief was that visual impairment or deaf-blindness shouldn’t stop anyone from communicating with family, friends, and loved ones online.


Website instead of mobile apps

Before the team and I could learn more about the users and their types of disabilities, we had to make a big choice regarding technology.

For reaching as many users as possible, we decided to develop a website instead of native mobile apps for iOS and Android. Since the project had a very tight budget, this was the only feasible 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 our choice.


Meeting users with deaf-blindness

Two years earlier I had taken a course in website accessibility, but apart from that no one in our team had any experience in accessibility. We knew we had much to learn.

With help from the organization Förbundet Sveriges Dövblinda, we set up meetings with a user with deaf-blindness. The goal was to learn about the challenges of using Facebook and other websites using assistive technologies. These meetings were both educational and inspirational.


Making a prototype using HTML, CSS, and Javascript

To be able to perform usability testing with people using assistive technologies, I designed and developed a prototype using HTML, CSS, and Javascript. Screen readers like Voiceover and JAWS can read HTML well, but they can’t interpret prototypes done in apps like inVision or Axure RP.

I made sure to follow the Web Content Accessibility Guidelines. I also wrote realistic content like:

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

Writing this content took more time than I had expected, but proved to be essential for the usability testing sessions. We wanted it to feel like the users were using Facebook, but through another account.

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.

Usability testing and improving the prototype

The entire team and I worked together when usability testing the web prototype.

Our project lead handled the time-consuming task of planning the sessions, while I put together the tasks for the users and ran the sessions. Our developers took notes during the sessions and assisted the users when they needed help.

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

We invited four to five people with varying degrees of visual impairment and deaf-blindness to each session. During these sessions they performed typical Facebook activities like:

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

We used the feedback from each session to improve the web prototype for the next session, to which the users were invited back.

The users gave great constructive feedback! They were respectful, but didn’t hold back either. If we had made a mistake, we got to hear it loud and clear.

It was humbling to learn how the slightest adjustments to HTML markup and UX Copy could solve or break the accessibility of a certain piece of the design. We had to be thorough and avoid basic mistakes to not waste session time.

I learned that great accessibility takes a lot of time to get right and almost no time to screw up

In total, we held four group testing sessions. I also made two home visits to one participant for additional testing. Two other participants also did more testing on their own and answered detailed questions over email.


More testing, but with real content

Once the team and I were satisfied with the prototype, we reused much of its code for the final website.

With real Facebook content in place, we set up one more usability testing session with the same participants before releasing “Fejjan För Alla”. It went very well!

Struggling with the Facebook API
The Facebook API wasn't meant for building Facebook outside of Facebook. As expected, this became a huge struggle. For some must-have features we had to get creative. For example, the API allowed us to retrieve unread messages, but not mark them as read. Hence, we just listed the latest active message threads in descending order. It wasn't perfect, but it tested well.


Result and impact

We released the website “Fejjan För Alla” in February 2014. Based on the immediate feedback, Facebook could now have gotten easier to use for several hundred thousand people in Sweden living with some type of visual impairment.

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

Article on svt.se about the website
“Fejjan För Alla” got national news coverage when released. Here at SVT.

Note: “Fejjan För Alla” was taken offline later in December 2015 due to upcoming Facebook API restrictions. Too many essential features were no longer possible to maintain.


How it made me feel

Even though I was familiar with website accessibility, working with people with different degrees of visual impairment and hearing loss had a profound effect on me. I realized what a huge effect good and bad digital design can have on someone’s everyday life.

“Fejjan För Alla” was the most humbling project I’ve ever been a part of. Since then, great accessibility is always a top priority for me when taking on new design work. It also made me start giving talks on this topic.

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