Reflow to Single Column

[allanj-uaag]

Current versions of SC and Definitions

• SC for viewing | SC for editing
• SC in full draft guideline ## Current versions of SC and Definitions
• Understanding doc for viewing | Understanding doc for editing | Understanding doc in master

Open issues and Surveys

Open issues: SC Status page

(Links to surveys require W3C Member access)

SC Shortname

Linearization

SC Text

A mechanism is available to view content as a single column, except for parts of the content where the spatial layout is essential to the function and understanding of the content.

Suggested Priority Level

Level A

Related Glossary additions or changes

none

Relevant Guidelines and Success Criteria

• Guideline 1.3 Flexible Data
  • SC 1.3.2 Meaningful Sequence
• Guideline 1.4 Distinguishable
• SC 1.4.4 Resize Text
• SC 1.4.8(2) Visual Presentation (width)
• Guideline 2.4 Navigable

Guideline 1.3 (Flexible Date) is essential for reflow. SC 1.3.2 (Meaningful Sequences) establishes the necessary structure for reflow to occur. Without reflow SC 1.4.4 (Resize Text) could not be extended to enable very large text. Finally, without reflow restriction of column size would be difficult. This allows raising the level of SC 1.4.8(2) (Visual Presentation (width)) to Level A.

Principle 1, Guideline 1.4 (Distinguishable) is the most appropriate location for this new success criteria. This is because it focuses on presentation of content in a single column of elements with all text in single column format.

The final fit for reflow is in Principle 2, Guideline 2.4 (Navigation). Most people with low vision could benefit from a single column view of a page. This is because items get lost in a two dimensional presentation. (See Benefits below)

Description

Content can be viewed in a single column. All text is presented in single column format and the Line Length SC ensures that all lines of text word wrap to fit the available space. Data tables will have a standard tabular display, a two-dimensional matrix. Some user agents do not support active data such as form controls in reflow. In these cases the content author is not responsible for creating content that reflows.

This good reflow of HTML was accomplished by a custom style sheet.

Properly reflowed PDF text.

Improper characters used by the author for spaces. This causes words to jam together with reflow. This authoring problem occurs frequently with PDF.

Benefits

One important need of most people with low vision is to reconfigure a presentation from a normal two-dimensional page to a one-dimensional organization of data. This is not always the case, but it is a frequent need. For quick scanning the original structure may be useful to scan for recognizable items. This is usually done when the user knows a page and is looking for just one thing. In cases where careful examination of the page is necessary one column presentation is needed. The reasons are given below.

1. Continuous Reading: Many people, with and without disabilities, find it more difficult to read when they must scroll from the bottom of a column of text to the top of another column. With low vision the need is greater. To go from one column to next frequently requires paging up several screens to get from the bottom of one column to the top of the next. Additionally, using a small scrollbar and cursor is difficult with limited sight. This makes getting from the bottom of a column and finding the top of the next column more difficult. Reading flow degrades and comprehension suffers.
2. Reliable Searching: (visual navigation of the viewport) Searching for a specific item within a page of information is difficult for almost everyone with low vision. This is because the field of vision is limited either by enlargement requirements, or physical visual field loss due to tunnel vision. The ability to only scroll in one dimension vertical only or horizontal only but not two dimensions, dramatically simplifies this problem. A person can start at the top of the page and move element by element down the page until the bottom, and be certain that every item has been scanned. (TSBVI,Specific Eye Conditions, Corresponding Impact on Vision, And Related Educational Considerations)
3. Resizing Text on a Large Scale: Two column or more do not support large print text. Even if text stays within column boundaries, multi-column format will not provide enough space for text in large print. Even medium length words will not fit for sizes exceeding 250%. This causes excessive hyphenation and becomes distracting. This criterion is a necessary condition for useful text resize criterion for people with visual acuity worse than 20/70. Many people in this range require print size greater than 1/2 in. (1 cm.). This cannot be sustained with standard formats. content.

User Need: Users can set blocks of text in one continuous block, instead of in multiple columns.

Source: Accessibility Requirements for People with Low Vision, Section 3.2.2

Testability

