Building an Accessible Culture Within HealthSparq One

Time to put the spotlight on building accessible culture

Last year we started a UI redesign of the HealthSparq One application. Along with updating design patterns, adding features to easily guide members to what they need, and generally overhauling every area of our application, we were also tasked with another important mission:

Make HealthSparq One accessible for everyone.

Rethinking our application to make it available to users with special needs is a critical component of our UI redesign – and to HealthSparq’s mission of helping people make smarter health care choices. People are using our tools when they need health care services, and we know we need to meet that need for the millions of individuals in the U.S. with a disability (census bureau).

Why is accessibility so important? Without accessibility we:

• Deny service to users
• Don’t have as extensive a user base as we could have
• Might not be compliant with anti-discrimination law
• Provide a poor user experience to some users

With accessibility, we become part of something larger. We aren’t just working to make our redesigned application accessible; we’re helping to make the web more accessible. It was clear that accessibility needed to be part of our UI redesign goals.

Setting an accessibility strategy and a vision

With all the above in mind, we set goals and milestones for building an accessible application. We wanted to:

• Make sure everyone visiting HealthSparq has a great experience.
• Improve the redesigned HealthSparq One to support users with special access needs.
• Communicate and collaborate with employees to increase accessibility awareness and promote engagement.
• Expand accessibility testing (use automated + manual testing).
• Ensure employees have the skills and resources to make HealthSparq One accessible.
• Improve accessibility by implementing the Web Content Accessibility Guidelines (WCAG).

Then, we started thinking about resources. Content, designers, developers and QA would all need to own a piece of accessibility in the UI redesign. And we needed support and buy-in from management, which meant creating a business case for accessibility.

It was also time to set objectives. The Worldwide Web Consortium (W3C) developed the WCAG (Web Content Accessibility Guidelines) as a set of universal accessibility standards for the internet. They also helped us set our company standards for accessibility: We chose to zero in on WCAG 2.0 Levels A and AA.

On a parallel track, we started thinking about how to grow a culture of accessibility.

Getting our bearings

Before we got started on outlining where to include accessibility principles into our redesign, we dug deeply into the WCAG to see where we were already doing things right and systematizing those behaviors. We confirmed we were already doing a lot of things we needed to do to become accessible. We always use:

• Clear labels on forms
• Content written at an 8th grade reading level
• Forms that don’t automatically submit
• Logical and meaningful order for our content
• Plain language
• Screens that work in landscape and portrait
• Subheadings to break up sections
• Text that can be resized
• Valid and proper HTML tags
• Warnings before the application times out (and the timeouts don’t happen too quickly)

Even though we always do these things, now that we will be doing them to improve accessibility we must continually monitor and evaluate their use to make sure they’re still working as intended.

Maximizing an existing effort to focus on accessibility

We were already doing some new things for the UI redesign that were going to help us with accessibility. Simply by creating new and consistent patterns in our design system, we aligned ourselves more closely with accessibility goals.

Some of the UI redesign components that we’re taking as wins for accessibility:

• Becoming consistent in our use of buttons, icons and links

• Defining best practices
• Giving users multiple ways to move back and forth between screens

• Making navigation consistent
• Updated forms
• Using a color contrast ratio of 4.5:1 for normal text

Staying focused on the work ahead

Once we defined our vision, we could begin to think about tactics. We were already doing a lot to support accessibility in our application, which gave us a head start. This allowed us to quickly prioritize the remaining WCAG and to begin working on fixes.

Some of the things we need to do to continue an accessible culture:

• Add text alternatives
• Allow users to skip to the main content
• Hide icons and promotional images from screen readers
• Make fields ‘tabbable’ – accessible by keyboard only

We learned a lot about accessibility so far…and we are still learning

Within our new focus on accessible culture and the efforts we’re undertaking, we’ve already learned a lot. Here’s just a few of the biggest things we’ve learned so far:

It’s going to take time. Like more time than we ever thought it would take.

We will always have to wait to have a test environment to determine whether accessibility projects worked the way we wanted them to. This is the only way we can test things like tabbing from field to field, text alternatives and the skip to the main content link. 

We need to get other people involved (and engaged).

And we need to keep them involved and engaged. We’re well into the UI redesign; we have a new Enhanced Homepage and we’re deep into working on profile pages and search results. We need to keep the accessibility working group going, meeting only when we need to, but meeting occasionally to exchange information. We also need to raise awareness to keep digital accessible culture at top of mind. 

This isn’t a one and done. It isn’t even a two and done.

We also learned that accessibility isn’t a one-time project. Every time we add a new feature, do regression testing or work on a change request, we need to review the application’s accessibility again. And again and again and again.

Tools and Resources We Recommend for Accessibility

Automated software can help catch some accessibility issues. But manual testing (testing with assistive technology) is the only way to really know how the application works with a keyboard and a screen reader. Accessibility experts recommend testing using multiple automated tools combined with manual testing using several screen readers in different browsers. I relied on free screen readers like Chrome Vox and Mac’s Voiceover to test our application in different browsers.

Free accessibility webinars are all over the web. Since they are put on by people who care a lot about accessibility, every single one I have attended has been a good use of time.

Some resources I used repeatedly during this process:

• Everyday Words for Public Health Communication (CDC)
• Federal Plain Language Guidelines (Official guidelines for the Plain Writing Act of 2010)
• Medline Plus How to Write Easy-to-Read Health Materials
• WebAIM user studies
• WCAG (Web Content Accessibility Guidelines)

And too many to list here. If you want more, get in touch with me and I’ll get the full list to you.

An aha moment: Elevate accessibility by building an accessible culture

Along with integrating Level AA of WCAG 2.0 into the redesigned UI, we also wanted to raise awareness and get support for the accessibility project. I started an accessible culture working group hoping to meet this goal. This group is comprised of members from across our company, who all bring their ideas and experiences to the group every time we meet.

Our account managers are also now equipped with a handy checklist to help them guide clients in maintaining an accessible experience for users. And, our internal wiki is chock-full of checklists, style guidelines and more for attaining accessibility.

We’re also recognizing Global Accessibility Awareness Day (#GAAD) on May 16th for the first time this year. We’re hosting a lunch for employees to learn more about accessibility. And, we’re also putting up posters to raise awareness of different types of special needs and to show how digital accessibility can make the online experience easier.

Looking forward to what comes next

We know that we can continue to improve. We could change our job descriptions to target designers and developers with a digital accessibility background. We could also research enabling Alexa (or similar) as an accessibility tool for HealthSparq One. And, we will continue to conduct accessibility testing and accessibility awareness training.

We still need to think about accessibility first. That’s one of the lessons we’ve learned. As we work on the new UI redesigns for search results, we need to anticipate the trouble (yes, I’m saying trouble) we’ll have with the maps and the challenges (this time I’ll say challenges) we’ll have with filters.

But this time, we’ll know a lot more going in, a lot more about what to expect. Of course, I am hoping the rest of the UI redesign and our accessibility efforts will go smoothly but…we are also ready for and equal to any challenges that arise.