w3c / wcag21

Repository used during WCAG 2.1 development. New issues, Technique ideas, and comments should be filed at the WCAG repository at https://github.com/w3c/wcag.
https://w3c.github.io/wcag/21/guidelines/
Other
140 stars 55 forks source link

Reflow to Single Column #58

Closed allanj-uaag closed 7 years ago

allanj-uaag commented 7 years ago

Current versions of SC and Definitions

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 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.

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

good PDF reflow

Properly reflowed PDF text.

bad PDF relow

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

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

Email

GitHub

Minutes

Surveys

Wiki Pages

GreggVan commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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:

DavidMacDonald commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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

DavidMacDonald commented 7 years ago

Link to Lisa's proposal #51

mbgower commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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

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

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

alastc commented 7 years ago

@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 commented 7 years ago

@alastc change short name to "Single column:

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

==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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Ah, better, thanks.

DavidMacDonald commented 7 years ago

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

johnfoliot commented 7 years ago

From WG call of 01/17/17 What would happen if content was laid out in

- would that content pass or fail? Tables can be linearized today, although doing so may break the grid layout being sought by developers who might use code like this.

alastc commented 7 years ago

I assume that was tables? It would pass if it linearised in an understandable order & was visible, and fail if it did not. It would be exempt if you would lose information from linearising it.

GreggVan commented 7 years ago

Hi

A few thoughts on reflow SC

you can’t linearize a table without breaking the relationships horizontally or vertically.

you can linearize but you need to linearize it twice — and even then you can’t alternately look at horizontal and vertical relationships without having to jump back and forth between the linearizations)

and if it is not a simple table…. You are pretty much hosed.

Tables are also not the only information that can’t be linearized. Maps, diagrams, and any other spatially encoded information.

So linearization or reflow is great and should be required for all “running text” where reflow would not change the meaning or functionality. But not all content can be reflowed. Not all web technologies allow reflow either— so if you want to be technology independent — you need to consider that as well.

Best

gregg

LJWatson commented 7 years ago

This feedback is based on a collective review by @PatrickHLauke @JSpellman, @IanPouncey and @LJWatson

The intent of this SC addresses a valid use case (one discussed by @alastc and @LJWatson as far back as Techshare 2005), and incorporates important concepts like horizontal scrolling, but it appears to have quite serious ramifications.

Our reading of this proposal is that it would take current (if not ideal) methods for controlling layout and make them invalid. For example, a layout using <table role="presentation"> would conform to WCAG2.0, but fail 2.1. It could (and should) be argued that table based layouts are to be discouraged, but the same concern applies to the far more widespread use of fixed width layouts.

To be clear, we think this SC is a good idea, but the difficulty in meeting it can't be over-emphasised.

alastc commented 7 years ago

Thanks @LJWatson,

The intent is that the author wouldn't have to provide the mechanism for reflowing content unless they actively prevent it. I realise, especially reading the exceptions, that this is not clear yet. There has been some confusion in the group about this, and it has manifested in the language.

But to focus on the intent, a user would be over-riding the author styles. I made a little test case to especially tackle tables: https://alastairc.ac/tests/layouts/pixels-tables.html

The page layout is pixel based, and it includes 3 tables. the first two are layout, the last is a data table. The two 'linearise' links on the right are actually bookmarklets that apply a short script. That script linearises the page, over-riding the set styles.

I'm afraid it is a visual example but I'll drop some example code is as well. For tables the (jQuery based script) includes things like:

var layoutTableCells = $('table[role=presentation] td');
$(layoutTableCells).css('display', 'block');

That's a simple method of linearising the table. The method of identifying layout tables could obviously be expanded, but the principle is there.

For data tables it includes this to keep them within the viewport:

var dataTables = $('table:has(th)');
$(dataTables).wrapAll( "<div style='width: 100%; overflow:auto; outline:3px grey solid;padding:3px' />");

It also includes more to remove positioning etc.

So the idea is that a user would have this type of thing as a user-stylesheet, bookmarklet, or browser extension.

There is more work to do in terms of defining techniques, finding out what exactly prevents users from doing this now. There are many reasons why this bookmarklet doesn't work across all sites, but it is working out which can be solved by improving the 'user-agent' script, and which the site author has to do.

There is also plenty of "prior-art" along these lines from things like instapaper, Safari reader, and thankfully an open-source one called Just Read.

DavidMacDonald commented 7 years ago

