2023-08-23 Meeting notes

 Date

Aug 23, 2023

 Participants

  • @Adam Stankiewicz

 Goals

  •  

 Discussion topics

Time

Item

Presenter

Notes

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:

{ "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

Form.Autosuggest Accessibility - Label Association · Issue #2436 · openedx/paragon

  • 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: feat: add attributes to input and wrapper component by httpsmenahassan · Pull Request #2570 · openedx/paragon
^ 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.

 Action items

 Decisions