Note on WCAG risk for fluid type

[aardrian]

Added two sentences with two links total noting the risk with clamp() and vw for WCAG 1.4.4.

[github-actions]

Alex Recommends Report

Alex recommends the following language changes, but Alex is a regular expression based algorithm, so take them with a grain of salt.

src/site/content/en/blog/min-max-clamp/index.md

Level	Location	Word	Recommendation
⚠️	147:30	just	just may be insensitive, try not to use it
⚠️	220:41	clearly	clearly may be insensitive, try not to use it
⚠️	238:25	just	just may be insensitive, try not to use it

[netlify]

Deploy preview for web-dev-staging ready!

Built with commit 51568f8

https://deploy-preview-4080--web-dev-staging.netlify.app

[jpmedley]

Thank you for the contribution. I have a suggestion about it and we need to get the approval of the post author.

@una what do you think?

[aardrian]

@jpmedley Let's pretend I am new to GitHub. I cannot find what you changed or requested to be changed.

If it is adding an article to this sentence: "…it is a WCAG failure under…", then I am totally on board with it.

[una]

Suggested change:

{% Aside 'warning' %}
Limiting how large text can get with max() or clamp() can cause a WCAG failure under 1.4.4 Resize text (AA), as a user may be unable to scale the text to 200% of its original size. Be certain to test the results with zoom.
{% endAside %}

[una]

Thank you for opening this PR! I agree it's important to note in there and wasn't aware of this caveat before regarding text accessibility.

(As an aside, this sounds like a browser bug that should be resolved, as zoom should always override preferences. Do you think this is worth bringing up as a bug?)

Let me know what you think of the update. I reworded it to be more focused on the primary content/be more direct and added a bit of styling that will call this out as a warning

[aardrian]

With one exception, I am totally fine with your edit. I would not pretend to be able to do your voice, so I tried to keep it as generic as possible.

The exception is that you replaced vw with max(), and while max() is a good add (thanks!), viewport units (including vh) have their own call-out in WCAG and are the most common reason today that I end up flagging this SC in audits: F94: Failure of Success Criterion 1.4.4 due to incorrect use of viewport units to resize text.

As for the browser bug question, maybe? We already convinced browsers to ignore that meta tag that prevents zooming at all, so there may be a case for a method to zoom without making users have to wade into the settings / guts. Would be happy to gather your thoughts separately (partly because I am too close to the issue, methinks).

[jpmedley]

My requested change seems to be gone completely.

What I questioned was the need to say that this limitation is per the spec. Nearly every requirement of the web is because of a spec. We don't say it every time and don't need to because it's assumed. Is there more to this limitation than the fact that spec authors had to pick a number and it happens to be 200? Is so, then that's the explanation that should be here, not that it's in a spec.

[aardrian]

I may be a bit confused here. I cited the WCAG Success Criterion that mandates the ability to scale text by at least 200%. That SC is encoded in global accessibility legislation as well, so WCAG is now more than a set of guidelines (it is not a spec), but is law. I linked to the SC directly because it provides reasons, techniques, known failures, and more. To explain all of that in this article would be well outside the scope of the article.

Does that address your concern?

[aardrian]

FWIW, I would have been fine with @una's edit (and as the author I think she would have final say). But I am happy to see this approved and thanks for accepting it.

[jpmedley]

Yeah, I messed that up. Corrected in #4112