w3c/wbs-design or
by mail to sysreq.
W3C
Site Navigation
Nearby
Results of Questionnaire WCAG2ICT - Review proposed answer to Issue 4
The results of this questionnaire are available to anybody. In addition, answers are sent to the following email address: maryjom@us.ibm.com
This questionnaire was open from 2024-04-27 to 2024-05-01.
7 answers have been received.
Jump to results for question:
- Introduction: Survey regarding Issue 4 on applying 1.4.4 Resize Text to native mobile apps
- (Part 1 of 4 for Issue 4) Point 3: SC 1.4.4 should require scaling to the extent supported by user settings of the platform
- (Part 2 of 4 for Issue 4) Points 4 & 5: Parts or all of the text is already a sufficient size
- (Part 3 of 4 for Issue 4) Point 6: Are built-in platform accessibility features considered AT?
- (Part 4 of 4 for Issue 4) Does 1.4.4 Resize Text guidance in WCAG2ICT need changes?
1. Introduction: Survey regarding Issue 4 on applying 1.4.4 Resize Text to native mobile apps
A list of major commenter points was gathered from Issue 4: Looking for guidance regarding SC 1.4.4 Resize Text on native mobile apps. The extra Friday group has drafted some potential responses to these points. This survey is to review those proposed responses.
If you need the full background, see Issue 4: Looking for guidance regarding SC 1.4.4, Resize Text, on mobile native apps and the WCAG2ICT discussion thread on 1.4.4 Resize Text.
Proposed responses to the various points brought up in the issue can be found in the Google doc on 1.4.4 Resize Text. Each question links to the description of the commenter's point. The draft responses you're reviewing are the level 4 headings below each of those points. In your responses, if you do not agree or think edits are needed, please help us to quicker resolution by drafting an alternate response with the desired edits.
Summary
| Choice | All responders |
|---|---|
| Results |
Details
| Responder | Introduction: Survey regarding Issue 4 on applying 1.4.4 Resize Text to native mobile apps | Comments |
|---|---|---|
| Phil Day | OK. Detail below | |
| Chris Loiselle | No comment. | |
| Sam Ogami | ||
| Loïc Martínez Normand | ||
| Bruce Bailey | I have no significant concerns for where we are in addressing Issue 4. I have only the one minor comments in this survey. But just to state my prejudices: 1. using platform setting (when they are robust and well documented) meets the SC. 2. large / header fonts need not scale by %200 [ but tiny / footer not scaling is a fail ]. 3. 200% is EZ, developers are trying for 400%. For the TF consideration: 16 px -> 32 px is 400% (2x high, 2x tall) [ please correct me if I am off base with this ] | |
| Mike Pluke | ||
| Fernanda Bonnin |
2. (Part 1 of 4 for Issue 4) Point 3: SC 1.4.4 should require scaling to the extent supported by user settings of the platform
For this question, review Option 2 proposed response to Point 3 in the Google doc.
Indicate if this answer sufficiently addresses the point brought up. If edits are needed, provide the detailed edits in the survey or in the Google doc.
Summary
| Choice | All responders |
|---|---|
| Results | |
| The proposed way to handle Point 3 and proposed response is sufficient, as is. | 3 |
| The proposed way to handle Point 3 and proposed response is sufficient, with edits. (Provide detailed changes here or in the Google doc.) | |
| Something else. (Provide your alternate proposal in the Google doc.) | 3 |
(1 response didn't contain an answer to this question)
Details
| Responder | (Part 1 of 4 for Issue 4) Point 3: SC 1.4.4 should require scaling to the extent supported by user settings of the platform | Comments |
|---|---|---|
| Phil Day | The proposed way to handle Point 3 and proposed response is sufficient, as is. | |
| Chris Loiselle | The proposed way to handle Point 3 and proposed response is sufficient, as is. | |
| Sam Ogami | Something else. (Provide your alternate proposal in the Google doc.) | Adding "When known by the authors" to first sentence. When known by the authors that a user agent or platform does not provide a text enlargement function, authors would need to provide it. Need to make clear that the author needs to know that the user agent does not support zoom. This also adds a requirement to all interfaces without exemption. Where the same information is conveyed on multiple displays only one display needs to meet this SC. |
| Loïc Martínez Normand | I agree with option 3 (Sam's edits). | |
| Bruce Bailey | The proposed way to handle Point 3 and proposed response is sufficient, as is. | |
| Mike Pluke | Something else. (Provide your alternate proposal in the Google doc.) | Sam's Option 3. |
| Fernanda Bonnin | Something else. (Provide your alternate proposal in the Google doc.) | The normative text of the S.C. doesn't provide specific requirements for how to approach the scenario where the user agent doesn't provide text enlargement. If the platform does not support resizing text, and WCAG2ICT requires applications implement it from scratch themselves, it implies that applications have the responsibility of shipping their own assistive tech, to support anything else in WCAG that doesn't have an exemption for inadequate platform support (e.g. reflow). This would also set precedent for future guidance that may include other AT and interaction models. |
3. (Part 2 of 4 for Issue 4) Points 4 & 5: Parts or all of the text is already a sufficient size
For this question, read and understand Point 4: We should allow large text to enlarge to less than 200% and Point 5: We should allow most or all text to enlarge to less than 200%, when the text is initially not particularly small in the Google doc. Then read Option 1, the draft response which the Friday sub-group felt covered both situations.
Indicate whether this response is sufficient to address the issue raised. If edits are needed, provide the detailed edits in the survey or the Google doc.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Proposed response to points 4 & 5 is sufficient, as-is. | 6 |
| Proposed response to points 4 & 5 is sufficient, with edits. (Provide detailed changes here or in the Google doc.) | |
| Something else. (Make your alternate proposal either in the survey or the issue.) | 1 |
Details
| Responder | (Part 2 of 4 for Issue 4) Points 4 & 5: Parts or all of the text is already a sufficient size | Comments |
|---|---|---|
| Phil Day | Proposed response to points 4 & 5 is sufficient, as-is. | |
| Chris Loiselle | Proposed response to points 4 & 5 is sufficient, as-is. | |
| Sam Ogami | Something else. (Make your alternate proposal either in the survey or the issue.) | Point 4 option 1 is fine. I am not sure on Point 5 |
| Loïc Martínez Normand | Proposed response to points 4 & 5 is sufficient, as-is. | |
| Bruce Bailey | Proposed response to points 4 & 5 is sufficient, as-is. | |
| Mike Pluke | Proposed response to points 4 & 5 is sufficient, as-is. | |
| Fernanda Bonnin | Proposed response to points 4 & 5 is sufficient, as-is. | mostly curiosity: why did we decided on using the "height of letter h" vs the possibility in point 5 of "Achieve a font size sufficient for 20/40 or 20/80 vision, without reference to the percentage increase. Base this on the viewing distance established in WCAG2ICT's extended definition of 'CSS pixel.'" |
4. (Part 3 of 4 for Issue 4) Point 6: Are built-in platform accessibility features considered AT?
For this question, read and understand Point 6: We should allow large text to enlarge to less than 200% in the Google doc. Then read Options 1 and 2, the draft responses.
Indicate which proposed response you prefer and if it is sufficient to address the issue raised. If edits are needed, provide the detailed edits in the survey or the Google doc.
Summary
| Choice | All responders |
|---|---|
| Results | |
| Prefer Option 1, as-is. | 2 |
| Prefer Option 1, with edits. (Provide your proposed changes in the Google doc.) | |
| Prefer Option 2, as-is. | |
| Prefer Option 2, with edits (Provide your proposed changes in the Google doc.) | |
| Something else. (Provide your alternate proposal in the Google doc.) | 5 |
Details
| Responder | (Part 3 of 4 for Issue 4) Point 6: Are built-in platform accessibility features considered AT? | Comments |
|---|---|---|
| Phil Day | Something else. (Provide your alternate proposal in the Google doc.) | Reiterate Point 4 option 1 which gives more explanation about how to meet intent if 200% scaling is not supported. I agree with Bruce and think the distinction between platform features like magnification and bolt on AT is unhelpful - we should take a systems view and ensure that the system meets the requirement, rather than specifying the architecture of the solution. |
| Chris Loiselle | Prefer Option 1, as-is. | |
| Sam Ogami | Something else. (Provide your alternate proposal in the Google doc.) | Just remove "without requiring the use of assistive technology" for the SC for WCAG2ICT. This should be updated in WCAG also. I am at a loss to why you cannot use AT to meet this requirement. Built in AT is a platform feature. |
| Loïc Martínez Normand | Something else. (Provide your alternate proposal in the Google doc.) | In my understanding of the intent of SC 1.4.4, the use of screen magnification is not allowed as a way to pass 1.4.4. With this understanding, it doesn't matter if the screen magnification is a separate software (such as ZoomText for Windows) or if its part of the operating system (such as "Magnifier" in Windows 11). If the user has to rely on an external magnification, then 1.4.4 is not met. So my proposal would be something similar to option 1 (short-and-sweet) but in positive way: built-in platform services are AT from the user's perspective. Option 3: Loïc's proposal For the purposes of the “without assistive technology” requirement in 1.4.4, built-in platform accessibility features **are considered** assistive technology. |
| Bruce Bailey | Prefer Option 1, as-is. | Option 1 is short-and-sweet and avoids getting into the question as to if a built-in magnification feature is AT or not. |
| Mike Pluke | Something else. (Provide your alternate proposal in the Google doc.) | +1 to Loïc's Option 3 |
| Fernanda Bonnin | Something else. (Provide your alternate proposal in the Google doc.) | One more thing to consider here is that beyond Magnifiers being considered an "assistive technology" or not; is whether magnifiers should only "count" as a way to meet the S.C. if they replicate a way of increasing text size, as a customization of text rendering; rather than a customization of viewport rendering, as magnifiers tend to do instead. |
5. (Part 4 of 4 for Issue 4) Does 1.4.4 Resize Text guidance in WCAG2ICT need changes?
Read the current WCAG2ICT guidance in Applying 1.4.4 Resize Text to Non-web Documents and Software with the previous questions and proposed responses in mind.
Indicate whether you think the guidance needs changes. Provide thoughts, or preferably, proposals, on what those changes might be.
Summary
| Choice | All responders |
|---|---|
| Results | |
| The guidance for 1.4.4 is sufficient, as-is. | |
| The existing guidance for 1.4.4 needs changes. (Provide your proposal in the Google doc.) | 4 |
| The existing guidance is sufficient, but could benefit from additional notes. (Provide your proposal.) | 3 |
Details
| Responder | (Part 4 of 4 for Issue 4) Does 1.4.4 Resize Text guidance in WCAG2ICT need changes? | Comments |
|---|---|---|
| Phil Day | The existing guidance is sufficient, but could benefit from additional notes. (Provide your proposal.) | Notes from Point 4, option 1 provide useful additional commentary for systems that may not natively support 200% zoom. |
| Chris Loiselle | The existing guidance for 1.4.4 needs changes. (Provide your proposal in the Google doc.) | Not entirely sure what is meant by "software players", does this include or is not limited to audio and/or video or multi-media players? If we are after those type of "players", then name them. Software players seems very broad. |
| Sam Ogami | The existing guidance for 1.4.4 needs changes. (Provide your proposal in the Google doc.) | Note 2 should be changed a state that using AT is ok to meet this SC. Also add why web is a special case where AT cannot be applied to meet the SC. (not sure why this is) |
| Loïc Martínez Normand | The existing guidance is sufficient, but could benefit from additional notes. (Provide your proposal.) | +1 to Phil's proposal |
| Bruce Bailey | The existing guidance for 1.4.4 needs changes. (Provide your proposal in the Google doc.) | I am not clear what Google doc to use for this minor editorial suggestion. Current: > 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. I recommend making this two sentences OR just delete everything [unless the content will not work with zoom] after the last comma. |
| Mike Pluke | The existing guidance is sufficient, but could benefit from additional notes. (Provide your proposal.) | +1 to Phil's proposal |
| Fernanda Bonnin | The existing guidance for 1.4.4 needs changes. (Provide your proposal in the Google doc.) | Looking at the large discussion in issue #4, it seems like the existing guidance doesn't provide an answer to all open questions, are there changes or additions we can make to the notes to answer them drawing from the discussion in issue #4 and the options in point 4 and point 5? |
More details on responses
- Phil Day: last responded on 30, April 2024 at 15:19 (UTC)
- Chris Loiselle: last responded on 1, May 2024 at 16:48 (UTC)
- Sam Ogami: last responded on 1, May 2024 at 21:01 (UTC)
- Loïc Martínez Normand: last responded on 1, May 2024 at 22:23 (UTC)
- Bruce Bailey: last responded on 1, May 2024 at 22:29 (UTC)
- Mike Pluke: last responded on 1, May 2024 at 22:59 (UTC)
- Fernanda Bonnin: last responded on 1, May 2024 at 23:42 (UTC)
Non-responders
The following persons have not answered the questionnaire:
- Gregg Vanderheiden
- Shadi Abou-Zahra
- Mary Jo Mueller
- Mitchell Evan
- Charles Adams
- Daniel Montalvo
- Shawn Thompson
- Olivia Hogan-Stark
- Laura Miller
- Anastasia Lanz
- Devanshu Chandra
- Bryan Trogdon
- Thorsten Katzmann
- Tony Holland
- Kent Boucher
Send an email to all the non-responders.
Compact view of the results / list of email addresses of the responders
WBS home / Questionnaires / WG questionnaires / Answer this questionnaire
Report issues
on GitHub project