1.4.4 Resize Text: Potential changes based on AG WG review

[maryjom]

In the AG WG review of the recent updates to WCAG2ICT (Issue #750) there was some concern expressed regarding the introductory language, and potentially also the notes. We'll cover this in 2 parts.

1. Introductory language

Possible changes to the introductory information on the applicability of 1.4.4 Resize Text. There have been two suggested changes to this language in issue 750.

Proposal 0 - Current language in WCAG2ICT

This success criterion is problematic to apply directly to non-web software because not all platforms provide text enlargement features that increase all displayed text to 200%. Non-web software needs to work with platform capabilities where they exist, but when the platform has text resizing that up to 200%, but not all text types scale to 200%, it is unreasonable for all apps on a particular platform to be required to build in their own text resizing. A reasonable expectation would be for non-web software to work with the text sizing features to the extent the platform provides. Doing so would still address the user needs identified in the Intent from Understanding Success Criterion 1.4.4. The following criterion is recommended as a substitute for the WCAG language:

Proposal 1 - from Gregg's comment

Modifies most of the introductory text.

This success criterion is problematic to apply directly to non-web software because not all platforms provide text enlargement features that increase all displayed text to 200%. Some platforms such as some mobile platforms do not provide built-in utilities to allow scaling of all text to 200% whereas all browsers did when the SC was written. The task force felt that the intent was to support scaling up to at least 200% by the platform, not to require that all software provide its own scaling function. However, if there is no scaling function in the platform at all then text scaling should be provided to ensure that text is large enough for those with 20/40 vision (the equivalent of 200% of 20/20). Note that this success criterion also has special considerations for ICT with closed functionality. The following criterion is recommended as a substitute for the WCAG language:

Proposal 2 - from Jon's comment

Rewords the second from the last sentence starting with "A reasonable expectation..."

This success criterion is problematic to apply directly to non-web software because not all platforms provide text enlargement features that increase all displayed text to 200%. Non-web software needs to work with platform capabilities where they exist, but when the platform has text resizing that up to 200%, but not all text types scale to 200%, it is unreasonable for all apps on a particular platform to be required to build in their own text resizing. A reasonable expectation would be for non-web software, where the platform has text resizing support up to 200%, but where not all text resizes to 200% of it's default due to the resized text already being 200% of the default body text size, resizes to the extent the platform provides. Doing so would still address the user needs identified in the Intent from Understanding Success Criterion 1.4.4. The following criterion is recommended as a substitute for the WCAG language:

2. Possible adjustments to the notes

Jon expressed concern about the notes, but we had made some adjustments so it's difficult to tell what might need changing. We currently have 2 notes that are similar to what he commented on - Notes 3 and 4

Note 3 (Added) (for non-web software)
The Intent section in Understanding 1.4.4 Resize Text refers to the ability to allow users to enlarge the text on screen at least up to 200% without needing to use assistive technologies. This means that the non-web software provides some means for enlarging the text 200% (zoom or otherwise) without loss of content or functionality, or that the non-web software works with the platform features to satisfy this success criterion.

Note 4 (Added) (for non-web software)
For non-web software, sometimes the platform provides text scaling to 200% for most, but not all text (e.g. headings, which are naturally large, may not be increased in size to 200%, but other text does increase to 200%). In such cases, authors would only need to support text scaling to the extent provided by user settings in the platform, without losing content or functionality, to satisfy this success criterion.

Do we need both notes? Should one be eliminated? Should the note(s) be edited further?

[maryjom]

@GreggVan @mraccess77 Just want to double check that this issue characterizes the concerns and proposals you both added in the AG WG Review issue #750. Jon, it did seem like you might also want adjustments to the notes - probably Note 3 - but I wasn't sure if you felt the notes also needed adjusting if the introductory text was more explanatory. Perhaps removing Note 3 would be reasonable since Note 4, I believe, provides the boundaries more clearly.

[bruce-usab]

1. I prefer Proposal 2 over Proposal 1. I don’t agree with Proposal 0, for the concerns @mraccess77 raised. I don’t think Proposal 0 (i.e., the current language as-is) warrants delay in publication.
2. I think we need both notes and that neither needs any more word smithing.

Whichever we settle upon (either Proposal 1 or 2) I will have minor editorial suggestions. I will wait to provide that feedback, pending the preferred direction of the TF. 😄

[GreggVan]

• Proposal 0 doesn't address the issues
• Proposal 2. Uses " A reasonable expectation would be " which leaves one baffled as to whether it is required or we think it should be a recommendation not a requirements - or we recommend that as the requirement.

I think Proposal 1 is the best (and only one left standing.)

HOWEVER - let me put one more on the table.

Proposal 3

Here is a variation on that -- that I think covers all the angles including places where no resizing is needed to achieve the same thing as 200% increase over normal sized text.

This success criterion is problematic to apply directly to non-web documents or software when the user agent or platform does not provide text enlargement features that increase all displayed text to 200%. For example some mobile platforms do not provide built-in utilities to allow scaling of all text to 200% whereas all browsers did when the SC was written - and the intent when the original SC was written was to support and not interfere with that (not require software to provide their own). However, if there is no scaling function in the platform at all, then text scaling should be provided to ensure that text is large enough for those with 20/40 vision (the equivalent of 200% of 20/20). Note that this success criterion also has special considerations for ICT with closed functionality. The following criterion is therefor recommended as a substitute for the WCAG language when applying to non-web software:

Except for captions and images of text one of the following is true
a) text can be resized without loss of content or functionality without assistive technology up to 200 percent using text resizing functionality of the platform or, if the platform provides text resizing capabilities but it does not reach 200 percent for all text, up to the text sizing capabilities of the platform, or
b) if the non-web software is designed to work on a platform that has no text resizing capabilities, or that functionality is not exposed to the user when using the software, text can be resized without loss of content or functionality without assistive technology up to 200 percent using text resizing functionality of the software, or
c) the platform has text resizing support that enlarges all text is up to 200% of the size of the default body text or larger and that feature is supported, or
d) software is running on a known hardware platform and all text is already known to be 3/8 of an in or larger in size.

