ZX-calculus and accessibility

Suggested red and green colours

The ZX calculus has always been a red / green calculus. This can cause problems if authors use shades of red and green that are hard to distinguish for people with CVD. We present here shades of red and green that should be distinguishable by people with any form of CVD, will print clearly in greyscale, and satisfies the W3 web standards for contrast against black text.

This is black text against the preferred shade of red
This is black text against the preferred shade of green

For methodology and metrics see the Jupyter notebook here. Comments from the community are welcome, and should be directed to Hector Miller-Bakewell.

How to implement in LaTeX

Simply add the following two snippets of code to your preamble. The first defines the colours "zx_red" and "zx_green":

\definecolor{zx_red}{RGB}{232, 165, 165}
\definecolor{zx_green}{RGB}{216, 248, 216}
The second defines two node types "gn" and "rn" for use inside tikz diagrams:
\tikzstyle{gn}=[rectangle,rounded corners=0.8em,fill=zx_green,draw=Black,
  line width=0.8 pt,inner sep=3pt,minimum width=1.5em,minimum height=1.5em]
\tikzstyle{rn}=[rectangle,rounded corners=0.8em,fill=zx_red,draw=Black,
  line width=0.8 pt,inner sep=3pt,minimum width=1.5em,minimum height=1.5em]
We also encourage authors to demonstrate which colour is which. For example by including a tikz green node and red node immediately after first mentioning the colours:
  The ZX-calculus is built from red [red node] and green [green node] spiders.
Note that we encourage rounded rectangles over circles. And strongly encourage green Z nodes to be lighter in shade than red X nodes when printed in greyscale.

Alternative colours schemes:

The suggested colours above are by no means the only choice available. We require that contrast of black text against the colours is at least 4.5 under all CVD transformations, and suggest (but do not require) a lowest Delta-E value of at least 5. Here is another colour scheme suggested by the community:

This is black text against red
This is black text against green

Which passes the contrast test, but has a lower Delta-E than the suggested colours.

Livestreaming of workshops

There are many reasons that someone may be unable to make it to a workshop in person. Here we give some recommendations on how to run a livestream, so that these people can still participate in the scientific discourse.

Setting up a stream

Chairing a stream

There should always be a dedicated person whose task it is to manage the stream. This should also be on a rota, to spread the load and allow people to focus on the talks they are most interested in. The chair's duties include:

Note that those on the stream may well be in different timezones, so relative timings ("in 15 minutes") are preferred to absolute times ("at 2 o'clock".) Notes from previous conferences / livestreams are included in the sections below.

Notes from running a livestream during the ZX workshop, Grenoble 25-26 February 2019

The stream:

The set-up:

There were three types of session, all with slightly different set-ups.

  1. Talks with slides.
    • The webcam was pointed at the speaker, who was told where the field of view of the camera was and requested not to wander out of it. Speakers generally took this in their stride (or at least didn't appear visibly to be put off). The speaker's laptop was also connected to the Hangout and they shared their screen. This meant people on the Hangout could chose to full-screen either the slides or the picture of the speaker.

    • Dealing with audio feedback was an important issue. The full solutions on each laptop were the following:

      • Chair's laptop: connected to webcam, video and microphone set to capture from webcam, speakers on.

      • Speakers' laptop: connect to projector. Mute speakers before entering the Hangout. Once in, immediately mute microphone. Share screen (sometimes sharing only the application caused the Hangout to crash so generally 'share entire screen' was preferred). Then start slides as usual for a presentation.

    • Questions: sometimes the livestream could not hear questions from the audience. Asking the speaker to repeat any questions solved that. For questions from the livestream, either the chair read out questions written into the chat, or else livestream attendees unmuted their microphones and asked through the chair's laptop. It worked quite well to turn the laptop around to the speaker so they could see the video of the person asking the question. There was a direct line of sight between the speaker, the webcam, and the chair+laptop.

  2. Talks on the whiteboard.
    • Again the webcam was pointed at the speaker. This time, only the webcam image and sound was broadcast. This worked less well than slides talks. Challenges included getting the speaker to write large enough for the livestream to read, and to move the webcam around mid-talk to make sure the speaker and board were always in shot.

    • In general, the whiteboard did not come over well on the webcam, and almost all detail was lost.

    • One possible solution in future is to have a second person broadcasting from the speaker's location, who is copying the contents of the whiteboard onto their own laptop (eg using a digital pen) and sharing their screen.

  3. Discussion sessions.
    • For these sessions the livestream was projected onto the main screen, and the webcam positioned in front of it pointing at the audience. This enabled two-way communication and involvement of the livestream participants. If auto-switching of the livestream was disabled, someone (eg the chair) needed to manually click on whichever livestream person was speaking in order to put them into the main window. This seemed to work well and the audio in both directions enabled reasonably free discussions.


Final comment: HIGHLY RECOMMENDED that we move to make livestreaming a normal part of workshops within the community.

Home Tutorial Publications Accessibility Map PyZX Demo