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

Accessibility fix: Allow iOS browsers to auto-scale fonts based on user preference #219

Open
chrislachance opened this issue May 25, 2021 · 7 comments

Comments

@chrislachance
Copy link

Please add font:-apple-system-body to the :where(:root) CSS to allow iOS devices to auto-scale font sizes based on user preference set in Accessibility > Display & Text size.

@jonathantneal
Copy link
Collaborator

jonathantneal commented May 25, 2021

The auto-scaling feature is wonderful. At least, it should be wonderful.

Unfortunately, it’s badly implemented, enough so that it can actively hurt desktop Safari users. In desktop Safari, the rem unit is dropped to 13px, regardless of the initial or current viewport size, and authors are given no way to know whether this is a deliberate user preference or not, nor are they given a way to specify a minimum font-size in the cases where it was not deliberate. It’s also a confusing pattern for authors, since additional font values like -apple-system-headline resolve to the same font-size as -apple-system-body in iOS and desktop Safari.

If there is a way around these issues in CSS, then I will probably be eager to add this feature, even if it only benefits iOS users.

@chrislachance
Copy link
Author

chrislachance commented May 25, 2021

There is, but its a hack that targets iPad & iOS.

@supports(-webkit-touch-callout:default){ /* iOS and iPadOS, but not Desktop */
:where(:root){font: -apple-system-body}}
}

@chrislachance
Copy link
Author

Better yet, here's a Codepen with updated code. Desktop Safari is targeted instead to just manually reset to 16px as it does in its user-unsettable User Agent Stylesheet. If iOS were targeted instead, then custom font-family stuff needs to be set in 2 different :root areas, which is a pain to maintain. - https://codepen.io/chrislachance/pen/OJpmgrM

Seems like the heaviness of this solution may go against what the goals of Sanitize are, however, so I get it if you don't want to add to the library.

@jonathantneal
Copy link
Collaborator

Your work is incredible, @chrislachance.

I’m sad to present some more bad news. If I adjust the text size in iOS and then disable the setting, the text size adjustment is still applied. This feels actively harmful.

I noticed that it’s not just iOS Safari getting this wrong. I noticed that iOS Mail continued to use the disabled text adjustment.

If you have the time and availability, you could make the web better by filing a bug with Apple, and advocating for the change until it happens. Your only reward may be knowing it eventually does the right thing, and the esteem of your fellow developers, like myself, who knew nothing of this until you showed it to me.

@chrislachance
Copy link
Author

Interesting. Can you share a screenshot of the disabled setting? I must have missed that one.
I've already asked Safari iOS to consider fixing this for its browser officially a few days back. (Unless you have secret contacts at Apple :) )

@chrislachance
Copy link
Author

BTW, if you mean the setting shown in this image, it only allows for users to pick larger sizes.
It's not an enable/disable toggle (weird huh?)

@jonathantneal
Copy link
Collaborator

To answer your question, yes, I was incorrectly identifying the control as a toggle, and I agree that it’s a weird, unexpected user interface.

I’ve taken the issue to Twitter, in case there are other ideas. I want to know if users can adjust the text size in macOS, to test whether the 1rem fix is merely disabling the accessibility (similar to how it disables the accessibility in iOS).

https://twitter.com/jon_neal/status/1437917257108271107

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