[maryjom]

After the 28 August WCAG2ICT meeting I did some further study into what the WCAG Intent says for 1.4.4 Resize Text.

It is true that G142 allows for passing when commonly-available user agents support zoom (as Gregg aptly pointed out). There is still failure techniqueF69: Failure of Success Criterion 1.4.4 when resizing visually rendered text up to 200 percent causes the text, image or controls to be clipped, truncated or obscured that caused me some concern, but inside of this technique it says (emphasis is mine):

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.

The Intent for Understanding SC 1.4.1 (2nd paragraph) talks about the multiple ways that user agents provide text scaling and the author’s responsibility is to have their content not prevent the user agent from scaling the content effectively. Translating this to no-web documents and software, it would mean that if a platform has multiple ways to provide text scaling, they should be also be supported - meaning, they do not prevent the platform’s method of scaling content. Excerpt from this paragraph says:

The author's responsibility is to create web content that does not prevent the user agent from scaling the content effectively. Authors may satisfy this success criterion by verifying that content does not interfere with user agent support for resizing text, including text-based controls, or by providing direct support for resizing text or changing the layout. An example of direct support might be via server-side script that can be used to assign different style sheets.

But then the 3rd paragraph of the Intent seems to contradict the previous paragraph by saying:

Content satisfies the success criterion if it can be scaled up to 200% using at least one text scaling mechanism supported by user agents.

IMO, for non-web documents and software this means that if a user agent and/or platform provides multiple methods of text scaling (through zoom, setting font size, etc.) that if ONE of these methods is supported, then it passes.

I'll just put it out there, that I don't think users with low vision would really be satisfied with this outcome though this is the meaning relayed in the Intent - which means that if a user agent or platform provides any method of zoom to 200% that the user has readily available to them (e.g. a mobile platform's pinch-to-zoom or, arguably, a desktop OS's zoom capabilities), then any other method of text scaling (like changing font size in the platform or in the user agent) wouldn't need to be supported by the content.

[daniel-montalvo]

Quoting from @GreggVan email.

I just realized that we have been worrying about a non-existent problem regarding 1.4.4

We have been worrying that inlarging the text to 200% was not supported on all products, particularly focusing on mobile where it makes some fonts larger but not necessarily all.

This worry was predicated on thinking that it meant inlarging the text in a fashion that would word wrap etc. so there would be no horizontal scrolling. (or vertical for top/down languages)

In fact, this provision only requires that the content can be ZOOMED to 200%. There is in fact no requirement in 1.4.4 for “no horizontal scrolling”. As desirable as this is - it was not in 1.4.4. And in fact the techniques for 1.4.4 acutally list magnification or zoom as being a sufficient technique.

THEREFORE

• there is no need for this note on non-web Software.

NOTE 2: For non-web software, sometimes the platform provides text scaling to 200% for most, but not all text (e.g. headings, which are naturally large, may not be increased in size to 200%, but other text does increase to 200%). In such cases, authors would only need to support text scaling to the extent provided by user settings in the platform, without losing content or functionality, to satisfy this success criterion.

nor for this phrase in the requirement

either up to 200 percent or, if the platform provides text resizing capabilities but it does not reach 200 percent for all text, up to the text sizing capabilities of the platform.

THERE IS A CONCERN HOWEVER

for things like KIOSKS where the OS functions are blocked and for products that do not have an OS with ZOOM capability (dedicated function products like a themostat ) So we DO need to address those.

But on the other hand - we should not be requiring zoom on things that already have large print (larger than 200% of normal body text)

