Importance of Web Content Accessibility Guidelines (WCAG) 2.1 for Network Scientists and Students with Disabilities

[dpgiakatos]

Overview:

Web Content Accessibility Guidelines (WCAG) 2.1 are critical for ensuring that our website is inclusive and accessible to a diverse audience, including network scientists and students with disabilities. This issue outlines the importance of adhering to WCAG 2.1 standards and highlights specific challenges that individuals with disabilities may face when accessing visual content, such as line charts.

Why WCAG 2.1 Matters:

1. Inclusivity for All Users: WCAG 2.1 ensures that our website is designed to be accessible to individuals with various disabilities, including visual impairments. This inclusivity is fundamental to providing an equal opportunity for everyone to access and benefit from the content.
2. Enhancing User Experience for Network Scientists: Network scientists rely heavily on visual data representation, such as line charts, to analyze and interpret complex network structures. Adhering to WCAG 2.1 guidelines ensures that these visual elements are presented in a way that is perceptible to all users, regardless of their abilities.

Addressing Challenges for Users with Disabilities:

1. Colorblindness Considerations: Individuals with colorblindness may struggle to differentiate between certain colors in line charts. Following WCAG 2.1 guidelines, we can implement alternative methods such as patterns, labels, or textures to convey information, ensuring that color is not the sole means of conveying critical data.
2. Text Alternatives for Non-Text Content: Providing descriptive text alternatives for non-text content, including images and charts, is essential. This assists screen readers in conveying information to users with visual impairments, enabling them to understand the content and context of line charts.

Action Items:

• Ensure that all visual elements, particularly line charts, comply with WCAG 2.1 guidelines.
• Implement alternative methods for conveying information in line charts to accommodate users with colorblindness.
• Create a designated space, potentially in the footer (open for discussion), to house a button or menu (options) for opening the accessibility panel. This panel should facilitate various accessibility features, such as color adjustments for conditions like Deuteranopia. Implement the necessary functionality to trigger these changes seamlessly from the panel.
• Before commencing with the coding process, it is essential to provide mockups for discussion regarding the proposed UI changes. This step ensures alignment with the team and allows for feedback on the intended modifications.

Pre-Conclusion Guidelines:

Before creating any pull requests, please adhere to the following guidelines:

1. Discussion Prior to Pull Requests (Important): Do not create any pull request without prior discussion. Engage with the team to ensure alignment on proposed changes.
2. Understanding WCAG 2.1 Guidelines: Familiarize yourself with the WCAG 2.1 guidelines, which can be found here, before initiating the implementation process.

These guidelines are crucial to maintaining a collaborative and informed development process. Ensure that proposed changes are in line with our discussions and that you have a comprehensive understanding of the WCAG 2.1 guidelines for effective implementation.

Conclusion:

By prioritizing and implementing WCAG 2.1 guidelines, we are not only meeting regulatory requirements but also fostering an inclusive environment where network scientists and students with disabilities can engage with and benefit from the content on our website. This issue serves as a guide for understanding and addressing specific challenges related to visual content accessibility.

[MAVRICK-1]

Ensuring that visual elements, including line charts, comply with Web Content Accessibility Guidelines (WCAG) 2.1 is crucial for making content accessible to a wide range of users. Here are key considerations to make line charts WCAG-compliant:

1. Color Contrast:

   • Ensure sufficient color contrast between the lines, data points, and the background. This is critical for users with low vision or color blindness.

2. Text Alternatives:

   • Provide text alternatives or labels for each line and data point. Screen readers should convey the information accurately.

3. Interactive Features:

   • If the line chart is interactive, ensure that all interactive features are accessible via keyboard navigation. Users should be able to navigate through the chart and interact with it using only the keyboard.

4. Keyboard Access:

   • Ensure that keyboard-only users can access and understand the information presented in the line chart. Make sure interactive elements are focusable and have clear indicators.

5. Data Tables:

   • If the line chart includes complex data, consider providing a data table that accompanies the chart. This allows screen reader users to access the detailed information.

