diff --git a/techniques/general/g301.html b/techniques/general/g301.html
new file mode 100644
index 0000000000..c34b52d118
--- /dev/null
+++ b/techniques/general/g301.html
@@ -0,0 +1,189 @@
+
+
+
+ Accounting for meaningful text indentation and Reflow
+
+
+
+
Accounting for meaningful text indentation and Reflow
+
ID: G301
Technology: general
Type: Technique
+
+
When to Use
+
All technologies that support style switching
+
+
+
+
Description
+
There can be instances where indentation of text is considered important to the presentation and understandability of the text content. If the indentations were to be removed, then meaning or functionality could suffer. For instance, the nesting of unordered lists can be harder to notice if indentations are removed. Additionally, maintaining indentations can be important to help understand code patterns, if not even necessary for the code to function.
+
Since maintaining indentation is important for these instances of text, two-dimensional scrolling of these distinct sections of content could be necessary. However, there are still styling modifications that could be made to help ensure the indentation was maintained, but as much text was made visible within the viewport as possible. Making such adjustments could limit, if not mitigate any two-dimensional scrolling from occurring, making the content easier for people to read.
+
+
+
+
+
Examples
+
+
A website conveys information in a nested list format. The understandability of the list hierarchy is supported by the indentation of the list content. While it is important for the individual list item text to reflow, the list hierarchy would suffer if flattened so that all content would fit within a 320 CSS pixel wide viewport.
+
The following example list contains additional nested lists to provide more context for each of the parent list item's text. To maintain the visual hierarchy, the indentation of each list level remains present, but modified once an author defined CSS breakpoint is met. Additional styles are set for different breakpoints to mitigate against the potential for content to extend beyond a 320px wide viewport, while accounting for visual spacing against the borders of the viewport, to attempt to make the content not feel cramped. At the smallest breakpoint, the content of list items receive a minimum width to mitigate against potentially "squished" content lists with many nested levels. At this breakpoint, each nested list level can be horizontally scrolled into view, and once a nested list is visible within the viewport, only vertical scrolling will be necessary to read the content of the nested list's items.
+
+<div class="example">
+ <ul>
+ <li>
+ <p>Make a list using one of the HTML list elements, or even an ARIA role=list container.</p>
+ <ul>
+ <li>
+ <p>There are three types of lists in HTML which can contain list items (li elements.</p>
+ <ul>
+ <li><p>the ul element</li>
+ <li><p>the ol element</li>
+ <li><p>the menu element</li>
+ </ul>
+ </li>
+ <li>
+ <p>Another type of list, description lists, exist as well - but they do not contain list items (li elements).</p>
+ </li>
+ ...
+ </ul>
+ </li>
+ <li>
+ <p>Neither the start or end tags of any of the HTML list elements are omissible.</p>
+ <ul>
+ <li><p>The end tags of li elements can be omitted if the li element is immeditely followed by another li element or there is no more content in the parent list element.</p>
+ </li>
+ ...
+ </ul>
+ </li>
+ ...
+ </ul>
+</div>
+
+
+*, *::before, *::after {
+ box-sizing: border-box;
+}
+body, html {
+ font-family: arial;
+}
+@media screen and ( max-width: 640px ) {
+ .example {
+ overflow: auto;
+ max-width: 640px;
+ }
+ ul {
+ padding-inline-start: 1.25em;
+ }
+ li p {
+ padding: .25em;
+ margin: .5em 0 .5em -.25em;
+ max-width: 300px; /* saftey net for max-width */
+ }
+}
+@media screen and ( max-width: 400px ) {
+ ul { padding-inline-start: 1em; }
+ li p { min-width: 300px } {
+ min-width: 300px;
+ }
+}
+
A website providing code snippets needs to maintain line indentations, as the indentations are meaningful not only to the structure of the code, but in some languages - such as with Python, are requirements when defining blocks of code.
+
As a user zooms in the web page, the CSS of the indentation can be adjusted to maintain this necessary structure, while also allowing more text to be visible on a single line.
+
+
The following represents a Python code example. The indentation of each line of text is necessary to create a group of statements that are executed as a block.
+
+def complex_function(x):
+ if x > 0:
+ for i in range(x):
+ if i % 2 == 0:
+ print(f"{i} is even")
+ for a in range(i):
+ if a % 5 == 0:
+ print(f" {a} can be divided by 5")
+ else:
+ print(f" {a} cannot be divided by 5")
+ else:
+ print(f"{i} is odd")
+ for a in range(i):
+ if a % 2 == 0:
+ print(f" {a} is even")
+ else:
+ print(f" {a} is odd")
+ else:
+ print("x is not a positive number")
+
+
The following code example demonstrates the use of indentation to convey the nesting of elements in an HTML document:
Display the web page in a user agent where the page can be zoomed, or the user agent can be resized.
+
Zoom in or resize the browser window so that the viewport is equivallent to 320 CSS pixels wide.
+
The list content fits within the width so that it is only necessary so scroll vertically to read the list.
+
Or, each nested list can be horizontally scrolled into view. Only vertical scrolling is necessary to read the content of list items within each specific nested list level.
+
+
+
Expected Results
+
+
Checks 3 or 4 are true.
+
+
+
+
Procedure for code snippets
+
+
Display the web page in a user agent where the page can be zoomed, or the user agent can be resized.
+
Zoom in or resize the browser window so that the viewport is equivallent to 320 CSS pixels wide.
+
The code snippets fits within the width so that it is only necessary so scroll vertically to read each line of code.
+
Or, for code where non-wrapping lines are not essential, the code wraps or a mechanism is provided to allow line wrapping.
+
Or, the indentation and linebreaks are meaningful to the code language.
+
+
+
+
diff --git a/techniques/general/g302.html b/techniques/general/g302.html
new file mode 100644
index 0000000000..720f3bb484
--- /dev/null
+++ b/techniques/general/g302.html
@@ -0,0 +1,63 @@
+
+
+
+ Section panels that scroll horizontally are designed to fit within a width of 320 CSS pixels on a vertically scrolling page
+
+
+
+
Section panels that scroll horizontally are designed to fit within a width of 320 CSS pixels on a vertically scrolling page
+
+
ID:
+
Technology: general
+
Type: Technique
+
+
+
When to Use
+
All technologies.
+
+
+
Description
+
The objective of this technique is to ensure that users can zoom in on text within a horizontally scrolling section, while not requiring horizontal scrolling to read the content of each individual panel. Although the entire section requires horizontal scrolling to navigate between panels, each panel is designed to fit within a fixed width of 320 CSS pixels. This ensures that when a 320 CSS pixel wide viewport is used, and the card is in the viewport, each card will remain fully visible without the need for additional horizontal scrolling to read its content.
+
+
+
Examples
+
+
A product carousel
+
The homepage of an online retail website includes several informational sections, some of which feature carousels showcasing highlighted products. These carousels require horizontal scrolling and have a computed height greater than 256 CSS pixels. Each panel is 320 CSS pixels wide, allowing users to see the full width of the card without horizontal scrolling. Consequently, users only need to scroll vertically to view the entire card, ensuring compliance with success criterion 1.4.10 Reflow for that section.
Check that the layout includes sections of content that scroll horizontally within a vertically scrolling page.
+
Check that each horizontally scrolling section is divided into distinct panels.
+
Open the webpage in a user agent that supports 400% zoom, setting the viewport dimensions to 1280 CSS pixels in width.
+
Activate the zoom function to enlarge the view by 400%.
+
Check that the content of each individual panel within the horizontally scrolling sections is fully readable without the need for additional horizontal scrolling.
+
+
+
Note
+
+
The native browser scrollbar is not included in the viewport dimensions. Therefore, when setting the view to 1280 CSS pixels wide for a vertically scrolling page, make sure to exclude the scrollbar width.
+
+
+
diff --git a/understanding/21/img/carousel-fail.mp4 b/understanding/21/img/carousel-fail.mp4
new file mode 100644
index 0000000000..534e9591e1
Binary files /dev/null and b/understanding/21/img/carousel-fail.mp4 differ
diff --git a/understanding/21/img/carousel-large-screen.png b/understanding/21/img/carousel-large-screen.png
new file mode 100644
index 0000000000..f71256ec3c
Binary files /dev/null and b/understanding/21/img/carousel-large-screen.png differ
diff --git a/understanding/21/img/code-diff.gif b/understanding/21/img/code-diff.gif
new file mode 100644
index 0000000000..c83b14e794
Binary files /dev/null and b/understanding/21/img/code-diff.gif differ
diff --git a/understanding/21/img/code-view-columns.mp4 b/understanding/21/img/code-view-columns.mp4
new file mode 100644
index 0000000000..eb33c5d31f
Binary files /dev/null and b/understanding/21/img/code-view-columns.mp4 differ
diff --git a/understanding/21/img/exception-does-not-extend.jpg b/understanding/21/img/exception-does-not-extend.jpg
new file mode 100644
index 0000000000..973e2ec58a
Binary files /dev/null and b/understanding/21/img/exception-does-not-extend.jpg differ
diff --git a/understanding/21/img/max-width-video.jpg b/understanding/21/img/max-width-video.jpg
new file mode 100644
index 0000000000..2b097d0ddd
Binary files /dev/null and b/understanding/21/img/max-width-video.jpg differ
diff --git a/understanding/21/img/news-large-screen.png b/understanding/21/img/news-large-screen.png
new file mode 100644
index 0000000000..2c7d30fa38
Binary files /dev/null and b/understanding/21/img/news-large-screen.png differ
diff --git a/understanding/21/img/news-reflow.png b/understanding/21/img/news-reflow.png
new file mode 100644
index 0000000000..0d78edaf15
Binary files /dev/null and b/understanding/21/img/news-reflow.png differ
diff --git a/understanding/21/img/reflow-400zoom-1280x1024.jpg b/understanding/21/img/reflow-400zoom-1280x1024.jpg
new file mode 100644
index 0000000000..7e1bc911bb
Binary files /dev/null and b/understanding/21/img/reflow-400zoom-1280x1024.jpg differ
diff --git a/understanding/21/img/reflow-no-sticky-ad.png b/understanding/21/img/reflow-no-sticky-ad.png
new file mode 100644
index 0000000000..58cb0dfe91
Binary files /dev/null and b/understanding/21/img/reflow-no-sticky-ad.png differ
diff --git a/understanding/21/img/reflow-sticky-ad.png b/understanding/21/img/reflow-sticky-ad.png
new file mode 100644
index 0000000000..9ad745e5d9
Binary files /dev/null and b/understanding/21/img/reflow-sticky-ad.png differ
diff --git a/understanding/21/img/rich-document-with-comment.png b/understanding/21/img/rich-document-with-comment.png
new file mode 100644
index 0000000000..52f18e71e4
Binary files /dev/null and b/understanding/21/img/rich-document-with-comment.png differ
diff --git a/understanding/21/img/single-carousel-panel.png b/understanding/21/img/single-carousel-panel.png
new file mode 100644
index 0000000000..47cb6493a7
Binary files /dev/null and b/understanding/21/img/single-carousel-panel.png differ
diff --git a/understanding/21/img/table-exception.jpg b/understanding/21/img/table-exception.jpg
new file mode 100644
index 0000000000..e6e555c69f
Binary files /dev/null and b/understanding/21/img/table-exception.jpg differ
diff --git a/understanding/21/img/unnecessary-horizontal-scrollbar.jpg b/understanding/21/img/unnecessary-horizontal-scrollbar.jpg
new file mode 100644
index 0000000000..c1badf5b3d
Binary files /dev/null and b/understanding/21/img/unnecessary-horizontal-scrollbar.jpg differ
diff --git a/understanding/21/reflow.html b/understanding/21/reflow.html
index a03d1f481f..68ee28100c 100644
--- a/understanding/21/reflow.html
+++ b/understanding/21/reflow.html
@@ -16,64 +16,293 @@
In brief
What to do
Make lines of text reflow within the viewport.
Why it's important
People who need bigger text find it difficult if they must scroll to read long lines.
-
+
Intent of this Success Criterion
-
The intent of this Success Criterion is to support people with low vision who need to enlarge text and read it in a single column. When the browser zoom is used to scale content to 400%, it reflows - i.e., it is presented in one column so that scrolling in more than one direction is not necessary.
-
For people with low vision, both enlarging and reflowing text are critical to reading. Enlarging text enables the perception of characters. Reflowing text enables users to track from the end of one line to the beginning of the next line.
-
Avoiding the need to scroll in the direction of reading in order to reveal lines that are cut off by the viewport is important, because such scrolling significantly increases the effort required to read. It is also important that content is not hidden off-screen. For example, zooming into a vertically scrolling page should not cause content to be hidden to one side.
-
-
How reflow works
-
User agents for technologies such as HTML/CSS, PDF, and ePub have methods for reflowing content to fit the width of the window (viewport). When appropriately authored, page content can reflow (wrap) to stay within the window's boundaries (viewport) when users zoom in to enlarge the size of content. Spatial relationships of content may change when users zoom, but all information and functionality should continue to be available.
-
Supporting the reflow of content is also known as 'Responsive Web Design'. It is enabled by CSS media queries which reformat the web content for different viewport widths (at particular break points) in order to provide optimised layouts for mobile devices such as tablets or smartphones. Importantly, these breakpoints are not only triggered by narrower viewports, but also when users employ the browser zoom function to zoom into the page.
-
In a desktop browser at 100% (default) scale, typical web pages that support reflow display content in two, three or more columns. Zooming in will at some point trigger a change of layout, so content will now be displayed in fewer columns. At a higher magnification scale of 200% or more, content will usually be rendered in a single column. Parts of content that were in the marginal columns, like a navigation menu or supplementary content, will now typically appear on top of or below the main content.
-
-
-
Viewing distance and display resolution
-
The value of 320 CSS pixels was chosen as a reasonable minimum size that authors can achieve. This value lines up with the reported viewport width of small displays of common mobile devices. The width of 320 CSS pixels exactly corresponds to a desktop browser window set to a width of 1280px and zoomed in to 400%. It should be noted that 400% applies to the dimension, not the area. It means four times the default width and four times the default height.
-
- A letter of the same CSS pixel size on different displays with different resolutions
+
+ The intent of this success criterion is to let users enlarge text and other related content without having to scroll in two dimensions to read. When lines of text extend beyond the edge of a viewport, users will be forced to scroll back-and-forth to read line by line. This can cause them to lose their place and can significantly increase both physical and cognitive effort. Therefore, most sections of content are expected to reflow within the appropriate sizing requirement defined by this success criterion.
+
+
+ A section of content that requires two-dimensional layout for understanding or functionality, such as a table or map, has an exception to this success criterion. However, sections of content within the two-dimensional layout, such as each cell within a table, would still need to meet this success criterion. Although there is an exception for sections of content that require two-dimensional layout for understanding or functionality, authors can improve the user's experience by making efforts to reduce scrolling for that type of content.
+
+
+
+
+
+
Basic text reflow
+
The most basic form of reflow occurs on a text-only page. By default, a long line of text will wrap to fit within the available viewport. For text written in left-to-right (LTR) and right-to-left (RTL) horizontal languages, it will wrap within the width of the viewport. For languages that are written vertically, the text will wrap within the height of the viewport.
+
+
+ [ simplified visual - ideally show horizontal text wrapping AND vertical text wrapping ]
+
+
+
For pages where the primary written language expects vertical scrolling (such as English), users do not expect to horizontally scroll back-and-forth to read that content. Similarly, users reading content written in a language and direction that expects horizontal scrolling (such as traditional Chinese or Japanese) it would not expect to vertically scroll back-and-forth to read that content.
+
-
When we read, the size of the print is not as important as the image it projects on the retina of our eye. Phones are designed for close viewing while desktops are designed for viewing farther away. As a consequence 16px print on a phone is physically smaller than 16px print on a desktop. This is not a problem because both print sizes cast the same image on our retina if they are viewed at their intended distance.
-
-
-
Visibility and availability of content
-
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.
-
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.
-
-
+
+
Users who need to enlarge (zoom) text to read it benefit significantly when it reflows. Regardless of the size of the text, it continues to wrap within the visible viewport. A whole line of text is visible, making it easier for the eye to track from the end of one line to the start of the next. Users only need to scroll in the direction of reading to read additional lines of text.
+
+
This criterion requires non-excepted sections of content that are written in horizontal languages reflow when narrowed to a width equivalent to 320 CSS pixels. Similarly, sections of content that are written in vertical languages (which are not as commonly used on the web and so will be used much less frequently in examples) need to be able to reflow when rendered at a height equivalent to 256 CSS pixels.
+
+
+ [ simplified movie showing a browser window and text reflowing as it enlarges and showing text reflowing as viewport width is decreased ]
+
+
+
Enlarging text via browser zoom, or resizing a browser window to be a narrower width are two ways in which, unless prevented by a web author, text can reflow.
+
Note that the UI of the browser (user agent) remains scaled to the zoom level set by the operating system.
+
+
+
+
+
+
Reflowing websites and web applications
+
+
Modern websites and applications commonly employ responsive web design best practices to adjust or relocate sections of content to fit within smaller viewports. Neither adjusting or relocating content is considered a loss of information or functionality, so long as users are still able to access the content. When content can fit within smaller viewports it not only helps those using mobile devices to read content. It also helps people who need to resize or zoom in a web interface on larger devices, as is the intent of this success criterion.
-
Content exceptions for reflow
-
Content which requires two-dimensional layout for usage or meaning cannot reflow without loss of meaning, and is therefore excepted from the need to be presented without two-dimensional scrolling. For example, graphics and video are by their nature two-dimensional. Cutting up an image and stacking the blocks would render the content unusable. However, it is possible to have these elements stay within the bounds of viewport even as other content zooms to 400% (see advisory techniques).
-
Data tables have a two-dimensional relationship between the headings and data cells. This relationship is essential to convey the content. This Success Criterion therefore exempts data tables from needing to display without scrolling in the direction of text (e.g., horizontally in a vertically scrolling page). However, cells within data tables are not excepted unless the cell contains types of content that also requires two-dimensional layout for usage or meaning.
-
Interfaces which provide toolbars to edit content need to show both the content and the toolbar in the viewport. Depending on the number of toolbar buttons, the toolbar may need to scroll in the direction of text.
-
-
-
Responsive web design and other ways to meet this Success Criterion
-
Using the responsive web design approach is the most effective method of achieving the goal of allowing people to zoom in to 400%. Each variation (CSS break point) of the page at the same URL should conform (compare Conformance for WCAG 2.1).
-
For organisations which are using legacy systems or are not able to update their layout methods for some reason, an alternative conforming version could be a mobile site which has a fixed 320px wide layout. The user should be able to find that version from the default website.
-
-
Avoiding scrolling in horizontally and vertically written languages
-
The success Criterion applies to both horizontally and vertically written languages. Zooming the page for horizontally written languages where pages scroll vertically by default (e.g. English) should not require horizontal scrolling. Zooming the page for vertically written languages which scroll horizontally by default should not require vertical scrolling.
+
Adjusting content into a single column
+
+
A common way for many article-driven web pages to meet the Reflow success criterion is to ensure that the presentation of a web page can adjust to a single column of content, fitting into a 320 CSS pixel wide viewport and only requiring a user scroll vertically to read the content of the web page.
+
+
+
+
+
At a default browser zoom and default desktop display resolution, a news site shows snippets of news teasers, ads, and other multimedia widgets as distinct sections of content. These sections can vary in size and arrangement to fit the web page design, but each section can be read and interacted with on its own without relying on the visual layout or other sections of content to be understood.
+
+
+
+
+
+
+
The news site layout adjusts to fit different viewport sizes, whether from resizing the browser or using its zoom features. As the web page layout adjusts, the sections of content stack vertically, allowing for scrolling in one direction to read. The main navigation is hidden behind a hamburger menu button, and the media player is moved and simplified to stay visible without blocking the page content.
+
+
+
+
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, 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 simply stacked to fit in a single column layout.
+
-
The relation of Reflow to the Success Criterion 1.4.4 Resize Text
-
The focus of the Reflow Success Criterion is to enable users to zoom in without having to scroll in two directions. Success Criterion 1.4.4 Resize Text also applies, so it should be possible to increase the size of all text up to 200% while simultaneously meeting the reflow requirement. For most implementations, the text is expected to continue to enlarge as the magnification increases, so that users can magnify text up to (and beyond) 400%. In an implementation where text does not consistently increase its size as people zoom in (such as when it is transformed based on a media query to adapt to small-screen usage), it must still be possible to get to 200% enlargement in order to satisfy the Resize Text criterion.
-
For example, if at the default browser setting of 100% zoom, text is set at 20px when the window is 1280 CSS pixels wide, at 200% zoom it will visually appear at twice the size. After zooming by 400% the page reflows to fit within the 320 CSS pixel viewport, the author may decide to set the page's text size to 10px. The text is now half the original size in CSS pixels, but as it has been enlarged to 400%, it is still displayed at twice the size compared to the default browser setting at 100% zoom. It is not required to achieve 200% text enlargement while remaining inside a specific breakpoint (as zooming may result in the variation for a new breakpoint becoming active), but it should still be possible to get 200% text enlargement in some way compared to the default 100% zoom.
+
Content that can benefit from two-dimensional layout for meaning or functionality
+
+
Building complex web interfaces will often involve incorporating complex layouts and widgets which often need modified layout, functional adjustments or both when content is enlarged.
+
+
Conforming to this success criterion doesn't mean all sections of content need to stack in a single column within smaller viewports. Nor does it require all sections of content scroll in a single direction, so long as each can be read without two-dimensional scrolling to read the lines of text they present.
+
+
Although the following examples could be designed to work without horizontal scrolling, they have been designed to demonstrate conforming to the success criterion.
+
+
Nested lists or code formatting
+
Lists and blocks of code often rely on indentation of text to visually convey hierarchy and meaning. If the indentation were to be removed, then meaning or functionality could suffer. For instance, the nesting of unordered list hierarchies would become more difficult to notice if indentation were removed. Additionally, maintaining indentations and non-breaking lines can be important to help understand code patterns, if not even necessary for the code to function.
Within vertically scrolling web pages, implementations of carousels can allow for horizontal scrolling of their content. As the carousel scrolls, a new carousel panel or panels are displayed within the visible viewport. As long as each individual panel within the carousel can fit within a 320 CSS pixel viewport, then a user need only scroll in a single direction to read an individual panel's content.
+
+
+
+
+
+
Pass: A carousel presents different panels of teaser content about homes for sale. The carousel container scrolls horizontally, independent of the vertical scrolling of the primary web page. Each individual panel within the carousel is designed to be read vertically, following the direction of reading (top to bottom) of web page's content. When enlarged, each panel can fit within the 320 CSS pixel viewport.
+
+
+
+
+
+
+
Fail: In this modified version of the previous carousel, the second panel's content does not fit within the 320 CSS pixel viewport.
Being able to review differences in code, or text, side-by-side can be an instance where a scrolling two-column layout can benefit users.
+
+
+
+
+
+
+
+
Pass: An interface to review code/document changes provides a two-column comparison between the original and modified content. Each column fits within a 320 CSS pixel wide container and a horizontal scrollbar can be used to position each column into the visible viewport.
+
+
An alternate view can show each changed line stacked on top of each other, but the two-column comparison view allows for direct comparison between original and modified lines of code on the same horizontal plane. This can be easier for some users to understand, especially when changes span multiple lines, reducing the need for vertically scrolling between each original and changed block of content.
+
+
+
-
Browsers on mobile operating systems
-
Most browsers on mobile operating systems do not combine reflow and zoom in the same way as on desktop browsers. These mobile browsers normally support reflow when changing the orientation of the device -- content will be adjusted to the new viewport width. However, these mobile browsers can only magnify content to achieve 1.4.4. Resize Text in manners which do not constrain reflow to a single dimension, for example by using a pinch gesture to scale up content or a double tap on a particular column to make it fill the viewport width. This means that zoomed content in most mobile browsers involves two-dimensional scrolling regardless of what an author does.
-
Mobile user agents can offer reflow when users zoom into content, as evidenced by the Dolphin browser for Android. The lack of magnified reflow support in browsers on mobile operating systems can therefore be regarded as a user agent support issue.
+
Content that meets exceptions for Reflow
+
+
For many 'traditional' web pages where the page's primary purpose is for a user to read distinct sections of content containing multi-line paragraphs of text, the web page is generally expected to scroll vertically (when written in languages such as English). For users with low vision who might need to zoom the web page to read, it is generally expected that as the viewport size decreases due to the increase in zoom level, that the content of the page would reflow to fit within the confines of the viewport.
+
+
However, not all content can fully reflow without degradation of the information or functionality. As already mentioned, this includes tabular data, graphics, maps, presentations, or interfaces that necessitate persistent toolbars.
+
+
+
Understanding the scope of exceptions
+
If a section of content meets the exception for two-dimensional scrolling, the exception only applies to that section. When a section of content is excepted from Reflow, the exception does not automatically extend to other content that doesn't need two-dimensional scrolling for understanding or functionality.
+
+
+
+
+
Fail: Due to the way this example was implemented, the web page has both horizontal and vertical scrollbars. While the table meets the exception for two-dimensional layout for understanding, the paragraphs following the table in the screenshot do not.
+
+
+
+
A data table relies on two-dimensional layout for understanding, but by presenting the table in its own scrollable container it allows other content which does not meet a two-dimensional layout exception to reflow as its containing element adjusts. for example, due to browser resizing, or zooming.
+
+
+
+
+
Pass: Tabular data has a Reflow exception. An element that contains a table with a minimum height, width or both, can be styled to provide bidirectional scrollbars allowing a user to scroll the table's content and mitigating bidirectional scrollbars appearing at the page level. On the left, a web page at default zoom shows a table of four columns represents the files a user has access to. On the right, the web page is zoomed in and the table is rendered within a containing element with is own bidirectional scrollbars.
+
+
+
+
There can be instances where two-dimensional excepted content extends beyond the visible viewport, causing the entire page to scroll. At the same time, other non-excepted content on the same page reflows within the visible viewport. Unlike the prior table example with the paragraph not reflowing, such a situation does pass. 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 bidirectional scrollbars at the page (viewport) level in order to support the viewing of excepted content, so long as the non-excepted content only needs scrolling in one direction.
+
+
Whenever possible it is in the best interest of the user to limit two-dimensional scrolling only to the individual sections of content which necessitate such scrolling, rather than allowing the page at large to scroll in two dimensions. For example, an unnecessary horizontal scrollbar could lead a user to believe there is content existing off-screen for them to scroll to. But if that scrollbar appears only because of one instance of excepted content, a user could expend effort looking for other non-reflowing content which doesn't exist.
+
+
+
+
+
Pass: A video player without a max-width: 100% CSS property causes it to remain full-sized at smaller (zoomed in) viewports. The rest of the page content reflows within 320 CSS pixel wide container. So, while there is a large horizontal scrollbar at the page level, it is due to the video player which has a reflow exception. Unlike the prior table example where the page was implemented in a way where paragraphs extended off-screen and required two-dimensional scrolling to read, this scenario passes because all non-excepted content reflows. However, this does not provide the best user experience, and ideally the styling of the video player would be updated to mitigate the otherwise unnecessary horizontal scrollbar.
+
+
+
+
+
+
+
Pass: By providing the video player a max-width: 100% CSS property, the video fits within the container element. A horizontal scrollbar no longer appears on the page, thus mitigating any expectation that content, beyond the video, might be present outside of the visible viewport.
+
+
+
+
Graphics, video and other fixed-dimension media
+
+
Graphics and video are by their nature two-dimensional. Slicing up a graphic (photograph, drawing, graph, etc.) and stacking the blocks would make the graphic difficult to understand, if not rendering it unintelligible. However, it is possible to have these elements stay within the bounds of the viewport even as other content zooms to 400%.
Data tables and grids have a two-dimensional relationship between column and row headers and their data cells. This success criterion therefore exempts data tables and grids from needing to display without scrolling in the direction of text. However, individual cells would still need to meet Reflow - unless the cell contains content that also requires two-dimensional layout for usage or meaning.
+
+
Other content that is related to the table or grid, such as a preceding heading, a search field, or an accompanying pagination to load different sets of data are not excepted from meeting Reflow. For instance, while a table may require two-dimensional scrolling to maintain its understandability, a heading and paragraph that introduce the table, or a pagination component - allowing a user to navigate to different "pages" of table content - would still be expected to reflow to meet the intent of this criterion.
+
An "electronic program guide" used to display programs to stream online might be presented alongside other content outside of its grid-based layout. Such content, unless having their own exceptions, would be expected to reflow.
+
+
+
+
+
Pass: A table is preceded by a heading, and followed by a pagination component. The table is excepted from Reflow, and is rendered within a scrollable container. The heading and pagination are not excepted, and adjust to fit within a zoomed in viewport.
+
+
+
+
Interfaces with persistent toolbars
+
+
Interfaces which provide toolbars to edit content need to show both the content and the toolbar in the viewport. Depending on the number of toolbar buttons, the toolbar may need to scroll in the direction of text, or might even need to remain fully visible and scroll along with the rich text content or editable canvas area that it provides features for editing.
+
+
+
+
+
TODO: example of a persistent toolbar interface
+
+
+
+
Layout needed for usage and meaning
+
+
Complex web application interfaces allow users to create content set to defined dimensions. For instance, presentations or documents can be based on physical printing or display sizes. Complex interfaces often allow for content to be created that is directly related content to, but not a part of, the primary author-created content. For instance, presentation notes, editing comments/suggestions for a text document, dynamic messaging presented along with a message (chat) interface, etc. Each of these related sections of content often need to be presented in parallel to each other, and their understandability can diminish if their overall location were to change.
+
+
+
+
+
A rich text document is presented at the height and width dimensions which represent how the page would be formatted if physically printed. A piece of text is highlighted, indicating it has a comment associated with it. This comment (a section of content) is located to the side of the rich text document in its own column. This comment does not need to maintain a specific height or width since it only exists as part of this interface. Therefore, this comment is expected to reflow so that it can fit within a 320 CSS pixel wide viewport, while the rich text document can maintain its necessary height and width.
+
Rendering the comments inline with the text of the document would alter the presentation of the dimension-specific layout, as the comments are meant for the authors of the document, and are not to be printed.
+
Bidirectional scrollbars would be needed to ensure someone can horizontally scroll between the rich text document, to the column of comments.
+
+
+
+
Finally, interfaces which represent the creation of or rendering of presentations created by users (for instance, creating or presenting slide decks) often cannot simply reflow content, as doing so could easily result in breakages to the presentation of the author's content.
+
+
Instead, it would be expected that such interfaces provided content authors with a means to create an alternative presentation that does meet the requirements of this success criterion.
+
+
+
+
+
+
+
Why specifically 320px and 256px?
+
The value of 320 CSS pixels for vertically scrolling content was chosen as a reasonable minimum size that authors can achieve. This value aligned with reported viewport width of small displays of common mobile devices that were available when this criterion was originally drafted. The 320 CSS pixels generally corresponds to a desktop browser window set to a width of 1280px and the browser viewport then zoomed to 400%. It should be noted that 400% applies to the dimension, not the area. It means four times the default zoom level viewport width and four times the default zoom level height.
+
+
+
+ A letter of the same CSS pixel size on different displays with different resolutions
+
+
+
When we read, the size of the print is not as important as the image it projects on the retina of our eye. Phones are designed for close viewing while desktops are designed for viewing farther away. As a consequence, 16px print on a phone is physically smaller than 16px print on a desktop. This is generally not a problem because both print sizes cast the same image on our retina if they are viewed at their intended distance. The CSS reference pixel, the px unit used on the web, reflects this. The CSS reference unit is an angular measurement (1.278 arc minutes), not a length measurement. Most older people, and some people with low vision hold their phone closer than is typical, but again, by using the CSS reference pixel, developers (and designers and content authors) have stable metrics for their design choices.
+
+
Acknowledging viewport vs resolution discrepancies
+
+
As technology and user interaction with technology evolves, adhering to Reflow becomes less about if there is a specific resolution or browser zoom level that neatly aligns with the sizing requirements of this success criterion, but rather that sections of content can be presented in a viewport equivalent to those sizing requirements. For instance, someone with a browser window docked to one half of their display could have a viewport width of 960 CSS pixels. A user could then zoom the browser 300% and achieve a viewport of 320 CSS pixels wide.
+
+
Additionally, not all users who can benefit from Reflow will be viewing web pages at a screen resolution that neatly zooms to either of Reflow's sizing requirements. Rather, an operating system's display resolution and the size of one's browser viewport will commonly not align. For instance, if one were to set their desktop computer's display resolution to 1280 by 1024 pixels, the browser's viewport would be smaller than these dimensions since the operating system and browser UI would detract from the available screen real estate. Some operating systems might not even provide a display resolution that neatly scales to the 320 or 256 CSS pixel dimensions, regardless of zoom level.
+
+
+
+
+
A browser window presented on a laptop with a resolution of 1280 by 1024 pixels. The web page has been zoomed in 400%. However, even with the operating system's taskbar set to auto-hide, and a minimalist amount of browser UI, the viewport is smaller than what one might initially believe without understanding this difference. The viewport is 318 pixels wide due to the browser needing to present page's vertical scrollbar. The viewport is 236 pixels tall due to the browser's tabs and address bar UI taking up their own vertical space.
+
+
+
+
Not all user agents will support this SC's normative sizing requirements
+
+
An important factor in being able to support Reflow is for a user agent to allow the adjustment of content within specific windows of content, if not the size of the window itself. When Reflow was originally drafted, most mobile operating system browsers handled content zooming and reflow differently than on traditional desktop browsers. For instance, the content of a web page could reflow only when the mobile device's orientation changed. This was because for many mobile browsers at the time, zooming a web page was more of a magnification feature. “Pinch zoom” gestures or double-tap to enlarge would magnify the web page content, allowing a user to then swipe or drag the web page so portions of it could be visible by the magnified screen.
+
+
These days, more browsers on mobile devices or other devices that allow users to open applications at fixed dimensions (e.g., full screen or split screen) allow for scaling features that are more in-line with traditional desktop browser zooming. Or, these devices have incorporated zooming features at the OS level that can allow at least some level of reflowing of content for web pages. Many of these features, however, do not commonly adjust the fixed-dimension browser viewport to the 320 CSS pixel width for vertically scrolling content, or 256 CSS pixel height for horizontally scrolling content.
+
+
While one can regard the inability to resize fixed-dimension browsers to the 320 CSS pixel or 256 CSS pixel sizes used by this criterion a user agent support issue, it is not the intent of this criterion to mandate that devices need to support these specific sizes for presenting content, nor is it to be assumed that if content cannot be presented within such sizes on specific devices that the web page would pass or fail Reflow. If a web page can be viewed on a device where the sizing requirements of this criterion can be accurately tested, then it is on such devices where a web page's ability to meet Reflow is best to be determined.
+
+
+
+
Overlap with other success criteria
+
When reviewing a web page for Reflow, issues related to other WCAG success criteria might be discovered. The following are examples of potential overlaps with other success criteria, though not all overlapping success criteria are mentioned.
+
+
Resize Text
+
The focus of the Reflow success criterion is to ensure that users are not prevented from zooming into web pages, and when doing so text within sections of content will wrap so that the text can be read without having to scroll in two directions. Success criterion 1.4.4 Resize Text overlaps with this goal, as it should be possible to increase the size of all text to at least 200% while simultaneously meeting the reflow requirement. For many web pages, the text of the page is expected to continue to enlarge as the browser magnification increases, so that users can magnify text up to (and beyond) 400%. In an implementation where text does not consistently increase its size as people zoom in (such as when it is transformed based on a media query to adapt to small-screen usage), it must still be possible to get to 200% enlargement to satisfy the Resize Text criterion. It is important to note that while the intent of Reflow will commonly result in the enlargement of text, Reflow does not specifically require any text size enlargement be reached. There may even be instances where one needs to prevent some text from becoming too large, and thus requiring unwanted two-dimensional scrolling.
+
+
For example, if at the default browser setting of 100% zoom, text is set at 20px when the window is 1280 CSS pixels wide, at 200% zoom it will visually appear at twice the size. After zooming by 400% the page reflows to fit within the 320 CSS pixel viewport, the author may decide to set the page's text size to 10px. The text is now half the original size in CSS pixels, but as it has been enlarged to 400%, so it is still displayed at twice the size compared to the default browser setting of 100% zoom. It is not required to achieve 200% text enlargement while remaining inside a specific breakpoint (as zooming may result in the variation for a new breakpoint becoming active), but it should still be possible to get 200% text enlargement in some way compared to the default 100% zoom.
+
+
Focus Not Obscured (Minimum)
+
When sections of content have been designed to be fixed position or “sticky” at larger viewport sizes, authors need to ensure such sticky content does not fully obscure the element which has user keyboard focus, or in the case author created content does obscure content, there is a way for a user to dismiss the obscuring content without requiring the advancement of keyboard focus. Such sticky or fixed content can pose significant issues for those who would benefit from Reflow, as aside from obscuring keyboard focus, such sticky or fixed content can make reading content difficult if not impossible.
+
+
For example, a website's content properly reflows to fit within a 320 CSS pixel wide viewport. The website also displays fixed-position ads. The ads are often presented in a lower corner of the web page when rendered in larger viewports. However, when attempting to zoom in the page, the ads remain in their fixed position. They obscure not only the focusable elements of the page, providing no way to dismiss the ad without finding / keyboard navigating to its close button, but significantly reduce the available space for reading.
+
+
+
+
+
The fixed position advertisement not only obstructs the hyperlink that has keyboard focus, but significantly limits the available space to read the content of the web page.
+
+
+
+
+
+
+
Making the advertisement's positioning static, the reflowed content of the web page can be read, and the advertisement (not shown in this screenshot) can still be viewed when scrolling the page.
+
+
+
+
+
Beyond this sticky advertisement example, commonly toolbars, menubars, navigation and other "sidebar" content may be presented with sticky or fixed positions at larger viewport sizes. It is strongly suggested that at smaller viewport sizes that such components are modified to have static positioning, or their display can be toggled by the user. Doing so will help ensure the zoomed in content can be read by users, as the sticky components will no longer obstruct the view of the web page's content.
+
Benefits
-
This Success Criterion helps people with low vision who require text enlargement by enabling them to read the content seamlessly, eliminating the necessity to scroll in multiple directions.
+
This success criterion helps people with low vision who require text enlargement by enabling them to read the content seamlessly, eliminating the necessity to scroll in multiple directions.
@@ -89,11 +318,22 @@
Examples
PDF offering reflow
In a PDF created to conform to PDF/Universal Accessibility (ISO 14289), the content can be reflowed and zoomed in to make reading possible for someone with low-vision.
+
+ Alternative presentations to truncating content
+
A web page presents long strings of text which are truncated to save space. E.g., user generated content that does not fit into the space allocated for the interface's design, or authentication keys which do not wrap, etc.. The content is presented as truncated, but a link is provided to a web page where the content is fully visible without truncation, or a mechanism is provided on the web page to reveal the truncated content.
+
+
+ Preformatted text conveys meaning
+
The presentation of text where the layout has specific meaning, such as code indentation for Python or "ascii art" as just two examples, would lose meaning if the layout were not presented correctly. This success criterion does not apply where that meaning would be lost. However, this is not the case for most other instances of text where text wrapping can be applied without loss of meaning. Additionally, for instances of indentation that convey meaning, consider reducing the size of the indentation at zoomed in levels. As the text will be bigger, the reduced indentation width can still be noticeable.
diff --git a/working-examples/reflow-carousel-panel-horizontal-scroll/index.html b/working-examples/reflow-carousel-panel-horizontal-scroll/index.html
new file mode 100644
index 0000000000..1ba4c438b9
--- /dev/null
+++ b/working-examples/reflow-carousel-panel-horizontal-scroll/index.html
@@ -0,0 +1,304 @@
+
+
+
+ Carousel panels that scroll horizontally are designed to fit within a width of 320 CSS pixels on a vertically scrolling page
+
+
+
+
+
+
A black jacket with an unusual scale-like and heavily textured surface
+
$600
+ Colors
+
+
Black
+
Brown
+
Grey
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/working-examples/reflow-carousel-panel-horizontal-scroll/jackets.png b/working-examples/reflow-carousel-panel-horizontal-scroll/jackets.png
new file mode 100644
index 0000000000..14a372ab03
Binary files /dev/null and b/working-examples/reflow-carousel-panel-horizontal-scroll/jackets.png differ
diff --git a/working-examples/reflow-indenting/index.html b/working-examples/reflow-indenting/index.html
new file mode 100644
index 0000000000..46ae95276d
--- /dev/null
+++ b/working-examples/reflow-indenting/index.html
@@ -0,0 +1,110 @@
+
+
+
+ Reflow: Code snippet indentation examples
+
+
+
+
+
+
+
Example 1: Python code snippet
+
With Python, indentation and new lines have meaning.
+ This example adjusts indentation width at different breakpoints to maintain indentation, while ensuring more, characters can be seen
+ within a 320px wide viewport. Code lines do not wrap, as that could lead some to believe a new line has started, which would be invalid.
+
+def complex_function(x):
+ if x > 0:
+ for i in range(x):
+ if i % 2 == 0:
+ print(f"{i} is even")
+ for a in range(i):
+ if a % 5 == 0:
+ print(f" {a} can be divided by 5")
+ else:
+ print(f" {a} cannot be divided by 5")
+ else:
+ print(f"{i} is odd")
+ for a in range(i):
+ if a % 2 == 0:
+ print(f" {a} is even")
+ else:
+ print(f" {a} is odd")
+ else:
+ print("x is not a positive number")
+
+
+
Example 3: HTML markup nesting
+
The following code example demonstrates the use of indentation to convey the nesting of elements in an HTML document.
+ Similar to the previous Python example, the indentation width adjusts at different breakpoints. But unlike Python, HTML
+ doesn't have strict syntax concerning new lines or indentation. So, this example provides a button to allow text to wrap, if the user would prefer that presentation.
+
+
+
+<html lang=en>
+ <head>...</head>
+ <body>
+ <div id=app>
+ <header>
+ <!-- header content here, Such as logo, primary navigation, search field, etc. -->
+ </header>
+ <main>
+ <!-- main content here, Such as headings to introduce the primary content of the page, and related sub-headings and sections. -->
+ </main>
+ <aside>
+ <!-- aside content here. Tangentially related content. Adverts. Links to other related pages. -->
+ </aside>
+ <footer>
+ <!-- footer content here. Copyright info, globally repeating company links and disclaimers. -->
+ </footer>
+ </div>
+ </body>
+</html>
+
+
+
+
+
diff --git a/working-examples/reflow-nested-lists/index.html b/working-examples/reflow-nested-lists/index.html
new file mode 100644
index 0000000000..5acd008218
--- /dev/null
+++ b/working-examples/reflow-nested-lists/index.html
@@ -0,0 +1,91 @@
+
+
+
+ Reflow: lists with nested list levels
+
+
+
+
+
+
+
Example list with nested lists
+
+
+
+
+
Make a list using one of the HTML list elements, or even an ARIA role=list container.
+
+
+
There are three types of lists in HTML which can contain list items (li elements.
+
+
the ul element
+
the ol element
+
the menu element
+
+
+
+
Another type of list, description lists, exist as well - but they do not contain list items (li elements).
+
+
+
+
+
+
+
+
Neither the start or end tags of any of the HTML list elements are omissible.
+
+
The end tags of li elements can be omitted if the li element is immeditely followed by another li element or there is no more content in the parent list element.
+
+
The list marker for each li element is initially based on the parent list element used.
+
+
+
The list maker can be modified by using CSS,
+
+
A list item's ::marker can be styled similarly to other pseudo elements, like ::before and ::after. Use it to modify or restyle or create custom unordered list markers.
+
Using the ::before pseudo element, one can use the CSS counter and content properties to create custom incrementing numeration for list items.
+
+
+
or the list marker can be modifed by using the type attribute, if the parent list element is an ol element. The type attribute is obsolete on the ul element, and is not allowed on the menu element.
+
+
+
+
+
+
+
Validate your markup to make sure your lists are properly structured.
- 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+