Designing for Accessibility

We’ve recently given our PatientPack interface an overhaul to aid with accessibility. Here are the results

I’m Chris, the User Experience Analyst at Substrakt Health. I also handle all the design and frontend duties for PatientPack. Over recent months I’d felt that some of the early design decisions we made at the start of the project weren’t holding up to scrutiny. We decided to give it a re-working, and back this up with some user testing with visually impaired users.

The Before

The app was designed in April 2016 and because of our agile approach over the lifespan of the project (the app is consistently iterated upon to make a better product) I felt that the core of the design also needed iterating to match the evolution of the functionality. As well as the layout not quite reflecting where we were in terms of functionality, in recent demos some of the subtle greys and other brand colours were barely noticeable on large screens or projector screens. We needed to iterate…

The brand colour

PatientPack is a white label product – it can be applied to any organisation who wishes to use it as their primary patient facing app. MyHealthcare are our partners in getting the app up and running and therefore we used there brand as a basis for the app design.

We’d noticed over recent months that the contrast for items using the teal colour wasn’t as strong as we would have liked. In demo’s using projectors or large screens, I’d noticed that participants needed to move closer to the screen or we needed to make sure all lights were off in the room. Once we’d made the decision to rework the layout, I spent some time testing the colour in more detail by using an accessibility tool called StarkStark is a Sketch plugin you can use from within your Sketch project which aids testing for contrast and colour blindness.

Testing colours for accessibility


As a result of these investigations we decided to reduce the use of the lighter teal across the site, which included it’s use in the header and across all titles. This made a huge difference to the contrast of typography across the board and greatly improved the success of our testing with visually impaired users.


Another decision I took in the early days was to restrict the width of the layout on most pages. The theory here was that the interface would work primarily as a mobile interface. Its focus early on was for booking an appointment so I felt that if the process could work on a small screen, we could simply stretch this out when viewing on a desktop screen. This was working great, until it didn’t. The sections within the app were becoming more varied – in areas such as the lifestyle and long term conditions section there was a lot more browsable content – the smaller layout was proving restrictive.

Some other decisions we took in improving the layout were:

  • Increasing the font size
  • Reducing the number of subtle greys (which were becoming unmanageable, and useless in their lightest forms!)
  • Increased the contrast of greys across the site
  • Removed any shadows we originally had on some elements
  • Removed the max-width on content except from the main content area where we still use a max-width of 1200px





Form Elements

There were also a number of smaller changes we made the interface that came about from our testing sessions with visually impaired users. One of these were our form input fields. We’d already thought of making the active state obvious when tabbing through a form (orange highlight), but I’d used a fairly subtle grey for outlining an input field in it’s default state (designer being subtle and designy). We changed this to a darker line and darker text for placeholder text



Improving the contrast of form elements - Before


Improving the contrast of form elements - After


Hover contrast

There were a number of instances in the testing sessions where a user wasn’t aware of when they were hovering over a button. In light of this we increased the contrast on the hover states of all buttons by default. We also made sure all text for buttons is a strong enough weight. This difference is illustrated well in the main menu


Improving the contrast of hover actions - before


Improving the contrast of hover actions - after

Appointment type cards

The appointment type card changed quite drastically following user tests. People were unsure where exactly to click – the entire block is clickable but it’s not clear when you arrive on the page that this is the case. Highlighting and contrast were weak across the element so we needed to give this a boost. Testing caused us to change the following:

  • Added a call to action button even though whole item is clickable
  • Removed the green colour as a highlight colour. The green did the exact opposite for visually impaired users – an underline is better
  • The orange text, because of the thin weight was very difficult to read. We’ve increased the weight
  • As in the form inputs, the grey outline was also difficult to notice so we darkened this




Testing for accessibility is a bit like flossing – you know it’s really important but sometimes, you just don’t have time for anything more than a quick brush. Thankfully, over recent weeks we’ve given our interface a good floss – we’ve taken a bold step of reviewing our interface and making wholesale changes and the app is leaps ahead of where it was in regards to accessibility. We’ve got more user testing planned over the coming weeks so I’ll keep you posted on any further insights and changes we make.

If you’re interested in talking in more detail about accessibility, or would like a demo of the app itself, please get in touch by emailing us at