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

Investigate Dynamic Type to improve accessibility for iOS users #882

Closed
hannalaakso opened this issue Jul 10, 2018 · 12 comments
Closed

Investigate Dynamic Type to improve accessibility for iOS users #882

hannalaakso opened this issue Jul 10, 2018 · 12 comments

Comments

@hannalaakso
Copy link
Member

hannalaakso commented Jul 10, 2018

This came out of the work on #858.

We currently don't support adjusting the base font size on iOS devices due to iOS constraints.

However @36degrees spotted that Dynamic Type could solve this issue.

We should investigate this as it would be great to support iOS users who needs to adjust their base font size.

Who needs to know about this

Developers, Tim or Joe

@NickColley
Copy link
Contributor

I believe it would require us to not use the GOV.UK font?

@36degrees
Copy link
Member

36degrees commented Jul 11, 2018

From what I can tell, font: -apple-system-body; is doing more than just setting the font-family, and the dynamic font-sizing persists even if we override the font-family later - in other words, we can still use the font.

From a quick spike it seems to work well, with the exception that Laura's approach of 'scaling' the root font-size by setting it on the body won't work for us because everything is using rem. Frustratingly, this means that the 'base' font-size ends up being 17px. Setting the font-size on the html element stops the dynamic sizing from working, so that's not an option either.

I think we'd have to modify the typography-responsive helper to spit out another font-size declaration for iOS:

@supports (font: -apple-system-body) {
  font-size: $font-size / 17px * 1rem;
}

This seems to work, but will increase the size of our CSS and increase the complexity of that helper.

@NickColley
Copy link
Contributor

Saw this which is related, which seems to suggest setting the system font on the root element then changing it allows for the resizing to work: https://twitter.com/eriksen_dk/status/1075555147856732161?s=17

@NickColley
Copy link
Contributor

OK so need to do an investigation to see the impact on file size by adding that helper min/gzip, and if it's too large consider if it's a problem if the base size is 17px...

@NickColley
Copy link
Contributor

Looks like 11.4 kB with Ollie's suggestion and 10.4 kB without, so a decent chunk.

@NickColley NickColley moved this from In progress to Needs review in Design System Sprint Board Jan 24, 2020
@36degrees
Copy link
Member

Going to try and get a working example set up so we can see how it works, and what difference it makes to asset size.

@36degrees
Copy link
Member

Master branch:

$ wc -c dist/govuk-frontend-3.5.0.min.css
   88829 dist/govuk-frontend-3.5.0.min.css

$ gzip-size dist/govuk-frontend-3.5.0.min.css
10.4 kB

This branch:

wc -c dist/govuk-frontend-3.5.0.min.css
   99240 dist/govuk-frontend-3.5.0.min.css

$ gzip-size dist/govuk-frontend-3.5.0.min.css
11.4 kB

@NickColley
Copy link
Contributor

We think that the file size difference is worth it considering the improvements to usability.

We have two additional questions:

  1. Could we be OK with iOS devices having an initial root size of 17px instead of 16px (chat with Chris and Tim), this would mean we don't need to increase the file size.
  2. Is it a good idea in general to use this as it feels a bit hacky, we need to speak to someone from Apple/Webkit team to figure this out.

@36degrees
Copy link
Member

Interesting thread to read and follow here:
w3c/csswg-drafts#3708

@36degrees
Copy link
Member

If we do decide to ship this, we should ship it as an experimental feature behind a feature flag, ask for teams to try it out and feedback, and then we can either remove it or enable it by default in a future breaking release.

@NickColley
Copy link
Contributor

Agreed, it feels risky to ship a prefix vendored feature that is not standardised.

@NickColley
Copy link
Contributor

We want to review this when the standards have progressed more in the future, so will close this out for now.

@NickColley NickColley moved this from Needs review to Done in Design System Sprint Board Feb 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

4 participants