1.4.4 Resize Text - Misunderstandings Update - Interpretation

[joe-watkins]

Hi!

Throughout WCAG 1.4.4 Techniques there is reference to an upcoming clarification around a common misunderstanding of this SC. Is it text-only resize or browser zoom? Nobody knows.. is it both?

The callout states: https://www.w3.org/TR/WCAG20-TECHS/F69

Note: The Working Group has discovered many misunderstandings about how to test this failure. We are planning to revise this failure in a future update. Until then, if the content passes the success criterion using any of the listed sufficient techniques, then it does not meet this failure.

There is disagreement around how this SC is interpreted. Some folks believe a browser zoom (where everything just scales up ctrl +/-) is a sufficient technique, while others interpret the SC so that enlarging the text only to 200% must not cause the text, image or controls to be clipped, truncated or obscured. I lean towards the latter myself.

With the responsive web, it is pretty easy to create an experience that would pass this SC with it only being browser zoom with modern browsers that support media queries and that have great browser zoom. Authoring experiences that work with text-only resize is much more difficult and relies on fluid non-fixed sizing.

Both Firefox and Safari allow for text-only as an option for native browser zoom now which makes things interesting.

When will we see an update to some of these failures bringing more clarity around this SC? 2.1?

Thanks for all your hard work :)

[alastc]

Hi Joe,

By the letter of the SC text for 1.4.4 a site will pass if zoom is 'accessibility supported', i.e. people who need it can use a browser which has zoom. That is almost always the case, so since around 2009 it hasn't been a particularly effective criteria unless people take it further.

In 2.1 we now have ‘reflow’, which works in combination with resize-text. I did an overview of those.

We can’t change the WCAG 2.0 criteria, we are building on them and reflow & text-spacing are intended to fill in the gaps.

I need to check where F69 is referenced from, but it might be we need to remove that from 1.4.4 given the changes in user-agents.

-Alastair

[joe-watkins]

Thanks @alastc and awesome post -- how'd I miss that!?

For even greater clarity can we take a look at these questions:

1. To test/pass 1.4.4 A author/tester can visit a site in a modern browser, hit cntrl + browser zoom to 200%. If text is not truncated or obscured it passes 1.4.4? (reflow and text-spacing kick in for other concerns here - very cool)

2. If the answer to #1 is yes - because modern Firefox and Safari both have options for text-only in their browser zoom settings the tester should disable this when testing for 1.4.4?

F69 is referenced from Common Failures for WCAG 1.4.4

@alastc I appreciate your thoughtful clear answers but I'd like to distill this down for average bears to understand out in the wild. The web/tech has outrun this SC a bit.

[alastc]

With Reflow (1.4.10) in place the text-resize now fills in niche-cases where text doesn't scale with the zoom.

So the combined test for reflow, text-resize and text-spacing can be:

• Set the browser window to 1280px wide.
• Zoom in to 400%.
• Check content & functionality is available, and no horizontal scrolling (in LTR languages).
• Check text is at least 200% bigger.
• Turn on text-sizing (e.g. with a bookmarklet).
• Un-zoom through each media query, looking for overlaps / missing content.

There are a few niches in there, e.g. vertical text, text which varies depending on screen height, but that should catch most scenarios.

The 200% text-size check is because sites can use media queries or VW/VH units to prevent text getting bigger with zoom. If text increases somewhat, check that the browser-calculated size in pixels is at least 50% of the default. (E.g. default of 10px should be at least 5px at 400%.)

Is that distilled enough?

[Ryladog]

Actually, IMO, 1.4.4 was a pretty effective SC when WCAG 2.0 was published as zoom had not taken hold. Additionally, as mobile web apps began constricting pages/screen size the usefulness of this SC had a comeback.....

katie

Katie Haritos-Shea Principal ICT Accessibility Architect

[alastc]

Hi @Ryladog,

I didn't mean to say it was ineffective to start with, just that since around the time of IE8 (~2008), Chrome (2009) you could say zoom was widely available.

We still do need it for scenarios where reflow isn't available, such as mobile devices and tables.

