diff --git a/exception-does-not-extend.jpg b/exception-does-not-extend.jpg
new file mode 100644
index 0000000000..973e2ec58a
Binary files /dev/null and b/exception-does-not-extend.jpg differ
diff --git a/techniques/general/g20x.html b/techniques/general/g20x.html
new file mode 100644
index 0000000000..23b599998b
--- /dev/null
+++ b/techniques/general/g20x.html
@@ -0,0 +1,163 @@
+
+
+
+ Accounting for meaningful text indentation and Reflow
+
+
+
+
Accounting for meaningful text indentation and Reflow
+
ID: G206
Technology: general
Type: Technique
+
+
When to Use
+
All technologies that support style switching
+
+
+
+
Description
+
There are instances where indentation of text is considered important to the understandability of the text content. If the indentations 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 can be important to help understand code patterns, if not even necessary for the code to function.
+
Maintaining indentation is important for these instances of text, and would be considered essential for two-dimensional scrolling if the text were enlarged and could not be fully presented within the available viewport. 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.
+
+
+
+
+
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 container.
+
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 the lists is maintained, but reduced once an author defined CSS breakpoint is met. The container of the text content of each list item is given a maximum width of 320 CSS pixels so that even though the list will require bi-dimensional scrolling to view all nested lists, each list item in each nested list level will be able to be read witout the need to scroll in two directions.
+
+<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>
+
+
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,
+
or the list marker can be modifed by using the type attribute, if the parent list element is an ol element.
+
+
+
+
+
+
Validate your markup.
+
+
+
+
+
+@media screen and (max-width: 640px) {
+ .example {
+ overflow: auto;
+ max-width: 640px;
+ }
+ ul {
+ padding-inline-start: 1em;
+ }
+ li p {
+ max-width: 320px;
+ margin: .5em 0;
+ }
+}
+
+
+
+
+
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:
+
+
+
diff --git a/understanding/21/img/carousel-large-screen.png b/understanding/21/img/carousel-large-screen.png
new file mode 100644
index 0000000000..86923f1d24
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/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/npr-large-screen.png b/understanding/21/img/npr-large-screen.png
new file mode 100644
index 0000000000..3846d419d5
Binary files /dev/null and b/understanding/21/img/npr-large-screen.png differ
diff --git a/understanding/21/img/npr-reflow.png b/understanding/21/img/npr-reflow.png
new file mode 100644
index 0000000000..912feac722
Binary files /dev/null and b/understanding/21/img/npr-reflow.png 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..b72f144ca8
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..33772ee664 100644
--- a/understanding/21/reflow.html
+++ b/understanding/21/reflow.html
@@ -12,68 +12,245 @@
Understanding Reflow
In brief
-
Goal
Content can be enlarged without increasing line length.
-
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.
+
Goal
Content can be enlarged without needing to scroll in two directions.
+
What to do
Make long lines of text reflow within resized or zoomed in interfaces.
+
Why it's important
People who need bigger text find it difficult if they need to scroll back-and-forth to read multi-lined text.
-
+
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
-
-
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.
-
+
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.
+
+
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 expect to scroll up-and-down vertically to read that content.
+
+
+
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 if the scrollbars are necessary to scroll excepted content, and non-excepted sections of content otherwise meet Reflow.
+
+
However, whenever possible it is in the best interest of the user, to reduce physical and cognitive effort, to limit bi-directional scrolling only to the individual sections of content which necessitate such scrolling, rather than allow the page at large to scroll in two directions. For instance, one might maintain a single scrollbar at page level and confine content which needs bi-directional scrolling (such as a table) into a scrollable container.
+
+
+
+
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.
+
+
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 - while the actual user agent, and any UI provided directly by the user agent, remain scaled to the zoom level set by the operating system.
+
+
+
+
Vertically and horizontally scrolling content
+
Where a vertically scrolling interface has sections of content 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.
+
+
A vertically scrolling web page
+
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 standard desktop display, npr.org presents lead-ins to new stories, ads, and other multimedia widgets as distinct sections of content. The sections of content can vary in height, width and arrangement to visually fit together in the design of the web page, but none of the sections of content are reliant on their specific layout or visual relation to one another to be independently read or understood.
+
+
-
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.
+
+
+
+
The npr.org website layout reflows to accommodate different viewport sizes, which can occur due to browser resize, or use of browser zoom features. As the layout adjusts, the sections of content of the web page reflow. The distinct sections of content vertically stack, allowing for scrolling in a single direction to read. The primary navigation is initially hidden behind a disclosure widget button (a.k.a., a hamburger menu button), and the media player has been visually moved and simplified to allow it to remain persistent, but not obscure the content of the page.
+
+
+
+
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.
+
+
Thus, following responsive web design best practices can help many websites meet Reflow, the success criterion does not mandate fully responsive web pages. Building complex web interfaces (a.k.a., web apps) will often necessitate not only providing revised presentation, but revised functionality, or both when content is enlarged.
+
+
+
+
+
At larger viewport sizes with a default zoom level, buttons on a website invoke popup menus, with menu items that can invoke sub-menus. At zoomed in viewport sizes, such menus can pose difficulties for users because the menus are often partially positioned off-screen.
+
Revising the presentation and functionality of these menus, for instance by making them full screen and only presenting a single menu level at a time, can help ensure portions of the menu will not be positioned off-screen and thus difficult, if not impossible, for users to access.
+
+
+
+
Additionally, it can be common for web application to contain sections of content that meet one of Reflow's exceptions and can be presented in a bi-directional scrolling container within the otherwise single-direction scrolling interface.
+
+
Horizontally scrolling section within a vertically scrolling page
+
It is not uncommon for a web page to render a widget, such as a "carousel", "swim lane", or otherwise "horizontally scrolling container" which itself contains sub-sections of content that follow the otherwise esbalished reading direction of the page. Such widgets can meet the requirements of this success criterion, so long as the sub-sections of content can accommodate reflowing to each fit within the required width or height - per the intended reading direction each section represents.
+
+
+
+
+
A website provides a “carousel” or “swim-lane” of different panels of teaser (a.k.a., “lead-in”) content. This 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, like the primary content, even as the container scrolls horizontally.
+
+
+
+
+
+
+
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.
+
+
+
-
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.
+
Exceptions and content considerations 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 the content represents. As already mentioned, tabular data, graphics, maps, presentations, or interfaces that necessiate persistent toolbars.
+
+
Understanding the scope of exceptions
+
Where an exception for bi-directional scrolling would be applicable to a section of content, the exception does not extend to other sections of content which do not necessitate bi-directional scroling for understanding or functionality.
+
+
+
+
+
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.
+
+
+
+
Since a data table relies on two-dimensional layout for understanding, presenting the table in its own scrollable container would help ensure other content which does not meet an exception could reflow as the viewport adjusts.
+
+
+
+
+
Tabular data has a Reflow exception. An element that contains the a table with a minimum height, wdith or both, can be styled to provide bi-directional scrollbars allowing for a user to scroll the table's content and mitigating bi-directional 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 bi-dimensional scrollbars.
+
+
+
+
There can be instances where bi-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 - but can create an unwanted user experience. 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.
+
+
+
+
+
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 bi-directional 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.
+
+
+
+
+
+
+
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
+
For example, graphics and video are by their nature two-dimensional. Cutting 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%. Please review the advisory technique Using CSS max-width and height to fit images.
+
+
+
+
+
TODO info graphic example
+
+
+
+
Tabular data and grid-based UI
+
Data tables and data grids or grid-based UI have a two-dimensional relationship between the column and row headers and their associated data cells. This relationship is essential to convey the tabular data. This success criterion therefore exempts data tables and grids from needing to display without scrolling in the direction of text (e.g., horizontally in a vertically scrolling page). However, individual cells within tables and grids are not excepted - unless the cell contains types of content that also requires two-dimensional layout for usage or meaning.
+
+
Additionally, other content that is related to the table or grid, such as a heading or search field that might precede it, or a pagination navigation to load different sets of data that follows the table or grid, are not necessarily 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 - allowing a user to navigate to different “pages” of table content - would still be expected to wrap (reflow) to meet the intent of this criterion. Or, an "electronic program guide" used to display programs to stream online might be presented alongside other content outside of its grid-based UI. Such content, unless having their own exceptions, would be expected to reflow.
+
+
+
+
+
TODO table example
+
+
+
+
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 canvas area that it provides features for editing.
+
+
+
+
+
TODO: example of a persistent toolbar interface
+
+
+
+
Layout needed for usage and meaning
+
Additionally, many of these sorts of interfaces allow users to create content set to defined dimensions. For instance, presentations or documents based on physical printing or display sizes. These interfaces often allow for other related content to be created as directly related content to the primary author created content - e.g., presentation notes, editing comments/suggestions for a text document, dynamic messaging presented along with a message 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. For example, comments pertaining to a paragraph of text on one page of a document can be difficult to understand if they're not presented directly next to each other. Reflowing the comment inline with the document could cause the content of the document to be misrepresented or misconstrued as all being content written by the document's author, rather than separate authors (original author and editor).
+
+
+
+
+
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, and thus 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. Bi-directional scrollbars would be needed to ensure someone can horizontally scroll between the rich text document, to the column of comments.
+
+
+
+
+
+ Animated gif of a two column code-diff interface
+
+
+
+
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 - passing this success criterion.
+
+
While an alternate view can also exist to show each changed line stacked on top of each other, the two-column comparison view is maintained to allow for a more direct comparison between the original and modified lines of code, which some users may find easier to understand - particularly for instances where code diffs can take up multiple lines and thus could require much more scrolling to compare individual lines to each other.
+
+
+
+
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.
+
-
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.
+
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
+
+
+
+
While a 1280 by 1024 CSS pixel viewport size, zoomed by 400%, neatly aligns to the 320 and 256 CSS pixels sizing requirements of this success criterion, this success criterion is not mandating that all content fit within this exact viewport size, as explained in the Exceptions and Content Considerations for Reflow section. Additionally, not all users who could benefit from Reflow will be viewing web pages at this exact screen resolution.
+
+
+
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.
+
-
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.
+
Applicability for web content presented by user agents which do not support this SC's normative sizing requirements
+
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 device 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.
+
-
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.
+
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 some examples of potential overlaps with such criteria.
+
+
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 the intent of Reflow will commonly result in the enlargement of text, there 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 bi-directional 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, but the website presents fixed-position ads. The ads are often displayed in the lower corner of the browser when the page is rendered in larger viewports - but when attempting to zoom in the page, the ads do not become static. 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, navigations 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 actually 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 +266,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 noticable.
- 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+