Skip to content
This repository has been archived by the owner on Jun 30, 2018. It is now read-only.

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

Closed
peterkorn opened this issue Feb 5, 2018 · 9 comments

Comments

@peterkorn
Copy link

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
Copy link
Member

awkawk commented Feb 5, 2018

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

@awkawk awkawk added this to In progress in Resolving CR Comments Mar 2, 2018
@alastc alastc self-assigned this Mar 3, 2018
@alastc
Copy link
Contributor

alastc commented Mar 3, 2018

(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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

alastc commented Mar 15, 2018

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
Copy link
Contributor

alastc commented Mar 19, 2018

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

@alastc alastc closed this as completed Mar 19, 2018
Resolving CR Comments automation moved this from In progress to Done Mar 19, 2018
@allanj-uaag
Copy link
Contributor

allanj-uaag commented Mar 19, 2018

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

@alastc
Copy link
Contributor

alastc commented Mar 19, 2018

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?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Development

No branches or pull requests

8 participants