[Ryladog]

I understand what you are saying, but, when you consider that a government agency that I work for today uses IE-11 (and no other than browser) officially, "widely available" is often a view that many developers have, that is not necessarily true in the real world for many users.....

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/883#issuecomment-384810789, or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqys0Ev4urJaa-9_GT0OmWLeyYyzvCks5tsk0AgaJpZM4TjvU8 .

[patrickhlauke]

I understand what you are saying, but, when you consider that a government agency that I work for today uses IE-11

IE11 supports zoom just fine, unless i'm missing the point here?

[alastc]

I hear you, we were big proponents of liquid layouts at the time :-)

But times have moved on, with media-query support (even in IE) things changed.

[Ryladog]

Alastair, yes, true....:-)

My point Patrick, is, the usefulness of 1.4.4, for many users, lasted for quite a long time after WCAG 2.0 became a standard.....and then had a surprising re-birth in mobile....

.... but, 1.4.10 Reflow is certainly an improvement ....

katie

Katie Haritos-Shea Principal ICT Accessibility Architect

WCAG/Section 508/ADA/AODA/QA/FinServ/FinTech/Privacy, IAAP CPACC+WAS = CPWA http://www.accessibilityassociation.org/cpwacertificants

Cell: 703-371-5545 <703-371-5545> | ryladog@gmail.com ryladog@gmail.com | Oakton, VA | LinkedIn Profile http://www.linkedin.com/in/katieharitosshea/

People may forget exactly what it was that you said or did, but people will never forget how you made them feel.......

Our scars remind us of where we have been........they do not have to dictate where we are going.

On Thu, Apr 26, 2018 at 6:56 PM, Alastair Campbell <notifications@github.com

wrote:

I hear you, we were big proponents of liquid layouts http://zomigi.com/blog/the-liquid-web-site-motherload/ at the time :-)

But times have moved on, with media-query support (even in IE) things changed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/883#issuecomment-384813724, or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqylNJWq63LgBO2Tx6xBZVOuG5JR28ks5tslCwgaJpZM4TjvU8 .

[mraccess77]

@Ryladog wrote "the usefulness of 1.4.4, for many users, lasted for quite a long time after WCAG 2.0 became a standard.....and then had a surprising re-birth in mobile...."

I know I always say this -- but almost every day I encounter pages that still fail SC 1.4.4 with browser zoom on desktop due to many different issues. So this SC is still very valuable today and will continue to be valuable when combined with SC 1.4.10.

[WayneEDick]

Actually, from a user's perspective, 1.4.4 was almost useless.

If you qualify as having a low vision disability due to visual acuity, your visual acuity is less than 1/3 of normal. One would logically think that 333% would be the minimum effective enlargement, and that would be right. Lack of reflow moved it from too little to just plane useless.

WCAG WG was 180% wrong. I wish for once the WG would admit that serious failure. For years people like me were told we just didn't know how to use screen magnifiers correctly, or that we should use braille, or that we should just use screen readers. All that was I think to deny the fact that WCAG WG got it terribly wrong and delayed accessibility for low vision by 8 years. It was a terrible mistake and it hurt people. People with low vision were made to feel there was something wrong with them. That they were just incompetent because they could use this defective assistance.

I wish the working group could just admit their serious error.

[patrickhlauke]

@mraccess77

I know I always say this -- but almost every day I encounter pages that still fail SC 1.4.4 with browser zoom on desktop due to many different issues.

are these situations where it would fail 1.4.4 but pass 1.4.10? or are these pages that fail 1.4.10 anyway?

[Ryladog]

Wayne,

I know it was not enough by far. We tried to make it more, and we could not reach consensus at more.

But Wayne, it was something. Not enough for most, you are right.

The WG is not a single entity. You are part of this working group. Do you agree with every decision?

One reason WCAG 2.1 was undertaken was to address better access for what was not possible, imagined or could be agreed upon 10 to 12 years ago. It wasnt perfect. Neither is 2.1.

I hear your anger. I understand.

