W3C

Site Navigation

Nearby

Results of Questionnaire WCAG2ICT - Review of proposals for SC 1.4.10 Reflow

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email address: maryjom@us.ibm.com

This questionnaire was open from 2023-06-20 to 2023-06-28.

7 answers have been received.

Jump to results for question:

  1. Non-web documents - Note 1
  2. Non-web documents - Note 2
  3. Non-web software - Note 1
  4. Non-web software - Note 2
  5. Non-web software - Note 3
  6. Non-web software - Note 4

1. Non-web documents - Note 1

Review the following proposal options for Note 1 for non-web documents. Indicate if your preference out of the proposals and whether or not that choice can be incorporated as-is or needs changes. If you don't like any of the choices, indicate that and give your reasoning and/or an alternate proposal.


Proposal 1:

Note 1: An example of non-web documents which require two-dimensional layout for usage are nature photographs.


Proposal 2:

Note 1: Examples of non-web documents which require two-dimensional layout for usage are nature photographs or documents intended only for printing or archival of print format material.

Summary

ChoiceAll responders
Results
Prefer proposal 1, as-is.
Prefer proposal 2, as-is 2
Prefer proposal 1, with changes.
Prefer proposal 2, with changes. 1
Do not think further exception examples are needed. 4
Something else. Please suggest alternative content.

Details

Responder Non-web documents - Note 1Comments
Chris Loiselle Prefer proposal 2, as-is
Olivia Hogan-Stark Prefer proposal 2, with changes. Is "nature" needed?
Bruce Bailey Do not think further exception examples are needed. I have been persuaded by the issue conversation thread that the "maps and diagrams" example currently in WCAG is suffient.
Mitchell Evan Do not think further exception examples are needed. We should leave print format or archival exemptions to be matters of organizational policy and regulation (as in EU WAD "heritage collections"), not list them as examples of meeting the two-dimensional layout exception. PDF as a format has since the start has been optimized for print, yet also has supported reflow for most kinds of content since the early 2000s.
Mary Jo Mueller Do not think further exception examples are needed. I'm thinking that since we include the WCAG text, their examples are good enough.
Mike Pluke Do not think further exception examples are needed.
Loïc Martínez Normand Prefer proposal 2, as-is I prefer proposal 2, as it provides two examples.

2. Non-web documents - Note 2

Review the following proposal options for Note 2 for non-web documents. Indicate if your preference out of the proposals and whether or not that choice can be incorporated as-is or needs changes. If you don't like any of the choices, indicate that and give your reasoning and/or an alternate proposal.


Proposal 1:

Note 2: Not all document types support reflow, and some document types do not support reflow on some user agents. Such limitations are not under author control, but that does not mean that the content requires two-dimensional layout for usage or meaning. Such limitations might mean that the document type is not accessibility supported.


Proposal 2:

Note 2: In some cases, reflow may not be accessibility supported by a particular document type and its available user agents. Such limitations are not under author control, but this does not mean the document requires two-dimensional layout for usage or meaning.


Proposal 3:

Note 2: When user agents and authoring tools for a non-web document type do not provide support for content reflow, it may not be possible for non-web documents of that type to meet this success criterion.

Summary

ChoiceAll responders
Results
Prefer proposal 1, as-is. 2
Prefer proposal 2, as-is
Prefer proposal 3, as-is 1
Prefer proposal 1, with changes.
Prefer proposal 2, with changes.
Prefer proposal 3, with changes. 3
Do not think this note is needed.
Something else. Please suggest alternative content. 1

Details

Responder Non-web documents - Note 2Comments
Chris Loiselle Prefer proposal 3, as-is
Olivia Hogan-Stark Prefer proposal 3, with changes. Something doesn't sound right with the wording of "accessibility supported" and not quite sure what 1 and 2 are trying to say about two-dimensional layouts.

I like the simplicity of 3, but would maybe word differently:

Note 2: Certain non-web document types and their available user agents may not support reflow, which is beyond the author's control.
Bruce Bailey Prefer proposal 1, as-is. I prefer that the note focus on document/file type rather than user agents and/or authoring tools.
Mitchell Evan Something else. Please suggest alternative content. My vote is for part of Olivia's edit and part of Proposal 3, as follows: "If a non-web document type and its available user agents do not support reflow, it may not be possible for a document of that type to meet this success criterion."

