Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
KaneCheshire opened this issue Aug 13, 2019 · 7 comments
Open
Assignees

Comments

@KaneCheshire
Copy link
Contributor

KaneCheshire commented Aug 13, 2019

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

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.

@jfhector
Copy link
Contributor

jfhector commented Aug 13, 2019

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?

@KaneCheshire
Copy link
Contributor Author

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"!

@jfhector
Copy link
Contributor

jfhector commented Aug 13, 2019

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.

@KaneCheshire
Copy link
Contributor Author

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

@jfhector
Copy link
Contributor

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.

@KaneCheshire
Copy link
Contributor Author

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants