Semantic conveyed through Indented UI and Reflow 1.4.10 #887

cscrosati · 2019-09-05T19:14:14Z

Could it be that indented UI where the indent has meaning qualifies as an exception in the 1.4.10 Reflow requirement? Indentation conveys a lot of meaning visually that isn't color based, so it seems like this is a suitable exception when used as part of a control or UI that uses indentation.

I believe this is covered by the sentence

"Except for parts of the content which require two-dimensional layout for usage or meaning."

but I want to confirm this is correct in my interpretation. It might also be good to add this to the exception examples.

Here are a couple examples I have encountered recently:

Example 1: Indented List (or could be a system file picker, or a TreeView control)

This is level 1
- This is level 2
  - This is level 3
    - This is level 4
      - This is level 5
        
        This is level 6
        
        This is level 7
        
        Eventually deeper levels get quite indented. Making them flat level removes a lot of context that is visually conveyed without color change needed, nor text styling specifics.

Example 2: Sample code as text, imagine this gets very deeply indented, like in Chrome Dev tools Elements tab for example.

<html>
    <head>
    </head>
    <body>
        <div>
            <!-- ...... keep indenting more stuff in here -->
        </div>
    </body>
</html>

Note that for example 2 this could be managed by allowing the overflowing indented content to return to the beginning of the content area, but then the indent itself might be overflowing, or the content text becomes so long that it becomes difficult to identify the level of indentation without referring to the text backward from the current point of reading. You can understand better what I'm typing here by opening the Chrome Dev tools Elements pane in a moderately complex web page, with the Word Wrap setting enabled. Things get lost at deeper level.

Thoughts?

The text was updated successfully, but these errors were encountered:

JAWS-test · 2019-09-05T20:58:35Z

I think the examples fall under mentioned the exception: "require two-dimensional layout for usage or meaning"
But I think that only applies to the indentation. The entries themselves can wrap, as long as they have enough space to the right margin. I.e. the area should not be designed with a fixed width.
In addition, the indentation should be designed in such a way that it is easy to see but does not take up too much space.
In this respect, it is probably quite subjective at which point such elements violate 1.4.10

mraccess77 · 2019-09-06T17:19:24Z

This discussion came up with code samples as well and I believe there are ways to make a pre tag wrap as well as the list items should be able to wrap. As for indention -- a settings for different indention spacing or identifiers could be used -- so I'm not sure (personal opinion) if it falls into the exception.

WayneEDick · 2019-09-07T18:34:17Z

To All, Lists are a problem. The problem is that indentation in the large print realm is less valuable than space. There are a couple of ways to handle this that meet 1.4.10. 1. Use a smaller indentation as the CSS pixel width decreases. That is at each breakpoint decide: what is a visible and non-disruptive indentation size. Remember 1 em is a hell of a lot more visible at 400% than it at 100%. 2. Require users to move list items to the left margin to see entire lines, but never require users to horizontally scroll text within a list item. That should do it. The key thing to avoid is line-by-line horizontal scrolling. Those are the scrolls that cost enormous operational overhead. Best, Wayne

…

On Fri, Sep 6, 2019 at 10:19 AM Jonathan Avila ***@***.***> wrote: This discussion came up with code samples as well and I believe there are ways to make a pre tag wrap as well as the list items should be able to wrap. As for indention -- a settings for different indention spacing or identifiers could be used -- so I'm not sure (personal opinion) if it falls into the exception. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#887?email_source=notifications&email_token=AB6Q4F2SJTZBXGARMBMAAC3QIKGKBA5CNFSM4IUBPHUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6DPQCI#issuecomment-528939017>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB6Q4F5CSREL2WWO75KNWBLQIKGKBANCNFSM4IUBPHUA> .

JAWS-test · 2019-09-08T03:05:10Z

There are contents that have to be scrolled already without zoom. These can be the above examples, but also tables and other exceptions mentioned in 1.4.10. At 400% they have to be scrolled 4x more (if no layout changes take place). The question now would be: Is it a violation of 1.4.10 that content to be scrolled has to be scrolled 4x more (it can also be much more than 4x more, because at 400% zoom you have to scroll entries that are still perceptible at 100% without scrolling, because at 100% only a few entries have to be scrolled to read them)? I think, according to the wording of 1.4.10: no. Although according to the intentions of the WCAG it should be: Yes.

I think that's a difficult question. If here in the discussion an answer to it is found (or one has already been found in previous ones), I suggest adding this to the Understanding to 1.4.10

patrickhlauke · 2019-09-08T08:50:28Z

There are contents that have to be scrolled already without zoom

but those are not covered by the SC. more specifically: the SC only cares about (currently) when the viewport/browser window is 320 CSS px for a page that is primarily vertical-scrolling content / 256 CSS px for a page that is primarily horizontal-scrolling content.

