W3C

– DRAFT –
WCAG2ICT Task Force Teleconference

28 August 2025

Attendees

Present
bbailey, Chris_Loiselle, GreggVan, maryjom, PhilDay
Regrets
-
Chair
Mary Jo Mueller
Scribe
PhilDay

Meeting minutes

<Chris_Loiselle> Hi all, I would scribe but need to trust IRC, it keeps dropping. Thanks for the welcoming!

Announcements

<bbailey> https://github.com/w3c/wcag2ict/wiki/Work-for-the-week#28-august

EN v16 draft is out (EN 301 549). Comments due by this Sunday

<bbailey> Woot!

WCAG2ICT was published on 21 Aug. We still have more work to do - but that was good progress

<maryjom> https://www.w3.org/TR/wcag2ict-22/

Published version - see link

<maryjom> WCAG2ICT overview page: https://www.w3.org/WAI/standards-guidelines/wcag/non-web-ict/

Also updated the overview page

GreggVan: new EN draft is out. Do you have a link?

<bbailey> I am happy to see that previous URL works as expected: https://www.w3.org/TR/wcag2ict/

Don't think it is uploaded - was sent via email.

TF welcome Chris

AG WG comment: 1.4.4 Resize Text

<bbailey> w3c/wcag2ict#772

We did have comments on resize text - didn't block publication, but we still want to review the feedback

Issue 772 took comments from the AG WG general review thread, and also added some proposals for revised language

[Mary Jo sharing screen, currently showing issue https://github.com/w3c/wcag2ict/issues/772]

Introductory language - some concerns were expressed.

<maryjom> Proposal 0: 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

<maryjom> 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

<maryjom> Criterion 1.4.4. The following criterion is recommended as a substitute for the WCAG language:

Latest from v16 of EN: 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 with a 200 percent zoom feature would automatically meet this success criterion when used with such players, unless the content will not work with 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: 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 text needs to be at least as big as Arial at 16 CSS px.

WCAG2ICT TF - we modified the SC. Looks like the EN committee didn't take this change - probably as they were focusing solely on the latest comments rather than making new technical changes.

The issue (772) concerned the introductory text along with one of the notes

Jon's proposal rewords the penultimate sentence (proposal 2). Gregg's (proposal 1) rewords most of the paragraph.

Gregg also added proposal 3 with further refinements

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:

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 software when platforms do 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.

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

c) 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.

Gregg: This was written way back when - so can comment on that, and talk about the assumptions about 200% in all browsers. We are now talking about non-web content.

If it is all on a kiosk or something and it already has very large text - then there shouldn't be a requirement to also provide additional zoom.

3rd option - if there is no zoom on the platform - then you don't have to do anything (particularly in a closed system that doesn't allow access to any accessibility features).

Gregg: This is complicated; I've tried to cover all possibilities but it is rather complex and is therefore a little longer

<PhilDay> +1 to Gregg's proposal 3

maryjom to poll options

<maryjom> POLL: Which proposal do you prefer? 0) Proposal 0 – leave as-is, 1) Proposal 1, 2) Proposal 2, or 3) Proposal 3, or 4) something else

3, but would also accept 2 or 1

<GreggVan> 3

<Chris_Loiselle> Per what Gregg shared today, I lean to proposal 3

bbailey: Nice to use somebody else's suggestion. Jon's edit was fairly minimal over the previous suggestion which is nice, but Gregg's proposal 3 is more complete.

maryjom: Suggested next stage is to put in a PR and allow wider TF to review.

maryjom: Think that we can't get this into the EN at this late stage - only comments that are being accepted are updates to previous work.

<bbailey> I like Gregg's Proposal 3 but it seems to be missing Jon's key addition: 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

<Zakim> bbailey, you wanted to discuss another comment

bbailey: Another argument for using Jon's proposal as it is less change.

maryjom working on tweak to proposal 3 to address bbailey's concern above

<maryjom> For example some mobile platforms provide built-in utilities to allow scaling of some, but not all text to 200%, whereas all browsers did when the SC was written...

<maryjom> For example some mobile platforms provide built-in utilities to allow scaling of some, but not all text to 200%, whereas all browsers did scale all text to 200% when the SC was written...

GreggVan: Agree with the wording - but put it in the exceptions (a-c)

<bbailey> I think all these are just for non-web software and we don't say anything for non-web documents.

maryjom: We didn't pull this one into separate sections for non-web documents vs non-web software

<Zakim> PhilDay, you wanted to suggest we could just add or documents in the introductory paragraphs

Discussion ensued on whether this should also apply to non-web documents. If you embed code in a document, does it become software?

PhilDay: suggest we just add non-web documents or software

<maryjom> 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%.

<PhilDay> +1 to maryjom's modified text

ack

bbailey: can we move on and come back to this later in the meeting?

[maryjom adding Google doc to help with editing this introductory text to resize text]

<bbailey> Current phrasing seems to miss that SOME text must increase to %200 (or min 3/8).

<maryjom> Google doc: https://docs.google.com/document/d/17Ih8--GfBZEnuiKxIJJ95w4oI3x17ROLw_wuKzxtTws/edit?usp=sharing

Gregg has done a modified version to address Jon's comment

(Replaced proposal 3 with a new edit)

<bbailey> +1 to Proposal 3 (with its four options)

Gregg's latest edit (taken from google doc):

Proposal 3 - From Gregg’s comment in the new issue

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 therefore 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.

Chris_Loiselle: Gregg's point - the OS on mobile - should be held responsible for meeting this. We don't have to provide an exception. What we are writing here makes sense.
… Don't want to give an exception along the lines of "if you OS doesn't support it, then you are OK..."

maryjom: How do we cover the fact that mobile apps don't have to provide additional zoom in addition to the platform

Discussion about pinch-zoom in mobile. Is pinch-zoom AT? This requirement is without AT.

GreggVan: AT is not all the accessible features of the platform

Chris_Loiselle: Remember we discussed accessibility features vs AT. Pinch zoom is a feature, not AT.

What Jon was mentioning was lived experience of what could be considered as AT.

The other topic was possible adjustments to notes

Notes 3 & 4 became similar

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.

Gregg: references sufficient techniques for resize text - which says that zoom features pass
… from understanding document

browsers allow you to zoom - analogous to mobile apps allow you to zoom

bye

<Chris_Loiselle> if someone was to remove ability to zoom (pinch to zoom) then that would fail. I believe around 2017 iOS and Android changed user scalable restrictions

Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).

Diagnostics

Succeeded: s/langauge/language

Succeeded: s/text much increase/text much increase/

Succeeded: s/text much increase/text must increase/

Succeeded: s/1 to Proposal 3 (with 4 options)/1 to Proposal 3 (with its four options)/

Succeeded: s/sufficient test/sufficient techniques

Maybe present: Gregg

All speakers: bbailey, Chris_Loiselle, Gregg, GreggVan, maryjom, PhilDay

Active on IRC: bbailey, Chris_Loiselle, GreggVan, maryjom, PhilDay