This keeps the clarity of proposal 3, which of the three proposals says most clearly that 1.4.10 Reflow can fail even if there's nothing a document author can do about it. (Proposals 1 and 2, as well as Olivia's "beyond the author's control," are all saying true things, but I can't tell whether the result is that 1.4.10 passes or fails.)

As of 2023-06-22, consensus in issue #159 is that such documents should fail 1.4.10, not pass.

I would not mention authoring tools in this note.

I would mention user agents. The PDF example again: PDF as a document type supports reflow, but not all PDF user agents do. So if you're in an environment like a company or school that requires a particular user agent, then you'd have to rely on that user agent for evaluating the criterion.
Mary Jo Mueller Prefer proposal 3, with changes. I like Mitch's edit combining Proposal 3, Olivia's input and his edits. Repeating the text here: "If a non-web document type and its available user agents do not support reflow, it may not be possible for a document of that type to meet this success criterion."
Mike Pluke Prefer proposal 3, with changes. I'm convinced by Mitch's arguments and like his proposal:
"If a non-web document type and its available user agents do not support reflow, it may not be possible for a document of that type to meet this success criterion."
Loïc Martínez Normand Prefer proposal 1, as-is. I feel that proposal 1 is more comprehensive.

3. Non-web software - Note 1

Review the following proposal for Note 1 for non-web software. Indicate whether it can be incorporated as-is or needs changes. If you have substantive concerns or changes, indicate that and give your reasoning and/or an alternate proposal.


Note 1: The intent section refers to the ability for content to reflow when user agent text enlargement is used to scale content or when the viewport changes in width. For non-web software, this means that when users scale content, adjust the size of a window or dialog, or change the screen resolution, the content will reflow without loss of information or functionality, and without requiring scrolling in two dimensions; or that the application works with platform features to meet this requirement.


Summary

ChoiceAll responders
Results
Incorporate Note 1, as-is. 6
Incorporate Note 1, with editorial changes.
I have concerns with Note 1 (explain and/or provide an alternative) 1
Do not think Note 1 is needed. (please explain)

Details

Responder Non-web software - Note 1Comments
Chris Loiselle Incorporate Note 1, as-is.
Olivia Hogan-Stark Incorporate Note 1, as-is.
Bruce Bailey Incorporate Note 1, as-is.
Mitchell Evan Incorporate Note 1, as-is.
Mary Jo Mueller I have concerns with Note 1 (explain and/or provide an alternative) I started reading comments added to Issue 2, like Andrew's: https://github.com/w3c/wcag2ict/issues/2#issuecomment-1148805921
I think that this might mean that we've got to give more leeway for this SC. Software applications may not be able to make their viewport the width and/or height of a mobile app or may not be able to reflow all possible content in the UI. I am not sure if this is built-in to modern platforms and would require a heavy burden of code to support this. Think about menus, etc. When using an application with a lot of menus and you reduce the window width, there's typically a different method of revealing menu and ribbon items, not reflowing them vertically (they have a responsive layout, of sorts). I'm not sure what happens with dialog boxes that have a lot of settings in them. In a Mac, it seems to handle things fine, though you cannot adjust the window size pretty to be wider or narrower, only vertically. So it seems there should be more exceptions built-in. E.g. the chrome of a software application (menus, etc.) may not need to support reflow - arguably those aren't "blocks of text" as talked about in discussions on this. Can anyone think of other cases where reflow might not be possible? Can alert dialogs reflow? Be resized?
Mike Pluke Incorporate Note 1, as-is.
Loïc Martínez Normand Incorporate Note 1, as-is. I think that note 1 is good.

4. Non-web software - Note 2

Review the following proposal for Note 2 for non-web software. Indicate whether it can be incorporated as-is or needs changes. If you have substantive concerns or changes, indicate that and give your reasoning and/or an alternate proposal.


Note 2: It is likely that there will be more frequent cases where two-dimensional layout is required for usage or meaning. For example:

  • If the content technology and platform software do not provide reflow capabilities.
  • When the software has a complex user interface with toolbars, as explained in the Intent from Understanding 1.4.10 Reflow.
  • When the content technology and platform software do not allow users to alter the size of an application window or its content.