1. HTML: Use the Easy Checks - A First Review of Web Accessibility document, Basic Structure check. Check that the sequence of text is in fact a correct reading sequence. Note: These tests remove all style. This means that items that the author did not intend to be seen become visible. It can be useful to display the pages side by side to compare what is intended to be visible and what is not. If this test passes the content can be restructured into an accessible format for low vision using CSS and JavaScript.
2. PDF: With a user agent that enables reflow, use the reflow option to see content reflowed into one column. No lines should be truncated. If this operation is successful the document passes.

Techniques

Existing Relevant Techniques

• G57: Ordering the content in a meaningful sequence (Note: Correct Reading Sequence and meaningful sequence are the same in this context.)
• F1: Failure of Success Criterion 1.3.2 due to changing the meaning of content by positioning information with CSS

New Techniques

1. HTML: Write content so that the source order of perceivable elements defines a correct reading sequence. It is perfectly appropriate to include items that are not displayed to users in any convenient order. Such elements do not disrupt the correct reading sequence of the entire page. Make sure that elements that are not to be perceived are marked in a standard way like "display: none" or "visibility: hidden" so they can be ignored by a reformatting program. Test your document with no style in your user agent(s). See that it makes sense as a page and is fully operable. After this content is arranged and tested, positioning and other block formatting of the page. Use style sheets for positioning so that it can be removed and the resulting view is readable and operable.
2. HTML: Use media queries based on em units for reflow to single column. Reason: When the line length shrinks below a certain number of characters, reflow to a single column is triggered whether the reduced character count is caused by shortened lines or increased font size. This makes the reflow to single column accessible on more devices.
3. Fxx: Text becomes unreadable because of reflow.
4. Fxx: Failure of Success Criteria Text Colors and Reflow to Single Column due to inserting important information by using the background-image property of CSS.
   Note: This is necessary because non-decorative images cannot be reflowed.

Related Information

Articles

• HTML Source Order vs CSS Display Order - Adrian Roselli

Email

• Reflow is ready, and so is Line length - Wayne Dick, 15 November 2016
• Terminology Question (LVTF thread) Wayne Dick, 1 November 2016
• Latest Reflow - Wayne Dick, 31 October 2016
• Reflow test case (Thread) - Alastair Campbell, 23 October 2016
• Reflow Final Draft Wayne Dick, 4 October 2016
• Reflow LVTF Thread 30 September 2016
• I have made changes to Line Length and Reflow to Single Column - Wayne Dick, 20 August 2016
• Requirements doc - Alastair Campbell, 18 February 2016

GitHub

• Reflow to Single Column - WCAG 1.4.8 item 5 or New item LVTF GitHub SC Issue #7

Minutes

• 17 November 2016 LVTF Minutes
• 27 October 2016 LVTF Minutes
• 20 October 2016 LVTF Minutes
• 13 October 2016 LVTF Minutes
• 06 October 2016 LVTF Minutes (Informal Meeting)
• 29 September 2016 LVTF Minutes
• 4 May 2016 LVTF minutes

Surveys

• Survey items for October 20 LVTF meeting

Wiki Pages

[GreggVan]

Great SC except that there are MANY other exeptions you need to make. MAPS, Diagrams, drawings, plans, schematics , etc.

And you can't make them by list -- you will always exclude them.

Before this can advance (and it is a good one ) you need to capture what needs to flow and what does not / can not without destroying the information.

hmmmm

how about

Except where reflow causes distortion or loss of information.

OH another problem
you just said single column. you didnt say REFLOW nor specify column width.

(also wrong form for an SC)

Maybe

All content can be viewed as a single column with reflow
except where reflow would cause distortion or loss of information

[alastc]

Can we use a similar exception to #77 Resize content?
...unless "the spatial layout of some the content is essential to that contents use, that part of the content is exempt."

It is worth considering these two together, as effectively Resize content is for browser based zoom up to 400%, and this one goes beyond that for people who re-style the content or remove styles from the content.

[DavidMacDonald]

If #57, #58 are not combined, here's a tweak of #58. Don't need the bit about reading order... its already required. SC 1.3.2

Content can be viewed as a single column, except where:

1. The content is in data tables which have more than one column
2. Content contains interactive controls that cannot be reflowed
3. Reflow would cause distortion or loss of information

---

Gregg raised concern that this list of exceptions could end up endless, and that we should find another way to characterizes the quality of the exceptions and make one generic statement. He suggested "except where reflow would cause distortion or loss of information". I added the third exception to try to address this possible endless list. (the 3rd bullet could also be something like "The layout is essential to the function and understanding of the content")