On Thu, Apr 26, 2018, 9:42 PM Patrick H. Lauke notifications@github.com wrote:

@mraccess77 https://github.com/mraccess77

I know I always say this -- but almost every day I encounter pages that still fail SC 1.4.4 with browser zoom on desktop due to many different issues.

are these situations where it would fail 1.4.4 but pass 1.4.10? or are these pages that fail 1.4.10 anyway?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/883#issuecomment-384838289, or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqyp2mLXD5BordX8q3jM-9KYUnQCIKks5tsneBgaJpZM4TjvU8 .

[mraccess77]

@patrickhlauke I believe that 1.4.10 alone would catch many of them but not all situations. Having both SC is still needed in my opinion.

@WayneEDick I agree that SC 1.4.4 did not address the primary need for reflow -- but I've failed SC 1.4.4 many times times in audits when there where issues that could be caught by it. So it did and does have value although is limited. Given that SC 1.4.8 addresses reflow although only at 200% I would say that the group at the time had made a conscious decision around 1.4.4. I was not invited to be a part of the group at that time -- so I can't speak to any discussions because I was not present unfortunately.

[alastc]

This is a rather large tangent now, but I will say that although I wasn't part of the group then, I can see why 200% was taken as the figure.

Anyone building websites in the 2000s could tell you that making an attractive site that scales up to 150% was difficult. The browser monoply of a buggy IE6 was difficult in 2004-8, and 200% was pushing it. Until we had media queries (supported) the tools were not there for more.

Anyway, things have changed, we can do more regular updates, lets head towards (or in front of) the puck now.

---

Heading back to the issue raised, we could save people quite a lot of time by having this sort of combined test process.

Where would be a good place to put this?

[DavidMacDonald]

@WayneEDick @mraccess77

In 2008, without breakpoints, making text zoom to 300% or 400% or even 200% without horizontal scroll was simply not something that would have gotten consensus. Large organizations at the time would never have allowed the entire web to be reduced to the kind of basic layout this would have required. WCAG would never have been accepted, would never have become required by law and would have been relegated to history as a great advocacy standard that academic organizations and governments could pick away at as they saw fit.

[mraccess77]

@DavidMacDonald I understand -- that is why I said it was a conscious decision to place 1.4.8 at AAA and 1.4.4 at AA. So we are in agreement. My point being is that it was not by omission but by commission based on factors that the group had to weight at the time.

[WayneEDick]

I don't want to relitigate the past, but sometimes it is important to recognize the magnitude of an error so that we don't make it again.

Enlargement without reflow was never accessible. For those like me who used closed circuit TV to read print on paper, it was the only way to read. That was how you had to read research journals. However, reflow became common with the Apple 2E. The technology was 30 years old in 2008.

Media queries made reflow easy when they became available, but a professional programmer could design pages that enlarged to 200% and word wrapped with HTML 4, CSS 2 and ECMAScript. It wasn't trivial, but it wasn't that hard. The technology was there.

The WG did not understand the importance of reflow to the user group. Enlarged text with reflow is to people with visual acuity loss as refreshable braille is to blindness. It is a static reading medium that supports time base reading with a screen reader.

It was exactly like removing refreshable braille from the non-visual reading toolkit. Would WCAG have passed without support for refreshable braille? The deep problem was that reflow is as important as refreshable braille, and the WG missed that critical fact.

The past is not important, but in the future I hope the WG remembers this truth. Whenever we think of an exception to allowing reflow just remember we are removing a feature that is as important as refreshable braille.

Respectfully, Wayne

[Ryladog]

Good point Wayne. I think your idea of adding some text along these lines to the Understanding 2.1 doc is a good idea. Maybe in the Benefits section...

On Fri, Apr 27, 2018, 1:46 PM WayneEDick notifications@github.com wrote:

I don't want to relitigate the past, but sometimes it is important to recognize the magnitude of an error so that we don't make it again.

Enlargement without reflow was never accessible. For those like me who used closed circuit TV to read print on paper, it was the only way to read. That was how you had to read research journals. However, reflow became common with the Apple 2E. The technology was 30 years old in 2008.

