top of page
UX CASE STUDY

Accessibility in Freshservice

A pleasant user experience is a “need to have,” not a “nice to have.” That’s why we’re making sure everyone who use Freshservice, finds it easy and accessible.

cover.png

Introduction and Background

Accessibility in Freshservice started as a design initiative. After another well known product was legally sued for not being accessible, Myself and my manager envisioned that the need for accessibility would hit us soon.

​

Since, at the same time we are moving to Ember framework, which will need us to develop our product from scratch, this will be the right time for us to focus more on designing for inclusion, This shift involves us to write new codes, and this is the right time for us to write codes which meets the coding standards for accessibility.


So, we started doing our ground research on Accessibility, Understanding Accessibility in Design context and leveraging the same, until then “Accessibility” or “A11Y” was an alien term for us.

Overview

Freshservice is an cloud IT support tool more like an Helpdesk, which is used by IT folks to manage Incidents or Service Requests, Assets and so on..
The tool has two different interfaces, Agent portal, catering to a number of personas like the service desk agent, admins, supervisors, and the Requester portal (a.k.a customer portal/ support portal) catering to the employees of an organisation. The support portal is used to raise tickets or service requests or to go through the knowledge base articles etc...

Freshservice is used by various industries, some of them are the Govt institutions, Higher educational institution, Banking sectors, Financial institutions, and many more, not being accessible will result in law suits and also levy heavy fines.

​

Accessibility is becoming a legal requirements around the world, and it is every designers, product developers responsibility to develop a product which is accessible to the special needs of the user. 

​

The Problem

Visual/Color contrast issues  - The input form fields and the help text within were not visible to certain users, Users were not able to distinguish the text from its background on the secondary button

​

Font legibility and option to increase font size - Users wanted to zoom or increase the font size to read the help articles, though the interface was capable of zooming upto 200%, users were still facing difficulties.

​

Keyboard focus and order - Keyboard focus was missing for links and buttons, and users were facing difficulty to use the Keyboard to access the tool without using the mouse. The focus order was not visible


Product was inaccessible to Assistive technology tools - Since there was no Alt text for the icons and images, it was difficult for users using screen readers to consume the information. 

 

No proper structure & semantic markups - Users were not able to make sense of the structure of the content on each page and understand how to operate within the system.

 

The Goal

The users of Freshservice app need to access information that is direct, simple and easy to digest so that they are able to understand the product and its features.

Goal.png

Business Needs

Accessibility compliant Customer Portal - Freshservice is in need of a compelling, user friendly and accessible support portal to sell their product while also catering to the users who has visual impairments, hearing problems, cognitive and motor disabilities..
 

My Role

I led the design strategy and was responsible for identifying the vendor who will help us achieve A11Y.

 

I worked alongside other designers, a Product owner, Developers and a Content Strategist.

 

And at a later stage, I was responsible for educating others in the organisation about the value of accessibility.

Outlining our approach

Process.png

Research Phase

​

  • Understanding A11Y and its levels

  • User Interviews & Empathy Labs

  • Competitor Analysis

  • A11Y Heuristics Evaluation (existing product)

  • Conducted Design hackathon

Develop Phase

​​​

  • DSM Components Audits

  • Wireframe

  • Visual Design

  • Usability Tests

  • Design Comp Accessibility Annotation

  • Development

  • Assessment by a third party vendor

  • Assessment of assistive technology tools

  • VPAT Documentation preparation

Delivery Phase

​​

  • Shipped an accessible product

  • VPAT Template with WCAG 2.1 AA

Understanding A11Y and its levels

PRELIMINARY RESEARCH

Different countries have different laws for digital accessibility and most of them adheres to the WCAG Guidelines.

For example - For US, Section 508 of the Rehabilitation Act requires all federal electronic and information technology to be accessible to people with disabilities, The recent refresh of Section 508 requires websites to adhere to WCAG 2.0 standards.

​

The Web Content Accessibility Guidelines (WCAG) are by far the most universal and popular guidelines for web accessibility.

Created by World Wide Web Consortium (W3C), WCAG is a set of guidelines to ensure online content is accessible to all users.

​

WCAG 2.0 uses four universal design principles.

​

  • Perceivable: Users must be able to perceive all relevant information in your content.

  • Operable: Users must be able to operate the interface successfully.

  • Understandable: Users must be able to understand the information and operation of the interface.

  • Robust: Content must be accessible to all users and can be interpreted by a wider variety of user agents.

Levels of Accessibility

levels.png

User Interviews & Empathy labs

We conducted remote Interviews with Participants with disabilities related to vision to understand the difficulties that they face in Freshservice support portal.

We analysed the different assistive technology tools like Screen reader (e.g., JAWS, NVDA, Claro, Dolphin, Window Eyes, ChromeVox) Speech input tools, tools to reduce visual stress, Tools for writing and spelling for Dyslexic users.

​

Findings from the User Interviews

​

User perception - The users were not able to perceive the information on the Freshservice application as it was not supporting the use of Assistive Technology tools. 

​

Showing informations on a pop-up was useless as none of the assistive tech tools were able to read them.

​

Most of the form elements and the buttons with illustrations were not visible for users having visual impairments.

​

Searching for something on the tool was difficult., When there were too many search results, there was no way where users can narrow the search results.

​

Accessing Solution articles was not intuitive as the articles were inside multiple folders.

​

Finding an Accessibility Vendor/ Consultant

Accessibility was really vast and it would be best to have a SME here to help us achieve accessibility, So I reached out to many vendors (Perkins Access, BarrierBreak to name a few) and finally resorted to Deque. 

​

Deque further trained us in Designing with Accessibility in mind and also trained our developers. 

​

During the Global Accessibility Awareness Day (GAAD), May 2019, Deque had organised an empathy lab in which we took part to understand the difficulties faced by users with special needs, we also had an opportunity to use the different assistive technology tools.

empathy labs.png

Competitor Analysis

We analysed some of our competitors and gathered on the following:

CA_A11Y.png

We found out that most of our competitors are complying to a WCAG 2.0 AA standard with a VPAT, We wanted to have the most latest , so we decided to comply to WCAG 2.1 AA

RESEARCH ON THE EXISTING PRODUCT

Accessibility Heuristics Evaluation

We conducted a heuristic evaluation for accessibility for all the screens and interactions in the existing product and evaluated them based on the following factors:
 

  • Interaction Methods and Modalities

  • Navigation & Way-finding

  • Structure & Semantics

  • Error Prevention & States

  • Contrast & Legibility

  • Language & Readability

  • Predictability & Consistency

  • Timing & Preservation

  • Movement & Flashing

  • Visual & Auditory Alternatives

By evaluating the accessibility of our existing product, we understood that there were many issues in the existing tool, and also a great opportunity to revamp the user experience of the product. 

THE STARTING POINT

Conducted Design hackathon

We organised a Designathon for the entire Freshservice Design Team.
The objective of this Designathon was to help the designers to unleash their creative ideas and experience a real-life design problem and in-turn craft a usable, viable, and an empathetic design solution.

​

What was it all about?
The entire Freshservice Design Team was split into teams of 2-3 members each and were given a problem statement to work on - Redesigning Self Service Portal
The team then brainstormed and worked for 8 hours to come up with prototypes for it
Each team presented their ideas to the panel
All the ideas and solutions were discussed, debated and at the end of it, we had many different ideas, ready to be executed.
These ideas will be implemented in the upcoming Requester Page Revamp

 

How did it help?
With our busy schedules, finding time for implementing our own ideas is a tough challenge, but this helped us to discuss, brainstorm, create mocks and craft meaningful design solutions in a matter of just 8 hours. It greatly helped all the participants to explore different solutions and the result was: a completely different approach from each team and many different ideas, all ready to be executed!.

Group 2.png
Different Solutions were made...
hack day.png

Web application

Chat-bot interface

Kiosk Set-up

Insights from Design hackathon
​
​

​

​

​

  • Search centric approach - Patterns in user behavior helped us understand how they interact with search, So with the help of a prominent search bar on the home page, providing users to take the search first approach.

​

  • A full page search results - When the search populates too many options in different category, it is hard to distinguish which is the right search, Optimising for scalability and the ease of use, we introduced a full page search results for users to consume the information and select the intended search result.

​

  • Cleaner home page  - The home page with a more prominent search bar and cards for frequent actions and a dedicated section to view tickets raised by the requester.  

​

  • Scalable Rail Navigation - The horizontal menu was not scaling, so we introduced a hamburger menu with rail navigation to be consistent with other freshworks suite of products.

​

  • Cleaner and accessible tickets detail page

​

​

​

​

Shift-Left approach

The top management and my peers understood the importance of Accessibility, but they were overwhelmed by the idea of executing it. because

  • they do not have an idea to where in the process a11y can be fitted.

  • and the accessibility checklists are pretty overwhelming.

​

It is best to consider accessibility early in a product’s lifecycle, as this reduces the amount of time and money you will need to spend to make your products accessible.

It's not a good idea to fit in accessibility when it comes to web products, the cost and effort of fitting in Accessibility to an existing digital product is more compared to starting it from scratch. So the right place to start is when you design.

