Saving lives with Revvity’s EVOYA Platform

The project aimed at the development of Revvity’s EVOYA platform. Revvity (RVTY) is a leading global provider of end-to-end medical solutions for scientists, researchers, clinical laboratories, and healthcare professionals. As part of its broader diagnostics solutions, EVOYA aims to support rapid screening during the neonatal period. It’s been developed as a multi-tenant web-based digital platform for management of data, analysis, and reporting of newborn screening test results and demographics. The detection of abnormal results at such an early age is crucial for a healthier life and can help to save lives.  

The platform is used globally, mainly by various professionals in clinical laboratories, while also serving physicians who submit the sample and information to the laboratory. Special attention is paid to keyboard accessibility, as clinical laboratory workers have been observed to be keyboard users. 

A large international project team

Achieving the ambitious project goals on time requires various expert teams, among them project management, product owners, domain experts, multiple developer teams, testing and verification, UX design, technical writers, and DevOps. The project team included people from different organizations, cultures, and geographical areas. Communication and collaboration naturally take place online, while considering large time zone differences. For the development process, we followed the Scrum methodology with a two-week sprint.

The project team had various levels of experience in implementing accessibility. A common practice in this case is to start by creating a shared understanding on accessibility and its implementation. Before that, it helps to have commitment.

The commitment to accessibility

If it’s not written down, it doesn’t exist. An explicit accessibility commitment on a project management level greatly helps to ensure that accessibility is systematically implemented. The following are the commitments made in EVOYA.

Accessibility objective 

The W3 Web Content Accessibility Guidelines (WCAG) is the most universally accepted standard for making accessible web content and is used as the technical guidelines by regional legislation such as Section 508 in the US and ETSI EN 301 549 in Europe. Consequently, EVOYA’s accessibility objective was documented in terms of a product requirement to comply with WCAG 2.1 AA level, which is the level recommended by most regulations. 

Accessibility champion

Once the goal is clear, someone needs to plan, coordinate, and guide the accessibility effort towards achieving the goal. Meet the accessibility champion. Obviously, this needs to be someone with accessibility experience, but the role doesn’t need to be exclusive. In EVOYA, I worked as the accessibility champion alongside my main role as a UX designer.

Definition of Ready and Done

The Definition of Ready (DoR) and Definition of Done (DoD) are lists of criteria that must be completed before a work is accepted for implementation or considered as done. In EVOYA, accessibility is included in DoR in terms of the accessibility guidelines and annotations described later. For DoD, accessibility is part of the implementation and verification criteria by ensuring the work is done based on the accessibility guidelines and annotations.

The implementation of accessibility 

Accessibility is a quality of the user interface (UI) and the service's content. These are implemented at the UI design and code levels and by content producers. Consequently, the implementation and verification of accessibility takes place throughout the entire project lifecycle – design, development, testing, and verification phases. We set the process off with an accessibility plan. 

Accessibility plan

Given the different backgrounds, I started by organizing an intro session for all people taking part in the project, aiming at establishing a common understanding of digital accessibility and its implementation. The result was an initial plan for the accessibility practices, tools, responsibilities, and overall process for implementing and verifying accessibility in EVOYA. 

Accessible design

Accessible design is a large enough topic for several posts. In essence, the UX design team has considered various accessibility lenses during design. Furthermore, having other people review a design has also helped to catch accessibility issues early on. 

Accessibility annotations

The UX design team documented accessibility guidelines for the implementation of UI components following trusted sources such as the W3C Web Accessibility Initiative, ARIA Authoring Practices Guide, and MDN HTML documentation. More notably, we associated the UI design with accessibility annotations, such as the page title, skip link, landmarks, interactive elements, ARIA live regions, and focus order. We used the extremely helpful A11y Annotation Kit for Figma. For a smoother design-development-testing handoff, we linked the accessibility annotations page in the relevant backlog work item.  

Accessible UI component library

There are many UI component libraries available in the market that can greatly save development time. Unfortunately, many of the libraries were not developed with accessibility in mind. We use the DevExpress library, where the UI components largely comply with the WCAG standard. In specific cases we also developed our own components following the guidelines listed in the previous section.

Accessibility linters

These handy coding helper tools automatically flag accessibility issues based on a set of predefined rules. Even though there is only a limited number of accessibility rules, linters are very useful in preventing basic issues early on and developing more accessible coding practices. Developers in EVOYA were encouraged to use axe Accessibility Linter.

Accessibility testing

The testing of accessibility has been done by people in various roles:

• Developers – they were encouraged to use axe DevTools, an accessibility checker that detects a larger (than linters) set of issues once the code is running in the browser. This testing is done during development on a local machine. 
• Testing team – once the development of a feature is done, testers walk through it in the testing environment with a larger testing lens. In addition to the accessibility checker, they also do keyboard testing and review the code to ensure it conforms to the guidelines and annotations defined in the design phase.
• Accessibility champion – I periodically conducted testing that extends the testers' scope by testing other WCAG requirements and with a screen reader. 

Note that we considered other approaches and tools for automated accessibility testing.

Accessibility verification

Prior to the beta release, EVOYA was subject to verification by end-user testing and an accessibility audit.  

• End-user testing focused among other things on keyboard accessibility. The testing was coordinated by a business manager with input from the UX team. 
• An accessibility audit was conducted by a third party that evaluated the EVOYA platform against the WCAG 2.1 AA level. The audit was organized by the EVOYA program manager and the accessibility champion. The results were very encouraging and validated the accessibility effort the team put in. The audit highlights the accessibility of the EVOYA platform, especially for keyboard users. Naturally, it also underlines a few areas for improvement that will be fixed for the next release.  

As development is continuing after the beta release, the team is carrying on with the same accessibility commitment and process, including periodic accessibility audits after releases.

Lessons learned

Overall, the EVOYA case highlights 3 interrelated principles that are critical to the implementation of accessibility, particularly in large projects: an explicit accessibility commitment, an early and continuous deliberate awareness to accessibility throughout the project lifecycle, and a shared responsibility by people in different roles for implementing accessibility.  

The journey also taught us the following:  

• Project turnover – a large and long-term project inevitably leads to people leaving and new ones coming in. To have everyone onboard in terms of accessibility, I periodically walked through the accessibility intro and process for newcomers. 
• An annotations-centric process – the annotations both address developers’ unfamiliarity with accessibility and lay the groundwork for the implementation of accessibility on a code level and its verification. Special focus was put on constantly optimizing the design-development handoff to minimize hindrances to the development process.  
• Accessibility of external services – EVOYA relies on certain external services, for example, for login. Due to the services being managed by a third party, initially they were not annotated for accessibility. Consequently, the audit highlighted some common accessibility issues on the services’ pages that were not found on annotated pages. This illustrates the significance of the annotations and the need to test external services also for accessibility. 
• The accessibility tradeoff with a UI component library – even libraries that claim to be compliant with accessibility standards may have issues, because full compliance is difficult to achieve. Whenever possible from an effort outlook, we developed our own UI components. But with the more composite components, like a data table that incorporates various built-in functionalities, we decided to go with the library and document the known issues. 
• Learn and adapt – having the project being the first accessibility implementation experience for many, we constantly learned what works and what should be adjusted to better accommodate the workflow and the project settings.

Final thoughts 

Accessibility can be successfully implemented in a large project. It requires a genuine commitment, understanding of the accessibility implementation and verification process, and delegation of responsibilities. The process described here is not a one-size-fits-all approach but rather a starting point to consider for your own process, practices, and tools. Once you get it rolling, please share your experience to help make the digital world more accessible for all.