Curate JupyterLab themes

[isabela-pf]

Summary

Based on sprint planning discussions in #114. Related to #8 and more flexibility to these fixes.

Quoting from #114

"Curate extreme themes" (quoting @tonyfast) in jupyter/accessibility for JupyterLab. For example, high contrast theme, grayscale, and similar accessibility-oriented prompts.

Acceptance Criteria

We have at least two themes for JupyterLab developed around accessible prompts. (I could be convinced we should close this at one theme.) At least one of these needs to be the a WCAG contrast compliant set.

Tasks to complete

I think we need to iron this out if it gets added to a sprint.

[trallard]

• Workaround from Update UI with accessible color contrast jupyterlab/jupyterlab#8832
• 💡 Ideas
  • Default Jupyterlab to make it more accessible (light/dark)
  • Build on design patterns from deathbeds/jupyterlab-fonts
  • jupyter-contrib? or jupyter/accessibility-tools
  • can we make https://github.com/trallard/jupyterlab-pitaya-smoothie Jlab 3 compatible?

Is this UI specific or syntax highlighting too?

[isabela-pf]

At the JupyterLab accessibility call on June 29, 2022 we discussed some themes people might want so that we can begin collecting them. Here is the list pulled from the meeting notes:

• Colour-blind friendly - as many as possible?!
• Selective contrast
• Something that addresses Irlen syndrome needs
• Monochrome (could be changed to use different colors in the future)

I'd also like to add some other ideas based on additional discussions I've had over the past year or so.

• Low contrast
• "Classic" (or something) JupyterLab—meaning a theme that preserves it's current color palette and look
• Review if there's any guidance in the W3C working group for cognitive accessibility that we want to draw upon.

[isabela-pf]

One more thought! I gave quick look to what themes are already out there as JupyterLab extensions, and I'm finding none that are specifically accessibility focused and few that mention accessibility as a consideration. This means we can't rule any of the above prompts out based on them already existing in the community.

(If you find an example of this, though, I'd love to hear I'm wrong.)

[isabela-pf]

Based on further discussion, here's a first pass at some criteria I'd like to propose we a) review JupyterLab with and b) curate and review our theme extensions based on. It's all up for critique, but I'd like to request special attention to the Up for discussion section where I've put things that I suspect may be out of scope for an extension specifically.

WCAG 2.2 guidelines

Must be included

The following guidelines are the minimum scope I believe we should consider for labelling a default theme "accessible." Since I think they are required, I've abbreviated many of them for length's sake. Full text is available in the links.

• 1.3.3 Sensory characteristics - A. Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound.
• 1.4.1 Use of color- A. Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
• 1.4.3 Contrast (Minimum) - AA. The visual presentation of text and images of text has a contrast ratio of at least 4.5:1 (Except for large text, incidental uses, and logos).
• 1.4.5 Images of text - AA. Text is used to convey information rather than images of text (see link for exceptions).
• 1.4.6 Contrast (enhanced) - AAA. The visual presentation of text and images of text has a contrast ratio of at least 7:1 (Except for large text, incidental uses, and logos).
• 1.4.9 Images of text (no exception) AAA. Images of text are only used for pure decoration or where a particular presentation of text is essential to the information being conveyed.
• 1.4.11 Non-text contrast - AA. The visual presentation of user interface components and graphical objects have a contrast ratio of at least 3:1 against adjacent color(s).
• 2.3.3 Animation from interactions - AAA. Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed.
• 2.4.7 Focus visible - AA. Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
• 2.4.11 Focus appearance (minimum) - AA. When user interface components receive keyboard focus, all of the following are true:
  • Contrasting area: There is an area of the focus indicator that has a contrast ratio of at least 3:1 between the colors in the focused and unfocused states.
  • Minimum area: The contrasting area is at least as large as:
    • Outline: the area of a 1 CSS pixel thick perimeter of the unfocused component, or
    • Shape: the area of a 4 CSS pixel thick line along the shortest side of a minimum bounding box of the unfocused component, and no thinner than 2 CSS pixels.
  • Adjacent contrast: The contrasting area also has a contrast ratio of least 3:1 against adjacent colors in the focused component, or the contrasting area has a thickness of at least 2 CSS pixels.
  • Not fully obscured: The item with focus is not entirely hidden by author-created content.
• 2.4.12 Focus appearance (enhanced) - AAA. When user interface components have keyboard focus, all of the following are true:
  • Contrasting area: There is an area of the focus indicator that has a contrast ratio of at least 4.5:1 between the colors in the focused and unfocused states.
  • Minimum area: The contrasting area is at least double the area of a 1 CSS pixel perimeter of the unfocused component;
  • Not obscured: No part of the focus indicator is hidden by author-created content.
• 3.3.2 Labels or instructions - A. Labels or instructions are provided when content requires user input.

Reach goals

I would like to meet these guidelines, but given time and resource constraints I'm not confident we'll be able to yet. I do want them flagged as further work wherever these efforts live.

