Figma Carbon coverage plugin design exploration II

[RichKummer]

Figma design exploration

Prototype logic breakdown

This exploration phase will focus on refining the different options within the assistant flow.

Some refinement considerations:

• We likely need a way for designers to manually run the plugin each time, otherwise the plugin could be too resource intensive.
• Status icons have restrictions on sizing.
• Do we need special messaging for using v10 components vs unrelated Carbon components?
• Could we include ways for designers to "ignore" certain messages (ex. a C4IP component triggers a warning, but it isn't actually an issue for Carbon coverage)?
• How might we weight different issues in a snapshot?
• How can we bucket different issues together instead of showing a long list.
• We might consider using Figma’s UI instead of Carbon to better make use of the plugin space.
  • https://yuanqing.github.io/create-figma-plugin/ui/
  • Storybook

### Tasks
- [ ] Explore Figma plugin Preact component library
- [ ] Identify Figma plugin Preact components that could be used
- [ ] Prepare for WatsonX challenge workstream
- [ ] Refine design explorations, focusing on assistant flows
- [x] Connect with Accessibility checker team to refine and collect feedback
- [x] Continue research of related experiences
- [x] Research into prototype logic

Follow up tasks:

• [ ] Connect with Juan to refine and collect feedback
• [ ] Prioritize feedback messages/logic

[RichKummer]

Plugin non-Carbon highlight logic:

Based on current prototype code: https://github.com/theiliad/carbon-figma-lint-plugin/blob/main/src/main.ts#L42

Messages:

1. Overridden [Carbon] instance. Please reset changes
2. Instance is not a [Carbon] instance
3. Text is not using Carbon (if text style is mixed in a single text element)
4. Text Style is not from Carbon (if text is not mixed like above, but is still not Carbon).
5. Text Color style should only use surface/text or feedback/text tokens (checks text color styles and if they are not Carbon, triggers this message)
6. Use a Divider Component Instead
7. Effects not from Carbon's elevation styles
8. Box border color should only use surface/border/* tokens
9. Box not adhering to [Carbon] guidelines (shows up if element is not an image and doesn't have fill or stroke).
10. Use relevant Carbon component (checks this logic: Boolean(hasStrokes || hasEffects || hasFills) && !Boolean(traversedNode.fills === figma.mixed)
11. Not created using Carbon Components/Tokens (unclear, checks if node is not one of these types in the array, and then if its parent is not a page)

Could we check for v10 components and provide a focused message to swap to v11?

• We cannot check whether it’s v10, we’d have to put all the IDs of V10 into our code and add a separate check to shoot out that msg that you’re talking about.

[RichKummer]

Access checker feedback 06/28/24

Jess Lin & Tom Brunet

Carbon coverage plugin

• Consider that you could have a node that has multiple issues (for example a text node that does not have a type token OR a color token).
• Is the same item repeated across instances in a design? For example, if I have multiple screens and the same element has the wrong type token on all screens, expecting it to show up multiple times.
• Asked if we could automate the swap from v10 to v11? (Likely we will be limited at the start.
• We want to put our focus on v11 and migrating to v11, so it’s safe to focus on that.
• There is an opportunity to provide guidance in the future - for example, highlighting an accordion that uses left and right alignment in the same group.
  • Could we provide guidance around how components interact on a page? For example, a modal that has a button overlaying it in the wrong area? (Probably not for launch, since those are both v11 components and would pass. But we should consider guidance messaging in the future).
  • Could prompt manual review - ‘How are you using this together?’
• Would expect the name of the plugin to be Carbon Coverage v11 at the start. Then change the name when it expands to check other libraries.
  • Interested in checking for more than the v11 library (at the same time when scanning ideally, but even one at a time).
  • With the plugin, could you ask what they are working on in the plugin for more focused help?
• Could we call out a custom (local, non-library) component and ask to review with Carbon team?
  • Idea is to highlight a component for contribution to Carbon (this might be tricky, since much of the time it’s probably more of an error, but might link to contribution docs).
• The Access checker flags items as “need review” and allows hiding because people didn’t want to have to re-reviewing them in reviews.
  • For the Coverage plugin, we need to make sure hiding an item persists between checks.
• Access checker has multiple views: organize by element, by rule (everything for a particular problem), or by requirement number (such as images needing alternatives).
  • Jess prefers going item-by-item to fix everything wrong. We might consider a way to change the view from “by node/item” to “by issue type”
    • Consider view content switcher or filtering - by node vs by issue type.
    • When working on design, Jess would prefer fixing an element/component for all its Carbon issues then moving on.
  • Would be useful to list the number of items in an issue type, or number of issues with a node. In the current design, this is in the (4) of the data table row label.
• Would be useful to mark designs or nodes that are not part of the design (would be useful for hiding).
  • Some items in a page might have floating elements that are not really part of the design, but leftover from explorations.
  • Even when checking within the design frames, might be useful. For example, in the prototype the focus is on the modal, not the background. So should be able to ignore messages around the background.

Access checker

• Access checker showed the items checked, then compared the passing with not passing of the checked items. There are items that are not checked on screen (in DOM, etc.).
  • The Access checker does not tell user they are skipping items, only focuses on checked items.
  • Some issues are not equally treated in accessibility. So the team separates into required, etc.
  • If users are in a hurry, they just focus on “Required”, not on the others.
    • If they know what to do.
• Early on with the Access checker, team had churn with product teams because they would go back to an early webpage and the v11 checker wasn’t helpful for a v10 file.
• For the Access checker, the team is adding more filters over time. Could be useful to think about adding more options to the Carbon Coverage plugin in the future.