W3C

Site Navigation

Nearby

Results of Questionnaire WCAG2ICT - SC 1.4.10 Reflow readiness to incorporate into editor's draft

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-03-31 to 2023-04-12.

9 answers have been received.

Jump to results for question:

Review of proposal for Success Criterion 1.4.10 Reflow

1. Review of proposal for Success Criterion 1.4.10 Reflow

Review the draft proposal for the Guidance When Applying Success Criterion 1.4.10 to Non-Web Documents and Software as well as the definitions and suggested content for the Closed Functionality section. Indicate if you think this is ready to incorporate into the editor's draft. Note any suggestions for improvement and/or reasoning in the comments field.

Summary

Choice	All responders
Choice	Results
The proposal can be incorporated into the WCAG2ICT editor's draft as-is.
The proposal can be incorporated into the WCAG2ICT editor' draft with the changes noted in Mary Jo's comment.	2
The proposal can be incorporated into the WCAG2ICT editor' draft with some additional changes.	6
The proposal isn't ready to incorporate yet.	1

Details

Responder	Review of proposal for Success Criterion 1.4.10 Reflow	Comments
Phil Day	The proposal can be incorporated into the WCAG2ICT editor' draft with some additional changes.	I still worry that this is hard to digest, and therefore may be ignored or even inadvertently misinterpreted. Sizes given in abstract "device independent pixels" still have the problem that they are more difficult to interpret than something more concrete, such as the ADA's min text size in section 707.7.2. 707.7.2 Characters. Characters displayed on the screen shall be in a sans serif font. Characters shall be 3/16 inch (4.8 mm) high minimum based on the uppercase letter “I”. Characters shall contrast with their background with either light characters on a dark background or dark characters on a light background. I suppose this circle could be squared by giving a couple of examples; one for a device at an arms length (so device independent pixel is Xmm, thus min text size of character I is Ymm), and possibly others for devices that are closer and further away (e.g. mobile device and digital signage respectively).
Fernanda Bonnin	The proposal isn't ready to incorporate yet.	Device independent pixel feels like a very abstract term. How will authors and testers know how to translate that into a) the expected viewing distance and angle, and b) the appropriate unit of measurement used in the platform? In note 2, the first bullet point is very relevant "If the platform software does not provide reflow capabilities"; however the note says "where two-dimensional layout is required for usage or meaning" and in this case, the fact that the platform software doesn't provide reflow capabilities doesn't immediately translates into thus two-dimensional layout is required (its more about the fact that the author responsibility is limited due to limitations in the technology) I think this could be a separate note where the bullet point is expanded with examples where platform software is not providing reflow capabilities.
Bruce Bailey	The proposal can be incorporated into the WCAG2ICT editor' draft with the changes noted in Mary Jo's comment.	I am okay with moving ahead with "device independent pixel" since there will be opportunity for public comment. But I agree with Phil and Fernanda concerns as well, so I would not mind at all if we keep working on this one.
Gregg Vanderheiden	The proposal can be incorporated into the WCAG2ICT editor' draft with some additional changes.	1) The current draft says that cell phones are held at arms length - 28 inches. That is the distance for monitors. Since nobody holds their phone at arms length (except someone who is far sighted and forgot their glasses) 18 inches is a more typical distance for viewing a phone and should be used. 2) This seems to say that software should not reflow. This essentially eliminates any ability to use screen scale to enlarge text on screen. 3) I think we should skip the "closed product" part of this for now. There are so many problems with this text. I would put that text into a Parking Lot and include my comments here with it - so we can proceed with the rest. * If there are requirements for screen-scale-like-zooming - then the software and content need to reflow to the new scale. If not - then no problem so no need to mention. (and we don't control if there is a screen-scale-like zoom. ) * Content reflow on a closed product is no more difficult than on any other user agent. It should follow the same rules if there is is content zoom. * The reference to memory makes no sense to me. Memory is the lowest cost thing on closed products and they typically have more than they need - and memory is not much affected or required for reflow. 4) A CSS pixel IS a device independent pixel -- so it is not clear why we need to define a new term that no-one understands and that means exactly the same thing as CSS pixel -- rather than just using CSS Pixel and define it the same way with a note that for systems that don't use CSS the angle of view can be used instead. (or am I misunderstanding something?) That would make it simply "as written substituting "e-document or software" for web ...
Loïc Martínez Normand	The proposal can be incorporated into the WCAG2ICT editor' draft with some additional changes.	I like very much the proposal, based on the definition of "device-independent pixel". My only suggestion for change is editorial, as in the current proposal there are two ways of writing the term: "device-independent pixel" or "device independent pixel". I don't know which one is more correct, but we need to agree on one.
Thorsten Katzmann	The proposal can be incorporated into the WCAG2ICT editor' draft with some additional changes.	I agree with Gregg that cell phones are usually held less then arm's length, this should be changed in the note. The definition of device independend pixel is quite short: "visual angle of about 0.0213 degrees". It would be helpful to explain the calculation as it is done e.g. by Microsoft https://learn.microsoft.com/en-us/windows/win32/learnwin32/dpi-and-device-independent-pixels. So it depends on the 96 dpi and the conversion from radians to degrees, multiply rad by 180 / π to get grad (https://en.wikipedia.org/wiki/Radian).
Mike Pluke	The proposal can be incorporated into the WCAG2ICT editor' draft with some additional changes.	I agree with Gregg's comment about a more realistic viewing distance example. A possible re-write, that uses a more internationally common measurement system in a consistent way (currently we have one measure in inches and one in mm) could be: Example: In the case of a mobile phone, a typical viewing distance is around 45 cm (18 inches). At that viewing distance, the size of a device-independent pixel is 0.17 mm. PS I cheated - I just scaled the pixel size example and didn't go back to the equations. In answer to Loïc, I think it should be "device-independent".
Olivia Hogan-Stark	The proposal can be incorporated into the WCAG2ICT editor' draft with the changes noted in Mary Jo's comment.
Mary Jo Mueller	The proposal can be incorporated into the WCAG2ICT editor' draft with some additional changes.	After reading everyone's comments I think this needs additional changes to address splitting the one bullet as Fernanda said. Fixing the editorial change mentioned by Loïc, and then perhaps having a short table of viewing distance and size for the pixel size. Regarding using the term "device-independent pixel" - doing an internet search yields uses of that term, but it is different than a CSS pixel. It just doesn't feel right using a term "CSS pixels" in a non-web context that does not use CSS at all so I think it would be confusing to native software developers who know nothing of CSS. I plan to have Alistair from AGWG join us for a discussion to see if he can help us with this. I also prefer to continue thinking about and discussing the closed functionality aspects now while we are coming to fully understand this SC which will help in exploring what it means and how it may or may not be able to be supported in all potential closed functionality technology.