The Liip.ch accessibility certification: a quick look back

Liip entered 2017 with a big success: liip.ch [1], our main website, has been certified as WCAG 2.0 AA compliant by the Access for All foundation.

Where it all began

Historically, Liip has always put great care into web content accessibility. We consider it as an important feature of any web project, for all kind of users, regardless any disability.
Of course, most of the time, customers are simply not aware of the topic at all and this is where we try to first make them know about it and then actively participate.
Depending on the sensibility of the customer, this may take long. But in the past, we have already helped a few of them to achieve the certification.

Ironically, though, our own website was not certified so we decided to start the official certification process in 2014. Without starting from scratch but using our freshly revamped website as a base.

Who did it?

Let me get this out of the way: the accessibility process is never a one-man show.
In order to achieve anything, it’s paramount to involve all the “actors” of a web project: from the end users to the editors, and, of course, the people involved in the implementation.

In fact, as an informal team, designers, UXers, marketing experts and developer, all contributed to the final implementation.
I may say that everyone both brought and took away something from working on this project.

For instance, marketing people and UXers, but also developers, were surprised to discover that the accessibility improvements that they made, in the end, benefited also them, as regular website users.
Furthermore, they’ve been forced to see things from a different point-of-view, which is always a good thing.

Challenges on the way to accessibility

So, it took us three years and, as you may have guessed, it’s not been a pleasure cruise and I am saying this for two single reasons.

Customer projects first

Customers’ work has always had the priority, as it’s normal for an – albeit mid-sized – agency since this is what makes us pay our bills.
We worked on the accessibility certification whenever we had some “spare” time to dedicate, basically between projects.

No worries, we can fix it

We had completely relaunched our website a bit more than one year before, so we could not afford to completely rebuild it from scratch.
We decided to apply the necessary changes to achieve the certification to the existing website.
Unfortunately, it wasn’t the wisest decision.

We faced quite a few issues that simply would not have been existed in a website designed and implemented with the “accessibility in mind” from the first day. One example is the colors contrast which was not enough for most parts of the website. We wouldn’t have needed to fix this if the design had addressed the issue since the beginning.

What we actually achieved

Our main goal, what pushed us to get the official certification, was (and still is) to show that we can make visually appealing websites (or web applications) accessible, removing all kind of barriers to the benefit of all users.

It was pretty obvious, in fact, that the previous design had a few “flaws” that impacted “normal” users too.
For instance, the page header elements were barely readable for non-visually impaired users too.
So we fixed that issue for everybody.

Page header before the accessibility fixes

Page header before the accessibility fixes

Page header before the accessibility fixes

Page header after the accessibility fixes

Nevertheless, also thanks to the great collaboration with the “Access for all” foundation, we managed to fix everything and achieved the AA certification in January 2017.

What’s next?

The weak point of all the certification processes is to keep up with the high standard achieved.
This means that even greater care need to be taken in keeping the website accessible both from the design and content editing point of views.

The main “weak point” is content editing. Usually, the presentation stays pretty stable during the website life cycle but content can become “dirty” and hinder the accessibility.
One of the most effective ways to prevent this is to enforce the production of accessible content through carefully thought-out UIs and editing processes. I am thinking, for instance, about requiring the editor to enter a value for the “alt” attribute for images.

Over the years, the sensibility against the content accessibility topic has grown a lot within Liip so I am pretty confident that everybody will contribute to keeping the website as accessible as possible.

[1] the accessibility certification only applies to the main liip.ch website. Related websites like socialwall.liip.ch or blog.liip.ch are not concerned.

Tags: ,

Why bother with User Testing? Part 2 : Answer 5 common objections

User Testing is essential, just like I explained it in my last blog post. But your client / boss refuses to pay for this option. No, sorry, this is not an option. At all. They will argue that there is no money , that there is no time left, that the product is super simple, they already know the users…

1. Why bother with user testing? We perform well!

Client: no need for this, our product is great, we’re not leaders for nothing.

fatboyslim_greatest_hits_cdcov

Designer: Oh really? If you never test it with users, how can you be sure that they don’t struggle regularly on your product?

Continue reading about Why bother with User Testing? Part 2 : Answer 5 common objections

Tags: , , , , , , , , ,

User Testing Part 1/2 : Why you should perform them – The risks you avoid

If the team working on a project is competent, why should it be bothered with user testing? Because user testing does not mean that anyone is not competent enough. User testing is about avoiding risks and improving a product.

Great teams sometimes deliver wrong products

Yes, why?  We perform WELL, we are talented designers, Product owners, Product designers, we know our business, we are good enough so that we don’t design unusable stuff… Therefore, our clients can rely on us for delivering simple, intuitive and cutting the edge experiences through great products…

However, there are terrible websites online. There are terrible products on the shelves, there are garments that just don’t fit what they are supposed to, there are tools supposed to simplify our lives, but they are just bringing more complexity to our lives.

Continue reading about User Testing Part 1/2 : Why you should perform them – The risks you avoid

Tags: , , , , , , , ,

The fears about innovation and Users’ loyalty – how can a UXer help? Part 2/2

Innovation and changes are risky meanwhile necessary. UXers can support change and deal with risk management. Discover in 3 steps, how UX can help dealing with these fears… and help bringing innovation.

