Responsiveness and Accessibility Improvements in Eli Review

A development initiative that improved the responsiveness, accessibility, and aesthetic of Eli Review's basic layout

Client/Project: Eli Review
Timeline: August 2016
Objectives: Use newer web standards to create responsive and accessible layout
Team:
  • Mike McLeod, Project Manager, Eli Review
My Role: Front-end engineering
Categories: , , ,

Overview

Not only had Eli Review’s look grown stale between 2012 and 2016, but it had missed out on advancements in responsive design and accessibility. This is the story of how I brought my front-end engineering skills to bear on these problems, not only improving the app’s aesthetics but taking some first steps to making the app responsive and improving accessibility.

Backstory: stagnant since 2012

We launched Eli Review as a commercial product in 2010, and it received a major facelift in 2012. The app’s layout and aesthetic were consistent between then and 2016. By that time, however, we were facing a number of issues, and not just how much the drop shadows had come to irritate me.

One significant issue was that the layout did a poor job of connecting users to our documentation. We have extensive resources, from user guides to tutorials, that users would never be able to find if they had signed in to the app and not our marketing and support website.

It's difficult to visualize the more important concerns, but here's the 'before' version of the sign-in page with a gradient background ????.

Another problem was the complete lack of responsiveness of the app. It would display consistently on larger screens, but the layout was locked in a 960-pixel-wide container that did not respond to smaller screens. Responsive design had long since become an industry standard by 2016, and we needed to adapt.

The layout also lacked responsiveness to new standards for accessibility. It did not take advantage of any newer HTML layout options like <nav> or <footer> and did not set tab priorities for keyboards. It was long since time to take some basic steps to supporting accessibility conventions.

Finally, in terms of visual appearance, the app’s look came to be pretty dated by 2016. The drop shadow under the logo and the gradient in the background were both trends that had died out long before and (in this designer’s opinion) desperately needed to go.

User Stories and Project Scope

We did not develop substantial documentation for this project because it was limited in scope and mostly front-end work. However, we did have three user stories in mind:

  • As a user, I want Eli Review to be more accessible so that my screenreader can better navigate the app.
  • As a teacher, I want it to be easier to find Eli Review’s support content so that I can share it with my students.
  • As a student, I want it to be easier to find Eli Review support material so that I can answer my own questions or ask for help when I needed it.

We also set a business goal for ourselves of increasing traffic to our support resources. We did not have specific targets in mind, but we wanted to reduce the number of questions asked to us by instructors who knew that a resource existed but couldn’t remember where to find it. We also wanted new instructors and students to be able to discover these materials independently.

What Changed

The following is a brief summary of all of the high-level changes I was able to make the the layout of the app with this initiative:

  • New header – I designed and built a new primary nav menu to include a new “menu” button that opens a slide out menu containing an organized set of resources for all users.
  • New footer – I also designed and built a footer section (there wasn’t an existing version to replace – we just didn’t have a footer for some reason) that let us expose our resources again as well as prompt users to subscribe to our newsletter. This design would eventually be replicated on the support website to create more visual consistency between the two sites.
  • Semantic markup – I was able to rebuild the app’s basic layout using newer HTML elements like header, footer, and nav and assign them useful ARIA roles.
  • Accessibility improvements – adding semantic markup itself greatly improved accessibility, but I was also improve the app’s tab indexing, making it easier to use many of its features using just the keyboard.
  • Responsiveness – I made the new header and footer full-width elements that respond to browser width and adjust appropriately to support users at different resolutions.
  • Aesthetic improvements – I was happy to be able to strip out the background gradients and the tiny, pixelated logo that included a drop shadow. I replaced the logo with a new SVG version that scaled very nicely.

Before & After

The course-level completion report lets instructors see timeliness across an entire course.

BEFORE: This screenshot illustrates an instructor’s course homepage before this development effort. Here it’s easy to see how there is no footer in the layout, the primary navigation menu is not responsive, and the app has a blue-black gradient background. Not as easy to see are the unsemantic elements making all of this possible.

The course-level completion report lets instructors see timeliness across an entire course.

AFTER: The changes in the updated version of that same course homepage view are also apparent immediately – the new header and footer both stretch to accommodate the width of the screen in a way the previous version couldn’t handle while the pixelated gif logo has been replaced with a sharp, responsive png logo (that mercifully does not include a drop shadow).

The new slide out menu opened when the user clicks the “Menu” button contains all of the necessary account options but also a new hierarchical set of resources for all users. The footer element also contained many of the top-level support resources supported on our marketing and support site, creating some additional structural and visual consistency between the two sites. Lastly, the new layout also included a prominent link prompting users to subscribe to our newsletter.

Outcomes / Takeaways

While the improvements to accessibility were harder to track, and improved aesthetics are mostly personal preferences, we had two metrics we used to gauge the impact of this work:

  • Traffic to support resources: in the weeks and months following the rollout of this new design, Google Analytics recorded substantial growth in traffic to our support resources. I added campaign metadata to links in various sections so that we could differentiate between traffic from the menu and the footer, and the menu had far greater impact. Traffic more than doubled in the first month of the rollout and has grown in proportion to our user base – these resources get used a lot.
  • Newsletter signups: Our newsletter had not grown substantially since we started publishing it, but including these prominent links caused growth to spike. Between August 2016 and August 2017, our newsletter grew by 85%, and in the years since, there has been an annual growth rate of 54%.

It’s important to acknowledge that this effort to improve accessibility is only a start and that it should and will continue both as we improve the app and learn about new methods to support users. Work I know we still need to do to improve accessibility includes:

  • Better semantic markup throughout the body – I was able to use modern semantic markup when creating the new header and footer, but the body of each page in the app is still messy. As I work on individual interfaces, I will continue to make them use newer markup that will aid devices in understanding what the content is.
  • Find more accessible third-party resources – several of the libraries we use for advanced interactivity are not keyboard accessible. Finding resources we can use to replace those libraries should be a top priority.
  • Listening to feedback – continue listening to user feedback as they share stories with us about what works and what doesn’t and adapt accordingly.