Meeting minutes
dmontalvo: Has made changes to the code. Pull request fixes some of the broken links for included content, missing notes etc
… Also fixes bug where new notes from WCAG 2.2 changes were not being included - now it is all done. Webpage also updated.
Editors to review the PR above - and anyone else who is interested. Changes things in definitions, tags, and content should now be current
Announcements
1.4.10 Reflow – replacement text for Notes 6 and 7
<maryjom> https://
Last worked on reflow a couple of weeks ago - Friday meeting early in March.
Above google doc contains draft content
Result of Friday meeting was Option 3A. Then wanted Sam's input as he was key in some of the feedback.
Sam then came up with option 3B
Option 3A: Mitchell’s edits to Option 3 (to replace current editor’s draft’s Notes 6 & 7) NOTE 6: As written, this success criterion can only be met by non-web documents or software where the underlying user agent or platform can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 240 CSS pixels for horizontal scrolling content.
…
When the underlying user agent or platform does not support these dimensions for scrolling, reflow is highly encouraged as this capability is essential to persons with low vision. As a reasonable benchmark, implement and evaluate at the nearest possible equivalent size to what the Reflow success criterion specifies. For systems that do not support zoom, scrolling, and reflow, user needs such as low vision are often addressed by other means (i[CUT]
…
to using sufficiently large text and single screen designs).
Option 3B: Sam’s edits to option 3A NOTE 6: As written, this success criterion can only be met by non-web documents or software where the underlying user agent or platform can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 240 CSS pixels for horizontal scrolling content. ...
… When the underlying user agent or platform does not support these dimensions for scrolling, reflow is encouraged.
Sam's concern was that he thought we were exceeding our remit with the last sentence (talking about other means to meet user needs).
This note is in the general SC guidance, not in the SC problematic for closed
SC problematic for closed / 1.4.10 reflow has the following text in the current editor's draft:
1.4.10 Reflow — Many closed functionality products do not allow users to modify the viewport or change font sizes, so there would be no need to impose a requirement on all closed functionality that content is able to reflow. Additionally, many closed functionality products do not display large chunks of text and only have UI controls; in such cases, two-directional scrolling to access the text and UI controls may be considered essential.
Lauramiller: Extra context in last 2 sentences may be helpful, but it is quite a lot of words - so conciseness would be better
mitch11: Extra content was from a group discussion - doesn't feel strongly on the conciseness/extra help debate.
mitch11: Think we should propose both alternatives to get full TF input
maryjom: 'encouraged' change to 'is generally considered to be best practice'
mitch11: not sure what is meant by "reflow is encouraged".
Minor editorial to option 3B
Option 3B: Sam’s edits to option 3A NOTE 6: As written, this success criterion can only be met by non-web documents or software where the underlying user agent or platform can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 240 CSS pixels for horizontal scrolling content. ...
… When the underlying user agent or platform does not support these dimensions for scrolling, reflow is generally considered a best practice.
mitch11: Are we saying 2 contradictory things? Can only be met by X, but if not met, reflow is encouraged. Are these contradictory?
maryjom: Because WCAG is specific about viewport size we can't be too specific.
mitch11: Ok with ambiguity then if it is due to WCAG ambiguity
Consensus - take both options 3A & 3B above to full TF (with extra editorial change as per above)
[minor editing of option 3A in google doc to reduce complexity]
Edited version of 3A:
NOTE 6: As written, this success criterion can only be met by non-web documents or software where the underlying user agent or platform can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 240 CSS pixels for horizontal scrolling content. ...
When the underlying user agent or platform does not support these dimensions for scrolling, reflow is encouraged as this capability is important to persons with low vision. As a reasonable benchmark, evaluate at the nearest size to what the Reflow success criterion specifies. ...
For systems that do not support zoom, scrolling, and reflow, user needs such as low vision are often addressed by other means (including but not limited to using sufficiently large text and single screen designs).
mitch11: On vacation for next 2 weeks. Issue 4 is currently assigned to me. Can we cover this next?
ChrisLoiselle: Q about platform vs system?
… Are the differences clear?
Further tweak to last sentence of Option 3A:
For platforms that do not support zoom, scrolling, and reflow, user needs such as low vision are often addressed by other means (including but not limited to using sufficiently large text and single screen designs).
Issue 4 – Looking for guidance regarding SC 1.4.4 Resize Text, on mobile native apps
mitch11: Mitch started a discussion # 220
<maryjom> https://
In the SC problematic for closed section, we have the following note for 1.4.4 Resize text:
1.4.4 Resize Text—because the text rendering support in a closed environment may be more limited than the support found in user agents for the Web, meeting Success Criterion 1.4.4 in a closed environment may place a much heavier burden on the content author;
maryjom: Could take a similar approach as for reflow - if not support 200%, test at the closest that is supported
mitch11: One possible proposal, if mobile platform does not support 200%, then application should support 200%
… Prefer to not state 'it must'
<maryjom> https://
Reference to editor]s draft to see if we need to change SC content to address the public comment
mitch11: Note 2 addresses the argument about only requiring on the platform. Note 2 says it is an either/or situation for application or platform
Does anyone disagree with note 2?
No objection from group. Mitch to base reply on issue 4 using the content from note 2
… issue 4 is a public comment
[Discussion around system magnifiers like pinch zoom on mobile, seems strange to require app to support 200% as well as text can be enlarged in other ways˙
mitch11: Think we need other perspectives to pressure test the reply to the comment
mitch11: Thinking about a questionnaire to get more input on these questions
maryjom: Similar questions have been raised in general AGWG
Other view is to 'let the magnifier do the work'
If technology has changed to the point where platforms/user agents have done the work for you in terms of resize, why not make use of those features?
Bruce & Mike Gower have been discussing similar issues in AG WG issues list.
Next step? Mary Jo to contact Bruce & Mike and ask them for input. Mike could join our call to discuss it.
mitch11: Feels like we are at working session stage - not reviewing final content stage
See whether this is just a WCAG issue -in which case we could leave it to them.
mitch11: WCAG3 - not just web, so it should also be covered there
We will continue working on other issues next week.
Do we think there needs to be a change to 1.4.4 Resize text? That is a question to mull over
We will work on other issues in extra working meeting tomorrow, and then next week.
There is also a mobile task force working on guidance for meeting WCAG criteria on mobile, so they may also be relevant.