6. Avoid Red-Green Combinations:

   • Avoid using red-green combinations for lines, as this can be challenging for individuals with red-green colorblindness. Opt for color combinations that have higher contrast.

7. Use ARIA Roles:

   • Implement Accessible Rich Internet Applications (ARIA) roles to enhance the accessibility of dynamic content and interactive features within the chart.

8. Provide Descriptive Titles:

   • Include a descriptive title for the line chart. This helps screen reader users understand the context and purpose of the chart

By incorporating these considerations, enhance the accessibility on line charts, making them more inclusive for users with diverse abilities. Regular testing and user feedback are essential to ensure ongoing accessibility improvements.

[horizenight]

@dpgiakatos would like to work on this issue.

[dpgiakatos]

As a first step, let's concentrate on one rule—Low Vision Issue Rationale. My suggestion is to integrate a button into the Plotly ModeBar (check the example here: Plotly Configuration Options). This button would open a menu, allowing users to choose from the following categories:

• None (Full color perception)
• Protanopia (Complete red-green disability)
• Tritanopia (Complete blue-yellow disability)
• Achromatopsia (Complete color disability).

What are your thoughts on this approach?

[horizenight]

The above appraoch does sound good : but as per my research Plotly.js still does not have a built-in dropdown component for the modebar.

So approaches can be :

1. Plotly Configuration Options as they use the toggler button to toggle beteween different categories . This also opens to possibility of changing the icon with each click that changes the color and icon to signify(instead of dropdown) ( icons are subject to change )

   

2. A custom dropdown : like this

[dpgiakatos]

No, I don't think a dropdown button is a good idea, as it may confuse the user (they might perceive it as an action button rather than a help button). Instead, let's have a button in the modebar that opens a dialog (see example: Quasar Dialog) where the user can select the categories. This solution not only addresses the current issue but also provides an opportunity to incorporate additional accessibility features for the plot in the future.

Regarding colors, have you checked if Plotly provides palettes with colors specifically designed for the four categories (None, Protanopia, Tritanopia, Achromatopsia)? I haven't searched for it yet.

[horizenight]

As the above tasks require research and feasibility check will be updating this comment with research and breaking down the task : ) The Dialog Box approach is quite great and surely will be helpful in other accessibility features. Tasks :

• [ ] Map a DailogBox to mod button in modular through which we can modify the line chart colours ( minimal goal )
• [ ] Research if Plotly provides palettes with colours specifically designed for the four categories - [ ] Research accessibility options provided by Plotly ( would be addressed later )
• [ ] Alternatively: Research and generate a palette for the four categories

[dpgiakatos]

I agree with this approach to the tasks, except for the third point. Let's focus solely on colors for now.

[ArnabBCA]

Detailed Explanation on how I will Implement it :

A Seperate File example PlotyChartColor.js which will contain json object with

