Reflow and diverging content behaviour desktop vs. mobile

[detlevhfischer]

There are cases where sites have content that does not reflow (content slider areas). I would assume such content would pass 1.4.10 Reflow when hidden chunks of content can be progressively brought into view through interaction (activating arrows, scroll bars). When such content is displayed in mobile browsers, the behaviour often differs: No controls or scrollbars, just swipe. This of course fails 2.5.1 Pointer Gestures - but what about Reflow?

If mobile was the benchmark, such a content slider would conceivably fail (because content could also be shown in one column). On desktop, it might pass due to controls for accessing hidden content.

Do we need to pin down the conditions (desktop / mobile) under which such content is evaluated? Does it fail if it fails in either of the environments (assuming that for most public-facing web content, the accessibility baseline will usually also include mobile devices / browsers)?

[patrickhlauke]

reflow does not mandate that everything be present without interaction / not hidden behind disclosure widgets, dropdowns, accordions, carousels. it just requires that content - when visible - doesn't cause two-dimensional scrolling. as such, i'd say it's unrelated.

[detlevhfischer]

@patrickhlauke I agree that 2.5.1 and 1.4.10 are unrelated, but that was not my point. Reflow requires that content can be presented without loss of information or functionality. When arrows for the slider are shown (desktop) that condition is met. When arrows are not shown (mobile browsers) that condition is not met. So I assume that the decision whether content passes or fails 1.4.10 is in this case down to the chosen accessibility baseline (are mobile UA included or not).

[patrickhlauke]

i think this is all mixing up various issues here. it's a failure of 2.5.1, and arguably 2.1.1 (if there's no other way for a keyboard user to activate/operate the carousel). i wouldn't say it's a failure of 1.4.10 reflow per se (as otherwise, with that logic, ANY other issue to do with things not working properly would also be a 1.4.10 issue, at which point this turns into a rather circular/catch-all SC when really it's about making sure content reflows appropriately to viewport without generating two-dimensional scrolling)

[detlevhfischer]

Well, leaving alone other SCs, if you assess whether content reflows and something like a slider doesn't, you would have to assess whether it is covered by the essential exception. Since slider content could easily be rendered as a vertical column, it doesn't really. If however there are elements to bring content into view (progressively), it wouldn't be so much different from a menu tucked away and displayed by activating a menu button - something that is clearly OK at 320px. So I still think the assessment whether content meets 1.4.10 Reflow can also depend on the availability of elements to bring tucked-away stuff into view.

[patrickhlauke]

but a carousel/slider isn't horizontal scrolling. it presents separate slides, whose content then would (unless i'm missing something) fit the 320px width. again, 1.4.10 doesn't prohibit things being hidden/refactored/turned into sliders/carousels/tabbed panels/accordions/etc.

[detlevhfischer]

Hm, well, it depends - the example I was thinking of is not separate slides - look at this page in the Zalando shop, in a desktop browser there are horizontally scrollable areas (e.g. under "Ähnliche Produkte"), in a mobile browser there are no scrollbars.

[patrickhlauke]

Yes, but these are still discrete individual "slides" that are as wide as the viewport and the content within each slide reflows. i.e. the user doesn't have to, say, scroll horizontally to read a whole sentence.