[WIP]: Theming checklist

[isabela-pf]

This PR adds the draft theming checklist that I'm using to review current JupyterLab theming and our own work. I expect it to change. I am opening this for transparency.

Related to quansight-labs/jupyter-a11y-mgmt #133.

[isabela-pf]

I'm not sure if this fits as a new file in the PR or not, so I'm posting it here to keep the use of this checklist consolidated for now.

JupyterLab 3.2.0 on Binder (July 12)

Truncated version of the checklist with an emphasis on non-color review.

Percievable

• Instructions for understanding and operating content do not rely solely on 1.3.3
  • shape
  • color
  • size
  • visual location
    • They may rely on proximity to other content?
  • orientation
  • sound
    • JupyterLab doesn't use sound.
    • This is about ensuring that there are text versions of instructions, but I'm not sure how to check this at a high-level.
• Color is not the only means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.[1.4.1]
• Text has a contrast ratio of at least 4.5:1 (Except for large text, incidental uses, and logos). 1.4.3
  • Contrast ratio is at least 7:1 (Except for large text, incidental uses, and logos). 1.4.6
• Text is used to convey information, rather than images of text. See guidelines for exceptions. 1.4.5 and 1.4.9
  • The only images I can find with text are PDF and Markdown file icons, as well as kernels launcher cards with letter names (ie. C++ and R). I consider these logos, and the information is represented directly next to them.
• User interface components and graphics have a contrast ratio of at least 3:1 against adjacent color(s). 1.4.11
• When a measurement should scale with text size, it is measured in ems. When a measurement should not scale with text size, it is measured in px. Source
  • I haven't found a good way to check this without reviewing components one by one, which is untenable.
• Syntax highlighting has a contrast ratio of at least 4.5:1
• Red and green are not used adjacent to one another or to convey opposite information unless they are labelled with non-color versions of the information at every instance

Operable

• Animations tirggered by interaction can be disabled (see guidelines for exceptions). 2.3.3.
  • There is no setting to turn this off, but there are few animations. We have the loading logo, the "simple" mode toggle, maybe progress bar (I can't trigger one), and extension side bar expand/collapse.
• There is a visible focus indicator. 2.4.7
  • There is not! Some areas, like Launcher cards, have both hover and focus states that can be triggered. These may be used for reference. List items have hover but not focus. Most buttons and tabs have hover but not focus.
• Visible focus indicators have (2.4.11 and 2.4.12)
  • A contrast ratio of at least 3:1 between focused and unfocused states.
    • A contrast ratio of 4.5:1 between focused and unfocused states.
      • Launcher card focus meets this without hover.
  • An area of either 1px thick perimeter of the unfocused component, or 4px thick line on the shortest side of the unfocused component.
    • Launcher card focus meets this.
  • A contrast ratio of at least 3:1 between the focused component and adjacent colors, or a thickness of at least 2px.
  • The focus indicator is not hidden by author-created content.
    • I don't know how to test this.
• The target for clickable areas is at least 24 by 24px. See guidelines for exceptions. 2.5.8
  • Question: is this measured in area? Or is it truly both dimensions need to be at least this?
  • Does not meet this: menu bar, file browser breadcrumbs, toc top bar, extension refresh button, tab close, cell collapser, in cell toc collapser, TOC paragraph link
  • Does meet this: side bar sections, new launcher (file browser), file browser top bar, file browser search, file browser sort, file browser items, everything in running tab, toc items, table of contents expanded extension button (enable/disable), extension collapser carrot, extension management buttons (about, update, install, etc.), debugger top bars, status bar buttons, tabs, notebook toolbar, one-line cell height, dialog button, dialog drop down
• The target for clickable areas is at least 44 by 44px. See guidelines for exceptions. 2.5.5
  - Most places are not meeting this.
  - Does meet this: launcher card, two-or-more line cells

Understandable

• Areas with user input have labels or instructions. 3.3.2
  • Cells never do. I feel like this is normal, though, and this somehow does not count.
  • I'm not sure how to be certain I've caught everything. See next item for further detail on what I checked.
  • Some things aren't clear on how they are activated (ie. debugger). This might be a stretch for the standard, but I think it's worth noting.
• Labels and instructions are persistent.
  • Does not meet this: "Search" bars in the file browser and extension tab and command palette, cell tags Add tag, Launcher
  • *Does meet this: Change kernel dialog, settings editor *
• All clickable areas have tool tips.
  • The following are areas without tool tips: menu bar, file browser search bar, file browser sort, running close all tabs (and probably shut down all), TOC items, the entire extensions section (or it has nondescriptive ones), running button in status bar, shield in status bar, launcher tab, settings tab, close tab, … in notebook toolbar, cell collpser, toc collapser, cells, deactivated buttons (I think this is allowed)

[steff456]

When a measurement should scale with text size, it is measured in ems. When a measurement should not scale with text size, it is measured in px. Source. I haven't found a good way to check this without reviewing components one by one, which is untenable.

So I started looking for some insight about the issue with ems/rems/px in multiple sites and it seems that it is really hard to just create rules that will work every time because each use case may be different.

My proposal is to start with an audit based on use cases focused in certain parts of the interface to detect particular cases where we will decide if it is best to use ems, rems or px and start fixing the shape and size of certain objects. For doing this audit we will first define the use cases, ej. behavior of the side bar and do the following tests:

1. Put the zoom at 200%
2. Put the zoom at 400%
3. Change the default value of text size from 16 to 30 in the web browser
4. Test with different screen sizes

The main goal will be to see how the side bar currently behaves and if it is usable and start gathering insights to see how we can start to fix the issues. We will need to mix the 4 points among each other to see different settings of the same use case, in this case the side bar.

[isabela-pf]

I added everyone's in-meeting feedback via suggestion so we have some history of the discussion stored for later. Please let me know if I missed anything.

[isabela-pf]

Suggested change

	400% zoom

1.4.10: Reflow