// PlotyChartColor.js
const colorPalettes = {
  "dark": [
    {
      "Protan": [// array of 10 colors],
      "Deutan": [// array of 10 colors],
      "Tritan": [// array of 10 colors]
    },
    {
      "Protan": [// array of 10 colors],
      "Deutan": [// array of 10 colors],
      "Tritan": [// array of 10 colors]
    },
    {
      "Protan": [// array of 10 colors],
      "Deutan": [// array of 10 colors],
      "Tritan": [// array of 10 colors]
    }
  ],
  "light": [
    {
      "Protan": [// array of 10 colors],
      "Deutan": [// array of 10 colors],
      "Tritan": [// array of 10 colors]
    },
    {
      "Protan": [// array of 10 colors],
      "Deutan": [// array of 10 colors],
      "Tritan": [// array of 10 colors]
    },
    {
      "Protan": [// array of 10 colors],
      "Deutan": [// array of 10 colors],
      "Tritan": [// array of 10 colors]
    }
  ]
};

module.exports = colorPalettes;

1. The colors will be taken from https://leonardocolor.io/ in the (Colors for data visualization) section the website offers color Palettes where we can select WCAG compliant colors and Different color categories with Different background colors Dark and Light (Black and White)

2. The color Palettes will consists of two categories beacuse we will have dark and light mode in the website #684

3. Then we will import it in the ReactiveChart.vue component will have to modify the layoutLocal function and add a property colorway: which is supported by ploty.js

4. Create a Dialog component https://quasar.dev/vue-components/dialog where the user will select the Color Categories "Protan", "Deutan", "Tritan" and "Default"

5. We will then map the colors and pass the array of colors colorway: and then we will watch a variable using vue watch and we will then run react() function to rerender and update the colors in the chart

6. We will the store the color preference in the local storage so that the user dont have to switch colors again.

7. The color Palettes will take affect on all line chart and pie chart (Mentis)

8. The Default colors will be the ploty.js Default colors if no color blind option is selected.

For Dicussion

9. The Dialog Component can be pot in the navbar. Like a dropdown Help > Accessibility or in the footer.

10. Currently The NetworkDelayChart.vue and RirCountrySunburstChart.vue these two is overiding the chart colors we have to remove the colors in these two components.

[ArnabBCA]

@dpgiakatos @mohamedawnallah pls review it.

[ArnabBCA]

A Demo of Default colors in Light (currently used by the website no color change is done) and Dark Theme

[dpgiakatos]

I think that @horizenight is working on this issue. So, @horizenight, do we have any progress?

[ArnabBCA]

I think that @horizenight is working on this issue. So, @horizenight, do we have any progress?

The issue was opened for a long time with no progress report. That's why

[ArnabBCA]

@dpgiakatos is the dark theme Looking good?

[dpgiakatos]

There is no rush for this issue, as it is an app enhancement. Let's wait for his reply first, and we'll proceed accordingly. Also, @ArnabBCA, please do not implement anything without being assigned first.

[dpgiakatos]

@dpgiakatos is the dark theme Looking good?

The dark theme should also be combined with the corresponding palettes. As mentioned, it is already an issue #684, but it is also connected to this issue. So, if @horizenight has made some progress on this issue, then you might work together on the color palettes (dark theme and Low Vision Issue Rationale). In any case, we should wait for his reply first.

[horizenight]

Hello @dpgiakatos Thank you for waiting for my response, got really busy in college endeavours.

But here is my research finding:

1. While the minimal goal: is to find the correct way to represent the dialog box trigger button as to make it more accessible and intuitive. So after researching my opinion is to have a global button in navbar of the page so that we modify the setting for the whole website. The global accessibility controls give more intuition over localised control.

An example of this approach :

2. Color Pallete for the four categories: I really like Arnab's approach of defining a array ( with 10 colors that are acceptable for that category) of the colors and passing that to the plotly component, as it gives more customisation.

This source defines the colors we can use in the pallete for each category: https://mk.bcgsc.ca/colorblind/palettes.mhtml#projecthome

For Discussion:

1. How many colors are needed in each category?

[dpgiakatos]

Nice article! Let's go with the 24-color palette. Additionally, let's add a temporary button in the footer (subject to discussion with other maintainers for potential changes later) that will open a dialog. This dialog will allow users to switch between light/dark themes and between color palettes for color blindness.

Also, @horizenight and @ArnabBCA, would you like to collaborate on addressing issues #684 and #709?

[ArnabBCA]

Nice article! Let's go with the 24-color palette. Additionally, let's add a temporary button in the footer (subject to discussion with other maintainers for potential changes later) that will open a dialog. This dialog will allow users to switch between light/dark themes and between color palettes for color blindness.

Also, @horizenight and @ArnabBCA, would you like to collaborate on addressing issues #684 and #709?

Yes ,I would like collaborate on this issue i will provide the background colors and he can generate the color palettes based on that. After he as implemented the preferences Dialog and toggle colors based on the preferences i can make make it toggle based on the theme.

[dpgiakatos]

I am closing this issue as it has been inactive for a long time with no reported progress. While accessibility for our website is important, we will address it comprehensively after internal discussion.