and if it is not a simple table…. You are pretty much hosed.

@greggvan Wouldn't the exception cover it.

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.

GreggVan commented 7 years ago

Looks like it would to me

G

There will be a lot of debate about what does or does not fall into "essential to the function and understanding of the content.” but a glossary item and the Understanding WCAG 2.0 (2.1?) doc could help there.

gregg

On Jan 22, 2017, at 1:55 AM, David MacDonald notifications@github.com wrote:

and if it is not a simple table…. You are pretty much hosed.

Wouldn't the exception cover it.

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.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/58#issuecomment-274313209, or mute the thread https://github.com/notifications/unsubscribe-auth/AJph3jIUl-zsHDdWMAgj2p-eCfSbUoxNks5rUv1YgaJpZM4K-ARo.

awkawk commented 7 years ago

Closing since the Pull request was created for this SC. New comments go there: https://github.com/w3c/wcag21/pull/89

DavidMacDonald commented 7 years ago

In an attempt to address the TPG comments by @LJWatson which suggests this is too broad a requirement, and too difficult to meet, I think perhaps changing "content" to "running text" or "blocks of text" would cover a significant amount of the problem in @WayneEDick article on usability problems with horizontal scroll while reading text. http://nosetothepage.org/Fitz/2dScroll.html.

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

Running Text: More than 25 characters of text (13 in CJK)

allanj-uaag commented 7 years ago

+1 For block of text. Won't have to define a new term.

On Feb 2, 2017 11:36 AM, "David MacDonald" notifications@github.com wrote:

I think perhaps "running text" or "blocks of text" would cover a significant amount of the problem.

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

New definition: Running text: More than one clause of text.

If that definition doesn't work we we could fall back to "blocks of text" which is already defined as "more than one sentence of text".

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/58#issuecomment-277026733, or mute the thread https://github.com/notifications/unsubscribe-auth/AG_WL7nZJ6XNTC1LoPcw_XfOSQtQfxW5ks5rYhQmgaJpZM4K-ARo .

GreggVan commented 7 years ago

I think a better definition of running text would be something like:

Running text text whose meaning is is derived solely from its linear presentation of one word after the other, and where positioning of words on the page or wrapping of the text does not affect it's meaning or impact.

You can then talk about content which consists of blocks of running text ( the blocks being paragraph sort them)

gregg

On Feb 2, 2017, at 6:36 PM, David MacDonald notifications@github.com wrote:

I think perhaps "running text" or "blocks of text" would cover a significant amount of the problem.

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

New definition: Running text: More than one clause of text.

If that definition doesn't work we we could fall back to "blocks of text" which is already defined as "more than one sentence of text".

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/58#issuecomment-277026733, or mute the thread https://github.com/notifications/unsubscribe-auth/AJph3lohxGTVuosk2AstKVExfaOgUW7Lks5rYhQmgaJpZM4K-ARo.

WayneEDick commented 7 years ago

Absoutely NO. This is linearize content, not just text.

On Thu, Feb 2, 2017 at 9:38 AM, David MacDonald notifications@github.com wrote:

I think perhaps "running text" or "blocks of text" would cover a significant amount of the problem in @WayneEDick https://github.com/WayneEDick article on usability problems with horizontal scroll while reading text. http://nosetothepage.org/Fitz/ 2dScroll.html.

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

New definition: Running text: More than one clause of text.

If that definition doesn't work we we could fall back to "blocks of text" which is already defined as "more than one sentence of text".

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/58#issuecomment-277026733, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0OF-dRbiiAtrY0vhqkt5cdYLDqrYHuks5rYhR9gaJpZM4K-ARo .

WayneEDick commented 7 years ago

Running text is not enough. I can't tell you how many important phrases are chopped by boxes that are too small.

Linearize means linearization of block items. The text will follow.

Why can't we have that. We can already produce a linearized accessibility API. Why is that so difficult in the browser?

Wayne

On Thu, Feb 2, 2017 at 10:44 AM, Wayne Dick wayneedick@gmail.com wrote:

Absoutely NO. This is linearize content, not just text.

On Thu, Feb 2, 2017 at 9:38 AM, David MacDonald notifications@github.com wrote:

I think perhaps "running text" or "blocks of text" would cover a significant amount of the problem in @WayneEDick https://github.com/WayneEDick article on usability problems with horizontal scroll while reading text. http://nosetothepage.org/Fitz/ 2dScroll.html.

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