In my last blog post, we realized that companies are faced with an ambiguous situation, between innovation and users loyalty. Meanwhile users want  cutting the edge experiences and dislike learning news things.

1: Deal with these bad feelings concerning change in companies

I have bad news. If your company is struggling at innovating, maybe it is because it is excellent at killing good innovation ideas. Big companies are expected to innovate, but managing people in such companies just freak out at the simple idea of dealing with edgy ideas.

Continue reading about The fears about innovation and Users’ loyalty – how can a UXer help? Part 2/2

Tags: , , , , ,

The fears about innovation and Users’ loyalty – how can a UXer help? Part 1/2

Innovation – what a buzzword! The request for innovation is everywhere, in every request for proposal, even on the lips of some end users. As if companies that do not innovate go bankrupt. End users want exciting experience, and reject change at the same time. It is an ambiguous situation.

Let’s innovate while keeping users happy ! But how?

Innovation: Risky but necessary

Innovation is everywhere! Is every existing thing not good enough and has to be improved? As if we required on a daily basis cutting the edge and exciting experiences! May it be only for pouring coffee in our mugs, or for giving feedbacks to developers who implemented what we co-designed with a client, or for completing a survey, booking a room, making a conference call…

The users of a product know what’s wrong with a product, what is not working properly, what takes too much time. In other words, they know what could be improved. It might be risky  for a company to take the leap, because end users might dislike the change.

Continue reading about The fears about innovation and Users’ loyalty – how can a UXer help? Part 1/2

Tags: , , , , , , , ,

When Innovation Exceeds the User Need – The iCloud Case Study

Yesterday I saw a video about a talk given by Johnny Chung Lee, a Human Computer Interaction researcher currently working at Google on the Project Tango platform, at Stanford HCI Seminar – «Interface Technologies That Have Not Yet Left the Lab». I was impressed about the amount of extraordinary ideas which still haven’t reached the market. For many of them the time hasn’t yet come. Though as Johnny Lee mentions, one of the reasons why they may fail is the lack of good Experience Design. Interfaces are there to capture the user need. Technologically driven people still tend to ignore the frustration felt by a user when he/she can’t achieve his/her goal. The over-excitement about new technology blinds them and puts the user into second place. That’s why one should always ask oneself – Why should a user use my product?

Continue reading about When Innovation Exceeds the User Need – The iCloud Case Study

Tags: , , , , ,

A recommender system for Slack with Pandas & Flask

Recommender systems have been a pet peeve of me for a long time, and recently I thought why not use these things to make my life easier at liip. We have a great community within the company, where most of our communication takes place on Slack. To the people born before 1990: Slack is something like irc channels only that you use it for your company and try to replace Email communication with it. (It is a quite debated topic if it is a good idea to replace Email with Slack)

So at liip we have a slack channel for everything, for #machine-learning (for topics related to machine learning), for #zh-staff (where Zürich staff announcments are made), for #lambda (my team slack channel) and so on. Everybody can create a Slack channel, invite people, and discuss interactively there. What I always found a little bit hard was «How do I know which channels to join?», since we have over 700 of those nowadays.

Bildschirmfoto 2016-06-16 um 11.34.12

Wouldn’t it be cool if I had a tool that tells me, well if you like machine-learning why don’t you join our #bi (Business Intelligence) channel? Since Slack does not have this built in, I thought lets build it and show you guys how to integrate the Slack-API, Pandas (a multipurpose data scientist tool), Flask (a tiny python web server) and Heroku (a place to host your apps).

Continue reading about A recommender system for Slack with Pandas & Flask

Tags: , , , , ,

Discussing ‘open design’ at iadlab15

Andy and I lately got invited to host a ‘lab session’ at the iadlab15 interaction design conference in Bern. We proposed to animate a discussion on a quite abstract topic: open design.

What the true meaning of our topic was, we didn’t know by the time we proposed it. Yet we had a strong feeling that the ‘open’ culture wasn’t as strong in the design scene as it is in the tech scene and wanted to discuss that assumption, openly.

We thus introduced the open design notion with a big question mark: opensource we know since ages, opendata is now proving its value to the world, what about open design?

It turned out the discussions went fantastically well and we got thanked many times for having brought the topic onto the table.

Even more astonishing to us, what we encountered is a generational gap: digital-native creatives showed interest and seem to integrate open practices whereas their elders tended to disregard – if not despise – them.

Continue reading about Discussing ‘open design’ at iadlab15

Tags: ,

The User Experience of APIs

After having read how some people can hold and transmit the terrible misconception that designing APIs has nothing to do with designing great experiences, I felt one could provide a few insights into the benefits of shaping an API around its consumers – the developers and the machines – as much as around the data.

Continue reading about The User Experience of APIs

Tags: , , ,

Halve-halve-halve : a group prioritization method

Priorities matter at every step of an agile design and development process, yet setting priorities is a daunting task and prioritization in group within a workshop even more.

Reaching general consensus on priorities is always hard

I remember many workshops I facilitated where the mood was open and friendly until I invited the participants to set priorities in the ‘big cloud’ of needs and wishes postit-ed on the wall. At this crucial moment, two distinct group behaviours would occur:

Continue reading about Halve-halve-halve : a group prioritization method

Tags: , ,