Time | Item | Presenter | Notes |
---|
5 minutes | Checkbox Sizes | Kaleb Davenport | Notes: |
10 minutes
| Accessibility considerations for Expandable Input Groups
| Harper Wentz
| Some of our filtering options on edx.org have as many as 100 options. For example the Partner field could have many Schools and Companies that offer learning products. We want to ask what is the best approach for making these lists accessible? If we display the partners with the most results (instead of displaying them in alphabetical order) how should we indicate this to screen readers?
Notes: |
10 minutes | vertical variant for Stepper | Vladyslav Zadorozhnii | In the 2U MFE Studio project there is a task to rewrite this component to React. And they wanted to use stepper but there is no vertical variant for this. Should we customize stepper component to support vertical variant? Something like this: Notes: Disabled should use low contrast text Should not use color alone to represent state Needs some design thinking for the component Some pushback on the component usage/use case, consider stateful functionality
|
2 min | [inform] Form.Autosuggest accessibility | Max Frank | https://github.com/openedx/paragon/issues/2410 |
| Tailwind CSS? | | Notes: Some folks like Tailwind over Bootstrap Is there a route to using something other than Bootstrap Tailwind is an approach using utility classes and our design tokens project is a way for paragon to move towards it The conversation should be how not to be dependent on bootstrap, instead of making it more tailwind specifically https://tailwindcss.com/ Concern over conflicting CSS classes, javascript, and other resources driven by bootstrap We have a fragmented experience already today What are the advantages that Tailwind provides? What are the complaints associated with Bootstrap at 2U? Discovery for tailwind, maybe utility classes How do we support it on the design side? How to support in Figma Level of top down support
|