Re: Horizontal scrolling & reflow

Hi Everyone,
I always try to think how these scenarios would play out on a mobile phone.
The presentation is usually linear. So, there would be bands of content
that were either entirely vertical or entirely horizontal. Has anyone
looked at these cases on a phone?

Best Wayne

On Wed, Sep 5, 2018 at 9:34 AM Alastair Campbell <acampbell@nomensa.com>
wrote:

> Hi David,
>
>
>
> (Chair hat off btw, I intended to bring this to the group to check my (and
> everyone’s) understanding of this niche scenario.)
>
>
>
> > I don't remember discussion distinguishing content from a web page for
> the purposes of this SC.
>
>
>
> It was part of the internationalisation discussion, there’s a thread here:
>
> https://github.com/w3c/wcag21/issues/674
>
>
>
>
>
> > I think the intention is that western users should not have to
> horizontal scroll and Eastern LV users shouldn't have to vertically scroll.
>
>
>
> The problem is that within “eastern” pages there are likely to be *both*
> vertically and horizontally read / scrolled content. An example from that
> thread: http://tategaki.github.io/awards/  (I’m not saying that meets the
> SC, just that it demos multiple content directions. And: Vestibular trigger
> warning!) Or a complete page: https://www.chenhuijing.com/zh-type/
>
>
>
> Both CSS Grid and Flexbox layout methods have been designed to be
> reading-mode independent, i.e. work left-right and/or top-bottom. You can
> literally change a value or two and the whole layout switches direction!
>
> So the support is improving rapidly, and we were considering reading-mode
> during the SC development.
>
>
>
>
>
> > It is vertically scrolling page (Western languages) and adding
> horizontal for one paragraph would be 2 directions of scrolling so the only
> exception I can see in the SC is "Except for parts of the content which
> require two-dimensional layout for usage or meaning."
>
>
>
> The same SC is covering a lot of scenarios, the main four we’re thinking
> about here are:
>
>    1. Vertically scrolling pages which require horizontal scrolling
>    (unnecessarily)
>    2. Horizontally scrolling pages which require vertical scrolling
>    (unnecessarily)
>    3. Vertically scrolling pages with sections of horizontal scrolling
>    (necessarily for some languages)
>    4. Vertically scrolling pages with sections of horizontal scrolling
>    (for some interactive elements)
>
>
>
> So like a fishing net with particular shaped holes, we want to catch
> certain things but not others. We want to catch 1 & 2, not catch 3, and I
> think it is ok not to catch 4 if it fits the SC text. But that’s what I’m
> checking with the group: scenario 4.
>
>
>
> From a LV point of view, multi-direction scrolling can be confusing. Heck,
> it can be for anyone, but clear design & scroll bars can help with that.
> Where it is most problematic is where you cannot fit the entire element
> (block of text or otherwise) into the viewport as you scroll.
>
>
>
> I.e. A horizontally scrolling block of text or set of images is ok if it
> fits in the viewport as you scroll horizontally.
>
>
>
> So what I’m saying is: If you have a section of a vertically scrolling
> page that scrolls horizontally, it is ok if it fits with 256px high.
>
>
>
> I don’t think that will affect blocks of text very much, because in a 320
> x 256px view you can’t fit large blocks of text, the wrapping would go out
> of that area.
>
>
>
> What I’d like to avoid is banning (small) interactive elements that, as
> part of their interaction, use horizontal scrolling.
>
> E.g. one of the methods for having a toolbar that fits in a small view is
> to allow horizontal scrolling!
>
>
>
> It would be counter-productive to prevent techniques which help make
> zoomed-usage work.
>
>
>
> Cheers,
>
>
>
> -Alastair
>
>
>