Media queries made reflow easy when they became available, but a professional programmer could design pages that enlarged to 200% and word wrapped with HTML 4, CSS 2 and ECMAScript. It wasn't trivial, but it wasn't that hard. The technology was there.

The WG did not understand the importance of reflow to the user group. Enlarged text with reflow is to people with visual acuity loss as refreshable braille is to blindness. It is a static reading medium that supports time base reading with a screen reader.

It was exactly like removing refreshable braille from the non-visual reading toolkit. Would WCAG have passed without support for refreshable braille? The deep problem was that reflow is as important as refreshable braille, and the WG missed that critical fact.

The past is not important, but in the future I hope the WG remembers this truth. Whenever we think of an exception to allowing reflow just remember we are removing a feature that is as important as refreshable braille.

Respectfully, Wayne

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/wcag21/issues/883#issuecomment-385044021, or mute the thread https://github.com/notifications/unsubscribe-auth/AFfqykM7dS0zEosjF3CUmZLRJbBNBzPdks5ts1lsgaJpZM4TjvU8 .

[joe-watkins]

@alastc and gang Tnx! Helpful for sure. Question though.. please review the attached .gifs - Which zoom does one use for testing 1.4.4 in a browser that support text-only zoom -- text-only enabled or disabled?

1. Firefox browser zoom with text-only enabled. Browser zoomed to 200%, only text is enlarged, Main navigation falls apart.

2. Firefox browser zoom with text-only disabled. Media queries jump into action and the small screen version of the site is visible at 200% zoom.

In both of these cases I'm using browser zoom. Both deliver very different results. In the first example I'd consider the main navigation a failure of 1.4.4 and the second I would not. (Though the cognitive load of a completely different layout and removal of content is another topic) This is where confusion comes in for designers/devs.

Does the WG believe, because it works in example 2 above with normal zoom, that CNN doesn't have a text resize failure on its hands?

And if Reflow kicks in here to save the day for 1.4.4 regarding the first example with text-only enabled -- how and why?

tnx much! ;)

[mraccess77]

WCAG is a functional standard. The outcome is that text resizes. All that has to exist is a mechanism. There is a mechanism. Not all mechanisms have to support. Regarding responsive design -- as long as the responsive view has all of the same functionality and content even if it's under a hamburger menu or otherwise available then it's a pass. CNN may have other issues related to resize such as those related fixed headers, etc. -- I can't say if the whole site passes or not without testing.

[alastc]

Which zoom does one use for testing 1.4.4 in a browser that supports text-only zoom

That's isn't how WCAG works, the criteria asks whether it is possible for the user to do X (in this case X is increase the size of text, with any method).

So if a reasonable amount of browsers (that users can get) support general zoom then authors (i.e. designers and devs) can rely that feature.

[patrickhlauke]

1.4.4 says "text can be resized", without specifying how. whether you're getting different results depending on how a user chooses to resize, that's generally unimportant. what counts is: does at least one of these ways of resizing end up with the user being able to resize text "up to 200 percent without loss of content or functionality"? and of course, the method should be readily available to users in most mainstream user agents (which arguably means, on desktop, we're likely looking at full-page zoom)

[joe-watkins]

Thanks @mraccess77, @alastc, @patrickhlauke Super clear and wow RWD saves the day :) This is a super low bar to reach for devs.. no laws saying an author couldn't reach beyond WCAG to support text-only resize though huh?

And I enjoyed the sidebar chat from others :) tnx again all!

[alastc]

Hi @WayneEDick,

I also don't want to re-litigate the past, but if we don't accept the constraints of the time, we can't move on.

It is always a balance between what is feasible, and what enables the best access.

Enlargement without reflow was never accessible... reflow became common with the Apple 2E. The technology was 30 years old in 2008.

On the web it started well (basic but accessible in this regard), but when organizations started putting up more complex layouts that were optimal for the majority, the reflow aspect suffered. It doesn't matter if there was some technology that supported it 40 years ago, 15 years ago the web didn't support it for the types of layouts organisations wanted.

