W3C

– DRAFT –
WCAG2ICT Task Force Teleconference

14 August 2025

Attendees

Present
bbailey, GreggVan, LauraM, maryjom, PhilDay, PhilDay4
Regrets
Chris Loiselle
Chair
Mary Jo Mueller
Scribe
PhilDay, maryjom, PhilDay4

Meeting minutes

Announcements

In CfC with AGWG on latest draft. Meant to end on Tuesday 19th at 5pm

Seen mostly +1s of support

1 comment added to issues from John A to review issue w3c/wcag2ict#750

https://github.com/mraccess77

<maryjom> /github.com/mraccess77/w3c/wcag2ict#750 (comment)

No thumbs down to block it - but was concerned about the changes proposed in resize text

Looks like it will go ahead and publish

But we may wish to respond to the comment later in the call

Daniel & Mike P also aware of some minor editorial changes that were made.

Publication likely to be on 21st August

Hope to publish Tuesday/Thursday next week

<Zakim> bbailey, you wanted to ask about checklist doc

bbailey: Is the checklist document public facing?
… to list the changes made
… The document that Mary Jo did to list the changes for Mike to see for EN

So it should be available via ETSI GitLab

Mary Jo just did a comparison between EN 301 549 notes and our new changes to WCAG2ICT. Mary Jo can send a copy if requested

We will have 1 week to review the latest draft of EN

We will not have a meeting next week - 21st August

We will resume on 28th August

Comments for WCAG2Mobile

AG WG comment on WCAG2ICT Review issue

w3c/wcag2ict#750 (comment)

2 comments were added

1 comment on 1.4.10, and another on 1.4.4

w3c/wcag2ict#750 (comment)

w3c/wcag2ict#750 (comment)

Text of the comment for ease of reference: For SC 1.4.10 Note 5 - this doesn't seem to align with the updates to the understanding document for SC 1.4.10 which interpret content blocks at 320 rather than the viewport as a whole. For example, a 3 column document could pass even if a document viewer didn't support 320 CSS pixels because each block of

text was less than 320 CSS pixels wide.

NOTE 5 reads: The intent section refers to the ability for content to reflow (for vertical scrolling content at a width equivalent to 320 CSS pixels, or for horizontal scrolling content at a height equivalent to 256 CSS pixels) when user agent zooming is used to scale content or when the viewport changes in width. For non-web software, this means

that when users scale content, adjust the size of a window, dialog, or other resizable content area, or change the screen resolution, the content will reflow without loss of information or functionality, and without requiring scrolling in two dimensions; or that the application works with platform features that meet this success criterion.

<bbailey> Recently refreshed Understanding Reflow: https://www.w3.org/WAI/WCAG22/Understanding/reflow.html

Understanding SC 1.4.10 was recently refreshed.

Bruce worked on it - there were substantive changes (many of the examples)

<bbailey> Note 1: 320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom. For web content which is designed to scroll horizontally (e.g., with vertical text), 256 CSS pixels is equivalent to a starting viewport height of 1024 CSS pixels at 400% zoom.

Current SC 1.4.10 NOTE 5

NOTE 5 (ADDED) (FOR NON-WEB DOCUMENTS)

As written, this success criterion can only be met by non-web documents where the underlying user agent or platform software can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 256 CSS pixels for horizontal scrolling content.

When the underlying user agent or platform software does not support these dimensions for scrolling, reflow is encouraged as this capability is important to people with low vision. As a reasonable benchmark, evaluate at the nearest size to what the Reflow success criterion specifies.

Proposed change:

NOTE 5 (ADDED) (FOR NON-WEB DOCUMENTS)

As written, this success criterion can only be met by non-web documents where the underlying user agent or platform software can present blocks of content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 256 CSS pixels for horizontal scrolling content.

When the underlying user agent or platform software does not support these dimensions for scrolling, reflow is encouraged as this capability is important to people with low vision. As a reasonable benchmark, evaluate at the nearest size to what the Reflow success criterion specifies.

https://w3c.github.io/wcag2ict/#reflow

Above link is the current editor's draft

Proposed change:

NOTE 5 (ADDED) (FOR NON-WEB DOCUMENTS)

As written, this success criterion can only be met by non-web documents where the underlying user agent or platform software can present blocks of content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 256 CSS pixels for horizontal scrolling content. The updated understanding document gives

examples of how this reflow should work.

When the underlying user agent or platform software does not support these dimensions for scrolling, reflow is encouraged as this capability is important to people with low vision. As a reasonable benchmark, evaluate at the nearest size to what the Reflow success criterion specifies.

Proposed change:

NOTE 5 (ADDED) (FOR NON-WEB DOCUMENTS)

As written, this success criterion can only be met by non-web documents where the underlying user agent or platform software can present content (or blocks of content) at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 256 CSS pixels for horizontal scrolling content. The updated understanding document

gives examples of how this reflow should work.

When the underlying user agent or platform software does not support these dimensions for scrolling, reflow is encouraged as this capability is important to people with low vision. As a reasonable benchmark, evaluate at the nearest size to what the Reflow success criterion specifies.

