1.4.4 - Clarification needed for Success Criterion for mobile browsers

[clshortfuse]

I've been in the process of porting some applications from Native to Web and have hit a roadblock a with Google Chrome. I've been trying, without any success, for over a year to get Google to make changes for text-based accessibility issues. There is no text-scaling support, nor is there zoom (as defined by WCAG) support for Chrome on Android. The only thing available is "pinch-to-zoom" which is basically screen magnification. I've seen too many comments and user-created articles and such stating that this is acceptable, but in actual practice, it's not, and from the reading the guidelines it's not either

I'll begin with the text of 1.4.4:

Success Criterion 1.4.4 Resize text (Level AA): Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.

Now, from the Intent section of:

https://www.w3.org/WAI/WCAG21/Understanding/resize-text.html

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. Users may benefit from scaling all content on the Web page, but text is most critical.

Now, let's look at the Sufficient Techniques:

1. G142: Using a technology that has commonly-available user agents that support zoom

According to G142

The objective of this technique is to ensure content can be scaled uniformly by using a Web technology supported by user agents that change text size via a Zoom tool.

The examples posted include

Internet Explorer 7 and Opera 9 provide a zoom function that scales HTML/CSS page content uniformly.

To my understanding, zoom is using Ctrl + and Ctrl -, on the keyboard. This means the layout essentially changes and the content reflows. This is similar to change the CSS zoom property.

The problem is, despite it's name, pinch-to-zoom does not "zoom" as explained by WCAG. Pinch-to-zoom magnifies instead. That means nothing changes in layout or size. No reflow happens. And according to 1.4.4, screen magnification CANNOT satisfy Success Criterion, even if it's provided by the user-agent. If the browser does not have actual page zoom (not magnify) function, then we cannot use this technique. Therefore, both Safari for iOS and Chrome for Android cannot use G142.

2. L22: Supporting Browser Zoom in Silverlight

3. SL23: Using A Style Switcher to Increase Font Size of Silverlight Text Elements

Both of these are Silverlight specific and do not apply to mobile browsers

4. Ensuring that text containers resize when the text resizes AND using measurements that are relative to other measurements in the content by using one or more of the following techniques:

• C28: Specifying the size of text containers using em units
• Techniques for relative measurements
• • C12: Using percent for font sizes
• • C13: Using named font sizes
• • C14: Using em units for font sizes
• Techniques for text container resizing
• • SCR34: Calculating size and position in a way that scales with text size
• • G146: Using liquid layout

These are all dependent on quote from Intent stating: "User agents that satisfy UAAG 1.0 Checkpoint 4.1 allow users to configure text scale."

According to UAAG 1.0 Checkpoint 4.1 the user agent must supply the following:

1. Allow global configuration of the scale of visually rendered text content. Preserve distinctions in the size of rendered text as the user increases or decreases the scale.
2. As part of satisfying provision one of this checkpoint, provide a configuration option to override rendered text sizes specified by the author or user agent defaults.
3. As part of satisfying provision one of this checkpoint, offer a range of text sizes to the user that includes at least:
   -the range offered by the conventional utility available in the operating environment that allows users to choose the text size (e.g., the font size), or
   -if no such utility is available, the range of text sizes supported by the conventional APIs of the operating environment for drawing text.

On Safari on iOS, point # 3 can be satisfied by using html { font: -apple-system-body; } which would allow Apple's Dynamic Type support to take into effect. This would take the operating system's font-size and apply it to the root element, thereby allowing use of em or rem.

This is not available on Google Chrome for Android, and the closest thing they have is a heuristics based, font-boosting solution which only scales some elements. This issue has been part of Google's bug tracker for over 560 days: https://bugs.chromium.org/p/chromium/issues/detail?id=779409

There is nothing on Google Chrome on Android to allow to use the system font-size and nothing in the browser that will let use set the default or minimum font-size. By comparison, Firefox on Android has an option in Settings called "Use system font size". With this enabled, the Firefox user agent satisfies # 3.

5. G178: Providing controls on the Web page that allow users to incrementally change the size of all text on the page up to 200 percent

At this point, there is only one option left for Chrome on Android, and it's this one.

This is what I am currently forced to provide for users using Chrome for Android, which is a custom built dialog which provides the user the ability to set the font-size of <html> to something other than 16px (the forced default in Chrome for Android). No other modern browser, be it mobile or desktop needs this.

6. G179: Ensuring that there is no loss of content or functionality when the text resizes and text containers do not change their width

Specifics to this aren't necessary for this discussion. Basically, make sure text scaling works properly.

---

So this is where I am with Chrome for Android. I've read a lot about how just letting users pinch-to-zoom is enough. But consider the following. Suppose Chrome for Android did not have this feature. Suppose that I, as a developer, instead of supporting text scaling with em or created a dialog box to select the font-size, decided to create my own Javascript-based custom pinch-to-zoom implementation. I would do the exact same thing as Chrome for Android does not. After all, that's essentially what we'd be saying by accepting "pinch-to-zoom" magnification to satisfy 1.4.4.

But the reality is, creating this implementation would violate Level A guidelines because of the following Success Criteria:

2.5.1 Pointer Gestures
All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.

It's a contradiction to say that it's a multipoint that wouldn't be allowed in Level A would suffice for a Level AA (1.4.4) guideline. Also, considering the history of why 1.4.4 was probably implemented in the first place. It was likely created to work against the cumbersome nature of using screen magnifiers. By just allowing "pinch-to-zoom" to satisfy 1.4.4, where exactly is the line drawn between what is a screen magnifier, and what is not?

---

I've been trying for over year, without success, to petition Google to fix their text scaling support. But unless Google realizes this is a problem, it doesn't seem like they give it much attention. If I'm completely wrong about this, I'd like to know how, and what I should be doing for users that need text scaling on Android for Chrome. I am faced with the issue of needing to help users scale their text, and not rely on two finger gestures, either because the web page doesn't allow it (ie: using Google Maps), or because operations must be single-touch (accessibility).

[patrickhlauke]

Short answer: if the site itself does not prevent zooming/scaling (i.e. it's not trying to prevent pinch-to-zoom in Chrome), then it passes 1.4.4.

The fact that Chrome as a UA does not have a non-gesture-based way of operating zoom is an issue with Chrome, not with your web content.

[patrickhlauke]

additionally, 1.4.4 does not require reflow. that's what the new 1.4.10 Reflow is for. but the nuance there is different ... it's not about reflowing in response to zooming, but more about responsively adapting to viewport width - so the fact that mobile browsers generally don't do reflow on zoom is not your concern.

[clshortfuse]

@patrickhlauke Thanks for the quick response. The problem is, what is "zoom" and what is "magnify"?

It's unclear. From my understanding "pinch-to-zoom" isn't zoom. It's magnify. And everything I've read says that screen magnification can't satisfy 1.4.4. I know my initial comment is rather long, but I did address that in the G142 section.

That's the problem with the language used:

The author cannot rely on the user agent to satisfy this Success Criterion for HTML content if users do not have access to a user agent with zoom support. For example, if they work in an environment that requires them to use IE 6.

The IE6 was not considered to have "zoom support". My understanding is, "zoom" is the Ctrl+ zoom, and not screen magnifications or font-boosting (IE6-like).

Also see G142:

Internet Explorer 7 and Opera 9 provide a zoom function that scales HTML/CSS page content uniformly.

IE6 had what's essentially we call font-boosting.

Opera 8.5 had screen magnification which, unless I'm mistaken, is the same as pinch-to-zoom (zoom and pan).

You can see that here: http://www.armory.com/~filbo/opera/zoom/

By saying screen magnification is "zoom support" means we're changing the language of the original guideline. It wasn't considered a Success Criteria before, but it is now?

[patrickhlauke]

The problem is, what is "zoom" and what is "magnify"?

it doesn't matter. the normative SC talks about resizing text. Can you (somehow) make text twice as big as normal? Without needing to use additional assistive technology (e.g. using an actual screen magnifier)

By saying screen magnification is "zoom support" means we're changing the language of the original guideline.

the only language that is normative is the SC text itself. everything else (understanding, techniques, etc) is non-normative/informative only (and keep in mind that a lot/most of that content was written in 2008

[clshortfuse]

@patrickhlauke

Can you (somehow) make text twice as big as normal?

That's an extremely relaxed interpretation with nothing in the text or guidelines to support that. All the points in the additional text are clearly discussing resizing text as an alternative to screen magnification. On the original text:

Except for captions and images of text

is rather clear that we're not talking about screen magnification. We're talking about text-scaling. Screen magnification does all, and not just text.

The language in the Intent is also clear we're talking about allowing 200% text scaling and then allow a scrolling/panning magnification system. In other words, allow text scaling up to 200%, and then use magnification:

The working group feels that 200% is a reasonable accommodation that can support a wide range of designs and layouts, and complements older screen magnifiers that provide a minimum magnification of 200%. Above 200%, zoom (which resizes text, images, and layout regions and creates a larger canvas that may require both horizontal and vertical scrolling) may be more effective than text resizing. Assistive technology dedicated to zoom support would usually be used in such a situation and may provide better accessibility than attempts by the author to support the user directly.

That seems pretty clear to me that you should not rely on screen magnification for anything under 200%, and instead implement text-scaling (browser supported or a custom implementation provided by the author).

On your point of:

the only language that is normative is the SC text itself. everything else (understanding, techniques, etc) is non-normative/informative only (and keep in mind that a lot/most of that content was written in 2008

Back in 2008, user-agent-provided screen magnifiers like in Opera 8.5 or text-boosting solutions like in IE6 weren't sufficient despite it fact it would answer your question of "Can you (somehow) make text twice as big as normal?" . You're essentially saying, "That was this, and this is now." Then at what point in time, and where is it written that it's now okay to accept user-agent-provided screen magnifiers (unless you're debating that's now that pinch-to-zoom isn't screen magnification)? Opera 8.5 is the clear example. And if it's okay to just allow screen magnification, then you're saying that the guidelines have been relaxed. That also means Opera 8.5's screen magnification conforms with 1.4.4. (I'm sorry if that sounds brash. Though it may seem that way it's not my intention.)

The reality is that screen-magnification and no other exception (ie: using Android for Chrome), provides a very inaccessible experience for users. You lose the ability to scroll though pages normally, and reading a wide paragraph involves heavy use of panning. Unless I'm missing something, that should have been the original purpose of creating 1.4.4, or else what was the original point? (Again, not trying to be rude, it's just rhetorical).

---

In the end, if this is the new understanding going forward (and as you said it was written 2008), the guidelines need to be updated to state that. If screen magnification is okay now, and not just after 200%, then again, the guidelines needs to be updated and the text changed.

[patrickhlauke]

you are confusing, among other things, "magnification" (which is what an actual assistive technology like ZoomText, or an OS-level screen magnifier, would provide) with "full-page zoom" (which is what desktop browsers nowadays do, where everything inside the browser's view - text, images, etc- get bigger).

back in 2008 resizing in browsers was, for the most part, still "text resizing". while some browsers offered full-page zoom, it was not the norm.

you mention IE6 ... IE's text sizing was actually perfectly acceptable as a way to pass this SC, provided that text actually resized. one of the problems at the time (and one that this SC wanted to address) was that text sizing set in px would not scale in IE6. THAT was one of the problems this SC tackled.

but as you don't seem to believe me, maybe some other members of the working group can assure you that i'm not talking rubbish ;)

[alastc]

Hi @clshortfuse,

Similar to your initial post in this thread, I outlined the zoom/reflow issues on desktop and mobile as well.

@patrickhlauke is correct about the guidelines, 1.4.4 (from 2008) requires that text can be made bigger, with no restriction on whether it creates bi-directional scrolling. 1.4.10 (from 2018) builds on that, and requires that content can be displayed at 320px wide without bi-directional scrolling.

The (fairly) obvious way to achieve that on the web is with responsive design. However, the only style of zoom/text-size generally available on mobile devices does not support 'reflow'.

The understanding doc for reflow acknowledges that:

Mobile user agents can offer reflow when users zoom into content, as evidenced by the Dolphin browser for Android. The lack of magnified reflow support in browsers on mobile operating systems can therefore be regarded as a user agent support issue.

Not ideal, but we are running up against the physics of small screens and the limitations of the main layout methods on mobile devices. As you are discovering, there is only so much an author can do.

Being able to zoom in without triggering bi-directional scrolling is a key requirement for people with low vision, we're trying to move towards that as fast as possible without making it in-feasible to do.

[alastc]

Having said all that, 1.4.4 could do with an overhaul, referencing IE6 isn't very helpful these days.

[clshortfuse]

@alastc Thanks for jumping in and trying to help me sort this out.

After thinking it some more, I'm realizing I'm disputing the difference between must do and should do. There is something else I read that help me arrive what where my confusion lied:

The techniques are “informative”, that is, you do not have to use them. The basis for determining conformance to WCAG 2 is the success criteria from the WCAG 2 standard, not the techniques.

https://www.w3.org/WAI/standards-guidelines/wcag/#whatis2

It was my understanding that if the techniques aren't met, then you're failing. I now understand that isn't the case.

@patrickhlauke is indeed right that the multi-point pinch scaling would satisfy 1.4.4.

The problem I have, and I hope the group has as well, is that it's really the bare minimum. So really what I'm arguing for is a change in the Technique language to reflect that relying on pinch-to-zoom isn't ideal. Best practice would support text-scaling. I did find bits and pieces of this type of language elsewhere in W3C:

Relying on full viewport zooming (e.g. not blocking the browser's pinch zoom feature) requires the user to pan horizontally as well as vertically. While this technique meets the success criteria it is less usable than supporting text resizing features that reflow content to the user's chosen viewport size. It is best practice to use techniques that support text resizing without requiring horizontal panning.

https://www.w3.org/TR/mobile-accessibility-mapping/#zoom-magnification

The best practice is what I'm advocating for, but I now understand how we were possibly bumping heads. It doesn't have to be, but it is best practice. But that language isn't given the appropriate emphasis I believe it deserves.

I will dispute something said before which is:

so the fact that mobile browsers generally don't do reflow on zoom is not your concern.

It is my concern because it is my user's concern, and I'm trying to satisfy their needs. My main focus (and concern) right now is getting the Chrome team to implement some sort of text scaling support. I would, ideally like to have something to show Google that the pinch-to-zoom isn't enough. I have that quote now, that applying best practice is impossible current on Chrome for Android. But the more better. I've even tried another angle of getting this resolved by pushing system-based font-size as a standard on the CSS end. See: w3c/csswg-drafts#3708 My next possible venue is filing the issue with the Google Maps team instead of just Chrome and seeing if that can get the ball rolling. I've been dealing with this for over a year now.

---

Summarizing, I think the Techniques should stress pinch-to-zoom, while satisfying the criteria, is not ideal and not best-practice.

---

PS: @alastc I read your article and since 2013, Apple does let you scale text in the browser with the OS settings. You have to apply:

html {
  font: -apple-system-body;
  font-family: initial; /** if you want to reset **/
}

From my research, it's really just Chrome for Android that doesn't have any alternative.

[patrickhlauke]

Having said all that, 1.4.4 could do with an overhaul, referencing IE6 isn't very helpful these days.

It could do with a big clarification about full-page zoom (both in the case of desktop where it reflows, or most mobile UAs where it results in bidirection scrolling) both being kosher to satisfy the normative wording of the SC (with a cross-reference to 1.4.10), definitely

[patrickhlauke]

It is my concern because it is my user's concern, and I'm trying to satisfy their needs

Which is great. But my point is: WCAG intends to set absolute baselines of what web content authors must do. In the context of WCAG, it's not your concern what the actual browser does/doesn't do. In the wider context of what you're apparently trying to achieve: you can't use WCAG to now go and convince Google to change the way their browser does/doesn't provide text scaling.

[jha11y]

Just a comment, pinch to zoom may be magnification, but it is separate from the OS level magnification which can be found in the OS settings app -> Accessibility -> magnification. Also Android Chrome has a text scaling option under settings -> accessibility. This was just tested on a pixel 2 with the latest chrome for android. Finally, most (but not all webpages) respond when the Android OS text size OS settings app -> Accessibility -> font size
Chrome text scale settings

Chrome webpage with OS level magnification active

[patrickhlauke]

Also Android Chrome has a text scaling option under settings -> accessibility

Interesting. it used to be that it had no effect on fonts defined in px, but it seems they've changed the behaviour now to override font sizing regardless.

[clshortfuse]

Finally, most (but not all webpages) respond when the Android OS text size OS settings app - Accessibility -> font size Chrome text scale settings

I'd disagree with that. I believe it only sizes H1-H6, P, and TEXTAREA elements. That means buttons, lists, tables, or input text boxes don't get sized, even if you use REM. I just tried it with 200% magnification on the top 15 Alexa ranked websites and I'd say 90% of the content doesn't get resized. Not even Google or Wikipedia.

That's the issue I've said has been unfixed for over 560 days.

https://bugs.chromium.org/p/chromium/issues/detail?id=779409

It doesn't scale the root element like most browsers do, but instead uses heuristics to apply to certain elements.

[jha11y]

@clshortfuse for "Finally, most (but not all webpages) respond when the Android OS text size OS settings app -> Accessibility -> font size" I'm referring to the Android OS level font size setting not the Chrome app text scaling. I have not extensively tested the limitations for the Chrome App text scaling.

[clshortfuse]

@jha11y Changing the system font size applies the the same scaling heuristics as changing it in the app settings.

On a related note, Android WebViews applies the system font scaling to the root element. I filed an issue with the Chromium team seeing if it could be replicated for PWAs. https://bugs.chromium.org/p/chromium/issues/detail?id=942045

[jha11y]

I thought it was just scaling all text-based content, but text-based links don't scale. Interesting heuristics choices on Google's part.

[alastc]

Hi @clshortfuse,

Summarizing, I think the Techniques should stress pinch-to-zoom, while satisfying the criteria, is not ideal and not best-practice.

We have levels of guidance, I'd summarise those as:

• The criteria are the baseline, things that must be done, tend to be consise and legalistic.
• Understanding docs explain them and can encourage best practices, but cannot requirement them.
• Techniques are known ways to meet the criteria, these can recommend/use best practices but some are needed show how to meet the minimum. Each is generally very focused, they don't generally make wider points (which is what the understanding doc is for).
• WAI produces tutorials which generally recommend best practices.

In terms of next steps, this one needs assigning, but I think the steps are:

• Review the text-size techniques & failures.
• Assess whether there is sufficient support for text-scaling on mobile devices for that to impact techniques.
• Propose an upate to the understanding doc, and whether any techniques need updating.

Opening the floor for volunteers...