1.4.10 Reflow shouldn't specify CSS pixel counts; should think about WCAG2ICT; needs good examples

[peterkorn]

Please shift specific pixel counts to Techniques; other than multipliers (e.g. 200%) or ratios (e.g. 3:1 contrast), numbers should be used very sparingly and are better in Techniques. Further, please think forward to non-web uses, to the range of ICT devices in use now and the future. Better to state this in terms of what you are trying to accomplish.

Also please think about user interface elements, and non-web ICT where other techniques may be use to achieve the desired end result.

Finally, this appears to be a further doubling of the AA SC 1.4.4 Resize text which specifies a 200% enlargement whereas this requires 400% (the first Note). Shouldn't such a doubling mean this is a AAA SC and not AA? Feels like too massive a change in a 2.x update (vs. a 3.0 compete overhaul).

[awkawk]

Thank you for commenting. For more information about how the AG WG will process this issue, see the following:

• Issue Processing - How the WG will discuss the issue
• Issue Resolution - Identifying and responding to the official WG response
• Issue Notification - How to limit notifications from GitHub

[alastc]

(Official response from working group)

There needs to be some way of making the SC testable, which means either having a starting point and zoom level (e.g. 1280px & 400%), or an ending point (e.g. 320 CSS px). Moving the values to the techniques would mean the SC is not testable, and could not progress.

To apply this to non-web ICT, you would need to use the platforms equivalent. These are already defined in iOS/Android/Windows, where each has a device-independent unit. For example, Apple uses "points" (not to be confused with CSS "pt"), Windows native development uses "effective pixels", Android call them "density independent pixels" (dips or dps).

To set the value would depend on the layout mechanisms used and whether there are standard screen sizes. E.g. If a kiosk had a 960px wide display that showed web-content then the SC can still apply, you would just need the kiosk to support zoom as part of the interface.

NB: Small screen browsers do not support 'reflow' when zoomed, which is partly why the end value of 320px was chosen, as that is a small screen. People who need things larger will need a larger display to show the same content, which is just physics. The same mechanism which means websites can reflow between dsektop & mobile is what enables the zoom on desktop to work so well.

Finally, this appears to be a further doubling of the AA SC 1.4.4 Resize text which specifies a 200% enlargement whereas this requires 400%

Not quite, the SC requires that the layout can reflow to an equivalent of 400%, but the 2.0 SC about text size still applies. I.e. text doesn't have to increase to 400% of the size, but people should be able to make it (at least) 200% bigger.

The original user-requirement was for level A with a 1000% upper limit, but the values were moderated by what was feasible, getting us to level AA at these values.

[patrickhlauke]

To apply this to non-web ICT, you would need to determine the platforms unit for pixels and set an equivalent. For mobile devices like phones these are already defined in iOS/Android/Windows, where each has a device-independent unit such as "pt". I.e. 12pt text on an iOS retina display is the same physical size as 12pt text on an older iPhone.

Indeed. CSS px are the web's density independent unit of measure (and all other measurements are anchored on the ideal pixel, which for all intents and purposes is what platforms/UAs should set their CSS px measurement at).

Native development uses different terminology for the same concept: Apple uses "points" (not to be confused with CSS "pt", nor with typographic "points" - as even on apple devices, an apple "point" does not translate to a real-world typographic "point" as measured on the screen), Windows native development uses "effective pixels", Android call them "density independent pixels" (dips or dps).

At least for Apple's "points", it seems (comparing screen sizes for various Apple devices given in "points" in the HIG) an Apple "point" is exactly the same as a CSS pixel. The same likely holds true for native Windows and native Android. So, to make WCAG applicable to non-web ICT, you'd need an explanatory note saying...essentially that: take the CSS px measures, and take them to mean "the platform's density independent unit of measure", referencing Apple's points, Windows' "effective pixels", Android's "dips".

[WayneEDick]

That is a really good response Alistair.
I do wish we could forget my original 1000% proposal, but if it serves to strengthen the 400% it works.

I really think the endpoint is the key. For example to keep retina display on my iMac I need 1600 x 900. To produce the equivalent of 400% at 1280 I must enlarge to 500%. The result is the same a 320px interface.

Can we construct a unit conversion table for ICT in general.

Wayne

[WayneEDick]

As we examine the 400%, I would like to point out that the WebAIM did not qualify whether magnification occured with or without word wrapping. At the time of the survey, 200% was about the maximum size you could get without 2D scrolling. I think that would be a factor in choosing 200% for many people with low vision. I always use to take things as big as I could before horizontal scrolling set in.

The question used was "Approximately what level of magnification do you most commonly use?" Even without including the impact of horizontal scrolling, 25% chose 400% or greater. Of those who chose enlargement (22 did not need enlargement) almost have 46% chose 300% or 400% or greater. That means that almost half of the people with low visual acuity choose 300% or more even with horizontal scrolling as a consequence.

[alastc]

I really think the endpoint is the key. For example to keep retina display on my iMac I need 1600 x 900. To produce the equivalent of 400% at 1280 I must enlarge to 500%. The result is the same a 320px interface.

For web content, I don't think you need a table, if you zoom in by 400% the text should be the same perceivable size as the laptop: at the intended viewing distance.

The iMac should show things slightly bigger (physically) than the laptop, the pixel density is slightly less, so you should get the same size text at 400% from slightly further away than the equivalent (mac) laptop.

The only reason to do a mapping table would be for non-web content not going through a standard browser, as the browser abstracts the measure from device-pixels to CSS-pixels.

[alastc]

The working group approved the response above, thanks for reviewing WCAG 2.1 @peterkorn.

[allanj-uaag]

-- see "reference pixel" -- https://www.w3.org/TR/CSS2/syndata.html#length-units

[alastc]

Hi @allanj-uaag, it would be good to add that link (as a reference?) to the Reflow understanding doc, and possibly linking the first mention of "CSS pixels" to the definition in WCAG2.1?