SO I SUGGEST

FOR NON-WEB DOCUMENTS — we go with just

10.1.4.4 Resize text
Where ICT is, or includes, a non-web document,
the non-web document shall satisfy the WCAG 2.2 Success Criterion 1.4.4 Resize text.
NOTE 1: Content for which there are software players, viewers or editors, or platforms with a 200 percent zoom feature would automatically meet this success criterion when used with such players, unless the content will not work with the zoom.
NOTE 2: It is best practice to use only fonts that allow for scaling without loss of quality (e.g. pixelized presentation). This applies in particular to embedded fonts.
NOTE 3: For ICT where the absolute size of the text can be controlled, it is best practice is for the default presentation of text to have an x-height of at least 1.2mm. For a 14 inch screen at 1920 x 1080 screen resolution with no zooming or display scaling, this means the x-height of the default text before zoom needs to be at least as big as Arial at 16 CSS px, and if zoom is not provided, the minimum size of the text in at least one setting would be 2.4mm or 32 CSS px.

FOR NON-WEB SOFTWARE — we go with just

11.1.4.4 Resize text
Where ICT is, or includes, non-web software that provides a user interface,
the non-web software shall allow text to be resized up to 200% without loss of content or functionality, except where the absolute size of the text is known or controlled by the software and the minimum font size is already 2.4mm or larger
NOTE 1: The Intent section in Understanding 1.4.4 Resize Text refers to the ability to allow users to enlarge the text on screen at least up to 200% without needing to use assistive technologies. This means that the non-web software supports the zoom features of the underlying platform software or that the non-web software provides some means for enlarging the text to 200% without loss of content or functionality.
NOTE 2: The techniques for 1.4.4 Resize Text list the normal Zoom feature of browsers and platforms to be sufficient to meet SC 1.4.4 and to not require that the Zoom feature wrap the text. A pinch zoom feature such as is found on mobile phones would meet this description if they allow zoom of at least 200%.
NOTE 3: Some applications such as kiosks or digital signs already have print that is larger than 200% of typical body text. Where their minimum text size is already known and of large print size, this requirement does not require additional zoom.
NOTE 4: Some applications do not allow access to the underlying platform zoom features or run on platforms without an underlying zoom feature. If their minimum physical font size is not known or is less than 2.4 mm, then the application would need to provide a feature that provides 200% zoom or creates a known minimum font size of 2.4mm.

NOTE 5: Good practice is for the default presentation for text to have an x-height that's at least as big as Arial at 16 CSS px so that it is 32 CSS after 200% zoom.

Thoughts ?

[detlevhfischer]

NOTE 3: Some applications such as kiosks or digital signs already have print that is larger than 200% of typical body text. Where their minimum text size is already known and of large print size, this requirement does not require additional zoom.
NOTE 4: Some applications do not allow access to the underlying platform zoom features or run on platforms without an underlying zoom feature. If their minimum physical font size is not known or is less than 2.4 mm, then the application would need to provide a feature that provides 200% zoom or creates a known minimum font size of 2.4m

To accommodate different non-web software display sizes and viewing distances, would it not be better to refer to the viewing-angle-based formula used in EN 301 549, 5.1.4 Functionality closed to text enlargement (possibly with a couple of examples what this means (i.e., to what minimum size it would translate) for a kiosk scenario and a small display scenario (such as the display of card reader or payment terminal)?

5.1.4 Functionality closed to text enlargement
ICT shall provide a mode of operation where the text and images of text necessary for all functionality is displayed in such a way that a non-accented capital "H" subtends an angle of at least 0,7 degrees at a viewing distance specified by the supplier.

[GreggVan]

I didnt think we were trying to write requirements for products with closed functionality. Just noting the problems that might arise with certain provisions in the list of SC in the appendix related to closed products.

[maryjom]

Any problems for products with closed functionality should be stated in that appendix. 1.4.4 already has a note that says to see that section.

I see this text as proposed by the EN 301 549:

NOTE 3:  Good practice is for the default presentation for text to have an x-height that's at least as big as Arial at 16 CSS px

This is similar to what was proposed last week, but this note is assuming the viewing distance is that of a laptop or print material that you're reading. Since this is being applied to all software, including digital signage, TVs, etc., this means viewing distance should be affecting the minimum acceptable font size.

My thought is that WCAG2ICT should NOT include such a note implying what a minimum font size should be.

[GreggVan]

Good thought with regard to TVs and Virtual displays. For signage - it would not usually apply since the provision requires software with a human interface.

I opened an issue in gitlab citing your comment (except it is currently note 4) and recommending

that we add ".. for software expected to be viewed at ~400mm." to the end of the note 4 so that it reads

Note 4: Good practice is for the default presentation for text to have an x-height that's at least as big as Arial at 16 CSS px for software expected to be viewed at ~400mm.