Meeting minutes
Issue 4 - 1.4.4 Resize Text
<maryjom> w3c/
<maryjom> Google doc link: https://
<maryjom> Discussion: https://
AG WG have been working on resize text, but no substantive input to share yet
<maryjom> w3c/
<maryjom> Google doc link: https://
<maryjom> Discussion: https://
bruce_bailey: (On AG WG calls on resize text). Most discussion has been around reflow.
… what passes reflow, and what does not
Applying SC 1.4.4, content from latest editor's draft: https://
Starting at point 3
Point 3: SC 1.4.4 should require scaling in native apps to the extent supported by user settings of the platform.
<bruce_bailey> +1 to best practice at the very least
mitch11: Perplexed on this between understanding that suggests 200% always, or common sense that should include some pragmatism
<Chuck> For non-web software, there may be cases where the platform does not scale all content up to 200%, as WCAG is limited to web content. In such cases, scaling content to the extent supported by user settings in the platform is considered a best practice.
Chuck: suggested a modification
<maryjom> What is in current editor's draft guidance: https://
bruce_bailey: Likes Chuck's statement, but strengthen best practice. "is the way to meet the intent of this success criteria"
<Chuck> For non-web software, there may be cases where the platform does not scale all content up to 200%, as WCAG is limited to web content. In such cases, scaling content to the extent supported by user settings in the platform is the best approach to meet this success criterion.
<Chuck> For non-web software, there may be cases where the platform does not scale all content up to 200%, as WCAG is limited to web content. In such cases, scaling content to the extent supported by user settings in the platform is the best approach to meet the intent of this success criterion.
bruce_bailey: Suggest we include this in the document as it is a helpful note
Agreement: take option 2 on Point 3 to task force
Point 4: We should allow the largest text to enlarge to less than 200%.
<bruce_bailey> +1 but the doc might not be so explicit
Gregg response: https://
mitch11: agrees that closed functionality suggestions from Gregg may be helpful for open systems as well - as a best practice
Chuck: Worried that we might be diminishing 200%
… in this case
… would rather have a direction that says "this is a sufficient approach to meet the 200% requirement" rather than "it's OK to not meet 200%"
<bruce_bailey> +1
Chuck: you have big text, ... this is a sufficient alternative to meet the intent of this success criterion.
<bruce_bailey> context is large headings not scaling 200%
mitch11: Would rather have a note on this question in the broader SC, not just in closed section
mitch11: Let's start with the issue response, then look at what needs to go back into the doc
Latest iteration: Where a platform does not support text enlargement up to 200%, non-web software content that has large text (such as content that, in its native size, the height of letter h is greater than 0.25 inches (6.35 millimeters)), would address the user need behind this success criterion.
mitch11: could also include the concept of 200% 'body' text or 'normal' text when you cannot always measure the physical size
mitch11: low vision group may have already written a similar statement
We could combine Points 4 and 5 together
Point 5: We should allow most or all text to enlarge to less than 200%, when the text is initially not particularly small
Proposal: take option 1 back to task force to address points 4 & 5
Option 1: Potential response
Where a platform does not support text enlargement up to 200%, non-web software content that has large text (such as content that, in its native size, the height of letter h is greater than 0.25 inches (6.35 millimeters)) would address the user need behind this success criterion.
Where a non-web software does not allow measurement of physical size, the non-web software should support scaling of 200% above a typical platform default size for body text, and anything smaller than body text.
May need survey to refine the content
Point 6: We've long held that PC magnifier programs are assistive technology and therefore not a method of meeting 1.4.4. Is the same true on other platforms?
Assertion came from the understanding text.
Understanding 1.4.4: “The intent of this Success Criterion is to ensure that visually rendered text, including text-based controls (text characters that have been displayed so that they can be seen [vs. text characters that are still in data form such as ASCII]) can be scaled successfully so that it can be read directly by people with mild visual
disabilities, without requiring the use of assistive technology such as a screen magnifier.”
PhilDay: Understanding might refer to the need for adding 3rd party accessibility technology. We could differentiate 3rd party and built in (platform or application) features that enhance accessibility such as platform features for zoom
Mitch to work on further refinements on Point 6
We can then survey the TF
Point 7 (new, not yet mentioned in issue 4): How can 1.4.4 apply to content with no clearly defined default font size?
This will be raised as an issue on WCAG3