Clarify toolbar exception in Understanding Reflow 1.4.10

[smhigley]

We've been having a lively discussion within some teams around Microsoft about the toolbar wording in Understanding Reflow's content exceptions, and what it means. It has mostly coalesced into two separate questions:

1. What is a toolbar? Is it only an element with role="toolbar", or anything that visually or functionally resembles a toolbar (e.g. any set of horizontal buttons that control nearby content)?

2. What is allowed to have a horizontal scrollbar when a toolbar is present? Is it the toolbar itself, or the toolbar along with the content it controls, or the entire UI of any site or app that contains a toolbar somewhere within it?

Part of the discussion comes from confusion around when a toolbar would require two-dimensional layout to preserve meaning or functionality. It's usually pretty simple to collapse overflowing toolbar actions into a "more actions" type menu without loosing meaning or function, and it's been hard to think of a practical example where this isn't the case (at least in my mental model of a toolbar). I think a practical example of a toolbar interface where reflow isn't possible could help clarify when to allow horizontal scroll, and when to reflow the toolbar actions.

For example, I imagine something simple like a rich text editor like the github comment textbox (or even the toolbar example in APG should not be an exception since reflow is possible without loosing meaning or function.

Anecdotally, the interfaces that have had the hardest time with the reflow requirement have not had trouble with toolbars, but with multiple panes of related content or interactivity -- e.g. an interface similar to Visual Studio or Photoshop where concurrent access to multiple related panels is fairly central to most users. It might possible to collapse everything but a single panel at any given time, but it's not necessarily a wonderful user experience. It's hard to draw the line on when or if two dimensional layout is necessary for usage in these cases though, since it's a slope of UI complexity rather than a single type of control. It would be great to have guidance on these types of interfaces as well, and whether they would ever fall under the two-dimensional
layout exception.

[WayneEDick]

Hi Sara, The most important part of the toolbar exemption is that it is for the toolbar only. One of the most common ways people with low vision are dragged into needing horizontal scrolling is when a toolbar drags dependent text off the page. That is prohibited by the SC. I don't think an actual specification of "toolbar" is necessary, though it might help in legal arguments. If you don't drag text controlled by the toolbar off the page, sane readers with low vision will be thrilled. Not required, but very usable: If it is ambiguous when a toolbar is truncated by the right border give the user an indicator that there is more content to see. I have missed many a control not thinking it is there. Best, Wayne

…

On Wed, Oct 9, 2019 at 11:14 AM Sarah Higley ***@***.***> wrote: We've been having a lively discussion within some teams around Microsoft about the toolbar wording in Understanding Reflow's content exceptions, and what it means. It has mostly coalesced into two separate questions: 1. What is a toolbar? Is it only an element with role="toolbar", or anything that visually or functionally resembles a toolbar (e.g. any set of horizontal buttons that control nearby content)? 2. What is allowed to have a horizontal scrollbar when a toolbar is present? Is it the toolbar itself, or the toolbar along with the content it controls, or the entire UI of any site or app that contains a toolbar somewhere within it? Part of the discussion comes from confusion around when a toolbar would require two-dimensional layout to preserve meaning or functionality. It's usually pretty simple to collapse overflowing toolbar actions into a "more actions" type menu without loosing meaning or function, and it's been hard to think of a practical example where this isn't the case (at least in my mental model of a toolbar). I think a practical example of a toolbar interface where reflow isn't possible could help clarify when to allow horizontal scroll, and when to reflow the toolbar actions. For example, I imagine something simple like a rich text editor like the github comment textbox (or even the toolbar example in APG <https://w3c.github.io/aria-practices/examples/toolbar/toolbar.html> should not be an exception since reflow is possible without loosing meaning or function. Anecdotally, the interfaces that have had the hardest time with the reflow requirement have not had trouble with toolbars, but with multiple panes of related content or interactivity -- e.g. an interface similar to Visual Studio or Photoshop where concurrent access to multiple related panels is fairly central to most users. It might possible to collapse everything but a single panel at any given time, but it's not necessarily a wonderful user experience. It's hard to draw the line on when or if two dimensional layout is necessary for usage in these cases though, since it's a slope of UI complexity rather than a single type of control. It would be great to have guidance on these types of interfaces as well, and whether they would ever fall under the two-dimensional layout exception. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#916?email_source=notifications&email_token=AB6Q4F33XZQH7RVMU63W7M3QNYNR3A5CNFSM4I7DADEKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HQW2GYQ>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6Q4F7OCPA4TD5PXSRSQ63QNYNR3ANCNFSM4I7DADEA> .

[JAWS-test]

What is a toolbar? Is it only an element with role="toolbar", or anything that visually or functionally resembles a toolbar (e.g. any set of horizontal buttons that control nearby content)?

I'm pretty sure: A toolbar does not need an ARIA role to be considered a toolbar according to this SC.

What is allowed to have a horizontal scrollbar when a toolbar is present? Is it the toolbar itself, or the toolbar along with the content it controls, or the entire UI of any site or app that contains a toolbar somewhere within it?

I think: If the content controlled by the toolbar falls under the exception itself and can be scrolled (e.g. an image in Photoshop), then one would only have to consider whether it is better to scroll the image and toolbar separately or together. On the one hand, many scrollbars can make the page confusing. On the other hand, separate scrolling can make work much easier.
If the remaining content is text (as in Word, for example), the toolbar should be wrapable or scrollable. The text must not be scrolled.

Part of the discussion comes from confusion around when a toolbar would require two-dimensional layout to preserve meaning or functionality. It's usually pretty simple to collapse overflowing toolbar actions into a "more actions" type menu without loosing meaning or function,

I think: If the buttons of the toolbar are no longer visible, but have to be shown first, then this is a limitation of function and meaning. In this case it can be better if the toolbar is scrollable. Scrolling is faster than showing the elements individually.

[alastc]

Hi @JAWS-test, your statements are giving the impression that 'this is the answer'. In the context of the guidelines and working group, we like to allow for discussion and then (if nothing has fallen out as the obvious answer) come to a consensus position.

It would help to preface comments with "in my opinion", or "the SC text says X which I interpret as Y", or "previously the group has said...". I just don't want people reading this to confuse one person's view with the group position. (My own included!)

So to answer @smhigley:

What is a toolbar?

The exception is written as:

Examples of content which require two-dimensional layout are ... interfaces where it is necessary to keep toolbars in view while manipulating content.

It isn't the toolbar as such, it is having one or more toolbars (or panels etc) that need to be is view whilst manipulating something else. Like the photoshop example you mentioned later, there are physical limits with having content on screen and having a toolbar (or something) on screen at the same time, that may not be possible without scrolling.

I think a practical example of a toolbar interface where reflow isn't possible could help clarify when to allow horizontal scroll, and when to reflow the toolbar actions.

One of the original examples that led to the wording was presentation software, where you have a 2D content area (that may require scrolling itself), and then toolbars to the top and/or left of that. If you assume a certain amount of content is needed on screen, plus the ability to choose tools to act on that content, that may require more width than 320px.

What is allowed to have a horizontal scrollbar when a toolbar is present?

It was phrased "Content can be presented without loss of..." to convey that only the content meeting the 2D exception would scroll, not the page. In practical terms that means putting a slide, toolbar (or data table, image etc) in a wrapper with it's own overflow & scrollbar, rather than making the whole page scroll.

If the application itself (like a presentation creator app) fills the screen and has sub-scrolling elements, it would be those bits of content that are scrolling themselves anyway. However, the same SC applies to long scrolling pages that have a 2D item on them (like this editor I'm typing into). In that case it makes much more difference to a user, who might have to scroll to read just because another item on the page requires scrolling.

[smhigley]

@WayneEDick and @alastc thanks for the clarification! It's nice to know both that "toolbar" is a fairly permissive term, and that allowed overflow is generally confined to the toolbar itself. The presentation creator app example is also really helpful -- we've actually discussed how reflow would apply to exactly that type of app 😄.

Would there be any possibility of getting some of this into the Understanding doc? As much as I'd love to point teams to this issue, I think the Understanding page would have a bit more authority :).

If I were to choose specific parts to update, changing this line:

This Success Criterion therefore does not apply to interfaces which provide toolbars.

to clarify that the SC only allows a second scrollbar within the toolbar itself + adding a presentation creator example to the Examples section would be first on my wishlist, and clear up a lot of the discussions we've had about this.

Thanks again! This has been an interesting SC to dive into, particularly on the very app-y web apps.

[mraccess77]

If I have a horizontal menu or toolbar (such as those found in a desktop application) does that menu or toolbar have to meet this requirement? Does it fall under and exception or not? It's not clear if the toolbar or menu bar needs to collapse or not. The toolbar itself doesn't require two dimensions to access - only 1 - horizontal and thus it seems the SC would not apply. If it were a 2d menu structure then that could be different. That is - do we evaluate something like a horizontally scrolling tab bar as it's own content and thus the SC doesn't apply or do we consider the tab bar part of the page content and consider the tab bar and associated content as one content block thus causing the SC to be applicable?

[scottaohara]

closing this issue as resolved per the updates made in #4055. I'm sure there's further examples/techniques that could be made on this topic - but I'd suggest we open a new issue for those as needed.