You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My name is Greg Whitworth and I'm the co-chair of the Open UI CG. The goal of Open UI is to standardize the anatomy, model, states, behaviors and the subsequent implications (eg: state changes, model updates, etc) of controls and components. In doing this we'll produce a standardized blueprint for what makes up a specific control or component, whether you're a javascript author or on the web platform.
We hope by doing this we will begin to piece together the puzzle pieces that will allow the web platform to unlock capabilities that have not been possible which leaves web developers with little choice but to completely recreate controls and components, and as you all understand many times this comes with unfortunate gaps in accessibility.
In order to recreate these controls/components web developers have to do the same process that UAs need to do by bringing in all of the pieces from the HTML specification, CSS, ARIA & ARIA practices to implement a specific control. There is enough consistency of cow paths on the web to be able to define these controls/components in a way that still allows flexibility for styling and capability.
By standardized the anatomy and states it allows us to be very specific in what events should be tied to which parts and the implications of those events on the control's model. Here is the event table for the select: https://open-ui.org/components/select#events-1 (this is a first draft and is incomplete as we figure out the best way to show interactions may have different implications based on states of certain parts).
As noted, we know there are still gaps but I wanted to begin figuring how best to involve you all since you all have done a lot of investigation in this space and I'd like to ensure you all can provide your expertise.
My initial proposal would be to request those that are interested to join the community group and let me know and I'll at mention you in the accessibility issues or we can raise a duplicate issue here that joins the two groups together that works as well. Whatever works best for you all and aligns with your processes.
I apologize for the long post but I'd love to have any involvement you all are willing to provide. Please don't hesitate to ask any questions you may have. Thanks!
The text was updated successfully, but these errors were encountered:
Engagement with WIA-ARIA, have a few key reps to engage in Open UI issues. Who would like to be those reps that I pull in for any discussion regarding ARIA, Keyboard, etc?
Long term Open UI goals:
Be one single place that implementors (whether web platform or component library author) can go to in order to fully implement the control with relevant specifications updates where necessary (eg: see the 'open' state on select)
Over time, as Open UI matures slowly direct more authors from WIA-ARIA Practices to Open UI specs
The hope will also be that over time usage of the built-in components will increase and the need for authoring practices will only be leveraged by authors that replace the slotted defaults and don't provide a part equivalent
Hey everyone,
My name is Greg Whitworth and I'm the co-chair of the Open UI CG. The goal of Open UI is to standardize the anatomy, model, states, behaviors and the subsequent implications (eg: state changes, model updates, etc) of controls and components. In doing this we'll produce a standardized blueprint for what makes up a specific control or component, whether you're a javascript author or on the web platform.
We hope by doing this we will begin to piece together the puzzle pieces that will allow the web platform to unlock capabilities that have not been possible which leaves web developers with little choice but to completely recreate controls and components, and as you all understand many times this comes with unfortunate gaps in accessibility.
In order to recreate these controls/components web developers have to do the same process that UAs need to do by bringing in all of the pieces from the HTML specification, CSS, ARIA & ARIA practices to implement a specific control. There is enough consistency of cow paths on the web to be able to define these controls/components in a way that still allows flexibility for styling and capability.
You can read more about the problem and initial exploration in this blog post: https://gwhitworth.com/blog/2019/07/form-controls-components/
By standardized the anatomy and states it allows us to be very specific in what events should be tied to which parts and the implications of those events on the control's model. Here is the event table for the select: https://open-ui.org/components/select#events-1 (this is a first draft and is incomplete as we figure out the best way to show interactions may have different implications based on states of certain parts).
As noted, we know there are still gaps but I wanted to begin figuring how best to involve you all since you all have done a lot of investigation in this space and I'd like to ensure you all can provide your expertise.
My initial proposal would be to request those that are interested to join the community group and let me know and I'll at mention you in the accessibility issues or we can raise a duplicate issue here that joins the two groups together that works as well. Whatever works best for you all and aligns with your processes.
I apologize for the long post but I'd love to have any involvement you all are willing to provide. Please don't hesitate to ask any questions you may have. Thanks!
The text was updated successfully, but these errors were encountered: