Responding to SC 1.4.4 Resize Text concerns about feasibility and user needs

[mitchellevan]

Our WCAG2ICT draft currently says:

Guidance When Applying Success Criterion 1.4.4 to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.4 (also provided below).

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.

The Intent section refers to the ability to allow users to enlarge the text on screen at least up to 200% without needing to use assistive technologies. This means that the application provides some means for enlarging the text 200% (zoom or otherwise) without loss of content or functionality or that the application works with the platform features that meet this requirement.

See also the discussion on Closed Functionality.

I agree with commenters in #4 that as currently written this is not always feasible and sometimes runs counter to user needs. Before I work directly on #4 I'd like to share my thoughts and get some initial reactions from my Task Force colleagues.

(The public may respond to this Discussion too, but that is not its main purpose. I intend to narrow down the Task Force's possible responses, then close this Discussion fairly quickly and move us back to #4. This is good because Issues carry more weight than Discussions.)

Following is a summary of points from #4 and how I propose we respond.

Point 1: All native apps should be exempted from WCAG criteria (such as 1.4.4) because the W stands for "web."

Proposed response: This was a fair question in 2020 (seven years after the first version of WCAG2ICT). However, the AG Working Group has since made it clear that we won't make such blanket exemptions merely because of the "W" in WCAG. On the contrary, the Working Group's 2022 approval of the WCAG2ICT Task Force Work Statement reaffirms our intention to "describe how WCAG 2.x and its principles, guidelines, and success criteria could apply to non-Web Information and Communications Technologies (ICT)."

Point 2: Native apps on small screen devices should be exempted from 1.4.4 because the requirement is unclear or not feasible.

Proposed response (drafted September 2023, deleted March 2023): Comments in #4 raise valid, important concerns about clarity and feasibility of applying 1.4.4 to non-web ICT, especially as ICT has evolved in the past 10 years. Now that the WCAG2ICT Task Force is active again, we're optimistic that we can respond to the community's points in an improved Working Group Note and achieve consensus on the update.

Proposed response (drafted March 2023): It is feasible to apply 1.4.4 as written to most content in mobile apps, and we do not plan to introduce a blanket exemption to 1.4.4 for mobile apps.

Point 3: SC 1.4.4 should require scaling in native apps to the extent supported by user settings of the platform.

Proposed response:

Where the user agent or platform does not provide a text enlargement function, authors must provide it. The normative requirement of 1.4.4 has no exemption for inadequate platform support, and (Understanding SC 1.4.4) clarifies this. It says, "The scaling of content is primarily a user agent responsibility," but also, "If the author is using a technology whose user agents do not provide zoom support, the author is responsible to provide this type of functionality directly or to provide content that works with the type of functionality provided by the user agent."

But does it necessarily follow that the 200% requirement is absolute for all content on all platforms, with no alternative ways to meet user needs? The following points address these nuances.

Point 4: We should allow the largest text to enlarge to less than 200%.

I support something like this because I've heard from members of the Low Vision Task Force that it can be good for user needs. Discussion points:

• To support user needs, how broad or narrow should the allowance be?
• Can we write a note in WCAG2ICT to say this meets the spirit of the criterion? OR
• Must we clarify that it is a good idea, even though it cannot pass normative WCAG? I've sometimes done this, while pointing out that policies outside of WCAG may allow meeting user needs in other ways, e.g. "equivalent facilitation" under US Section 508.

Point 5: We should allow most or all text to enlarge to less than 200%, when the text is initially not particularly small

I'd like to explore this idea, even if we only end up pointing evaluators outside of WCAG, e.g. "equivalent facilitation."

The scope of #4 was "mobile native apps." I would reframe this question in the context of apps which only appear on a known range of physical screen sizes or viewing angles. This will encompass watches, TVs, and closed systems.

Possibility: 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.'

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?

I'd like to ask the Task Force how to respond, thinking about:

• User needs
• Relationship to 1.4.10 Reflow
• Tablet apps and smartphone apps especially

Point 7 (new, not yet mentioned in issue 4): How can 1.4.4 apply to content with no clearly defined default font size?

Examples of text that starts out "far away":

• Text in 3D content that allows users to move through a virtual z-axis
• Text on a 2D storyboard app that has its own built-in zoom function across a wide range

Initial thoughts:

• I can't think of anything but a minimum visual angle for this.
• XAUR magnification user needs are not very specific.
• We'll also need something for 1.4.10 Reflow, at least to say it's likely to earn the essential exception.

[loicmn]

I think that the intent of SC 1.4.4 is already providing explanations on how to handle text enlargement when it is difficult due to user interface controls size (or screen size). It is explained that truncation + mechanism to access to full content is an acceptable solution:

Some user interface components that function as a label and require activation by the user to access content are not wide enough to accommodate the label's content. For example, in Web mail applications the subject column may not be wide enough to accommodate every possible subject header, but activating the subject header takes the user to the full message with the full subject header. In Web-based spreadsheets, cell content that is too long to be displayed in a column can be truncated, and the full content of the cell is available to the user when the cell receives focus. The content of a user interface component may also become too wide in user interfaces where the user can resize the column width. In this type of user interface component, line wrapping is not required; truncation is acceptable if the component's full content is available on focus or after user activation and an indication that this information can be accessed, is provided to the user in some way besides the fact that it is truncated. (Understanding resize text in WCAG 2.2)

So maybe what we need is a note in WCAG2ICT that explains "acceptable" solutions for 1.4.4 that could be used in the context of mobile applications.

[bruce-usab]

The TF keeps reiterating not to use WCAG for assessing hardware accessibility, and 1.4.4 is a good example as to why WCAG does not work for kiosks. I am not sure that an app on mobile is all that different a dilemma. For as reference:

• 508 closed hardware characters on display screen
• ADA ATMs and fare vending characters
• ACAA airport kiosks 14 CFR 382.57(c)(7)(ii)

[mraccess77]

SC 1.4.4 can be met many different ways including enlargement with two-dimensional scrolling, reflow, in app controls, following platform settings, etc. Despite the requirement to resize text - resizing the whole UI is an acceptable way of meeting the requirement.

The criteria also would seem to allow for options such as the iOS press and hold to enlarge the text used on navigation items or disclosure or drilling into links for truncated text.

While I agree there are limitations in UI text enlargement for up to 200% - that is just one way of meeting it - most apps can get to somewhere like 175% in many non-scrolling/wrapping areas and for vertically scrolling areas where reflow can be used there is no reason 200% can't be met - e.g. text messages, email, word processing, etc. Truncation and disclosure options help here as well as long as that info can be reached.

Hardware could implement two-dimensional scrolling with 200% magnification if the UI did not have room otherwise for enlargement - but there are many places where the UI can be enlarged sufficiently. This just means that closed software has to implement this feature.

I do agree that some hardware interfaces naturally have large text and thus they could be seen as being penalized for that now that they need to enlarge further compared to UIs where the text is small by default. So some visual angle measurement of magnification may be needed or physical text size examples such as in the ADA guidelines for ATM/Farecard could be considered based on this.

As for the user need - the need for larger text is absolutely critical. Limiting the requirements to something like 20/40 vision isn't sufficient and would not be enough for people with low vision.

[pday1]

Some (older) closed systems do not support scaling due to constraints in the architecture (e.g. the UI is not created using markup, but instead is composed from static elements). In this case, I support the point made by @bruce-usab above, that where the system does not allow scaling, other methods such as minimum text size are a helpful alternative.

[samogami]

Including a physical minimum text size in SC is crossing over into defining hardware requirements. Text size and readability requirements already exist in S508, EN 301 549. If additional hardware or physical measurement requirements are going to be added it should not be in this SC or anywhere in WCAG2ICT.

1.4.4 is not possible for all ICT given situations (small screen devices, limited computing power, non support of scaling) and should not applicable.

Non applicability does not mean that the manufacture is exempt from making there product accessible it is just not address in WCAG2ICT.

[bruce-usab]

Some (older) closed systems do not support scaling due to constraints in the architecture (e.g. the UI is not created using markup, but instead is composed from static elements).

Understood. I think it is would be better for WCAG2ICT to note that such examples do not pass, as compared to WCAG2ICT saying that an SC is not applicable.

where the system does not allow scaling, other methods such as minimum text size are a helpful alternative.

Agreed, and I think it reasonable to expect that regulation and litigation will give due deference to the nuance of WCAG2ICT.

In the past several years I have noticed kiosks screens having larger and larger fonts by default, with the on-screen messages becoming clearer and simpler. It would have been hard to have a normative requirement for all those improvement to usability. Maybe industry started in that directly sooner because they had too, but now it is just good business. A legal requirement for an enlargement feature on a system already using large bold fonts would be counterproductive IMHO.

[mraccess77]

On a personal note while I have seen self checkout systems with large text I have also experience buttons on point of sale devices where there is tiny print but a huge amount of padding on the buttons. That is the text is unreadable for me yet there is plenty of room for larger text within the button - they just choose to not make the text bigger for transaction details but have a sufficient size button on the screen.

[maryjom]

I'm going to try to address Mitch's point-by-point responses in different comments others can reference/discuss individually.

Point 1: All native apps should be exempted from WCAG criteria (such as 1.4.4) because the W stands for "web."
Proposed response: This was a fair question in 2020 (seven years after the first version of WCAG2ICT). However, the AG Working Group has since made it clear that we won't make such blanket exemptions merely because of the "W" in WCAG. On the contrary, the Working Group's 2022 approval of the WCAG2ICT Task Force Work Statement reaffirms our intention to "describe how WCAG 2.x and its principles, guidelines, and success criteria could apply to non-Web Information and Communications Technologies (ICT)."

My alternate proposed response: The application of WCAG to non-web ICT has been done, in practice, since 2017 when the EN 301 549 and Revised 508 Standards adopted it. Those standards used WCAG2ICT to aid in the interpretation of WCAG to non-web documents and software. While there may be instances where the fit isn’t perfect, WCAG2ICT tries to provide guidance, in the form of notes, to further describe how one might apply each success criterion in a non-web context.

[loicmn]

I like @maryjom proposed response, with a minor edit. The first version of EN 301 549 was published in 2014!. So the first sentence should be:

The application of WCAG to non-web ICT has been done, in practice, since 2014 when the EN 301 549 and Revised 508 Standards adopted it.

[maryjom]

Point 2: Native apps on small screen devices should be exempted from 1.4.4 because the requirement is unclear or not feasible.
Proposed response: Comments in #4 raise valid, important concerns about clarity and feasibility of applying 1.4.4 to non-web ICT, especially as ICT has evolved in the past 10 years. Now that the WCAG2ICT Task Force is active again, we're optimistic that we can respond to the community's points in an improved Working Group Note and achieve consensus on the update.

My edits to the proposed response
Comments in Issue #4 raise valid, important concerns about the clarity and feasibility of applying 1.4.4 to non-web ICT, especially as ICT has evolved in the past 10 years. The WCAG2ICT Task Force is working to respond to the community's points in an improved Working Group Note. We are also active in related WCAG issues on this criterion, as some of the clarifications are also needed in the Web context.

[loicmn]

I've been thinking about the issues related to 1.4.4 outside of the web.

For non-web documents I think the application of 1.4.4 is straightforward, as these documents need a user agent that can provide text enlargement. And, in addition, the technique G142 "Using a technology that has commonly-available user agents that support zoom" implies that if the user agent can do zoom, then the author of the non-web document does not need to worry about 1.4.4.

For mobile applications I think we can apply the same reasoning. If we generalise technique G142 so we can rely on the mobile operating system to do zoom, then mobile applications conform to 1.4.4. They don't need to implement any text-resize functionality. And the good news is that both Android and iOS implement system-wide Zoom capabilities. So, as of today, we could easily say that mobile applications conform to 1.4.4.

For desktop applications we could apply the same concept: if the operating system has a zoom functionality, then 1.4.4 is automatically met. And to my knowledge this is true in macOS, Windows and several Linux distributions.

Finally, we've got systems with closed functionality (or systems which run on limited hardware). In these cases, either the system cannot meet 1.4.4 due to hardware implementation, or they do something else. I think it is not for WCAG2ICT to explain how they could implement 1.4.4, but there are alternatives. For instance, requirement 5.1.4 of EN 301 549 requires systems "closed to text enlargement" to provide a mode of operation with a minimum font size (based on visual angle):

Where any functionality of ICT is closed to the text enlargement features of platform or assistive technology, the ICT
shall provide a mode of operation where the text and images of text necessary for all functionality is displayed in such a
way that a non-accented capital "H" subtends an angle of at least 0,7 degrees at a viewing distance specified by the
supplier

[maryjom]

I tend to agree with your thinking Loïc, but there's still a bit of minutia.

• Platform zoom (or text size increase) does not go as high as 200% - There was (is there still?) mobile platforms that have text enlargement and/or zoom that do not go up to 200%. Not sure if that is still true, but if it is, should the software author still be on the hook for meeting this criteria? My thinking is no. We could say if it gets "close" that's good enough - similar to the issue with the density-independent pixel "close equivalent" of a CSS pixel or the viewport size that may not go as big as the viewport defined in 1.4.10 Reflow. IMO, if there's software platforms that implement such features, they should be required to support at least to 200% increase in text size - not require every application on that platform to implement those features.
• Potential to fail if software interferes with platform font size settings If a text size increase is provided by the platform, then software should allow the UI to change with the larger fonts and not lose functionality. I imagine there could be cases where an app could be incorrectly implemented and there could be issues introduced. So the SC applies, as written, with notes to this effect (already written into WCAG2ICT).
• Some aspects of the UI under the platform control that don't respect text size changes An example where there is nothing a software author can do to fix the issue (e.g. the bottom menu on a mobile phone, hover text when you hover over icons, and maybe others.) The platform software might fail, but requiring every application to fix platform insufficiencies is not sustainable - maybe not even doable. WCAG doesn't, but should, have exceptions similar to other SCs for "user agent control" that could be for "user agent or platform control" where the software can pass. Perhaps the EN 301 549 could build in an exception such as that. We may want to add a note for that.

I totally agree with the closed functionality thoughts. Our current text in the SC Problematic for closed functionality says:

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;

Should something else be said? Maybe so, because some closed functionality software instead supports a minimum text size.

[GreggVan]

1. I agree that we should be talking about SCREEN SIZE and not "mobile". many "mobile" (iOS and Android) devices (e.g. tablets) now have screens larger than some laptops.

2. for some kiosks the default font size is larger than 200% of what web text is -- that the SC was designed for. Thus some "angle of view" is a better thing to think about for these closed systems. And screen size and viewing distance will quickly give you the angle of view for any content

3. I think most small screens -- have a zoom but not one that doesn't require horizontal scrolling. and FONT size features only work on some of the fonts. This all has to be re-thought out for small screen devices. NOT mobile. But 'small screen" is the key here. this is true of WCAG and WCAG2ICT.

4. if someone has very low vision - then choosing a small screen to read content is a real problem. I think that we should
   a) require all apps work in landscape mode where it uses the same "width" for the content -- thus enlarging it 200% automatically and require nothing more than that.
   b) for closed products such as kiosks etc. - where the size of the screen is known - the content should be such that it displays at the same physical size as 18 point or larger sans serif printed text (or specify the actual height of the letter H)

solutions ?
hmmm
a) applies as written for non-web content and software (with x substituted for y)
NOTE: supporting a landscape mode that preserved the content width of the portrait mode would result in a 200% magnification and this automatically meet this SC

For closed products - where the screen size is known, content that, in its native size, the height of letter h is greater than 0.25 inches (6.35 millimeters) would meet the spirit of this SC.

[This is equiv to 18 pt.
if you wanted to be equiv to 14 pt - the minimum size for large print on paper - it would be 0.2 inches (5.08 millimeters) .

[mraccess77]

I don't understand why folks keep saying SC 1.4.4 is not possible on a small screen device - it can be met with out any reflow/formatting changes and can be done with 2 dimensional scrolling. The 3.5 inch screen iPhones had 2d scrolling enlargement - even MS Dos could be scrolled 2 dimensionally with software. However, practical it will be for the user is a different matter.

I agree that other low power devices and such systems may have problems meeting the requirement - but I don't think screen size is a factor given that the SC does not require any reflow or re-formatting.

[mraccess77]

In addition, regarding the nav bar icons at the bottom of mobile screens and text - size - iOS has a feature when you press a pointer such as your finger over them they show the text in enlargement on the screen.