Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
1.4.4 - Clarification needed for Success Criterion for mobile browsers #730
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:
Now, from the Intent section of:
Now, let's look at the Sufficient Techniques:
According to G142
The examples posted include
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
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.
Both of these are Silverlight specific and do not apply to mobile browsers
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:
On Safari on iOS, point # 3 can be satisfied by using
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.
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
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
But the reality is, creating this implementation would violate Level A guidelines because of the following Success Criteria:
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).
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.
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.
@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 IE6 was not considered to have "zoom support". My understanding is, "zoom" is the
Also see G142:
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?
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)
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
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:
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:
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:
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.
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
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 ;)
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:
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 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:
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:
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:
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:
From my research, it's really just Chrome for Android that doesn't have any alternative.
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
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.
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.
It doesn't scale the root element like most browsers do, but instead uses heuristics to apply to certain elements.
@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.
@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
We have levels of guidance, I'd summarise those as:
In terms of next steps, this one needs assigning, but I think the steps are:
Opening the floor for volunteers...