Rule 59br37: Why test SC 1.4.4 Resize Text against a height of 1,024 CSS pixels?
Opened this issue · 1 comments
I was wondering why rule 59br37 sets a 1024 CSS pixel height value in the viewport:
This rule checks that text nodes are not unintentionally clipped by overflow, when a page is zoomed to 200% on 1280 by 1024 viewport;
It's a bit of an odd viewport isn't it? Remember, we're expecting low vision uses to be zooming in from a desktop resolution.
Take the following examples of common desktop screen resolutions from Browserstack:
- 1920 x 1080
- 1366 x 768
- 1536 x 864
- 1280 x 720
- 1440 x 900
- 1600 x 900
Did you get the 1,024 CSS pixel height from SC 1.4.10 Reflow? If so, SC 1.4.10 doesn't require a vertical scrolling page to meet a height. This is a common misconception. The height is only a requirement for horizontally scrolling content.
The distinction:
- English is a language that is read horizontally by default, which scrolls vertically. This is where width requirement of a 320 CSS pixels comes in because users will be coming from a 1,280 CSS pixels screen and zooming in 400%.
- Traditional Chinese, Vietnamese, Korean, and Japanese are examples of languages that are read vertically, which scrolls horizontally. This is where the height requirement of 256 CSS pixels comes in because users will be coming from a 1,024 CSS pixel screen and zooming in 400%.
In either case, there is no combined width and height requirement in SC 1.4.10 Reflow.
@anevins12 This was an arbitrary choice of viewport size, inspired by SC 1.4.10 Reflow. The third assumption of the rule states this:
- While success criterion 1.4.4 Resize text does not explicitly mention which viewport size has to be resized up to 200%, it is assumed that a viewport size of 1280 by 1024 is applicable. A 1280 by 1024 viewport size is explicitly mentioned under success criterion 1.4.10 Reflow.