GreggVan: Does not agree that adding blocks of content is helpful - sounds like you only need to reflow a portion of the page

<bbailey> The phrase "blocks of content" is not used under the intent section:

GreggVan: if we do use it, then we will need to define what we mean by it

<bbailey> https://www.w3.org/WAI/WCAG22/Understanding/reflow.html#intent

Proposal reverting to content, but keeping ref to new understanding:

NOTE 5 (ADDED) (FOR NON-WEB DOCUMENTS)

As written, this success criterion can only be met by non-web documents where the underlying user agent or platform software can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 256 CSS pixels for horizontal scrolling content. The updated understanding document gives examples of how

this reflow should work.

When the underlying user agent or platform software does not support these dimensions for scrolling, reflow is encouraged as this capability is important to people with low vision. As a reasonable benchmark, evaluate at the nearest size to what the Reflow success criterion specifies.

2nd paragraph in NOTE 5 needs to be removed as it is better covered in NOTE 8

NEW NOTE 5

Revised NOTE 5 removing erroneous 2nd paragraph:

NOTE 5 (ADDED) (FOR NON-WEB DOCUMENTS)

As written, this success criterion can only be met by non-web documents where the underlying user agent or platform software can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 256 CSS pixels for horizontal scrolling content. The updated understanding document gives examples of how

this reflow should work.

https://www.w3.org/WAI/WCAG22/Understanding/reflow.html#content-that-can-benefit-from-two-dimensional-layout-for-meaning-or-functionality

<Zakim> bbailey, you wanted to agree that middle paragraph note 8 does not belong

Thinks that 2nd paragraph works OK in NOTE 5, but not in NOTE 8

PhilDay: Clarify that NOTE 5 is for non-web documents, and NOTE 8 for non-web software - so additional paragraph is needed for both (or removed from both)

GreggVan: Thinks it should be removed from both NOTE 5 and NOTE 8

Discussion on whether systems that have less than 320 pixels are still a problem...

Products with very small displays like smartwatches and fitness bands - closed systems, probably out of scope for this, and will wrap / reflow anyway once zoomed

These notes already existed - the only change was to split them out for non-web documents and non-web software

<bailey> In current wcag2ict: https://www.w3.org/TR/wcag2ict/#applying-sc-1-4-10-reflow-to-non-web-documents-and-software

PhilDay4: Worried about removing these paragraphs.

maryjom: reiterated that the content has not changed, the only thing that changed was to separate the note into 2 separate notes applying to non-web documents and non-web software.

GreggVan: Understands that, but still feels that these notes are not good and need changing (specifically the 2nd paragraph): When the underlying user agent or platform software does not support these dimensions for scrolling, reflow is encouraged as this capability is important to people with low vision. As a reasonable benchmark, evaluate at the

nearest size to what the Reflow success criterion specifies.

<bailey> In November 2024 WCAG2ICT, this appears as note 7

<bailey> Note 7 is only for software

Looking through the meeting minutes, reflow was covered in many meetings: https://www.w3.org/services/meeting-minutes?channel=wcag2ict&num=3000

<bailey> Gregg is Note 7 bad here: https://www.w3.org/TR/wcag2ict/#applying-sc-1-4-10-reflow-to-non-web-documents-and-software

Bailey: NOTE 7 in 2024 version - had NOTE 7 with this content

GreggVan: thinks that NOTE 7 in Nov 2024 publication was wrong

Discussion about whether the content from the old NOTE 7 should also be applied to non-web documents

NOTE 7 should have only referred to non-web software and therefore should not have split into documents and software.

NOTE 5 for non

NOTE 5 for non-web documents should be removed

NOTE 8 for non-web software should remove the reference to non-web documents

1.4.10. Remove NOTE 5. NOTE 8 to remain.

w3c/wcag2ict#750 (comment)

<bailey> I will try and make a PR after this call

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

Diagnostics

Warning: ‘s/https://github.com/mraccess77/https://github.com/w3c/wcag2ict/issues/750#issuecomment-3186015764’ interpreted as replacing ‘https:’ by ‘/github.com/mraccess77/https://github.com/w3c/wcag2ict/issues/750#issuecomment-3186015764’

Succeeded: s/https://github.com/mraccess77/https://github.com/w3c/wcag2ict/issues/750#issuecomment-3186015764

Succeeded: s/our notes/EN 301 549 notes

Succeeded: s/list/link

Succeeded: s/the intent section: 320 CSS pixels is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom. For web content which is designed to scroll horizontally (e.g., with vertical text), 256 CSS pixels is equivalent to a starting viewport height of 1024 CSS pixels at 400% zoom./the intent section: /

Succeeded: s/Test/

Succeeded: s/ejbdccuuklgujrfufnvbcvutiegjbcfurcukiktficfc//

Succeeded: s/this appears as not 7/this appears as note 7/

Maybe present: Bailey

All speakers: Bailey, bbailey, GreggVan, maryjom, PhilDay, PhilDay4

Active on IRC: bailey, bbailey, LauraM, maryjom, PhilDay, PhilDay4