Summary

ChoiceAll responders
Results
Incorporate Note 2, as-is. 2
Incorporate Note 2, with editorial changes. 5
I have concerns with Note 2 (explain and/or provide an alternative)
Do not think Note 2 is needed. (please explain)

Details

Responder Non-web software - Note 2Comments
Chris Loiselle Incorporate Note 2, as-is.
Olivia Hogan-Stark Incorporate Note 2, with editorial changes. Note 2: There are various cases where two-dimensional layout is required for usage or understanding. These include:

- When the content technology and platform software do not provide reflow capabilities.
- When the software has a complex user interface with toolbars, as explained in the Intent from Understanding 1.4.10 Reflow.
- When the content technology and platform software restrict users from adjusting the size of an application window or its content.
Bruce Bailey Incorporate Note 2, with editorial changes. I think we might combine "it is likely" and "more frequent" to have a less subjectivity. Maybe:
Non-web software is more prone than web applications to situations where two-dimensional layout is required for usage or meaning.
Mitchell Evan Incorporate Note 2, with editorial changes. +1 Bruce's edit: "Non-web software is more prone than web applications to situations where two-dimensional layout is required for usage or meaning."

Omit the first bullet point: "If the content technology and platform software do not provide reflow capabilities." If we fail documents where reflow is not supported, why would we pass software?

Keep the second and third bullet points.
Mary Jo Mueller Incorporate Note 2, with editorial changes. I agree that the first sentence needs rewriting, and suggest: "Non-web software will have more frequent cases where two-dimensional layout is required for usage or meaning than what occurs on the Web."

After looking at the non-web document adjustment and Mitch's comment, I suggest that we remove bullet 1 and add a different note similar to the non-web document.
"NOTE: If the content technology and platform software do not support reflow, it may not be possible for non-web software to meet this success criterion."

Keep the other two bullets, but using Olivia's edit for the last bullet, repeated here: When the content technology and platform software restrict users from adjusting the size of an application window or its content.
Mike Pluke Incorporate Note 2, with editorial changes. I agree with all of Mary Jo's proposals.
Loïc Martínez Normand Incorporate Note 2, as-is. I think that the proposed note 2 is valid as-is.

5. Non-web software - Note 3

Review the following proposal for Note 3 for non-web software. Indicate whether it can be incorporated as-is or needs changes. If you have substantive concerns or changes, indicate that and give your reasoning and/or an alternate proposal.


Note 3: Some platforms do not support adjusting viewports to an equivalent of 320 CSS pixels wide or 256 CSS pixels high, and some do not support zoom as high as 400% for the larger measurements of 1280 CSS pixels wide or 1024 CSS pixels high. In such cases, reflow should be to the extent size alterations are available (the nearest possible equivalent).

Summary

ChoiceAll responders
Results
Incorporate Note 3 as-is. 2
Incorporate Note 3, with editorial changes. 4
I have concerns with Note 3 (explain and/or provide an alternative)
Do not think Note 3 is needed. (please explain)

