-
Notifications
You must be signed in to change notification settings - Fork 200
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scope of rendering environments in Open UI (e.g. Responsive Design) #237
Comments
I feel that components should be able to adapt to the capabilities of the device they're on, and that we should consider touch/pen inputs and small screens where relevant. I also believe that we should continue to improve our accessibility coverage - braille displays are a great suggestion for how we could expand here. Personally, I would like web apps to look and feel the same regardless of your operating system or browser - only responding to capabilities. However, historically browsers and operating systems have influenced the way controls work, and I feel like that's not something that will change in the near future. I'm also not saying this is wrong either. TLDR; I believe that we should broaden our scope, but I'm concerned that it could conflict with the UX browsers/operating systems want for their users - and we need to consider that too. |
@boazsender The scope of Open UI does not restrict in any way any of those items. While most specs haven't added them I would not be supportive of promoting a spec that didn't have touch event listeners added for behavior implications. Braille & screen readers I would expect to be covered in the accessibility sections of the template. If there are gaps in proposals for certain types of ATs then definitely raise them and is within the scope. What the major issue that was raised during that call is that overflow and scrolling begin to get into CSS land and we've shied away from standardizing styles. That said, @una made the solid point that this is actually about behavior and that is within scope of Open UI and as such should be documented. How to go about that may be done in many different ways but anything that impacts behavior, states and anatomy should be included to produce a good control.
So ultimately I would expect it to cover ALL of them where they impact behavior, state or anatomy. |
This was my understanding of scope as well. It is also my hope that what we work on maps back to existing assistive technology mappings, and does not rely on things like defining new ARIA. |
@boazsender any issues with the above, as I'm tempted to close this out unless there is a concrete next step you're looking for that you feel a telecon resolution/discussion would help address. |
I'm happy with closing this. Would at some point like more clarity on how we specify responsive behavior across touch, keyboard/mouse, screen reader, and etc. Doesn't have to be here or now. Or maybe that's figured out and documented somewhere? |
This issue is a stub to discuss Open UI's scope for multiple rendering technologies.
Should Open UI components specify responsive behavior across multiple rendering environments? Desktop and laptop computers? Screen readers? Mobile devices? Braille displays? Touch screens? What is the scope of a component spec?
This came up during yesterday's weekly call (2020-12-03) in the context of #218, which suggests introducing default horizontal scrolling behavior for
<table>
elements on small screen devices.Folks on the call mentioned that this question of the scope of responsive design has come up for other components as well, including for example, proposals to adjust the default toggle state for
<details>
/<summary>
across different rendering environments.The text was updated successfully, but these errors were encountered: