accessibility-guidelines icon indicating copy to clipboard operation
accessibility-guidelines copied to clipboard

"CSS" is not platform agnostic for the overview/summary page

Open KaneCheshire opened this issue 6 years ago • 7 comments

The following sentence isn't platform-agnostic so makes it appear to be a web-only requirement:

All information and functionality must be available on a screen that's 320 CSS pixel wide, without needing to scroll horizontally

I propose we use "points" instead of CSS or pixels:

All information and functionality must be available on a screen that's 320 points wide, without needing to scroll horizontally

KaneCheshire avatar Aug 13 '19 11:08 KaneCheshire

I actually propose we drop "px" everywhere, since iOS and Android don't use pixels at all, iOS uses points and Android use "dp". I propose we stick to points since it's a pretty common and well known. An example of where we're using px is 1.4.10 Reflow.

KaneCheshire avatar Aug 13 '19 11:08 KaneCheshire

You're right, this is an issue.

The reason I'm struggling to solve this issue, is that the dimension in the official WCAG success criteria is given in CSS pixels.

Potential solutions

Potential solution 1

Convert 320 CSS pixels into points, somehow. (I don't fully understand how this works, but I imagine that this is possible).

The downside of this approach is that the number we end up with would be different from the one in the WCAG, and probably quite obscure to web people (who use CSS pixels).

Potential solution 2

Alternatively, we could avoid giving a specific dimension in the overview page, and keep the specifics for the detailed page (where we can do it in a tech-specific way).

This is what the GDS version does: "1.4.10 [NEW] Make sure content will reflow to a single column when zoomed and not produce scrolling in both directions."

Conclusion

  • I suggest that we try removing any specific number from the overview page, and see how that tests with users.

  • I suggest we try to figure out how 1.4.10 applies to native apps. Concretely: what width does content need to fit in? We might be able to find this info online, or in web-a11y.slack.com or by raising an issue on the wcag via github.

What do you think?

jfhector avatar Aug 13 '19 12:08 jfhector

320pts is the smallest screen size width on iOS (which is actually 640 pixels, but that's not important because developers on iOS rarely think about the actual pixels, they just use points) which is an iPhone 5 size. I think that's where the 320 CSS size was determined.

Converting 320 CSS pixels into points should be as simple as saying 320 points, because on devices that have a 1x resolution scale, it will map to 320 pixels. On a 2x resolution scale (like an iPhone 5 which has 320 points width) it will map to 640 pixels even in the browser.

CSS developers can actually specify points anyway, but I think the system is smart enough to convert px into points on the devices that need it (on iOS at least, I've never had any issues specifying px in websites)

To further clarify in case it's not clear what points are versus pixels on iOS: Screens are measured in points, which can contain different amounts of pixels based on the resolution scale:

  • On a 1x scale device (old iPhones, iPads and MacBooks, and some computer monitors), 1pt = 1px
  • On a 2x scale device (Retina MacBooks, iPhone 4/5/6/7/8 and most iPads), 1pt = 2px
  • On a 3x scale device (iPhone 8 Plus, iPhone X, iPhone XS Max), 1pt = 3px

Android have even more resolutions which is why we don't ever really think about things in terms of pixels anymore, and I assumed this was also happening on the web by using "pt" instead of "px"!

KaneCheshire avatar Aug 13 '19 12:08 KaneCheshire

Thanks. This is useful.

I'm still confused for two reasons:

1. I'm not sure that 1 CSS pixel = 1 pt for the web.

There's another success criterion where this pixels/pts conversation matters: 1.4.3. Contrast (Minimum). This success criterion, is phrased using 'pts' as a unit. And it's explicitly indicated in a note that 1 pt = 1.33 CSS pixel.

See the green NOTE box on the 1.4.3 description page.

2. Reading the wording of 1.4.10 Reflow, it looks maybe they've just not taken native into account

The phrasing of 1.4.10 Reflow explicitely uses CSS pixels as a unit. There's no reference to pts, or to conversion.

So, this leaves me unsure about what to do. And I'm even wondering whether the 1.4.10 Reflow is meant to apply to native app design (given that it's explicitly about Responsive Web Design, which is generally a web concept).

Conclusion

Unless you can see clearly in all this, I suggest that we ask experts.

jfhector avatar Aug 13 '19 13:08 jfhector

Ah yes fair enough, it does seem like it might be aimed towards web specifically. Let's ask someone.

KaneCheshire avatar Aug 13 '19 13:08 KaneCheshire

Turns out that 1 CSS Pixel is a physical, resolution-agnostic dimension too, in the W3C's 'CSS Values and Units Module Level 3'.

1 CSS pixel = 1/96th of an inch And 1 pt = 1/72th of an inch

This is consistent with the note in the 1.4.3 description page, as 1 pt = 1.33 CSS pixel.

This still leaves a doubt re. the applicability of 1.4.10 to native apps. Because, if 'CSS Pixel' a physical value, there's nothing to suggest that the criterion is web specific.

I'll ask around.

jfhector avatar Aug 13 '19 13:08 jfhector

Hmm okay. We definitely don't have reference to a CSS Pixel on iOS though so don't think people would know what that means if that was the case. Weird though!

KaneCheshire avatar Aug 13 '19 13:08 KaneCheshire