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

creating an exception for large scale text from having to meet the requirements significantly reduces the usefulness of the SC 1.4.4 Resize Text #98

Open
ChrisLoiselle opened this issue Jul 28, 2021 · 3 comments

Comments

@ChrisLoiselle
Copy link
Collaborator

From Jonathan Avila - I wanted to bring this github issue (w3c/wcag#1671) and proposal from the community to the attention of this group. While the desire is to address very large headings and text (which if over 200%) of the default text may make sense, creating an exception for large scale text from having to meet the requirements significantly reduces the usefulness of the SC 1.4.4 Resize Text and I personally believe such an exception would mean the SC does not meet the minimum requirements for real users with low vision.

@ChrisLoiselle ChrisLoiselle changed the title From Jonathan Avila - I wanted to bring this github issue (https://github.com/w3c/wcag/issues/1671) and proposal from the community to the attention of this group. While the desire is to address very large headings and text (which if over 200%) of the default text may make sense, creating an exception for large scale text from having to meet the requirements significantly reduces the usefulness of the SC 1.4.4 Resize Text and I personally believe such an exception would mean the SC does not meet the minimum requirements for real users with low vision. creating an exception for large scale text from having to meet the requirements significantly reduces the usefulness of the SC 1.4.4 Resize Text Aug 21, 2021
@Myndex
Copy link
Member

Myndex commented Sep 27, 2021

Yes

I definitely agree that making large scale text an exception does harm to the SC.

BUT

I've also been on record over the last couple years that what is really needed is proportional sizing, where the largest text is zoomed less than the smallest text.

Culling over the archives of the LVTF, I see that this concept was in fact discussed about six years ago.

It is one of the issues I identified as a reason to get a vision-centered subgroup like LVTF going back in January, to be proactive in getting some of these technology limited issues addressed. In this case, it is getting browser developers on the same page.

I discuss this with examples here: https://www.myndex.com/WEB/TextZoomExample

And there's a related discussion here on the discussions tab.

The Alt SC (1.5.x) proposal

While we can't fully change WCAG 2.x, for WCAG 2.3, the proposed "alternative to 1.4.x" the 1.5.x "alt SCs" could (and are intended to) address this (and other similar problems).

For WCAG 3, what was mentioned in the guidelines is the need to zoom fonts not by a percentage, but up to a given font-size, to achieve a desired x-height.

A

@alastc
Copy link

alastc commented Jan 13, 2022

I think we need to establish what we want to mean by large text.

I don't think basing it on the definition from the text-contrast SC is useful, that was able to make an assumption that users could increase the text size from 1.4.4.

However, if a heading starts at 90px tall, 3 or 4 times the body text of the page, does it help to have that at 180px?

Surely if it is ok that the 'body text' (which needs defining) is readable at 200%, then anything larger than that is also readable?

@Myndex
Copy link
Member

Myndex commented Feb 5, 2022

Hi Alastair @alastc

I think we need to establish what we want to mean by large text.

24px is the equivalent to large text in the print world, so that would be a useful start for "large print" in general, though if you mean the "larger text on a page" I'd say 32px to 36px might be a better choice.

I don't think basing it on the definition from the text-contrast SC is useful, that was able to make an assumption that users could increase the text size from 1.4.4.

FWIW font-size is a spatial frequency metric, like font-weight, therefore it also has a direct effect on perceived contrast.

However, if a heading starts at 90px tall, 3 or 4 times the body text of the page, does it help to have that at 180px?

No definitely not. Above a certain size, readability is negatively affected. The readability range is 0.2 degrees to 2.0 degrees of visual angle. If we use x-height on the small end and cap height on the large end (which is reasonable per common use cases), that means an x-height of about 9.4px on the small end, and a 94px cap height on the large end.

For Helvetica, with a 0.5174 x-height and a 0.714 cap height, that means 18px to about 130px max.

If we want to leave space for headlines, that then implies that we want to be able to zoom and increase the 18px size up to ~90px (500%). This accommodates 20/100 or 6/30.

But while we are raising 18px to 90px, we do not want to raise a 32px headline to 160px, and especially not raise a 48px headline to 240px!!

In this situation, the 18px font goes to 90px, but the 32px font goes to 110px and the 48px font goes to no more than about 130px. See this chart:

click to enlarge
fontsize-2022

Surely if it is ok that the 'body text' (which needs defining) is readable at 200%, then anything larger than that is also readable?

Body text is defined here: Myndex/SAPC-APCA#39 (comment)

Yes... but 200% is not enough, as the previous paragraph and chart shows. Most browsers do go to 500% (though not all do it well).

Let's use 200%: you have an 18px (body), 24px, and 36px font. You raise the body font 200% to 32px... you don't want to leave the 24px font at 24px, now smaller than the body text — the designer's "intent" still needs to be observed — but if the 18ps font is doubled to 32px, that does not mean the 24px font needs to leap up to 48px... the 24px font would probably be good at 36px, and the 36px font at about 44px.

I have these examples:

https://www.myndex.com/WEB/TextZoomExample

Some of my draft work in this area:


The need for the proportional scaling method that is not based on percentage

Regarding scaling: the current 200% requirement does not address the issues of low vision necessarrly. 200% is literally the difference between 20/20 and 20/40. Plus the problem with large fonts or headlines — those should not be scaled up by the same percentage.

For best readability, the critical font size is a font that is two to three times larger than the acuity minimum. for normal vision that is about 16px to 18px. For 20/40 that is 32px to 36px. For low vision, a font size of 92px can be needed...But we also want to prevent fonts larger than 130px as that impacts readability as well.


Editorial Responsibilities (from my 2019 draft)

  • Content authors need to ensure that text can be scaled in size without breaking content, so that the:
    • User can scale the smallest content text five times larger on a full sized desktop screen without breaking content nor requiring horizontal scrolling for any single text element or text block.
    • User can scale the smallest content text two times larger on a mobile device without breaking content nor requiring horizontal scrolling for any single text element or text block.
    • User can scale the smallest content text five times larger on a mobile device without breaking content but horizontal scrolling is permitted in this use case.
    • For all of the above, larger text in the content such as headlines does not have to increase by the scale amount, provided it remains larger than the smaller text that is scaled up.
    • For complex content, the author should provide a simplified "reader mode" that presents body text in a simple form without clutter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants