University of Illinois (UIL) launched their shuttle service in November 2019 connecting Urbana Champaign to Chicago. Apart from offline ticket booking they needed online platforms for booking and managing trips. I worked on responsive web, Android and iOS platform design. Clients needed their booking platform to be Accessible following WCAG AA guidelines.
Getting a chance to work on a project where AA accessibility guidelines are required is rare for me. I
usually follow guidelines like enough color contrast, readable letters, meaning flow and multiple other
guidelines, however working on a project where WCAG AA compliance is needed is something very different
and requires much more planning and testing than a normal project. This was my first full fledged project
where I designed and tested for Accessibility. Before starting this project I had to go through multiple
guides, articles, tutorials and training to understand how to design for accessibility, how different
screen readers work. Apart from designing I was given a responsibility to lead and educate my development
team and QA team about accessibility.
In this case study I will focus more on how I designed for accessibility and dev collaboration, rather than my UX process.
I would divide my process into two major parts:
Discovery and Design:
Dev collaboration and quality analysis:
Youtube videos helped me in having a deeper look into how people with special abilities use computers and screen readers. I also spent a good amount of time reading multiple blogs by experts, and talking to my designer friends offline about how they tackled certain cases and scenarios.
Guidelines & resources:
I spent some time understanding how travel and booking websites are solving the accessibility problems and what patterns they are using. Expedia was my favourite oa all platforms (Web, iOS and Android). I learned a lot in terms of patterns and semantics from these three websites.
While sketching initially we were having a clear idea how screen reader flow is going to be. The sequence, any hidden element specially designed for screen reader users (like hidden headings)
Apart from supplying assets and design specs, I prepared one additional document for the reference of the development team. We called it “SR Flow Doc” (SR: Screen reader)
Paying special attention to:
Before implementing any small component in actual code base we tested those in an isolation to get better clarity on accessibility
Our stakeholder team had few accessibility experts, getting their timely feedback on design and frontend code was immensely helpful for us.
We were having soft usability testing sessions, early in the process by showing our designs to people who had some sort of color blindness to get an early idea about any possible usability issues. By collaborating with our stakeholders we ran multiple usability sessions on the University campus. We utilised Zoom for this purpose, in order to get real time user feedback.
This was one of the full fledged projects where I got an opportunity to study accessibility in more depth. Knowing how to code can be a big advantage if working for accessible projects. Projects with accessibility design require very close collaboration with the dev and QA team as compared to other projects