• 1.4.8 Visual presentation - AAA. For the visual presentation of blocks of text, a mechanism is available to achieve the following:
  • Foreground and background colors can be selected by the user.
  • Width is no more than 80 characters or glyphs (40 if CJK).
  • Text is not justified (aligned to both the left and the right margins).
  • Line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing.
  • Text can be resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text on a full-screen window.
• 1.4.12 Text spacing - AA. In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:
  • Line height (line spacing) to at least 1.5 times the font size;
  • Spacing following paragraphs to at least 2 times the font size;
  • Letter spacing (tracking) to at least 0.12 times the font size;
  • Word spacing to at least 0.16 times the font size.

Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.

Up for discussion

For the following guidelines, I'm unsure if they are within scope for a JuptyerLab theme extension. While they are all at least partially theming issues, they have some reason I'm not confident they fit our current goals.

For example, many of these would be repeat fixes across extensions which seems like an ineffective approach when compared to fixing it in core JupyterLab.

• 1.3.4 Orientation - AA. Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.
• 1.3.5 Identify input purpose - AA. The purpose of each input field collecting information about the user can be programmatically determined when:
  • The input field serves a purpose identified in the Input Purposes for user interface components section; and
  • The content is implemented using technologies with support for identifying the expected meaning for form input data.
• 1.3.6 Identify purpose - AAA. In content implemented using markup languages, the purpose of user interface components, icons, and regions can be programmatically determined.
• 1.4.4 Resize text - AA. Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.
• 1.4.10 Reflow - AA. Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:
  • Vertical scrolling content at a width equivalent to 320 CSS pixels;
  • Horizontal scrolling content at a height equivalent to 256 CSS pixels.

Except for parts of the content which require two-dimensional layout for usage or meaning.

• 1.4.13 Content on hover or focus - AA. Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:
  • Dismissible. A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
  • Hoverable. If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
  • Persistent. The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.

• 2.5.5 Target size (enhanced) - AAA. The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:

• Equivalent. The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;
• Inline. The target is in a sentence or block of text;
• User Agent Control. The size of the target is determined by the user agent and is not modified by the author;
• Essential. A particular presentation of the target is essential to the information being conveyed.

• 2.5.8 Target size (minimum) - AA. Targets have an area of at least 24 by 24 CSS pixels, except where:
  • Spacing: The target offset is at least 24 CSS pixels to every adjacent target;
  • Inline: The target is in a sentence or block of text;
  • Essential: A particular presentation of the target is essential to the information being conveyed.

Additional ideas to incorporate

As has been said many a time, WCAG is not the end-all list of efforts we can take. It is one of the easiest to reference for our use, though, and a good place to start when much of JupyterLab does not address those guidelines as-is.

The following are rough ideas of additional criteria we may want to include in our review and extensions.

• Are there unique recommendations from the W3C cognitive accessibility community group?
• Is it worth considering which elements use Pixels vs. ems to support better scaling UX?
• Do we want to switch all syntax highlighting out for a more accessible theme? Do we need to make it match each theme individually?
• I also think we should reference notebook accessibility toolbar extension for ideas on further criteria.
  • Have a styles manager built in to support customization on top of themes
  • They support light, dark, and high contrast themes

[isabela-pf]

Draft of the checklist version of this scope. Very subject to change, and will become a proper PR shortly.

[gabalafou]

I took a close look at this, and I think this needs to be flagged for focussed discussion in one of our team meetings.

The reason why is that I don't think I have enough knowledge at the moment about JupyterLab themes and stylesheets to really give this adequate review all by myself. I think to give this adequate review might need all of our combined expertise on this at the same time, asking each other questions in real time.

I think it would be super useful for me, for example, to go through the areas (WCAG guidelines) that you have identified one by one, and talk about whether or not we already have some thoughts about how we might address it via a JupyterLab theme extension.

[trallard]

From meeting on 2022-08-01

1. Are we all on the same page with what each item means?

• We are using this PR doc to align on vocabulary Quansight-Labs/accessibility@7696584?short_path=ae9e4a4#diff-ae9e4a46a307e3234480f0684742137952fb1d181184643f8c52753f5f8579e1

3. Does everything on the list fall in the scope of a JupyterLab extension?
4. Is there anything we want to add or remove?

• Syntax highlighting - new pygment theme will be left out of scope 🚫
• see Eric Bailey's themes https://github.com/ericwbailey/a11y-syntax-highlighting - but can be done at a later
• animation: let's mark for abandoning

---

📌 Refresher from grant deliverables: Work towards JupyterLab compliance with WCAG 2.1 requirements focused on low-vision and ambulatory users. In scope are:

1. Jupyter should be navigable by keyboard alone.
2. Support for 400% zoom.
3. Adequate colour contrast for interactive regions.
4. Work towards JupyterLab compliance with WCAG 2.1/2.2 guidelines, specifically focused on accessibility for blind users.

[isabela-pf]

Update: this discussion has moved to the main JupyterLab repo at JupyterLab #10004.