2023-08-23 Meeting 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:

Next steps:

• https://github.com/openedx/frontend-template-application/pull/641

• Documentation in Paragon README

• Present/inform at 2U’s Solution Review

• Present/inform at FWG.

• Inform in various Slack channels (in Open edX and internal 2U Slack channels).

• Argument only usage

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:

• See discussion on the PR here:

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.