At Fullscript our mission is simple, “Helping people get better”. We define “better” as “whatever it means to you”. We don’t define what “people” means because we shouldn’t have to. “People” simply means “everyone”.

For us engineers and designers who work directly on the Fullscript application, it’s important to think about the range of abilities that everyone who uses the application might have. People may see colours differently than others, making it difficult for them to interact with a webpage as it is designed. Some people can only use computers with specific devices because a keyboard and/or a mouse don’t work for them. The most common alternative device is called a screen reader. They work by reading out to the user a description of what is on the screen and allowing them to interact with the different elements that are described.

Knowing this influences the colour choices that our design team uses when they create pages that engineers then build. Engineers are responsible for ensuring that the elements displayed on a page have the correct identifiers built into them. This ensures that a wide variety of devices (including screen readers) can access and interpret the page correctly for their users.

Overall, we address this type of work as accessibility work; or more broadly we refer to this work as inclusive design. Although inclusive design is now at the center of how we approach product development at Fullscript, it was a journey to discover just how we could make that possible given the breadth of what we offer as a platform.

Let us take you through what we discovered, and what we didn’t, to make the Fullscript experience accessible to our vast customer base.

Code ownership

Ownership is a core tenant of the engineering culture at Fullscript. Each engineer takes pride in ensuring that their code is a complete solution to whatever the goal of that code happens to be. This has been our approach to strengthening digital accessibility across the whole team. With the help of regularly scheduled accessibility-focused talks and great collaboration, we entrusted the engineer writing the front-end code, to ensure their code is accessible. We are educated as a unit and work together to really inject accessible code into daily business. This strategy has worked very well in the mission of building out the core architecture of the Fullscript platform.

Fixing an important gap

While individual ownership was a good strategy for us as we were growing, in the spring of 2021 we decided it was time to reassess if our strategy was meeting the very high bar we set for ourselves when it came to “Helping people get better”. This is where my story really begins. One morning my manager pulled me into a Google Meet and told me that I would be switching my main focus to accessibility for the next several weeks.

Here’s my take on how Fullscript was able to really put digital accessibility as a priority and succeed.

Phase 1 — Tooling

The first problem we faced as a team was that manual auditing for accessibility issues turned out to be a very time-consuming process. Manually inspecting each differently coloured element on each page of the platform, to check for contrast issues, would probably have taken us at least an entire year of work!

Thankfully, with some time in research, we managed to find a great tool that could do a lot of this manual work for us. The tool is called Axe and it’s published by a company called Deque which self-identifies as “The Trusted Leader in Digital Accessibility”. This tool proved to be essential to our workflow and our engineering team had an overall positive experience using it.

Axe allows us to audit each page of our application for accessibility issues. The screenshot below is an example of an Axe audit. In the top left section, you can see that it found 26 issues and those issues were broken down into statuses: critical, serious, moderate, and minor, helping us with what to prioritize. Underneath the total issues, each of the individual issues is listed, and the screen on the right provides the exact information about each of those issues. Very clear detection and summaries, for our team to tackle the execution.

Phase 2 — The Grind

Axe worked so well for auditing that it only took us one day to determine that across 70+ pages and 50+ emails, we had 500+ outstanding accessibility issues. The total number of issues seemed quite daunting to all of us when we got started on fixing them. Thankfully, solving these types of issues was very straightforward so we worked through them at a speedy rate. Some examples of the types of issues we solved include:

Text Colour Contrast:

In our checkout path, we have a header component that shows the user how far along they are in the checkout process.

Original (un-accessible) Version

Final (accessible) Version

Previous to this change, you can see that the statuses such as ‘Cart’, ‘Shipping’, and ‘Delivery’ did not pass accessibility standards. The contrast between the colour of the text and the colour of the background was not distinctive enough. Quite frankly, it’s very hard to see. When we transformed this element in the platform, there is now a big difference in the darker grey text vs the background and is much easier to read.

Image Alt Tags:

Screen readers work by looking at a webpage and reading out what the first element is and whether the user can interact with it. For example, they can click a button, or type their name in a form field. The user then decides to interact or move on to the next component on the page. This works by default for most web elements because buttons and form fields usually already have text on the screen that describes what they are for.

Where this doesn’t work by default is with images. Screen readers are not yet smart enough to understand what an image is portraying. We solve this by including descriptions in our code that are specifically meant to be read by screen readers.

An example of this is the user account avatar image that we use in the top menu of our application. To the human eye, it appears obvious that this is a profile image for Andrew (as a 3-year-old). A screen reader sees two separate elements on it, a small circular image and one is a small text paragraph with the word “Andrew” in it. To help the screen we make sure there is an alt (stands for alternative) attribute on the image element that says “Avatar image for Andrew”.

It took 3 engineers close to a month of full-time work to get through all 500+ of the issues.

Phase 3 — What’s next?

The completion of this project has left us optimistic about the future of accessibility at Fullscript. The primary task for the engineering team that worked on these accessibility solutions, is to train the rest of the front-end developers on how to use the new auditing tool Axe and pass along lessons we have learned. Going forward the tool can be used as a quality assurance step for the whole team, to ensure all code is accessible before releases are made. A unified effort to put accessibility standards into all Fullscript code.

The work we completed in this project also prepared our codebase for another exciting improvement, colour theming. There has been a lot of buzz around ‘dark mode’ in tech. With tech giants like Slack, Twitter, Facebook, and Apple, all enabling users to change the background of pages from white to black, while maintaining contrast on the rest of the page elements. With ‘dark mode’ enabled page colours automatically update for proper visibility. While Fullscript doesn’t support dark mode today, it is something we are actively working on for our patient application. The colour changes we made during this accessibility project have laid the foundation for it. An update like this would also allow us to release other colour themes that are designed specifically for different types of colour blindness that our users may experience.

Looking to the future

Ultimately, by tackling the accessibility challenge head-on we’ve had immense learning around how we build inclusive experiences in everything we do. Engineering and design have been at the center of this mission and there is no doubt that our work will influence other initiatives Fullscript takes on.

We recently surveyed our patient base at Fullscript and discovered that ~14% of Fullscript patients identify as having a disability. This is on par with the rate we see in the North American population at large. It is our duty as builders and innovators to ensure that everyone who wants to participate in the Fullscript experience can do so without barriers; we want our practitioners and patients alike to know that we are thinking holistically about the software experiences we are creating and improving and we have made accessibility a central pillar of how we build software.

Have you had an experience at Fullscript in which you felt you could not complete your desired tasks without hitting barriers? We are open to addressing these issues head-on with you. Please reach out to support@fullscript.com and your feedback will be delivered to the team of accessibility champions here at Fullscript.

Fullscript is hiring! Please visit https://fullscript.com/careers to see all open positions and reach out if you have any questions!