search

w3c / wcag

Web Content Accessibility Guidelines
https://w3c.github.io/wcag/guidelines/22/
Other
1.11k stars 252 forks source link

Semantic conveyed through Indented UI and Reflow 1.4.10 #887

Open cscrosati opened 5 years ago

cscrosati commented 5 years ago

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)

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?

JAWS-test commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 notifications@github.com 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 https://github.com/w3c/wcag/issues/887?email_source=notifications&email_token=AB6Q4F2SJTZBXGARMBMAAC3QIKGKBA5CNFSM4IUBPHUKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6DPQCI#issuecomment-528939017, or mute the thread https://github.com/notifications/unsubscribe-auth/AB6Q4F5CSREL2WWO75KNWBLQIKGKBANCNFSM4IUBPHUA .

JAWS-test commented 5 years ago

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 commented 5 years ago

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 https://github.com/w3c/wcag/issues/698

jake-abma commented 5 years ago

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

alastc commented 5 years ago

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 commented 3 years ago

So are code blocks exempted from 1.4.10 or not?

patrickhlauke commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

put succinctly, yes (in my view)

alastc commented 3 years ago

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.