(1 response didn't contain an answer to this question)

Details

Responder Non-web software - Note 3Comments
Chris Loiselle Incorporate Note 3 as-is.
Olivia Hogan-Stark Incorporate Note 3, with editorial changes. Maybe break sentence 1 down into two parts –

Certain platforms do not support adjusting viewports to an equivalent of 320 CSS pixels wide or 256 CSS pixels high. Likewise, some platforms have limitations on zooming as high as 400% for the larger measurements of 1280 CSS pixels wide or 1024 CSS pixels high.

I think the second sentence needs more clarity –
– In such cases, reflow should be implemented to the fullest extent possible based on the available size alterations, aiming for the nearest possible equivalent.
– In such cases, reflow should be implemented to the nearest achievable equivalent.
Bruce Bailey Incorporate Note 3 as-is.
Mitchell Evan Incorporate Note 3, with editorial changes. I agree with Olivia.

For the last sentence: "In such cases, the Reflow criterion should be evaluated at the nearest available equivalent.
Mary Jo Mueller Combining Olivia's and Mitch's comments:

Note 3: Certain platforms do not support adjusting viewports to an equivalent of 320 CSS pixels wide or 256 CSS pixels high. Likewise, some platforms have limitations on zooming as high as 400% for the larger measurements of 1280 CSS pixels wide or 1024 CSS pixels high. In such cases, the Reflow Success Criterion should be implemented and evaluated at the nearest available equivalent.

Mike Pluke Incorporate Note 3, with editorial changes. Mary Jo's proposal captures all of my concerns.
Loïc Martínez Normand Incorporate Note 3, with editorial changes. I think that the last sentence is confusing and contains normative wording (should). I suggest a different version:

In such cases, reflow is to be considered to the nearest possible equivalent to the size alterations defined in the success criterion.

6. Non-web software - Note 4

Review the following proposal for Note 4 for non-web software. Indicate whether it can be incorporated as-is or needs changes. If you have substantive concerns or changes, indicate that and give your reasoning and/or an alternate proposal.


Note 4: Some software applications may need to provide a mode of operation where reflow is possible. An example is an authoring tool, where content can be viewed in a "print mode" with rulers and/or grids, and can alternately be read as reflowed text content.

Summary

ChoiceAll responders
Results
Incorporate Note 4 as-is. 2
Incorporate Note 4, with editorial changes. 5
I have concerns with Note 4 (explain and/or provide an alternative)
Do not think Note 4 is needed. (please explain)

Details

Responder Non-web software - Note 4Comments
Chris Loiselle Incorporate Note 4 as-is.
Olivia Hogan-Stark Incorporate Note 4, with editorial changes. Note 4: Some software applications may require a mode of operation that supports reflow. An example is an authoring tool that offers a "print mode" featuring rulers and/or grids, while also providing the ability to read the content as reflowed text.
Bruce Bailey Incorporate Note 4, with editorial changes. 1.4.10 is "can be presented". So I think the non-print mode can be used to meet 1.4.10. So I suggest including Note 4 as an affirmative example.

Note 4: Some software applications may include a mode of operation where reflow is not possible. An example is an authoring tool, which includes both a "print preview mode" (without reflow, for rulers and/or grids) and a "drafting view mode" where reflow is support.
Mitchell Evan Incorporate Note 4, with editorial changes. Like Olivia's, with a further edit: 'Some software applications may require a mode of operation that supports reflow. An example is an authoring tool that offers a "print mode" featuring rulers and/or grids, while also providing a mode which reflows the content.'

I omitted the word "text" because it's also important not to lose content and functionality.
Mary Jo Mueller Incorporate Note 4, with editorial changes. I prefer Bruce's affirmative example, with a tiny edit: "Note 4: Some software applications may include a mode of operation where reflow is not possible. An example is a document authoring tool, which includes both a "print preview mode" (without reflow, for users to view the spatial formatting) and a "drafting view mode" where reflow is supported."
Mike Pluke Incorporate Note 4, with editorial changes. I think Mary Jo's edit of Bruce's proposal is the simplest and clearest version.
Loïc Martínez Normand Incorporate Note 4 as-is. I think note 4 is goos as-is.

More details on responses

  • Chris Loiselle: last responded on 21, June 2023 at 19:54 (UTC)
  • Olivia Hogan-Stark: last responded on 21, June 2023 at 23:16 (UTC)
  • Bruce Bailey: last responded on 22, June 2023 at 12:36 (UTC)
  • Mitchell Evan: last responded on 22, June 2023 at 16:41 (UTC)
  • Mary Jo Mueller: last responded on 27, June 2023 at 13:51 (UTC)
  • Mike Pluke: last responded on 28, June 2023 at 17:43 (UTC)
  • Loïc Martínez Normand: last responded on 28, June 2023 at 18:21 (UTC)

Non-responders

The following persons have not answered the questionnaire:

  1. Gregg Vanderheiden
  2. Shadi Abou-Zahra
  3. Sam Ogami
  4. Charles Adams
  5. Daniel Montalvo
  6. Fernanda Bonnin
  7. Shawn Thompson
  8. Devanshu Chandra
  9. Bryan Trogdon
  10. Thorsten Katzmann
  11. Tony Holland
  12. Kent Boucher
  13. Phil Day

Send an email to all the non-responders.

Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire

Report issues on GitHub project w3c/wbs-design or by mail to sysreq.