if stuff already causes two-directional scrolling at larger other viewport sizes, that's not the current concern of the SC (however, as it's likely that if it already requires bi-directional scrolling in a large viewport, it will also require scrolling - even more or not - at zoom / smaller viewport, it's still a failure anyway - just that the failure is framed as "at the small viewport, this happens")

In theory, a page could have bi-directional scrolling happening all the time, EXCEPT at the very specific 320 CSS px width or 256 CSS px height. like a super-specific media query. that is, of course, a loophole. see #698

jake-abma · 2019-09-08T13:00:34Z

besides the loophole, if the indent has meaning where reflow is not possible / looses the meaning, it's an exception indeed.

alastc · 2019-09-30T09:38:13Z

If the indentation is "required ... for usage or meaning", then it would fit the exception. However, if there are valid techniques for showing the meaning without (as much) indentation then it wouldn't be required.

Wayne has discussed and sent in such a technique (which I have in my backlog to put into github and raise on a survey).

We know there are techniques for dealing with things like tables and code markup in better ways that aren't currently required by reflow, so it's an area we can tighten up on in future.

mraccess77 · 2021-05-11T18:08:37Z

So are code blocks exempted from 1.4.10 or not?

patrickhlauke · 2021-05-11T19:14:33Z

So are code blocks exempted from 1.4.10 or not?

you can force a particular line break/presentation of code blocks without altering their actual structure/indentation when copy-pasting, but for languages where indentation actually carries meaning (like python) it might still make it unreadable/confusing for somebody just looking at the code block directly on the page (rather than copy/pasting it into anything)

edit: so to be clear, i'd say "it depends" on what you're showing in the code blocks. if it still makes structural sense even if forcibly displayed as wrapping, not exempt. if it's for something where the indentation is meaningful (rather than a presentational convention/quirk, i.e. html elements are still nested correctly even without any indentation, but for python the indentation does matter/has the same meaningful role as braces in most other programming languages) then that situation would be exempt

mraccess77 · 2021-05-12T01:01:27Z

I take it the answer is you have to wrap code unless wrapping would change the meaning and lose critical information from the indention. So yes it is applicable, but with exceptions very specific languages.

patrickhlauke · 2021-05-12T01:21:34Z

put succinctly, yes (in my view)

alastc · 2021-05-12T11:34:50Z

The understanding doc has a section for content exceptions. Perhaps we could add something like:

The presentation of code where the layout has specific meaning (such as indentation for Python) would loose meaning if that layout were not presented correctly. Therefore this Success Criterion does not apply where that meaning would be lost. However, this is not the case for many languages where wrapping can be applied without loosing meaning.

including / expanding on the final comment in 887 - #887 (comment)

alastc added Discussion WCAG 2.1 labels Sep 30, 2019

alastc added the 1.4.10 Reflow label Oct 11, 2019

scottaohara added a commit that referenced this issue Oct 23, 2024

addressing issue 887

9dcfcbd

including / expanding on the final comment in 887 - #887 (comment)

scottaohara mentioned this issue Oct 24, 2024

Updated Reflow understanding doc #4055

Draft

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Semantic conveyed through Indented UI and Reflow 1.4.10 #887

Semantic conveyed through Indented UI and Reflow 1.4.10 #887

cscrosati commented Sep 5, 2019

JAWS-test commented Sep 5, 2019 •

edited

Loading

mraccess77 commented Sep 6, 2019

WayneEDick commented Sep 7, 2019 via email

JAWS-test commented Sep 8, 2019 •

edited

Loading

patrickhlauke commented Sep 8, 2019

jake-abma commented Sep 8, 2019

alastc commented Sep 30, 2019

mraccess77 commented May 11, 2021

patrickhlauke commented May 11, 2021 •

edited

Loading

mraccess77 commented May 12, 2021

patrickhlauke commented May 12, 2021

alastc commented May 12, 2021

Semantic conveyed through Indented UI and Reflow 1.4.10 #887

Semantic conveyed through Indented UI and Reflow 1.4.10 #887

Comments

cscrosati commented Sep 5, 2019

JAWS-test commented Sep 5, 2019 • edited Loading

mraccess77 commented Sep 6, 2019

WayneEDick commented Sep 7, 2019 via email

JAWS-test commented Sep 8, 2019 • edited Loading

patrickhlauke commented Sep 8, 2019

jake-abma commented Sep 8, 2019

alastc commented Sep 30, 2019

mraccess77 commented May 11, 2021

patrickhlauke commented May 11, 2021 • edited Loading

mraccess77 commented May 12, 2021

patrickhlauke commented May 12, 2021

alastc commented May 12, 2021

JAWS-test commented Sep 5, 2019 •

edited

Loading

JAWS-test commented Sep 8, 2019 •

edited

Loading

patrickhlauke commented May 11, 2021 •

edited

Loading