refine.bio refactoring and Web Accessibility

November 7, 2022

An excerpt from UNCG about web accessibility:

“IT’S BETTER FOR SOCIETY AND EVERYONE…It benefits society as a whole by allowing more people to be actively involved, contributing their ideas and point of views.”

In this blog post, I’d like to give an overview of the refine.bio refactoring process and web accessibility considerations. Through this process, our goal is to enhance the site usability and performance by improving the code quality and making the application more accessible. But before going into more details about them, let me provide you a quick history of refine.bio

A brief background of refine.bio

refine.bio is a cloud-based web application and one of the open-source projects maintained by the Data Lab. It’s designed to improve transcriptomic data accessibility and usability for pediatric cancer researchers of all technical backgrounds.

More specifically, a growing number of publicly available transcriptomic datasets (learn more in How does big data help us tackle childhood cancer?) are stored in various online repositories (e.g., GEO, ArrayExpress, SRA, ENA, DRA). refine.bio collects those datasets and harmonizes them using processing and normalization methods. That enables researchers to download and use normalized transcriptome data straight away in their own research without having to conduct their own pre-processing (Figure 1). This is especially helpful for researchers who have skills in analyzing data, but may not have the resources to process the raw expression data (learn more in Gene Expression Repositories Explained).

Figure 1

refine.bio now offers over 44k downloadable harmonized gene expression experiments and is still growing.

The Data Lab began the creation of refine.bio version 1 in 2017. While the current implementation works well and meets the needs of the end users, over the past year, we have been discussing ways to enhance existing features as well as exploring potential new features. Furthermore, we can now utilize new and better approaches to problem-solving by applying the lessons learned from the version 1 development.

Today, we're excited to inform you that the refine.bio refactoring process officially started in September of this year!

An overview of the refactoring workflow

The design and engineering teams play an integral role in the refine.bio development and I’m a part of the latter (learn more about How we integrate science and engineering). 

As mentioned earlier, in this refactoring process, the main objective of the engineering team is to enhance the user experience (UX) and to achieve better web performance by optimizing and improving the code quality. And the front end development primarily focuses on simplifying the codebase by incorporating a new tech stack and testing tools. As a front end engineer, I closely collaborate with our UX designer, Deepa (learn more about Strategies to center user needs for research tools) to ensure that all the necessary design considerations are reflected on the user interface (UI), and that includes web accessibility.

Why Web Accessibility matters

Accessibility (its numeronym is a11y) is the practice of designing inclusive environments or technologies to ensure their consistency and usability for all people regardless of their disabilities and socio-economic constraints.

Here is a remark made by Dr. Mohamed Jemni in his 2013  "Breaking the Silence" TED Talk:  

The disability is not the problem. The non-accessible environment and technology is the problem.”

Indeed, accessibility is not merely an ethical issue but also governed by the Americans with Disabilities Act (ADA) which applies to web technology as well. Thus, making an inclusive web application enables us to reach more people and communities, improve the application’s consistency and usability, and last but not least, meet ADA requirements.

At the Data Lab, we thoughtfully plan and develop refine.bio. By building this accessible open-source research tool, it allows us to make publicly available transcriptomic data easily obtainable to more researchers to help accelerate their research.

Web Content Accessibility Guidelines (WCAG)

WCAG are technical standards on web accessibility published by the World Wide Web Consortium (W3C), and we may reference this comprehensive document to improve the accessibility of web content.

The foundation of web accessibility is made up of 4 principles with 13 associated guidelines (Figure 2). 

Figure 2

3 Level of Conformance

To assess the level of WCAG compliance, 3 levels of testable success criteria are given for each guideline (Figure 3). In most cases, many organizations conform to Level AA, since according to WCAG Requirement 1, it’s not recommended that Level AAA conformance be required for it’s not possible to satisfy all Level AAA success criteria for some content.

Figure 3

WCAG Compliance for refine.bio (Practical Examples)

There are many ways in which we can make an accessible web application based on WCAG, and I’ll list a few practical considerations that could be applied immediately in front end development.

1. Build the Semantic Web Structure

Elements on a web page should have identifiable roles so that they can be understood by user agents (e.g., a browser) and assistive technologies (AT) (e.g., screen reader, screen magnifier, voice recognition software). In order to achieve this, we use the Accessible Rich Internet Applications Suite (WAI-ARIA) and semantic markup together (Figure 4).

