Updated Reflow understanding doc #4055
Conversation
This initial commit takes the current draft from the google doc that had been worked on for quite some time now, and makes it into a PR for further editing and review. Not all feedback from the google doc was directly taken/addressed, but there have been additional changes made that attempted to consider a good portion of the unresolved comments. Marking this PR as a draft, as there is still work to do (and I also need to upload all the new graphics for the examples - and a few examples still need to be created, which are currently marked as comments in the HTML file)
✅ Deploy Preview for wcag2 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
fix some missing/stray markup end tags
Co-authored-by: Dan Bjorge <[email protected]>
|
Briefly discussed on backlog call 9/6. |
attempt at further addressing issues: 2043 and 366
trying this text out to see what people think. again i'm wary about saying viewport here since that's not always what is needed.
attempting to briefly address issue 3311 and 648
|
making notes of existing issues addressed with this PR (more to come):
|
add in the carousel/swimlane examples that were noticed as missing during today's call. fix the broken animated gif and put it into a disclosure widget so that someone who doesn't want to see the animation can open/close it.
|
Discussed on backlog call 9/13, thank you @scottaohara! A preview is available but a reminder that the PR is still a work in progress. Most (but not all) content from Google Doc drafting has been pulled in and Scott has placeholders and inline notes-to-self. Looking really good! Outstanding question to @iadawn about replacing 4mb animated gif with an MP4, but where should a multimedia file go? TF would be okay with publishing without (and adding later) as the MVP need not be perfect. |
thanks @mfairchild365 for suggestions in simplifying my wordy intro paragraphs.
- wording updates per feedback i received off-github - added content to replace the "todo" placeholder content for section that introduces the carousel example
- spelling mistakes corrected - wording modifications to in brief section - expand tabular data section to call out grid-based UI, incorporating from off-github suggestion to reference "electronic program guides"
part 1 of at least 2. various wording adjustments for things that people commented could have been clearer. comment in the html to add a failing example (line 96)
the images were rather large - so made them a bit smaller to hopefully make the doc feel less 'broken up' by them
move the scoping of exceptions section into the exceptions section (preceded it, and that was weird) also fixes a paragraph with a missing start tag
including / expanding on the final comment in 887 - #887 (comment)
new reflow technique for handling indented / nested content where visual indenting should be maintained, but can still be adjusted for reflow this is just committing what's been done, the doc is incomplete
|
This is all great! I think this is ready to go live once the missing illustrations are created (no small task). |
| <figure> | ||
| <img src="img/single-carousel-panel.png" alt="one of the carousel panels zoomed in 400%. The text vertically flowing text fits within 320px width container." width="550"> | ||
| <figcaption> | ||
| <p>The content of each carousel "panel" (image, text content and call to action link visually represented as a right-pointing arrow icon) fit within a width of 320 CSS pixels. This helps ensure a user need only scroll vertically to read the text of each section of teaser content. The user can horizontally scroll the wrapping container element to bring each width-conforming panel of teaser content into view. A user can scroll vertically to view the image or read the text of each section of content.</p> |
There was a problem hiding this comment.
This is great; I think it'd be even better if it also included a corresponding example of a similar failing case (where an individual carousel item didn't fit). It might be helpful to use a consistent format for marking which examples pass and which fail (eg, in https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance.html, we had the figcaptions start with "Passes: " and "Fails: " for the figures demonstrating individual examples)
| <section> | ||
| <h3>Vertically and horizontally scrolling content</h3> | ||
| <p>Where a vertically scrolling interface has <a href="https://www.w3.org/TR/WCAG/#dfn-section">sections of content</a> which scroll horizontally, those sections would need to meet the 320 CSS pixel vertical scrolling requirement or an exception to pass this criterion. Similarly, in a horizontally scrolling interface that has sections of content which scroll vertically, the sections of content would need to meet the 256 CSS pixel horizontal scrolling requirement, or an exception to the criterion.</p> |
There was a problem hiding this comment.
i am thinking this is where clarifying content can be provided to call out that this sort of example: https://codepen.io/Giacomo-Petri/pen/poXqemZ is not a pass - and goes against the intent of reflow, as this content should be able to reflow and scroll vertically. the 256 height needs to be called out again as being a requirement for content that is meant to be read horizontally, where the language would wrap in "columns" instead of "lines"
| </section> | ||
|
|
||
| <section id="intent"> |
There was a problem hiding this comment.
adding this comment for myself to make sure i at least have a clear version of Mike's text from his closed PR:
The most crucial problem solved by reflow is allowing users to increase text size while keeping line length
within the width of the display. If users are forced to scroll to read lines of text, they are more likely to
lose their place, especially when scrolling in the opposite direction to locate the start of the next line.
|
Do I understand correctly, that this is not the end of improvement discussion on Reflow, but one step? On the current changes: There might be use cases where data needs to be checked according to other data, so a more complex scenario that the code diff. I recommend to mention it. |
| <dt>Goal</dt><dd>Content can be enlarged without increasing line length.</dd> | ||
| <dt>What to do</dt><dd>Make lines of text reflow within the viewport.</dd> | ||
| <dt>Why it's important</dt><dd>People who need bigger text find it difficult if they must scroll to read long lines.</dd> | ||
| <dt>Goal</dt><dd>Content can be enlarged without needing to scroll in two dimensions.</dd> |
There was a problem hiding this comment.
One of the intended goals of the In Brief material is to use different words than the SC wording as a means of enhancing meaning -- complement versus regurgitate. "Two dimensions" is confusing to a lot of people; repeating it accomplishes nothing.
There was a problem hiding this comment.
the reason this was changed was per feedback from @alastc
I probably should have raised this before, but line-length wasn't the motivation per-se.
It was more that you don't lose information from the view in two directions.
E.g. Content can be enlarged without needing to scroll in two directions.
when i updated this to say "in two directions", i received feedback from two other people asking "why are you changing the wording from what the SC says"
maybe we should take another stab at redoing this line, since there's conflicting recommendations now.
| <dt>What to do</dt><dd>Make lines of text reflow within the viewport.</dd> | ||
| <dt>Why it's important</dt><dd>People who need bigger text find it difficult if they must scroll to read long lines.</dd> | ||
| <dt>Goal</dt><dd>Content can be enlarged without needing to scroll in two dimensions.</dd> | ||
| <dt>What to do</dt><dd>Make long lines of text and other applicable content reflow within resized or zoomed in interfaces.</dd> |
There was a problem hiding this comment.
This exceeds the length of any of the other In Brief material (which had a target of 10 words or less), with little clear benefit. Is the rationale for the change that people don't know what a viewport is? I'm also very concerned that "other applicable content" has been worked in here. We have clear support in discussions that text was the primary consideration.
There was a problem hiding this comment.
as mentioned on the call, "other applicable content" was in regards to images, buttons, other phrasing content that might not have been understood to fall under "text" per feedback from @patrickhlauke.
but we also said on the call we could just make it clear that "text / lines of text" might include other bits that are text-adjacent. so agreed, we can simplify this down.
| <dt>Why it's important</dt><dd>People who need bigger text find it difficult if they must scroll to read long lines.</dd> | ||
| <dt>Goal</dt><dd>Content can be enlarged without needing to scroll in two dimensions.</dd> | ||
| <dt>What to do</dt><dd>Make long lines of text and other applicable content reflow within resized or zoomed in interfaces.</dd> | ||
| <dt>Why it's important</dt><dd>People who need larger text find it difficult if they need to scroll in two dimensions to read long lines that do not reflow.</dd> |
There was a problem hiding this comment.
Again, making something wordier by reusing words that are already in the SC, which arguably does little to improve understanding while definitely making it less brief.
There was a problem hiding this comment.
i see your point, i'll look at trying to trim these back down so long as they don't over simplify - which is why i was trying to address these, per the feedback i had received from both people in our group, as well as non-wcag participants
There was a problem hiding this comment.
My suggestion is to focus on the Understanding document and leave the In Brief alone for now. Remember that the In Brief had full scrutiny by the WG in the past year. The Understanding document itself has not been scrutinized as a whole since publication of 2.1.
There was a problem hiding this comment.
i'm fine with so long as others who requested these changes agree.
| <p>How much of the content is visible may change at different scales. For example, navigation menus that are fully visible in the desktop layout are often collapsed into fewer items, or even into a single menu button (the 'hamburger' icon pattern) so they take up less screen space.</p> | ||
| <p>The Success Criterion is met as long as all content and functionality are still fully available - either directly, or revealed via accessible controls, or accessible via direct links.</p> | ||
| </section> | ||
| <p>The intent of this success criterion is to let users enlarge (zoom in) multiline sections of content without having to perform bi-directional scrolling to read. Lines that extend beyond the viewport in the direction of reading require scrolling back-and-forth to read, which can significantly increase both physical and cognitive effort and cause users to lose their place. Outside of content which necessitates bi-directional layout to understand or function, content is expected to reflow within the appropriate sizing requirement defined by this success criteria, in regards to the content's intended direction of reading.</p> |
There was a problem hiding this comment.
| <p>The intent of this success criterion is to let users enlarge (zoom in) multiline sections of content without having to perform bi-directional scrolling to read. Lines that extend beyond the viewport in the direction of reading require scrolling back-and-forth to read, which can significantly increase both physical and cognitive effort and cause users to lose their place. Outside of content which necessitates bi-directional layout to understand or function, content is expected to reflow within the appropriate sizing requirement defined by this success criteria, in regards to the content's intended direction of reading.</p> | |
| <p>The intent of this success criterion is to let users enlarge text and other content without having to perform bi-directional scrolling to read multiple-line sections of content. Text that extends beyond the viewport forces users to scroll back and forth to read, which causes them to lose their place, and can significantly increase both physical and cognitive effort. Content is expected to reflow within the appropriate sizing requirement defined by this success criterion. The exception is content which functionally requires bi-directional layout .</p> |
| <!DOCTYPE html> | ||
| <html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml"> | ||
| <head> | ||
| <title>Adjusting indentation </title> |
There was a problem hiding this comment.
this will need to be updated to match whatever heading we settle on
| <p>Reflow applies to both horizontally and vertically written languages. For pages where the primary written language expects vertical scrolling (such as English), users do not expect to scroll back-and-forth horizontally to read that content. Similarly, users reading content in a written language/direction that expects horizontal scrolling (such as traditional Chinese and Japanese) do not have to scroll up-and-down vertically to read that content.</p> | ||
|
|
||
| <div class="note"> | ||
| <p>Reflow does not prohibit web pages from presenting both horizontal and vertical scrollbars for individual sections of content, nor does it disallow the use of bi-directional scrollbars at the page (viewport) level, when the content has been enlarged.</p> |
There was a problem hiding this comment.
I'm concerned that the last half of this essentially lets almost every case drive through a giant loophole. It appears to say that when you have zoomed in, bi-directional scrolling is not a fail.
There was a problem hiding this comment.
thanks @alastc - i see your point. The intent of this was to call out that bi-directional scroll bars at a page level do not necessarily mean the web page fails, so long as the scroll bars are there because of an exception, or if scroll bars appear but the content of the page can still be viewed without having to actually scroll in two directions to read it.
i hope that reading the rest of the doc makes this clear in context - but i can work on rewording this a bit so as to not to give off the wrong impression.
| <link rel="stylesheet" href="../../css/sources.css" class="remove"/> | ||
| </head> | ||
| <body> | ||
| <h1>New technique title goes here</h1> |
There was a problem hiding this comment.
This initial commit takes the current draft from the google doc that had been worked on for quite some time now, and makes it into a PR for further editing and review.
Not all feedback from the google doc was directly taken/addressed, but there have been additional changes made that attempted to consider a good portion of the unresolved comments.
Marking this PR as a draft, as there is still work to do (and I also need to upload all the new graphics for the examples - and a few examples still need to be created, which are currently marked as comments in the HTML file).
Preview link