-
Notifications
You must be signed in to change notification settings - Fork 285
/
Copy pathreflow.html
323 lines (280 loc) · 35.5 KB
/
reflow.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta charset="UTF-8"/>
<title>Understanding Reflow</title>
<link rel="stylesheet" type="text/css" href="../../css/sources.css" class="remove"/>
</head>
<body>
<h1>Understanding Reflow</h1>
<section id="brief">
<h2>In brief</h2>
<dl>
<dt>Goal</dt><dd>Content can be enlarged without needing to scroll in two dimensions.</dd>
<dt>What to do</dt><dd>Make long lines of text and other applicable content reflow within resized or zoomed in interfaces.</dd>
<dt>Why it's important</dt><dd>People who need larger text find it difficult if they need to scroll in two dimensions to read long lines that do not reflow.</dd>
</dl>
</section>
<section id="intent">
<h2>Intent of this Success Criterion</h2>
<p>The intent of this success criterion is to let users enlarge (zoom in) multiline sections of content without having to perform bi-directional scrolling to read. Lines that extend beyond the viewport in the direction of reading require scrolling back-and-forth to read, which can significantly increase both physical and cognitive effort and cause users to lose their place. Outside of content which necessitates bi-directional layout to understand or function, content is expected to reflow within the appropriate sizing requirement defined by this success criteria, in regards to the content's intended direction of reading.</p>
<p>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 that expects horizontal scrolling (such as traditional Chinese and Japanese) would not expect to scroll up-and-down vertically to read that content.</p>
<div class="note">
<p>Reflow does not prohibit web pages from presenting both horizontal and vertical scrollbars for individual sections of content, nor does it disallow the use of bi-directional scroll bars at the page (viewport) level, when the content has been enlarged.</p>
<p>However, it is often in the best interest of the user, to reduce physical and congnivite effort, to limit bi-directional scrolling only to the individual sections of content which necessiate such scrolling, rather than allow the page at large to sroll in two directions. For instance, one might maintain a single scroll bar at page level and confine content which needs bi-directional scrolling (such as a table) into a scrollable container.
</p>
</div>
<div class="note">
<p>An important factor in being able to support Reflow is for the user agent to allow users to adjust the size of content within specific windows of content. For instance, the browser's viewport.</p>
<p>Technologies such as HTML/CSS, PDF and ePub have methods of reflowing content to adjust to the size of the viewport. When appropriately authored, users can use zooming features, provided by the user agent (browser), to enlarge the content within the viewport. Unless otherwise prevented by author styling, the content of the web page will reflow (wrap) to adjust to the size of the viewport - 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.</p>
</div>
</section>
<section>
<h3>Vertically and horizontally scrolling content</h3>
<p>
Where a vertically scrolling interface has <a href="https://www.w3.org/TR/WCAG/#dfn-section">sections of content</a> which scroll horizontally, those sections would need to meet the 320px 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 256px horizontal scrolling requirement, or an exception to the criterion.
</p>
<h4>A vertically scrolling web page</h4>
<p>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.
</p>
<figure>
<img src="img/npr-large-screen.png" width="700" alt="screenshot of the npr.org home page. Displayed is the global site banner consisting of logo and primary navigation. A media player for live news radio. A primary story is displayed where the intro text and call to action links are presented in one column with a photograph related to the story in the column to its side. Directly beneath are three additional top stories in separate columns. Images introduce each followed by the story title and brief description. To the side of all the news stories is a sidebar for an advertisements to be displayed.">
<figcaption>
<p>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.</p>
</figcaption>
</figure>
<figure>
<img src="img/npr-reflow.png" width="500" alt="The npr.org site as rendered in a 320px wide viewport. The navigation in collapsed into a hamburger menu, so the global header visually is decluttered - redering only the hamburger button, npr logo an donate button by defaut. The media player has become a persistent sticky widget at the bottom of the viewport. News stories have been adjusted to fit into a single column - as only one news story lead-in can fit at a time into the reduced viewport size.">
<figcaption>
<p>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.</p>
</figcaption>
</figure>
<p>
While this 'stacking into a single column' approach may work for many web pages whose primary objective is to present sections of content for people to read (e.g., text and/or standard media such as graphics, videos that represent articles, blog posts, discussion threads, topic teasers, etc.); there are many instances of common, but complex, widgets and layouts which would become more difficult to visually understand or interact with if they were adjusted to fit in a single column layout.</p>
<p>Thus, while following responsive web design best practices will help many websites meet Reflow, the success criterion does not mandate fully responsive web pages. There will be instances in which more complex web interfaces need to expend additional effort by instead providing revised presentation, functionality, or both when content is enlarged - and thus presented in smaller viewport sizes. In other cases, aspects of the application's content will meet one of Reflow's exceptions and may be presented in a bi-directional scrolling container within the otherwise single-direction scrolling interface.
</p>
<h4>Horizontally scrolling section within a vertically scrolling page</h4>
<p>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.</p>
<figure>
<img src="img/carousel-large-screen.png" alt="horizontally scrolling carousel, containing multiple 'panels' of content (four visible in the screenshot).">
<figcaption>
<p>A website provides a “carousel” or “swim-lane” of different panels of teaser (a.k.a., “lead-in”) content.This content container allows for horizontal scrolling, independent from the vertical scrolling of the primary web page, and the vertical direction of reading of the individual sections of content within this horizontally scrolling container.</p>
</figcaption>
</figure>
<figure>
<img src="img/single-carousel-panel.png" alt="one of the carousel panels zoomed in 400%. The text vertically flowing text fits within 320px width container." width="550">
<figcaption>
<p>The content of each carousel "panel" (image, text content and call to action link visually represented as a right-pointing arrow icon) fit within a width of 320 CSS pixels. This helps ensure a user need only scroll vertically to read the text of each section of teaser content. The user can horizontally scroll the wrapping container element to bring each width-conforming panel of teaser content into view. A user can scroll vertically to view the image or read the text of each section of content.</p>
</figcaption>
</figure>
</section>
<section>
<h3>Exceptions and content considerations for Reflow</h3>
<p>
For many 'traditional' web pages where its primary purpose is for a user to read distinct short or long-form <a href="https://www.w3.org/TR/WCAG/#dfn-section">sections of content</a>, the web page is generally expected to scroll vertically (when written in languages such as English). For users with low vision who may need to zoom the web page to read its content, 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.</p>
<p>
Ideally, all sections of content would be able to reflow, allowing the content to be more easily read by users. However, not all content can reflow without degradation of the information or functionality the content represents - for instance, content which requires two-dimensional layout.
</p>
<h4>Understanding the scope of exceptions</h4>
<p>Where an exception for bi-directional scrolling would be applicable to a section or sections of content within a web page, such an exception does not extend to other sections of content which do not necessitate bi-directional scroling for understanding or functionality.</p>
<p>For example, while a data table would be given an exception to Reflow, presenting the table in a container which itself can scroll would help ensure other content which does not meet an exception could reflow as the viewport adjusts.</p>
<figure>
<img src="img/table-exception.jpg" alt="a table within a containing element that provides bi-directional scrollbars to view the content of the table. The content above and below the table reflows to fit within the available width of the viewport.">
<figcaption>
<p>Tabular data has a Reflow exception, so a containing element to the table can provide bi-directional scroll bars, mitigating bi-directional scroll bars appearing at the page level.</p>
</figcaption>
</figure>
<!--
TODO:
insert an example that has the table at a "full" width,
but also demonstrates other contnet of the page retaining
this "full" width, and thus failing reflow as the other
content "should" reflow.
the example of a full-width element that causes scrolling, but other content
still meets reflow exists below.
-->
<p>Even for content that meets the bi-directional scrolling exception, unless necessary, bi-directional scrolling at the page-level is best avoided. 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, e.g, the table, it can result in a poor user experience where someone spends time looking for <em>other</em> content that doesn't exist.</p>
<figure>
<img src="img/unnecessary-horizontal-scrollbar.jpg" width="600" alt="BBC Earth video extends far beyond the horizontal width of the browser's viewport, resulting in a large horizontal scroll bar for the web page. The content of the web page otherwise fits into a 320px wide container, which is validated by use of a browser's developer tools which show the containing element has a width of 320px.">
<figcaption>
<p>A video player without a <code>max-width: 100%</code> CSS property caused it to remain unnecessarily large at smaller viewport sizes. The rest of the page content was able to reflow into a 320 CSS pixel wide container. So while there was a large horizontal scroll bar at the page level, it was due to the video player which has a reflow exception. This 'passes' the Reflow SC, but is not a good user experience.</p>
</figcaption>
</figure>
<figure>
<img src="img/max-width-video.jpg" width="600" alt="video player visually fits within its containing element, and thus no horizontal scrollbar is present for the web page at a 320px wide viewport size.">
<figcaption>
<p>By providing the video player a <code>max-width: 100%</code> CSS property, the video now fits within the container element and thus no horizontal scroll bar is present on the page.</p>
</figcaption>
</figure>
<h4>Graphics and video</h4>
<p>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% (see advisory techniques).</p>
<figure>
<!-- insert an example of a graphic (info graphic) that fits the viewport or is presented at full height/width but within a scrollable container -->
<figcaption>
<p>TODO info graphic example</p>
</figcaption>
</figure>
<h4>Tabular data and grid-based UI</h4>
<p>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.</p>
<p>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.</p>
<figure>
<!-- insert different table example with pagination / prior content reflowing to show that content should reflow though
the table has the exception -->
<figcaption>
<p>TODO table example</p>
</figcaption>
</figure>
<h4>Interfaces with persistent toolbars</h4>
<p>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.</p>
<figure>
<img src="img/..." alt="TODO">
<figcaption>
<p>TODO: example of a persistent toolbar interface</p>
</figcaption>
</figure>
<h4>Layout needed for usage and meaning</h4>
<p>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).</p>
<figure>
<img src="img/rich-document-with-comment.png" alt="online rich text document - on the left: the text document is displayed at dimensions representing the physical width and height of the page. On the right, a comment referring to highlighted text in the text document.">
<figcaption>
<p>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.</p>
</figcaption>
</figure>
<figure>
<details>
<summary>Animated gif of a two column code-diff interface</summary>
<img src="img/code-diff.gif" alt="animated gif of a code editor, showing code lines 20 to 24. The differences between the original code and the modified code are presented as two columns, with the original on the left and the modified on the right. The gif demonstrates horizontally scrolling each column of code into view - within a 320 pixel wide viewport - where vertical scrolling is used to show that the full text of each column can then be read by scrolling in a single direction.">
</details>
<figcaption>
<p>
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 scroll bar can be used to position each column into the visible viewport - passing this success criterion.</p>
<p>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.
</p>
</figcaption>
</figure>
<p>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.</p>
</section>
<section>
<h3>Why specifically 320px and 256px?</h3>
<p>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.</p>
<figure id="figure-CSS-pixel-letter-4x">
<img src="img/css-pixel-by-device.png" width="462" height="198" alt="Diagram showing the size of character needed by viewing distance to make the same image on the retina with small screen devices close, large screen devices further away.">
<figcaption>A letter of the same CSS pixel size on different displays with different resolutions</figcaption>
</figure>
<div class="note">
<p>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, nor that all users who would benefit from Reflow would all be viewing web pages at this exact screen resolution.</p>
</div>
<p>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.</p>
</section>
<section>
<h3>Applicability for web content presented by user agents which do not support this SC's normative sizing requirements</h3>
<p>
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.
</p>
<p>
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.</p>
<p>
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.
</p>
</section>
<section>
<h3>Overlap with other success criteria</h3>
<p>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 wish such criteria.</p>
<h4>Resize Text</h4>
<p>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. <a href="resize-text">Success criterion 1.4.4 Resize Text</a> 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.
</p>
<p>
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.
</p>
<h4>Focus Not Obscured (Minimum)</h4>
<p>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.</p>
<p>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.</p>
<figure>
<img src="img/reflow-sticky-ad.png" width="550" alt="a music history website's section on the Medieval period of history. A fixed-position ad obstructs the majority of the content.">
<figcaption>
<p>
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.
</p>
</figcaption>
</figure>
<figure>
<img src="img/reflow-no-sticky-ad.png" width="550" alt="The same music history web page where the sticky ad no longer is sticky, and thus no longer covers the content of the page. The hyperlink 'Medieval Period of music' is visible within its paragraph of text.">
<figcaption>
<p>
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.
</p>
</figcaption>
</figure>
<div class="note">
<p>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.</p>
</div>
</section>
<section id="benefits">
<h2>Benefits</h2>
<ul>
<li>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.</li>
</ul>
</section>
<section id="examples">
<h2>Examples</h2>
<ul>
<li>
<strong>One column view in responsive design</strong>
<p><video controls="controls"><source src="https://alastairc.uk/w3c/reflow-example-1-BBC.mp4" type="video/mp4" /><source src="https://alastairc.uk/w3c/reflow-example-1-BBC.ogv" type="video/ogg" />Animation of zooming in on a responsive site. The content reflows to fit the screen.</video></p>
<p>Note that as the zoom percentage increases, the navigation changes first to hide options behind a "More" dropdown menu. As zooming continues, most navigation options are eventually behind a "hamburger" menu button. All the information and functionality is still available from this web page. There is no horizontal scrolling.</p>
</li>
<li>
<strong>PDF offering reflow</strong>
<p>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.</p>
</li>
<li>
<strong>Alternative presentations to truncating content</strong>
<p>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..</p>
</li>
</ul>
</section>
<section id="resources">
<h2>Resources </h2>
<ul>
<li>
<a href="https://www.google.com/url?q=https://docs.google.com/document/d/15ElCfY9VWzhPm3OSNofBe2x5Kt-nzt-TQFnZTcThV8o/edit&sa=D&source=docs&ust=1725541904107256&usg=AOvVaw0Y5vDE4bFZ6O1QbNOS094v">Reading with Low Vision in a Digital Setting: by Wayne Dick, PhD.</a>
</li>
<li><a href="http://web.archive.org/web/20220121073555/http://nosetothepage.org/Fitz/2dScroll.html">Operational Overhead Caused by Horizontal Scrolling Text</a> by Wayne Dick, 2017. The study shows the impact of horizontal scrolling on reading effort</li>
<li><a href="https://www.w3.org/TR/low-vision-needs/">Accessibility Requirements for People with Low Vision</a>. W3C First Public Working Draft 17 March 2016</li>
<li><a href="https://developer.mozilla.org/en-US/Apps/Progressive/Responsive">Responsive design resources</a> from MDN Web docs</li>
<li><a href="https://developers.google.com/web/fundamentals/design-and-ux/responsive/">Responsive web design basics</a> tutorial from Google</li>
</ul>
</section>
<section id="techniques">
<h2>Techniques for Success Criterion 1.4.10: Reflow</h2>
<section id="sufficient">
<h3>Sufficient Techniques</h3>
<ul>
<li><a href="../../techniques/css/C32">Using CSS grids to reflow content (CSS)</a></li>
<li><a href="../../techniques/css/C31">Using CSS Flexbox to reflow content (CSS)</a></li>
<li><a href="../../techniques/css/C33">C33</a></li>
<li><a href="../../techniques/css/C38">C38</a></li>
<li><a href="../../techniques/client-side-script/SCR34" class="script">SCR34</a></li>
<li><a href="../../techniques/general/G206" class="general">G206</a></li>
<li>Using PDF/UA when creating PDFs (Potential future technique)</li>
</ul>
</section>
<section id="advisory">
<h2>Advisory Techniques</h2>
<ul>
<li><a href="../../techniques/css/C34">C34</a></li>
<li><a href="../../techniques/CSS/C37">CSS, Fitting images to the viewport;</a></li>
<li>CSS, Reflowing simple data tables (Potential future technique)</li>
<li>CSS, Fitting data cells within the width of the viewport (Potential future technique)</li>
<li>Mechanism to allow mobile view at any time (Potential future technique)</li>
</ul>
</section>
<section id="failure">
<h2>Failures</h2>
<ul>
<li><a href="../Techniques/failures/F102" class="failure">Failure of success criterion 1.4.10 due to content disappearing and not being available when content has reflowed</a></li>
</ul>
</section>
</section><!-- end techniques -->
</body>
</html>