New definition: Running text: More than one clause of text.

If that definition doesn't work we we could fall back to "blocks of text" which is already defined as "more than one sentence of text".

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/58#issuecomment-277026733, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0OF-dRbiiAtrY0vhqkt5cdYLDqrYHuks5rYhR9gaJpZM4K-ARo .

GreggVan commented 7 years ago

what do you mean Wayne

I’m not sure what you are referring to.

I was answering the question of a good definition of “running Text"

you can’t define text to mean more than text.

If you want to change it to “running content” then you can include more than text.

gregg

On Feb 2, 2017, at 7:45 PM, WayneEDick notifications@github.com wrote:

Absoutely NO. This is linearize content, not just text.

On Thu, Feb 2, 2017 at 9:38 AM, David MacDonald notifications@github.com wrote:

I think perhaps "running text" or "blocks of text" would cover a significant amount of the problem in @WayneEDick https://github.com/WayneEDick article on usability problems with horizontal scroll while reading text. http://nosetothepage.org/Fitz/ 2dScroll.html.

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

New definition: Running text: More than one clause of text.

If that definition doesn't work we we could fall back to "blocks of text" which is already defined as "more than one sentence of text".

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/58#issuecomment-277026733, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0OF-dRbiiAtrY0vhqkt5cdYLDqrYHuks5rYhR9gaJpZM4K-ARo .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/58#issuecomment-277045162, or mute the thread https://github.com/notifications/unsubscribe-auth/AJph3hneOPeo-i6Q6Qz25oml0fYf3U71ks5rYiQ7gaJpZM4K-ARo.

WayneEDick commented 7 years ago

Linearization is not just about word wrapping. It is about organizing the page in a format so that it can be read without loosing document elements because they are way out on the periphery. This is for people who need enlargement and for people who need narrow field of view.

Otherwise we need to reinsert a width limit.

WCAG 2.1 is first draft is about putting the real needs out there. Just linerizing text is not the only issue. People with low vision have a reduced visual field. It may be medical(tunnel vision) or practical (induced by enlargement). Linearization is necessary for both.

Many do need very large print wrapped, but many need a linear page to sort through everything.

The statement above renders it very ineffective. Not what is wanted or intended from the LVTF. This is the most import SC to get right.

Wayne

On Thu, Feb 2, 2017 at 10:47 AM, Wayne Dick wayneedick@gmail.com wrote:

Running text is not enough. I can't tell you how many important phrases are chopped by boxes that are too small.

Linearize means linearization of block items. The text will follow.

Why can't we have that. We can already produce a linearized accessibility API. Why is that so difficult in the browser?

Wayne

On Thu, Feb 2, 2017 at 10:44 AM, Wayne Dick wayneedick@gmail.com wrote:

Absoutely NO. This is linearize content, not just text.

On Thu, Feb 2, 2017 at 9:38 AM, David MacDonald <notifications@github.com

wrote:

I think perhaps "running text" or "blocks of text" would cover a significant amount of the problem in @WayneEDick https://github.com/WayneEDick article on usability problems with horizontal scroll while reading text. http://nosetothepage.org/Fitz/ 2dScroll.html.

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

New definition: Running text: More than one clause of text.

If that definition doesn't work we we could fall back to "blocks of text" which is already defined as "more than one sentence of text".

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/58#issuecomment-277026733, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0OF-dRbiiAtrY0vhqkt5cdYLDqrYHuks5rYhR9gaJpZM4K-ARo .

WayneEDick commented 7 years ago

The first term had a proposed SC that was a significant change form the LVTF SC. So changed that it lost its point. Maybe it was old and I didn't see the date.

Wayne

On Thu, Feb 2, 2017 at 10:53 AM, GreggVan notifications@github.com wrote:

what do you mean Wayne

I’m not sure what you are referring to.

I was answering the question of a good definition of “running Text"

you can’t define text to mean more than text.

If you want to change it to “running content” then you can include more than text.

gregg

On Feb 2, 2017, at 7:45 PM, WayneEDick notifications@github.com wrote:

Absoutely NO. This is linearize content, not just text.

On Thu, Feb 2, 2017 at 9:38 AM, David MacDonald < notifications@github.com> wrote:

I think perhaps "running text" or "blocks of text" would cover a significant amount of the problem in @WayneEDick https://github.com/WayneEDick article on usability problems with horizontal scroll while reading text. http://nosetothepage.org/Fitz/ 2dScroll.html.

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