[mbgower]

Okay, last of my broad LVTF comments...
I'd like to assert that IF you make a requirement to Reflow into a single column without horizontal scrolling, it is very difficult to imagine a situation where you would need a more elaborate Resize Text requirement. If I can reach the existing 200% Resize Text and my authoring enables the new requirement to reflow into a single column without horizontal scrolling, then there should be nothing impeding the reflow to the abilities of the user agent, be they 250%, 500% or whatever. Can anyone think of a scenario where this would not be the case?

I think the reverse applies as well: if you don't offer the ability to reflow to a single column, you are going to have great difficulty achieving 400% magnificiation without scrollbars. So I don't see anything gained by creating both new requirements.

[DavidMacDonald]

If #57 and #58 are combined it could be something like this

A mechanism is available to view content as a single column, with blocks of text in this column user adjustable to 25 characters without requiring two dimensional scrolling, except where:

• The content is in a data table which have more that one column.
• The content contains interactive controls that that cannot be reflowed.
• The user-agent fits the layout to the view port, and does not provide a means of re-flowing content.
• Reflow would cause distortion or loss of information [OR The spatial layout is essential to the function and understanding of the content.]

[DavidMacDonald]

@mbgower I think most modern browsers stop at about 400%. There might be an argument for combining #77 resize one in here with #57 and #58. But I'm thinking we may want to leave them separate in the draft.

[alastc]

@mbgower For context, the original user-requirement was for the ability for a 1100% increase in sizing without horizontal scrolling!

That was broken down into two:

1. Resize content (400%), an advance on the current resize text but making use of responsive techniques. This is something content authors should test for as part of normal display with the site CSS, branding etc. Given the spread of mobile compatibility, this is not the same difficulty it used to be.
2. Reflow, aimed at 400% and above, assuming that the site styles are being over-ridden, so is to enable people to remove the layout and still read content in the correct order.

If you consider SC 1.3.2 to cover reading order in that scenario then arguably it could cover reflow, but previously it hasn't been interpreted that way.

The impact of these could be that the current 1.4.4 is redundant, however, it is still useful for niche cases within the exceptions. E.g. for content which requires 2D and can scroll, the text should be increased by 200%.

A short screencast to show visually how some of that is intended to work.

[lseeman]

merge with merge with visual-presentation wcag issue 51 Or
with support-personalization wcag issue 6

[DavidMacDonald]

Link to Lisa's proposal #51

[mbgower]

@alastc said:

the original user-requirement was for the ability for 1100% increase in sizing without horizontal scrolling!

Can you please explain the rationale for that target?
I'd also like to understand how you approach this target without AT. The most magnification I've seen in a user agent is 500%. Reflow doesn't make that number go any higher.
Reflow gives an author the ability to magnify 4x without scrolling. My admittedly quick assessment of a handful of well-known/used sites suggests that the breakpoint to a single column for most sites is much earlier than 400%. No site I tested with any kind of 'rich' content could achieve a 4x magnification without both scrollbars unless content was reflowed to a single column.

I guess if a user overrode the CSS of a page and made all the text very large THEN magnified it, they could approach 11x, but ultimately there are only 2 things authors need to do to achieve that: Reflow (to single column, no horizontal) and don't impede users' ability to use their own style sheets. I welcome being shown the failure of my logic, but it still seems to me that with just two such SCs in place, we arrive at a place where the limitations are all on the user agent (and beyond the control of the author).

If you consider SC 1.3.2 to cover reading order in that scenario then arguably it could cover reflow,

I was not considering Meaningful Sequence in this discussion. I've normally thought of that as a requirement to ensure the visual order matches the DOM order (as read by an AT, etc). I'd expect less issues with a single column reflow, but I would be surprised if that resolved all meaningful sequence issues.

1.4.4 is redundant, however, it is still useful for niche cases within the exceptions.

Given the need for backward compatibility, as well as to cover the exceptions, absolutely it is useful. I'll be a bit cheeky and suggest the 400% proposal seems to be redundant. If someone can reflow to single column without horizontal scrolling, and they are successfully meeting the 200% requirement, the limitation would seem to me to be the user agent. If folks want to specify 400% I'm not going to lose much sleep, but it seems unnecessary.

[mbgower]