Figure 4

Example: The landmark roles are used to properly assign identifiable roles to page regions so that they can be navigable by AT devices:

Each role also has inherited states and properties. If the same type of landmark is used more than once on the same page, we may use the “aria-label” attribute to differentiate them:

2. Write Accessible CSS

To style the layout and elements on the UI, we use Cascading Style Sheets (CSS). By designing the UI with appropriate CSS rules (e.g., font, color, spacing, visibility), we can make the UI more presentable and accessible.  

For instance, in the success criterion 1.4.3: Contrast under the Guideline 1.4 Distinguishable, in order to satisfy Level AA, color contrast of the visual presentation of text and text images should have the acceptable ratio defined as below (Figure 5):

Figure 5

When designing refine.bio’s custom color palettes, Deepa, our UX designer, carefully crafts them to make sure that they are accessible color combinations, so that they can be coded in CSS.

To manually verify color contrast, there are free color contrast accessibility validation tools available online such as a11y Color Contrast Accessibility Validator, Colour Contrast Checker CC, and Adobe Color Contrast Analyzer. Using these tools, we can test an existing web page, or individual color palettes. In addition, Deepa recommends Stark which is an accessibility plugin that can be installed in various web building software to help create accessible web applications.

3. Automate Web Accessibility Testing

It’s always good practice to select libraries and frameworks that have built-in web accessibility support, and there are various testing tools we can utilize as necessary. For example, as one of the front end tech stack, we are using Storybook which is a very popular design system that allows us to build UI components and pages in isolation. It comes with the a11y add-on, and with it, we can automate the accessibility testing to verify WCAG compliance not only at the page level, but also at the component level during development. 

Resources

Besides WCAG, there are many great resources available online for web accessibility. I’ll share some of them with you and hope you’ll find them helpful.

A11y-101

WebAIM

MDN

U.S Web Design System Gov

For further refine.bio updates, please visit our blog periodically and follow us on Twitter!

On this blog, we share our expertise with the scientific community. You can expect to read technical content about our processes, information about our products and services, and much more. Subscribe here to receive updates!

An excerpt from UNCG about web accessibility:

“IT’S BETTER FOR SOCIETY AND EVERYONE…It benefits society as a whole by allowing more people to be actively involved, contributing their ideas and point of views.”

In this blog post, I’d like to give an overview of the refine.bio refactoring process and web accessibility considerations. Through this process, our goal is to enhance the site usability and performance by improving the code quality and making the application more accessible. But before going into more details about them, let me provide you a quick history of refine.bio

A brief background of refine.bio

refine.bio is a cloud-based web application and one of the open-source projects maintained by the Data Lab. It’s designed to improve transcriptomic data accessibility and usability for pediatric cancer researchers of all technical backgrounds.

More specifically, a growing number of publicly available transcriptomic datasets (learn more in How does big data help us tackle childhood cancer?) are stored in various online repositories (e.g., GEO, ArrayExpress, SRA, ENA, DRA). refine.bio collects those datasets and harmonizes them using processing and normalization methods. That enables researchers to download and use normalized transcriptome data straight away in their own research without having to conduct their own pre-processing (Figure 1). This is especially helpful for researchers who have skills in analyzing data, but may not have the resources to process the raw expression data (learn more in Gene Expression Repositories Explained).

Figure 1

refine.bio now offers over 44k downloadable harmonized gene expression experiments and is still growing.

The Data Lab began the creation of refine.bio version 1 in 2017. While the current implementation works well and meets the needs of the end users, over the past year, we have been discussing ways to enhance existing features as well as exploring potential new features. Furthermore, we can now utilize new and better approaches to problem-solving by applying the lessons learned from the version 1 development.

Today, we're excited to inform you that the refine.bio refactoring process officially started in September of this year!

An overview of the refactoring workflow

The design and engineering teams play an integral role in the refine.bio development and I’m a part of the latter (learn more about How we integrate science and engineering). 

As mentioned earlier, in this refactoring process, the main objective of the engineering team is to enhance the user experience (UX) and to achieve better web performance by optimizing and improving the code quality. And the front end development primarily focuses on simplifying the codebase by incorporating a new tech stack and testing tools. As a front end engineer, I closely collaborate with our UX designer, Deepa (learn more about Strategies to center user needs for research tools) to ensure that all the necessary design considerations are reflected on the user interface (UI), and that includes web accessibility.

