Skip to content
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

Closed
boazsender opened this issue Dec 5, 2020 · 5 comments
Closed

Comments

@boazsender
Copy link
Contributor

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.

@boazsender boazsender changed the title Scope of rendering tech in Open UI (e.g. Responsive and Inclusive Design) Scope of rendering environments in Open UI (e.g. Responsive Design) Dec 5, 2020
@mrmckeb
Copy link
Collaborator

mrmckeb commented Dec 9, 2020

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.

@gregwhitworth
Copy link
Member

@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.

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?

So ultimately I would expect it to cover ALL of them where they impact behavior, state or anatomy.

@una una added the agenda+ Use this label if you'd like the topic to be added to the meeting agenda label Jan 11, 2021
@ericwbailey
Copy link
Collaborator

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.

@gregwhitworth
Copy link
Member

@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.

@gregwhitworth gregwhitworth removed the agenda+ Use this label if you'd like the topic to be added to the meeting agenda label Feb 2, 2021
@boazsender
Copy link
Contributor Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants