Re: [csswg-drafts] Browser zoom unit for accessibility [css-values-and-units] (#6869)

Hi @cookiecrook !

I'm a bit disappointed to hear you feel that way, but I can understand based on your experiences. Also, thank you for giving it attention.

From my personal experience, we work with a lot of people above 40-50 years old. It's not uncommon to see their devices with really large font sizes on their OS. We would very much like to keep that expectation with PWAs. I am willing to jump through hoops as a dev to cater to my users. But asking users to jump through hoops goes against what I feel is the intention of accessibility options. 

It's not uncommon for us to have users self install our enterprise applications only later to call and complain the font size is too small. Remember, the websites used to Add to Home Screen were displayed with the adjustments the users have in the browser. Those settings do not apply on install. Our best solution has been to remotely troubleshoot over the phone and, by use of Websockets, have the support agent remotely bump up the font size for the user. That's because asking somebody who is already having difficulties reading the screen to hunt for options is illogical. 

On the basis of how web devs misuse font size, I'm not surprised at all. Devs freely hijack font size because, apparently, multiples of two is too hard (/snark). But irresponsible usage of a feature intended to solve a problem, doesn't mean the problem doesn't exist. Nor does it diminish the importance of finding a solution.

Like the adage I'm sure you know, "No ARIA is better than bad ARIA". To straw-man your argument (apologies), we still have ARIA in place for responsible devs. I easily concede for trivial things, but I don't have any good responses for when people ask why their disabilities aren't given importance. The best I can do is shrug and assure I'm doing the best I can. But to tell them we can't because others might misuse it, is almost always interpreted as telling them their needs aren't important. 

Still, some finality is better than vagueness. To extend the ARIA illustration, browsers do have a very compatible accessibility features (eg: `HTMLInputElement`) and don't require devs to even know ARIA. It happens automagically. Perhaps Apple's solution is the better approach. I have my concerns because Chrome team tried their own heuristics for font scaling and, to be honest, it's not great. [7 years](https://bugs.chromium.org/p/chromium/issues/detail?id=645717) and it's still rough. There really is no in-between. If Apple/Webkit's position is we're not getting a standard and let platform/browser implementations choose their own pattern, then I can petition the Android team to create *something*. It doesn't have to be CSS, it doesn't have to be manifest or viewport. 

Being fair, I won't try to paint Apple with same brush. For me, now, `-apple-system-body` works best. And if Apple is discouraging its usage because of how error-prone is it and instead encouraging devs to lean on the Safari settings, that's great. Hopefully it stops being misused. But hopefully we can keep using it for Home Screen Apps. Accessibility features are never supposed to be about how much a feature is popular. It's about targeting the few who need it, regardless of the %. Still, the discussion for keeping `-apple-system-body` or guarding its usage is best discussed elsewhere (probably a WebKit issue). Maybe Home Screen App only... 🤔 

Again, thanks for dedicating time on the issue. ❤️ 
---------

As for this specific issue I do believe `dppx` is close to what was originally asked for. I do believe container queries related to `ch` and `lh` should likely be enough. What we have are inconsistencies between browsers (`dppx`) and perhaps a limitation to what container queries can express. I would have to see a inexpressible layout to think we need a new property. I could very much be wrong, but I think container queries can now target the original issue.

For example the calendar example, you should be able to calculate if a week (`13ch` which is 7 characters with `gap: 1ch`) would fit on screen. It's a bit of math involved, but still doable (and cleaned up with CSS Variables/SASS). That means you can now size containers based on whatever the user wants the font size to be (and how browser has selected zoom).

-- 
GitHub Notification of comment by clshortfuse
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6869#issuecomment-1511878362 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 17 April 2023 18:28:18 UTC