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

Services using AF do not resize text #43

Open
shabana-ali opened this issue Sep 22, 2020 · 5 comments
Open

Services using AF do not resize text #43

shabana-ali opened this issue Sep 22, 2020 · 5 comments
Labels
large text Audit task: switch to large text wcag Web Content Accessibility Guidelines 2.1

Comments

@shabana-ali
Copy link
Contributor

shabana-ali commented Sep 22, 2020

Increasing the font size on Chrome, Firefox or IE11 does not increase the size of the text.

GOV.UK Design System specifies font size in "em" and "px" as fallback. AF only has "px".

Seen on Vat View and Change https://docs.google.com/document/d/1ElwRokMTBHszYPdaJGPD3NoQCSAfgwnZ4zSPGnQHM7E/edit

@shabana-ali shabana-ali added wcag Web Content Accessibility Guidelines 2.1 large text Audit task: switch to large text labels Sep 22, 2020
@adamliptrot-oc
Copy link
Contributor

Digging into the wording of the criteria. (https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G142)
Sufficient techniques: Using a technology that has commonly-available user agents that support zoom

The objective of this technique is to ensure content can be scaled uniformly by using a Web technology supported by user agents that change text size via a Zoom tool.

and

This technique requires that the zoom function preserve all spatial relationships on the page and that all functionality continues to be available.

and

Internet Explorer 7 and Opera 9 provide a zoom function that scales HTML/CSS page content uniformly.

So that suggests that just using the page zoom is enough.
I know that there is some chatter on the WCAG boards about potentially dropping this criteria in the future.

Notable note: (https://www.w3.org/WAI/GL/2016/WD-WCAG20-TECHS-20160105/F69)

Note: The Working Group has discovered many misunderstandings about how to test this failure. We are planning to revise this failure in a future update. Until then, if the content passes the success criterion using any of the listed sufficient techniques, then it does not meet this failure.
Increase the text size of the content by 200%.
Check that no text is clipped, truncated, or obscured.

So basically as long as the font can be increased by 200% in some way (whether that includes the other parts of the page or not) and no readability is lost then we are good.

@adamliptrot-oc
Copy link
Contributor

I think it is worth testing and reporting. And I’d like to see the issue fixed in AF.
Just because it isn’t a WCAG doesn’t mean it doesn’t cause an issue for someone (who maybe wants bigger text but doesn’t want a page to take on a mobile layout).
So we should report it under “other accessibility/usability issues” but don’t flag it as WCAG.

@adamliptrot-oc
Copy link
Contributor

Plat-UI performed a spike to look at implementing non-px font-sizing in AF.
Due to the complexities involved, the high-traffic nature of services still using AF, the upgrade paths and the presence of large amounts of service-specific css in older services it was thought that it would be better to leave AF as it is.

@ashfaqhussain357
Copy link

New playfrontend library used. Only 5 or so services are using assets frontend so not deemed an issue anymore.

@shabana-ali
Copy link
Contributor Author

shabana-ali commented Jul 16, 2024

https://hmrcdigital.slack.com/archives/C01RVNY177E/p1715075868766259

May 2024 - four frontend microservices still currently using assets-frontend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
large text Audit task: switch to large text wcag Web Content Accessibility Guidelines 2.1
Projects
Status: Done
Development

No branches or pull requests

3 participants