Media queries made reflow easy when they became available, but a professional programmer could design pages that enlarged to 200% and word wrapped with HTML 4, CSS 2 and ECMAScript. It wasn't trivial, but it wasn't that hard. The technology was there.

I'm sorry but that's not the case. I was there, doing those kind of layouts.

By 2009 the cost of doing 'liquid layouts' (pre-media query support) was getting towards 30% of the overall cost of the project and increasing. Obviously it varied quite a lot, but the requirements for businesses, charities and government organizations for more complex layouts/designs were making that very difficult, past the point of feasibility.

The WG did not understand the importance of reflow to the user group.

I can't speak to the understanding at the time, but at the time I did argue for relative units and better resizing. It has to be balanced with feasibility, whether by mainstream methods or personalization (more difficult).

Oddly, I think I'll quote myself from 2007 (from the link above), it is so long ago it feels like quoting some else!

there are just so many ways of laying sites out at the moment, unless CSS3’s layout module makes it through soon I can’t see user agents being able to account for them all. I’m glad relative font-sizing got back into WCAG 2, but I don’t think it’s enough.

(New emphasis.) Back in 2007 I can't remember exactly what the CSS3 module was supposed to include, but I'd guess media queries.

For the content guidelines we are putting the requirements on authors. To raise the game, the requirements need to work with browsers as well.

[alastc]

@joe-watkins just to tie a bow on this:

If CNN used font-based units so that text-sizing worked without breaking, then they would size the layout and media queries with font-based units (EM, REM). Just like the Guardian do.

In that case, it works just like zoom. QED people might as well use zoom, there is no advantage (or dis-advantage) to using font based units.

[patrickhlauke]

there is no advantage (or dis-advantage) to using font based units

I believe the only advantage is that if a user has set a specific custom default font size in the UA, these layouts would auto-adapt based on that, whereas with zoom the user would have to do the zooming manually (but most - perhaps even all, at this point? - user agents remember the zoom setting from the last visit, on a per-site basis, so even that advantage becomes more ephemeral)

[alastc]

most - perhaps even all, at this point? - user agents remember the zoom setting from the last visit

Yes, if not in the default browser config, then at least with extensions. I use that myself for different defaults on different computers.

[mraccess77]

Chrome supports zoom level by sub domain and for all sites.

[StommePoes]

If a website sets its fonts in px units, we've been failing them because Firefox shows everything falling apart, as in the first CNN example. However it's only Firefox that we're testing-- trying to set a default text size in IE, or Chrome/blink means the px settings prevent the text from resizing. This means users either need to constantly resize per domain (sites using % or em-based font units will start at your desired size, while someone setting font-size to 13px gives you 13px and then you need to play with zoom). I abandoned text-only font-enlarge when the last browser I could use that overrode author's px-settings was Firefox (never had a mac), and there were actually zero websites I used that did not fall apart with it like CNN starting several years ago. I had to switch to browser zoom to use the web.

But it still seems like a tester's preference, and our admonition to authors we're auditing seems a bit more like a suggestion for better code rather than fixing a complete failure (when the sites can pass with browser zoom-- with all the sticky headers and footers being added everywhere, responsive design is starting to fail again).

[alastc]

Hi @StommePoes,

Well, as per my first comment, pixel sizing hasn’t technically been a fail of 1.4.4 since zoom has been widespread. Good practice perhaps, but the tools on both ends have changed.

We’ve massively improved coverage with adding reflow and text-spacing, but there is a gap in terms of ‘height’. I.e. there isn’t an SC to fail if there isn’t enough height to usefully read / use it so long as the text is bigger and there’s no horizontal scrolling.

There is a good nudge in that direction in the recommended way to test it, and from experience in training once people zoom into 400% on a laptop and can only see 1/3 screen, they want to change it.

If that isn’t enough, having an SC about usable screen space in both directions is a good candidate for 2.3 / 3.0.

[alastc]

So I think (barring tangents) this issue/question has been answered, can we close this @joe-watkins?

Thanks,

-Alastair

[joe-watkins]

Thanks @alastc I'm good!