BTW, shouldn't no two-dimensional scrolling (or whatever we're going to call it) be specified in this SC? Just because something is one column, doesn't mean it fits the browser width. I think that has to be clearly stated -- and there may need to be some language around the minimum width supported (or perhaps that's a user agent item).

[DavidMacDonald]

@alastc Here is the consensus proposal from LVTF for this issue.

Content can be viewed as a single column, except where:

• The content is in data tables which have more than one column
• Content contains interactive controls that cannot be reflowed

Gregg says: Great SC except that there are MANY other exceptions you need to make. MAPS, Diagrams, drawings, plans, schematics , etc. And you can't make them by list -- you will always exclude them. Before this can advance (and it is a good one ) you need to capture what needs to flow and what does not / can not without destroying the information. The following are possible third bullets. @GreggVan

• Reflow would cause distortion or loss of information OR
• The spatial layout is essential to the function and understanding of the content.

[alastc]

@mbgower I think we're talking at cross purposes here.

Did you see this email to the thread? https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JanMar/0202.html and the screencast? https://alastairc.ac/tests/layouts/resizing-scs.mp4

Reflow is the name of the SC, not necessarily the mechanism, perhaps we need to call it linearisability or something?

Can you please explain the rationale for that [1100%] target?

That is what some people with low vision need, and use when they can. You can get there in a browser, but you have to use both zoom and text size via user-stylesheets or something like that.

If I can reach the existing 200% Resize Text and my authoring enables the new requirement to reflow into a single column without horizontal scrolling, then there should be nothing impeding the reflow to the abilities of the user agent, be they 250%, 500% or whatever. Can anyone think of a scenario where this would not be the case?

It is not the case for most sites (which do get to 400%) under author-styles. At over 400% zoom, author-defined layouts will break down with no easy options available to the author. The branding at the top, the menus (even mobile optimised ones) will start overlapping. You have to take an extreme 'linearise all the things' approach.

Check this example page, and use the link "Linearise page at 20em wide" so see what I mean. That is orthogonal to sizing, some people have little peripheral vision and don't increase the size, but can't see very widely.

Also note how the navigation at the top changes order differently under a reflow and zooming-reflow.

ultimately there are only 2 things authors need to do to achieve that: Reflow (to single column, no horizontal) and don't impede users' ability to use their own style sheets.

Exactly, the first is covered by Resize content, and this is aimed primarily at the second.

I'd expect less [meaningful sequence] issues with a single column reflow, but I would be surprised if that resolved all meaningful sequence issues.

Agreed, and previously meaningful sequence hasn't been applied to the low-vision use case (thus the need for an SC).

If someone can reflow to single column without horizontal scrolling, and they are successfully meeting the 200% requirement, the limitation would seem to me to be the user agent.

The current 200% doesn't prevent horizontal scrolling, so it is not good enough. As soon as you put in a requirement for no horizontal scrolling then you need media queries to reflow, and if you have those, 400% is quite reasonable.

Also, we haven't had much luck with getting the user agents to change...

-Alastair

[DavidMacDonald]

@alastc change short name to "Single column:

Single Column: Content can be viewed as a single column, except where:

• The content is in data tables which have more than one column
• Content contains interactive controls that cannot be reflowed
• The spatial layout is essential to the function and understanding of the content.

==OR==

Single Column: A mechanism is available to view content as a single column, except where the spatial layout is essential to the function and understanding of the content.

==OR===

Single Column: Content can be viewed as a single column, except where the spatial layout is essential to the function and understanding of the content.

============
Then in the understanding we could list Tables, Interactive controls, maps, diagrams, drawings, plans, schematics , etc.

[alastc]

I'm not sure which option best indicates that the mechanism for making in single column can be done with the UA? What do you think about "Linearisation" as the short name?

Personally, I think data-tables and interactive controls should be covered under:

The spatial layout is essential to the function and understanding of the content.

That can be confirmed in the understanding doc.

Therefore I'm leaning towards:

Linearisation: A mechanism is available to view content as a single column, except where the spatial layout is essential to the function and understanding of the content.

Except that it implies if any of the content relies on spatial layout, the whole page is exempt.

So, how about:

Linearisation: A mechanism is available to view content as a single column, except where the spatial layout is essential to the function and understanding of the content, that part of the content is exempt.

Getting a bit long, but it has the meaning we want...

[DavidMacDonald]

I'm ok with that.... Word smithing to remove a few redundant words, might look like this:

Linearisation: A mechanism is available to view content as a single column, except for parts of the content where the spatial layout is essential to the function and understanding of the content.

[alastc]

Ah, better, thanks.

[DavidMacDonald]

OK I'll submit this as ready for group review.

[alastc]

Yep, presumably at the same level, so exempt anything within that block.

[alastc]

Noting another comment about the mechanism language:

this requirement sounds like it's asking for websites to place a "linearize" button on the page.

[joshueoconnor]

@alastc Could people who needed content linearised or single-column formatted - like this, not have a plug in etc that did this? So the dev has to code things in a way that just facilitates this functionality? That to me is reasonable, rather then the dev themselves having to have a 'mechanism'?

[alastc]

@joshueoconnor Yep, that's the primary aim. It is in the same category (in customisation levels) as adapting text - let the user do it. Maybe we can import the note from adapting text.

[joshueoconnor]

@alastc Sounds good to me :-)

[jake-abma]

Trying to get grip on this SC here some small remarks:

At “Relevant Guidelines and Success Criteria” I’m wondering if guideline 1.3 will be renamed as I see “Guideline 1.3 (Flexible Date) is essential for reflow.” I didn’t think 2.0 text would be changed and the current name is “Adaptable”.

textual corrections: “Flexible Date” should be “Flexible Data” and “(Meaningful Sequences)” should be “(Meaningful Sequence)”

[jake-abma]

About raising the level of SC 1.4.8(2) to Level A: I do understand there is a relation between 1.4.8(2) and Reflow to Single Column but restricting column size seems not appropriate. It could be that I do want to make a very wide column with big text for a web application shown on a large screen. So I’m wondering if 1.4.8(2) is relevant here as restricting to 80 characters for a Level A seems too strict.

[jake-abma]

The most appropriate location to me seems Principle 1, Guideline 1.3 (Adaptable) and not as suggested Principle 1, Guideline 1.4 (Distinguishable). This because 1.3 is about “Create content that can be presented in different ways (for example simpler layout) without losing information or structure.” Especially if we expect user to linearize content themselves. Guideline 1.4 is concerned with making the default presentation as easy to perceive as possible although I realize SC 1.4.4 Resize Text sits in 1.4.

Extending on this (Adaptable) I see we need to fix the concerns as Leonie mentioned when she brings on a valid issue when tables are used for layout: #58 (comment) This must be addressed.

And also Fiona has a point #58 (comment) for show/hide content and turning off CSS but this is inherent if we take the comment of Alastair into account at: #58 (comment) nr.2

So when Linearization is about adaptable content as Alastair says “but to make sure that if someone does forcibly reflow the content, the reading order makes sense.” It seems to me the content author only needs to be sure there is meaningful sequence in the DOM for web (HTML) .

[jake-abma]

The suggestion that reflow if covered by SC 1.3.2. seems valid especially when reading the text in the thread https://lists.w3.org/Archives/Public/w3c-wai-gl/2017JanMar/0202.html “2. Reflow to single column [2] is to enable people to go beyond 400% and have a correct reading order. It is NOT intended to be the authors responsibility to make the reflow happen (in HMTL), but to make sure that if someone does forcibly reflow the content, the reading order makes sense.”

In SC 1.3.2 we also have “For clarity: Providing a particular linear order is only required where it affects meaning.” And this covers linearization, not?

As Wayne already says in #58 (comment) “We can already produce a linearized accessibility API. Why is that so difficult in the browser?” isn’t this already true in the case of the DOM which must have a meaningful sequence (SC 1.3.2) and thus fits the condition for linearization?

[jake-abma]

As John says #58 (comment) “Tables can be linearized today“ and Alastair at #58 (comment) and #58 (comment) this is true from a CSS perspective if this is what you mean but not from an accessibility perspective as playing with the display property for a table removes the role from the accessibility API and causing screen readers to not recognize them as tables anymore. This means if you’re zoomed in and using a screen reader the tables are not read properly anymore. Also using the arrow keys cause strange behaviour skipping / jumping around.

[jake-abma]

For “A mechanism is available to view content…” I wonder if this is something a content author should / could provide or that it is a function of a user / user agent for instance and I see this was also mentioned by Paul and referenced by Alastair: #58 (comment). And Jared at #249
Seems like we’re steering at making it possible for users to do the linearization themselves and not providing a mechanism (to be available).

[GreggVan]

The difference between "“A mechanism is available” and "“A mechanism is provided” is that with “A mechanism is available” — the author can rely on the mechanism being provided on the other end and they just need to support it. With the “A mechanism is provided” - the author would need to provide it. This should be clear from the Understanding WCAG 2.0 document — and if it is not - it needs to be added so that it is clear. g

…

On May 5, 2017, at 6:04 AM, Jake Abma ***@***.***> wrote: For “A mechanism is available to view content…” I wonder if this is something a content author should / could provide or that it is a function of a user / user agent for instance and I see this was also mentioned by Paul and referenced by Alastair: #58 (comment) <#58 (comment)>. And Jared at #249 <#249> Seems like we’re steering at making it possible for users to do the linearization themselves and not providing a mechanism (to be available). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#58 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3psFnMi_3XbuMKVuQpVJf8Pwz-IBks5r2vQmgaJpZM4K-ARo>.

[DavidMacDonald]

Comment on linearization. I've accommodated and trained employees with low vision in banks and government for about 15 years. My experience is that once we need more than 400% (4x zoom), we are really into screen reader territory. I generally say "OK lets start thinking about migrating to learning a screen reader."

Almost all users I've worked at were extremely relieved to transition to screen reader at anything over 400%. One employee was nervouse to go to screen reader and hung onto zooming til it was 20x. (about 5 letters on a 27"screen) When we finally went to screen reader she was extremely relieved and wish she had done it sooner.

I don't think WCAG 2.1 should try to accommodate more than 400% without assistive technology. I think the ask upon the developer is disproportionate to the benefit to most end users.

I think after 400% the end user either needs AT like ZoomText's docreader app which reflows content, a screen reader, or other other means. I don't think it should be the author's responsibility at this point in history.

[joshueoconnor]

+1 to @DavidMacDonald

[alastc]

My experience is that once we need more than 400% (4x zoom), we are really into screen reader territory

Perhaps that is because there haven't been any good intermediate options? (I think Wayne and others would say magnification isn't a good option, at least for reading.)

I don't think WCAG 2.1 should try to accommodate more than 400% without assistive technology.

Do we consider user-side scripts/extensions AT? It is adapting the interface in a way that the author doesn't specify, so I would have thought so.

An important point about this SC is that we don't expect the author to provide a different interface, we expect them not to prevent the user making one.

[KerstinProbiesch]

I think that also in this case a note should be added, that the WG is seeking input on PDF.

[alastc]

I think you mean that for #77?

[KerstinProbiesch]

@alastc Also for this SC cause a PDF reflow is explicitly mentioned.

[alastc]

ok, I just meant this one hasn't gotten as far along yet, I don't think it is up for a CFC yet.

[DavidMacDonald]

(I think Wayne and others would say magnification isn't a good option, at least for reading.)

The docreader pulls out the content and reflows it and does anything with the text the user wants. It's not perfect. It can be heavy on the system, and doesn't pull put controls etc... But I'll stand by my experience with many low vision employees. More than 400% is getting into screen reader territory, and it's a huge ask on developers in today's wild west environment.

https://www.youtube.com/watch?v=6cbYmbeDZyQ
See at around 2:30.

[alastc]

Hi David,

The idea of this SC is to make something like ZoomText's docreader for the web work.

So this:

Becomes this (or something like it, the colours and size would be down to preference):

Simply by running a user-side script (that's a real example using bookmarklets).

As I've said above the mechanism is fairly straightforward, the things devs would have to worry about are mixing in layout with JS, and checking that dynamic updates to layout work when the layout has been neutralised.

[mraccess77]

Last time I checked the ZT doc read in PDF (Acrobat) it appeared that i was copying the content from the page using something like the clipboard and inserting it into the doc reader. I could be wrong and maybe on the web it is more complex than that.

[alastc]

According to their video the DocReader is for Word/PDF, and it does pull the text into a separate window. (AppReader they suggest for web content, but that reads it out audibly whilst highlighting the location, it doesn't try and re-format the text.)

[DavidMacDonald]

According to their video the DocReader is for Word/PDF,

Doc Reader is for HTML also.