2022-11-16 Paragon Meeting notes

5-10

Slack Migration

@Gabriel Weinberg

• We cannot create a connected channel today, and edX slack shuts down at the end of the week.

Notes

• Impacts:

  • #paragon-working-group in edX Slack goes away.

  • #paragon-working-group exists in 2U Slack.

  • We can’t currently connect #paragon-working-group Slack channel to the Open edX Slack.

    • This is a known issue for other groups as well. IT is working towards a solution.

  • The weekly PWG meeting is not impacted.

  • The connected #paragon-working-group channel in Open edX may become read-only.

• Interim solutions:

  • Separate/duplicate channels in Slack temporarily.

• This is more of a concern for FWG than PWG in terms of Slack channel usage.

• Adolfo to bring up these issues with Feanil.

5 mins

Use of !important

@Jeff Witt

Should it be avoided?
Possible(??? needs research) a11y implications

Notes:

• Typically an anti-pattern.

• https://github.com/openedx/paragon/blob/master/docs/decisions/0012-css-styling-conventions#L19

• Should always be avoided in Paragon (see above link).

• MFEs/apps should also avoid, if possible.

  • May be needed to override a class that uses !important itself.

• eslint/stylelint might help us enforce this?

• Helping Jeff understand best practices, as there might potentially be a11y issues with !important.

• Can be avoided.

• Should this be only to Paragon? Or for MFEs, too?

  • It may be annoying, but it’d be for the best?

  • If we can ignore one-offs, this would help

  • It should be relevant for / impact all FED repos.

• [question] Are there other stylelint changes we could make? E.g., using hardcoded pixel values, etc.

5-10 mins

Button text casing-

@Hamzah Ullah

Should Button enforce/standardize text casing (e.g., sentence casing)?

Notes:

• Buttons with Proper nouns need to be capitalized.

• Brand standard for edX.org vs. Open edX vs. other brands/themes.

• Optional prop / default / opt-out?

• Goal: to an app-level configuration for button casing.

  • Is this a configurable option (e.g., via environment variable? runtime config?).

• Sentence case component?

  • Accepts only strings.

  • E.g., <Button><SentenceCase>Hello World</SentenceCase><Button>?

• formatting components might be a generally good thing for a design system to have

• other standard formats?

• Are there other casing rules/standardizations for other places? e.g., header menu items, etc.

• FormatCasing component (with options, e.g. sentenceCase)

• what about a Text component (for bold, italics, etc.)?

  • Are there other design systems that have a Text / Typography type of component we could use for inspiration here?

• Focus on simple strings, not nested components.

• Why do this?

  • If we want to enforce this sentence case pattern, it falls back to:

    • Designers needing to ensure their mocks have proper casing.

    • Engineers needing to ensure their implementation has proper casing.

    • It makes the stylistic pattern more enforceable during implementation.

    • It is a nice to have. But worth considering.

[curious] What % of users are impacted by a11y issues on edX.org? Do we have data along these lines?

(framing of the question is important)

• design system save engineering fixing a11y bugs

• it’s not just the implementation time, it’s all the time around process as well (e.g., ticketing, grooming, discussions, etc.).

• [Jeff] “design system catch nearly 50% of a11y issues”

• “No back row” (2U)

• “Cost of a11y is low single digit %”

  • “Above single digit % if being sued

• 12% into higher ed today have a disability of one or another

  • About 50% of these ask for some sort of accommodation, e.g., deadline extensions.

• Non-higher ed is > 12%

  • (most common diagnoses)

    • ADHD

    • dyslexia

    • depression

• The expensive things we do as engineers are for visually impaired users (e.g., screen readers).

• ~1-2% moderately vision impaired (cannot be corrected)

• TBD the specific data for edX.org.

• [Jeff W] “It’s not a nice to have. It’s either use it, or you have chaos.”

• Demonstrating ROI is useful to justify what we’re doing more so than we can today.

• Jeff has some budget for a11y audits in the next year or two.

  • How many engineer sprints will we end up spending on this?

  • What is the right approach to prioritize a11y fixes for audits?

• Ways to handle a11y:

  • Design (catch it early)

  • Engineering

  • Compliance (training)

@Ben Warzeski (Deactivated)

How do we prioritize tech debt?

There’s a lot of things in flight about how we will be doing things long-term.

How do we update older apps for newly adopted patterns? Should we?

Examples:

• A11y issues in Paragon

  • How do they get prioritized alongside new product/feature work?

  • [Jeff] If a11y isn’t absolutely necessary to ship something and it’s not accounted for, it’ll probably never get picked up.

  • [Adolfo] If we run into these types of issues, file an issue in frontend-wg Github and tCRIL (Adolfo) can help triage.

    • https://github.com/openedx/frontend-wg/

    • Folks in community are looking for small, clearly defined tasks. Smaller a11y issues could fit the bill.