New definition: Running text: More than one clause of text.

If that definition doesn't work we we could fall back to "blocks of text" which is already defined as "more than one sentence of text".

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/58#issuecomment-277026733, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0OF- dRbiiAtrY0vhqkt5cdYLDqrYHuks5rYhR9gaJpZM4K-ARo .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/ wcag21/issues/58#issuecomment-277045162, or mute the thread < https://github.com/notifications/unsubscribe-auth/AJph3hneOPeo- i6Q6Qz25oml0fYf3U71ks5rYiQ7gaJpZM4K-ARo>.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/58#issuecomment-277047294, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0OF-roczpiPSa2yVgMf0SC4s6eFOLKks5rYiYQgaJpZM4K-ARo .

GreggVan commented 7 years ago

yes I know all that - very well. And push it all the time

but the topic was a simple one

what is the definition of the phrase “running text”

if you want to replace it with “running content” that is fine - and it may have a different definition.

But the definition of ‘running text’ was what I was proposing —and it is not just about wrapping. wrapping was just one test for whether the text had positional information embedded in it or was pure ‘running text’

gregg

On Feb 2, 2017, at 8:03 PM, WayneEDick notifications@github.com wrote:

Linearization is not just about word wrapping. It is about organizing the page in a format so that it can be read without loosing document elements because they are way out on the periphery. This is for people who need enlargement and for people who need narrow field of view.

Otherwise we need to reinsert a width limit.

WCAG 2.1 is first draft is about putting the real needs out there. Just linerizing text is not the only issue. People with low vision have a reduced visual field. It may be medical(tunnel vision) or practical (induced by enlargement). Linearization is necessary for both.

Many do need very large print wrapped, but many need a linear page to sort through everything.

The statement above renders it very ineffective. Not what is wanted or intended from the LVTF. This is the most import SC to get right.

Wayne

On Thu, Feb 2, 2017 at 10:47 AM, Wayne Dick wayneedick@gmail.com wrote:

Running text is not enough. I can't tell you how many important phrases are chopped by boxes that are too small.

Linearize means linearization of block items. The text will follow.

Why can't we have that. We can already produce a linearized accessibility API. Why is that so difficult in the browser?

Wayne

On Thu, Feb 2, 2017 at 10:44 AM, Wayne Dick wayneedick@gmail.com wrote:

Absoutely NO. This is linearize content, not just text.

On Thu, Feb 2, 2017 at 9:38 AM, David MacDonald <notifications@github.com

wrote:

I think perhaps "running text" or "blocks of text" would cover a significant amount of the problem in @WayneEDick https://github.com/WayneEDick article on usability problems with horizontal scroll while reading text. http://nosetothepage.org/Fitz/ 2dScroll.html.

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

New definition: Running text: More than one clause of text.

If that definition doesn't work we we could fall back to "blocks of text" which is already defined as "more than one sentence of text".

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/58#issuecomment-277026733, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0OF-dRbiiAtrY0vhqkt5cdYLDqrYHuks5rYhR9gaJpZM4K-ARo .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/58#issuecomment-277050213, or mute the thread https://github.com/notifications/unsubscribe-auth/AJph3iw7b661wG5IcYHJ1E6Tdd4XBu6gks5rYihmgaJpZM4K-ARo.

alastc commented 7 years ago

I'm not sure why we are trying to change this, I addressed TPGs comments before, have there been further comments?

WayneEDick commented 7 years ago

Sorry everyone. When I saw Linearization I thought it was the SC linearization, not defining linearization of text. I got frightened the SC was changing. OOPS.

Damn, I wish email wasn't so hard to read.

On Thu, Feb 2, 2017 at 11:10 AM, Alastair Campbell <notifications@github.com

wrote:

I'm not sure why we are trying to change this, I addressed TPGs comments before, have there been further comments?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/58#issuecomment-277052468, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0OFzxR7B2VCtaHIzHGoccyTLuIdnkDks5rYioxgaJpZM4K-ARo .

GreggVan commented 7 years ago

someone raised the question today — and it looks like they were suggesting “block of text” as a definition of running text (I thought)

That is not very good definition so I suggested other words to consider.

