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
Co-authored-by: Giacomo Petri <[email protected]>
Co-authored-by: Giacomo Petri <[email protected]>
thank you! Co-authored-by: Giacomo Petri <[email protected]>
Co-authored-by: Giacomo Petri <[email protected]>
|
While developing a technique for one of the new scenarios, I realized there might be an important edge case to consider during testing. Specifically, when we set the viewport width to 1280px, the browser's vertical scrollbar is included in this measurement. For instance, if the viewport is set to 1280px and then zoomed to 400%, a card with a width of exactly 320px (without any margin) isn't fully visible horizontally because the vertical scrollbar takes up some of the available width. Does this count as a violation? I intentionally designed the card to be 320px wide to fit the viewport exactly. While there’s some padding that ensures users can still read the content without needing to horizontally scroll, the card technically isn't fully visible within the 320 CSS pixels. This means a horizontal scroll is required to view the entire card. The issue arises because the technique I was creating asks testers to set the viewport, check for scrolling sections, and verify that each individual panel fits without requiring scrolling. However, when the vertical scrollbar is present, this condition isn't fully met. What are your thoughts on this? Would you consider it a failure? Note: I think we need to clarify how we define the viewport; should it be based on document.documentElement.clientWidth (which would pass) or window.innerWidth (which would fail?)? |
| <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) text and other content without having to perform bi-directional scrolling to read. Lines of text that extend beyond the viewport in two-directions force users to scroll back-and-forth to read, which can cause them to lose their place, and significantly increase both physical and cognitive effort. Sections of content are expected to reflow within the appropriate sizing requirement defined by this success criterion, in regards to the text's intended direction of reading. With exceptions for sections of content which functionally requires bi-directional layout for usage or meaning.</p> |
There was a problem hiding this comment.
"two-directions" is redundant. A line of text can only extend beyond the viewport in one direction. I've removed "zoom in" again because I find it disruptive to reading, and the method of text enlargement is irrelevant to the need to reflow
| <p>The intent of this success criterion is to let users enlarge (zoom in) text and other content without having to perform bi-directional scrolling to read. Lines of text that extend beyond the viewport in two-directions force users to scroll back-and-forth to read, which can cause them to lose their place, and significantly increase both physical and cognitive effort. Sections of content are expected to reflow within the appropriate sizing requirement defined by this success criterion, in regards to the text's intended direction of reading. With exceptions for sections of content which functionally requires bi-directional layout for usage or meaning.</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 view it. Text that extends beyond the edge of the viewport forces users to scroll back and forth to read a line of text. This can cause them to lose their place; it significantly increases both physical and cognitive effort. Sections of content are expected to reflow within the appropriate sizing requirements defined by this success criterion. An exception exists for sections of content which functionally require bi-directional layout for usage or meaning.</p> |
There was a problem hiding this comment.
hmm. maybe worth talking about this a bit. i understand the suggestions you're making, but they do change part of the point i was trying to make.
There was a problem hiding this comment.
Mostly happy with the updates, but I think the second sentence is missing the bi-directional aspect. I.e. it's confusing because "beyond the viewport" could be down, but here you mean (and assume) side to side. (or vice versa)
Text that extends beyond the edge of the viewport in two-directions forces users to scroll back and forth to read lines of text.
at least the way a browser calculates its viewport, it's the area that is not considered part of the browser chrome (its ui). this is why it's a bit of a misnomer to say that a 1280 resolution with a browser set to 100% would always mean you could zoom in 400% to get a 320px wide viewport. That's not true in all cases. For instance, if i set my OS resolution to 1280px wide and i maximize my browser, if i'm viewing a page with a scrollbar the viewport actually has a max width of 1272px. This maybe is your issue with creating something that's 320px wide, but it not neatly fitting into the viewport - because your viewport isn't actually 320px? but, regardless of that point, if the text is fully visible within the 320px wide area, but the border/padding of the card isn't completely in view - i don't think that should be considered a failure. One can read the content without having to scroll in two directions - that's the point of the SC. |
Co-authored-by: Mike Gower <[email protected]>
Co-authored-by: Mike Gower <[email protected]>
Co-authored-by: Mike Gower <[email protected]>
|
Discussed on TF call 12/13. Request to work on second sentence of Intent. |
| <div class="note" id="note-2dlayout"> | ||
| <p>An important factor in being able to support Reflow is for the user agent to allow users to adjust the size of content within specific windows of content. For instance, the browser's viewport.</p> | ||
|
|
||
| <p>Technologies such as HTML/CSS, PDF, and ePub have methods of reflowing content to adjust to the size of the viewport. When appropriately authored, users can use zooming features provided by the user agent (browser) to enlarge the content within the viewport. Unless otherwise prevented by author styling, the content of the web page will reflow (wrap) to adjust to the size of the viewport. At the same time, the user agent and any UI provided directly by the user agent will remain scaled to the zoom level set by the operating system.</p> |
There was a problem hiding this comment.
This makes it sound like users can be authored:
"When appropriately authored, users can use…"
| </figcaption> | ||
| </figure> | ||
|
|
||
| <p>While this 'stacking into a single column' approach may work for many web pages whose primary objective is to present sections of content for people to read (e.g., text and/or standard media such as graphics, videos that represent articles, blog posts, discussion threads, topic teasers, etc.); there are many instances of common, but complex, widgets and layouts which would become more difficult to visually understand or interact with if they were adjusted to fit in a single column layout.</p> |
There was a problem hiding this comment.
semicolon should be a comma:
; there are many instances of common, but complex, widgets …
Co-authored-by: Alastair Campbell <[email protected]>
Co-authored-by: Francis Storr <[email protected]>
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