The Design systems is often the best place to start! As designers we should ensure that the components in the Design systems are  Visually accessible, meaning, they should follow these guidelines:

CREATION

DSM Components Audits

The first step was to audit our Design Systems, it is necessary to understand the WCAG accessibility rules that are linked to the visual components.

​

Some actions that were performed on the DSM to improve Accessibility:

​

  • Avoiding the use of colors as the only visual means of conveying information

  • Ensuring sufficient contrast between text and its background

  • Providing visual focus indications for keyboard focus

  • Having a clearly defined boundaries and visual labels for form elements

  • Buttons were made much larger than the 44*44pt recommended by Apple’s Human Interface Guidelines

  • Use of Alt texts for images and icons for the purpose of screen reader.

Audits.png
WIREFRAMING

Layout & Functionality

The insights derived from the Design Hackathon were incorporated in the design

wires.png
VISUAL DESIGN

Designing the look and feel

The UI design required a lot of continuous feedback and retesting to create the final product. 

1_HomePage.png
2_Searchresults.png
3_RailNav.png
4_ServiceCatalog.png
USABILITY TESTS

Validating our Designs

The design required a lot of continuous feedback and retesting to get to the final product.

​

We tested our designs with users who were having some form of accessibility issues like color blindness, partial vision, and physical disability, so we can correct any issues and ensure as many people as possible have access to Freshservice.

​

Our main intention was to identify if our designs are visually accessible, and the outcome from the test turned out to be a success, as the participants did not face any issues with respect to the look and feel of the product.

​

But, we learned that an Accessibility expert can evaluate accessibility issues for a broad range of users, which might not be found by individual users.

​

​

DEVELOPER HANDOFFS

Digital Content Accessibility Annotations (DCAA)

The DCAA is a document created primarily for the developers. Deque's Subject Matter Experts will review the designs(mocks) and apply the appropriate accessibility guidance to those designs, to more fully inform the developer on what is required to achieve accessible outcomes.

​

The DCAA provides:

- Markup of UX and UI wireframes and comprehensive designs (comps) with accessibility requirements.

- Identifies important accessibility design information. 

​

Annotations help developers to understand how to build clean code for each page by mentioning what is h1, h2, title, link, button, header, footer, label, placeholder text, etc. 

dcaa2.png
dcaa.png

Support the team for implementation

Once the developers kick-started on the code, we needed to ensure that everything else, apart from visuals, was also accessible by checking the following:

  • UX issues

  • Works well in all the browsers

  • Responsive in all the resolutions

  • Keyboard navigations are implemented properly

  • Tab focus is visible and in the right order

  • Screen readers are working properly.

​

It took us a couple of months to check all these capabilities with the help of multiple developers page by page and we implemented a complete pack of accessibility versions a year after every team member’s contribution had been accounted for.

POST DEVELOPEMENT PHASE

Accessibility Assessment Report

Our developers used a tool "WorldSpace Attest" to fix 60% of the accessibility issues during development, and since Freshworks doesn’t have an accessibility testing team now ready to test the 40% manual issues, we took the help of Deque for accessibility assessment to assess the compliance of the development.

 They provided a detailed report in terms of what is compliant and what still needs to be fixed.

Report.png
ACCESSIBILITY CONFORMANCE REPORT

The Voluntary Product Accessibility Template (VPAT)

Freshservice's new self service portal is now the default portal that new customers get out of the box when they signup for an account.

Self service portal v2 also has a VPAT document that documents our adherence to the WCAG 2.1 AA standard. 

​

Getting the VPAT has been a long journey and I am incredibly grateful to the awesome team that has made all of this happen!

SUCCESS METRICS

Measuring Adoption and Impact

We have about 290 new customers who are using the accessible support portal and there has been no issue or support ticket raised for the same. This clearly showed that we have provided a quality output. I am glad that we got such a positive response and everyone liked it.

Conclusion

Accessibility is about considering all users. It means that as a product manager, designer, or developer, content strategist, you have to include those users with disabilities, or the elderly. It is really worth remembering that even a small improvement made for the minority is still beneficial for most users as it generally improves the usability and ease of use of the product for every user.

​

It was only when we started work on improving the accessibility of our Freshservice that we realized how much work there was – and still is ahead of us. On the other hand, we draw much satisfaction from knowing that visually impaired and users having other special challenges have more freedom when interacting with the product. 

​

Accessibility, being rather than a process, It should be the mindset of the people in the organization!

What next?

At this moment, we are building our Agent Portal accessible! stay tuned to read about it.

​

bottom of page