Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Time

Item

Presenter

Notes

10 minutes

Paragon CLI: install-theme

Adam Stankiewicz

[inform/demo] We recently released a new Paragon CLI. It comes with a single command to start: paragon install-theme

Allows consumers to install and use a custom @edx/brand aliased NPM package during local development without risking modifying/committing changes to the default installed @edx/brand-openedx package.

Example:

Code Block
languagejson
{
  "scripts": {
    "build:with-theme": "paragon install-theme && npm build",
    "start:with-theme": "paragon install-theme && npm start",
  }
}

Next steps:

Future CLI ideas:

Our roadmap includes:

  • Porting over existing CLI tools into the new Paragon CLI as additional commands.

    • Component generator

    • [design tokens] SCSS variables → CSS variables migration

  • Tracking Segment events when these CLI commands are used by consumers.

  • Automated migrations for consumers (i.e., dealing with breaking changes).

Notes:

  • 10 min

Label association

Mena Hassan

https://github.com/openedx/paragon/issues/2436

  • Can we move forward with the proposed fix?

  • How do we feel about labels?

  • Would be good to know if there's a preferred pattern or are we going to just need to make some exceptions here?

    • When we make exceptions, what's the criteria for that?

Notes:

  • [Jeff] each control has to have an accessible name, how prescriptive should it be? Don't let people screw up … and be more opinionated about it.

  • [Adam] Side note: TextFilter uses deprecated Input component (source).

  • Next steps:

    • We should document the options/requirements (more like a formal component proposal). Bring back to PWG.


5 mins

Form.Autosuggest Attributes

Mena Hassan

Draft PR: https://github.com/openedx/paragon/pull/2570#
^ this relies on some previous changes so it looks a little move involved than it actually is.

Checking to see if everyone is generally ok with the proposed changes

Notes:

10 min

Floating labels & AutoSuggest

Jeff Witt

It’s weird, weird, and more weird.
- suggestion overwrite floating label (recent observation)
- Google moving floating label out of the way when there is a suggestion from the browser (how?)
- Chrome AutoSuggest positioning is different for different people
- Chrome AutoSuggest capture with Share Screen is different for different people

Requests:
- Use AutoComplete attribute with granular semantic values
- Use AutoComplete whenever possible
- Store form results (particularly user data) and auto-populate fields when possible (WCAG 2.2 requirement)
-

Notes:

  • Screen readers don’t always read out form input placeholders. Shouldn’t rely on placeholders for labeling.

  • Floating label acts as a both a placeholder and a label.

  • Why aren’t floating labels great?

    • Text is small.

    • Browser is getting sophisticated with more autocomplete functionality, and overlays its recommendations on top of the floating label.

  • UX/a11y has stopped recommending the use of floating labels.

    • Tentative guidance: deprecate floating labels.

      • Request from community: default to floated/open state.

  • The browser native autosuggest hides form control feedback.

    • To get around this, put error and hint text above the input, not below.

  • Seems to be different browser behavior related to autocomplete overlays, etc. for different users?

    • Chrome seems to move the autosuggest in some situations, but not all.

      • If this is the case, we may be able to stick with floating labels.

    • [question] Is there a way to style the Chrome default autocompletes/autosuggests?

      • Adam Stankiewicz to file a technical discovery issue to look into this. Can prioritize this.

      • Jeff Witt to try to document these permutations as well.

...