Why Web Accessibility matters

Accessibility (its numeronym is a11y) is the practice of designing inclusive environments or technologies to ensure their consistency and usability for all people regardless of their disabilities and socio-economic constraints.

Here is a remark made by Dr. Mohamed Jemni in his 2013  "Breaking the Silence" TED Talk:  

The disability is not the problem. The non-accessible environment and technology is the problem.”

Indeed, accessibility is not merely an ethical issue but also governed by the Americans with Disabilities Act (ADA) which applies to web technology as well. Thus, making an inclusive web application enables us to reach more people and communities, improve the application’s consistency and usability, and last but not least, meet ADA requirements.

At the Data Lab, we thoughtfully plan and develop refine.bio. By building this accessible open-source research tool, it allows us to make publicly available transcriptomic data easily obtainable to more researchers to help accelerate their research.

Web Content Accessibility Guidelines (WCAG)

WCAG are technical standards on web accessibility published by the World Wide Web Consortium (W3C), and we may reference this comprehensive document to improve the accessibility of web content.

The foundation of web accessibility is made up of 4 principles with 13 associated guidelines (Figure 2). 

Figure 2

3 Level of Conformance

To assess the level of WCAG compliance, 3 levels of testable success criteria are given for each guideline (Figure 3). In most cases, many organizations conform to Level AA, since according to WCAG Requirement 1, it’s not recommended that Level AAA conformance be required for it’s not possible to satisfy all Level AAA success criteria for some content.

Figure 3

WCAG Compliance for refine.bio (Practical Examples)

There are many ways in which we can make an accessible web application based on WCAG, and I’ll list a few practical considerations that could be applied immediately in front end development.

1. Build the Semantic Web Structure

Elements on a web page should have identifiable roles so that they can be understood by user agents (e.g., a browser) and assistive technologies (AT) (e.g., screen reader, screen magnifier, voice recognition software). In order to achieve this, we use the Accessible Rich Internet Applications Suite (WAI-ARIA) and semantic markup together (Figure 4).

Figure 4

Example: The landmark roles are used to properly assign identifiable roles to page regions so that they can be navigable by AT devices:

Each role also has inherited states and properties. If the same type of landmark is used more than once on the same page, we may use the “aria-label” attribute to differentiate them:

2. Write Accessible CSS

To style the layout and elements on the UI, we use Cascading Style Sheets (CSS). By designing the UI with appropriate CSS rules (e.g., font, color, spacing, visibility), we can make the UI more presentable and accessible.  

For instance, in the success criterion 1.4.3: Contrast under the Guideline 1.4 Distinguishable, in order to satisfy Level AA, color contrast of the visual presentation of text and text images should have the acceptable ratio defined as below (Figure 5):

Figure 5

When designing refine.bio’s custom color palettes, Deepa, our UX designer, carefully crafts them to make sure that they are accessible color combinations, so that they can be coded in CSS.

To manually verify color contrast, there are free color contrast accessibility validation tools available online such as a11y Color Contrast Accessibility Validator, Colour Contrast Checker CC, and Adobe Color Contrast Analyzer. Using these tools, we can test an existing web page, or individual color palettes. In addition, Deepa recommends Stark which is an accessibility plugin that can be installed in various web building software to help create accessible web applications.

3. Automate Web Accessibility Testing

It’s always good practice to select libraries and frameworks that have built-in web accessibility support, and there are various testing tools we can utilize as necessary. For example, as one of the front end tech stack, we are using Storybook which is a very popular design system that allows us to build UI components and pages in isolation. It comes with the a11y add-on, and with it, we can automate the accessibility testing to verify WCAG compliance not only at the page level, but also at the component level during development. 

Resources

Besides WCAG, there are many great resources available online for web accessibility. I’ll share some of them with you and hope you’ll find them helpful.

A11y-101

WebAIM

MDN

U.S Web Design System Gov

For further refine.bio updates, please visit our blog periodically and follow us on Twitter!

On this blog, we share our expertise with the scientific community. You can expect to read technical content about our processes, information about our products and services, and much more. Subscribe here to receive updates!

Back To Blog