Re: UAWG2 Action re: 1.8.7 Reflow text (ACTION-938 )

Hello! My task after last week's conference call was to work on cleaning up Jan's proposal in email titled "UAWG2 Action re: 1.8.7 Reflow text (ACTION-938 )" (http://lists.w3.org/Archives/Public/w3c-wai-ua/2014JanMar/0026.html).

Here are Jan's original proposals followed by my suggested revisions. The changes are essentially editorial, not changing but in some cases clarifying the intent or scope. I didn't make any changes to Jan's proposals #2 and #4.

Jan's proposal #1:

    Proposal 1: We should address multi-column to 1-column reflow in a new dedicated SC. I don't say "within the width of the viewport" because of cases such as if a multi-column text block is in one cell of a layout table.

    1.8.X Multi-Column Text Reflow: The user can specify that recognized multi-column text blocks be reflowed into a single column.


Greg's revision #1:

    1.8.X Multi-Column Text Reflow: The user can specify that recognized multi-column text blocks each be reflowed into a single column.


Jan's proposal #2:

    Proposal 2: Remove 1.8.7 Reflow Text in its current form.


Jan's proposal #3:

    Proposal 3: For "1.4.4 Configured and Reflowed Text Printing" I think we should be clear that printing should occur AS IF the user had resized the browser window's horizontal size to the horizontal dimension of the paper. E.g.

    1.4.4 Printing: The user can print the rendered content, and the following are all true: (Level AA)
    - any rendered, visual, non-time-based content can be printed,
    - the user can choose between available printing devices,
    - the user can choose to print content as it is rendered on screen, reflecting any user scaling, highlighting, and other modifications,
    - the user can choose to have the printed content reflow as if the top-level viewport had been resized to match the horizontal dimensions of the printing device.


Greg's revision #3:

    1.4.4 Printing: The user can print the rendered content, and the following are all true: (Level AA)
    - any rendered, visual, non-time-based content can be printed,
    - the user can choose between available printing devices,
    - the user can have content printed as it is rendered on screen, reflecting any user scaling, highlighting, and other modifications,
    - the user can have printed content reflow as if the top-level viewport had been resized to match the horizontal dimension of the printing device's printable area.


(The changes include: replaced "the user can choose" with "the user can have" so as to not imply that the user must be able to choose other options, although of course that is not prohibited; made "horizontal dimension" singular instead of plural; made explicit that content should be wrapped to the width of the printer's printable area rather than the width of the media.)

(Note that we're inconsistent about whether we use "rendered content" or "the rendered content"; an editorial pass might want to clean that up at some point.)

Jan's proposal #4:

    Remove the definition of "reflowable content" as it is no longer needed by 1.4.4.


Jan's proposal #5 for a new global applicability note:

    Proposal 5: Move all mention of vertical languages to a global applicability note:

    5. Vertical layout languages: For user agents rendering, vertical layout languages (e.g. Mongolian, Han), success criteria relating to horizontal rendering, should be applied to vertical rendering.


Greg's revision #5:

    5.  Vertical layout languages: When user agents render vertical layout languages (e.g. Mongolian, Han), success criteria normally relating to horizontal rendering should be applied to vertical rendering instead.


Jan's proposal #6 (Strawman 1):

    Strawman 1: One idea for facilitating reflow is allowing user to remove absolute sizes, allowing the browser's own reflowing system to work:

    1.8.X Toggle absolute layout dimensions: The user can specify whether or not the user agent should observe absolute layout dimensions.


Greg's revision #6:

    (Saying "The user can choose" implies that user agents must offer the option of supporting absolute layout dimensions. Do we want to do that, or should we change the wording only to require that absolute layout dimensions can be ignored? I changed "observe" author-specified values to "respect" them.)

    (Version 1) 1.8.X Toggle absolute layout dimensions: The user can specify whether or not the user agent should respect author-specified absolute layout dimensions. (Level AA)

    (Version 2) 1.8.X Ignore absolute layout dimensions: The user can have the user agent override author-specified absolute layout dimensions. (Level AA)


Jan's proposal #7 (Strawman 2):

    Strawman 2: What about requiring a linearize feature at AA or AAA? (e.g. the FireFox's "Linearize Page" feature seems very straightforward http://forums.chrispederick.com/discussion/328/page-linearization)


Greg's revision #7:

    1.8.Y Linearize content: The user can have recognized content rendered as a single column, overriding formatting of columns and positioning specified by the author. (Level AAA)


     Thanks,
     Greg