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 was later turned into the final website titled Fejjan För Alla.
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. A new solution was needed.
My former employer HiQ got to help PTS with this. The team I was apart of also had a project lead and two full stack developers.
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.
We constructed our design process like this.
For reaching as many users as possible, the decision was made to develop a responsive website instead of native apps for iOS and Android. With the project budget in mind, this was the only realistic option as well.
The website would use Facebook’s APIs to replicate the Facebook features and experience outside of Facebook. Since HTML works well with assistive technologies such as screen readers, we felt confident in providing great accessibility with this choice of technology.
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. We needed to adress this issue right away.
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. These meetings were educational and inspirational.
Developing an HTML prototype
For usability testing with people using assistive technologies and tools like screen readers and Braille keyboards, you must use an HTML prototype since these technologies and tools 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 and event invitations
- Message threads with rich history
- Private events
Writing this content took more time than expected and was straining, but proved to be necessary for the usability testing sessions.
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. We learnt the hard way that we needed to be thorough with these details for not wasting valuable time during usability testing sessions.
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.
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 with the users.
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 even 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. It was a sad day.
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 affecting design can be and how much I’ve taken for granted. How being able send someone a message over social media can enrich one’s 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 this topic.
This was the most humbling project I’ve ever been apart of.