[7/28 CFM] Web editor improvement, a <set> component, <graph> axes

Discussion
,
1

In yesterday’s community feedback meeting, we discussed

  1. an ease-of-use improvement to the Doenet web editor
  2. the possibility of a <set> component
  3. tweaking the visual prominence of <graph> grid lines

Attendees: @Anurag_Katyal @Charles_Nykamp @Duane_Nykamp1 @Kris_Hollingsworth1 @Melissa_Lynn @Mike_Weimerskirch @Virginia_Mae

An ease-of-use improvement: scroll-to-component via a keyboard shortcut

Props to @Anurag_Katyal for this new feature. The dev version of the DoenetML editor allows you to scroll specifically to a component by Ctrl-clicking (Cmd-click on Mac). It works both ways: you can click on a rendered component or you can click a line in the editor.

One question that came up is: how are people supposed to find out you can do this?? We talked about adding an “A Tour of the Doenet Web Editor” page in the docs that goes through this ability and other tricks.

Brainstorming a <set> component

Prompted by @Carly_Vollet’s request, we brainstormed what it would look like to add a <set> component to DoenetML. Some topics that came up were:

  • Do we extend Doenet’s current components or make a new one?
  • What about people who want to add non-math items to a set?
  • How do we deal with intersections, unions, and subsets?

We generally agreed we should start with the most minimal functionality that satisfies the need, which seems to be: deduplication of elements. We thought about whether we could base the <set> tag off <group>.

Visual prominence of axes

@Kris_Hollingsworth1 proposed to make graph grid lines and axes less visually prominent in this thread. No objections, as long as the color contrast stays 4.5:1 for accessibility.

Join us next time

We’ll keep up a regular cadence of these meetings. The next one is in two weeks, same time and Zoom link. Anyone is welcome to join.

Tuesday, August 11
11am-noon Eastern
Zoom link

2

As a follow-up to our discussion on visual hierarchy for graph components, I confirmed that under WCAG 2.2 AA, the requirement for non-text elements (Success Criterion 1.4.11, Non-text Contrast remains a minimum 3:1 contrast ratio, not 4.5:1. This applies to meaningful graphical objects such as charts, graphs, and icons, as well as the visual boundaries and states of interactive UI components. Inactive controls and purely decorative elements are exempt. Based on this, I think allowing graph components such as axes and grid lines to fall within the 3:1-4.5:1 contrast range is both compliant and beneficial for maintaining visual hierarchy, while text labels can remain more prominent by meeting the higher 4.5:1 text contrast requirement. This approach supports accessibility without reducing the visual distinction between data elements and their labels.

3

Makes sense that the axes, tick marks, and grid need only 3:1.

I assume the axis tick labels, though, have to stay at 4.5:1, since they are text elements (and not large text).

1 Like