not trying to change anything (Unless running text is defined as ‘block of text’ in which case I am I guess. That would not be a good description.

gregg

On Feb 2, 2017, at 8:10 PM, Alastair Campbell notifications@github.com wrote:

I'm not sure why we are trying to change this, I addressed TPGs comments before, have there been further comments?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/58#issuecomment-277052468, or mute the thread https://github.com/notifications/unsubscribe-auth/AJph3o3Zq7qzcxkbQdn5s2-ZsUJTStrRks5rYioygaJpZM4K-ARo.

DavidMacDonald commented 7 years ago

OK, I'll let the previous language stand for the group to evaluate. "Content" rather than text, blocks of text or running text.

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.

WayneEDick commented 7 years ago

David,

That looks good.

Maybe we could add "visual function and understanding...".

This is because the primary reason for this disclaimer is text embedded at specific locations on images (not images of text) but text over images.

Thank you for all your good work.

Wayne

On 2/3/17, David MacDonald notifications@github.com wrote:

OK, I'll let the previous language stand for the group to evaluate. "Content"

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.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/w3c/wcag21/issues/58#issuecomment-277278309

DavidMacDonald commented 7 years ago

Maybe we could add "visual function and understanding...". [instead of just "function and understanding]

I think "function" is an important exception. I'd have to understand exactly what you mean by visual function, and then we'd have to find language the helps readers no the difference between "visual function" and "function", and then we'd have to figure out the implication of no exempting non visual functions that might get affected when the layout is changed.

alastc commented 7 years ago

I'm not sure adding 'visual function' would help, it is inherently visual if it is regarding layout.

There is an important point to make about the exception:

  • The user (agent) adapts the layout, without knowing in advance how the layout is put together. Therefore it has to be rather blunt, you can't customise the method of adaptation per site. At least to start with most sites will not being optimising for this so the script will have to try to linearise everything. I.e. the UA will try to linearise all elements of the layout.
  • The author needs to test that their layout doesn't interfere with linearisation, using one or more of the associated techniques. These are TBC, but will be based on what the user-agent should do. They could be things like removing CSS, or a baseline script that we create before 2.1 is released.

Therefore the exception means those things don't have to work when linearised. It does not mean that the user-agent doesn't try to linearise them...

lseeman commented 7 years ago

What is the status with this SC? Can it cover most of #51 ?

awkawk commented 7 years ago

Updated the issue description to reflect the FPWD text and reopening issue.

FionaHolder commented 7 years ago

I feel that a baseline script for testing to allow developers to alter their sites accordingly is necessary for this to be released. Just switching off CSS is too problematic, as techniques for responsive sites frequently rely on CSS to show/hide content.

Would also support a rename to "Single Column" for clarity.

WayneEDick commented 7 years ago

I like the name change. Maybe this needs brainstorm.

A CSS test could only be a crude indicator. A more robust script is needed and will be coming, but even this simple one reveals a lot. Example, could a page that passed 1.3.3 Meaningful Sequence, fail the simple script?

Thank you, Wayne

On Saturday, March 4, 2017, Fiona Holder notifications@github.com wrote:

I feel that a baseline script for testing to allow developers to alter their sites accordingly is necessary for this to be released. Just switching off CSS is too problematic, as techniques for responsive sites frequently rely on CSS to show/hide content.

Would also support a rename to "Single Column" for clarity.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/58#issuecomment-284159623, or mute the thread https://github.com/notifications/unsubscribe-auth/AH0OF1bDWqM22Vc7rfBh21w9M_gsmZrYks5riYeWgaJpZM4K-ARo .

FionaHolder commented 7 years ago

@WayneEDick I can see a page failing this but not 1.3.2 if it used tables for layout. That was raised as a concern above, the criterion essentially makes tables for layout invalid. Not that I'd be sorry to see them go though, but I'm sure there are other examples.

WayneEDick commented 7 years ago

It is very easy to undo table layout. Without specifying an explicit traversal order a layout table fails 1.3.2. I do not see that as a problem.

On Saturday, March 4, 2017, Fiona Holder notifications@github.com wrote:

@WayneEDick I can see a page failing this but not 1.3.2 if it used tables for layout. That was raised as a concern above, the criterion essentially makes tables for layout invalid. Not that I'd be sorry to see them go though, but I'm sure there are other examples.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

alastc commented 7 years ago

I agree, we can build on 1.3.1 (Info and Relationships) and apply the linearisation to non-data tables. E.g. check for role=presentation, or lack of THs. A layout table that fails this would probably fail 1.3.2 (Meaningful Sequence) already.