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/
<maryjom> /github.com/mraccess77/w3c/
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
2 comments were added
1 comment on 1.4.10, and another on 1.4.4
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://
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://
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://
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.
<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://
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://
<bailey> Gregg is Note 7 bad here: https://
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.
<bailey> I will try and make a PR after this call