E-mail List Archives

You are here: Home > Community > E-mail List Archives > View Thread

Thread: Browser zooming sufficient for WCAG 1.4.4 (resize text)

Number of posts in this thread: 24 (In chronological order)

From: Alastair Campbell
Date: Thu, Jun 25 2015 3:36AM
Subject: Browser zooming sufficient for WCAG 1.4.4 (resize text)
No previous message | Next message →

There seem to be quite a few myths & misunderstanding around zoom and
responsive design, I think it's worth being clear how it works and it is
something I've written about it quite a bit.

Robert asked:
"What is unclear is whether the, now ubiquitous, browser page zoom
functionality means that units like px are acceptable"

and Terri commented:
"fonts defined in px will NOT scale with the size the screen"

I can practically hear Joe Clark whispering in my ear: "Pixel is a relative
unit." and it is more true than ever. You need to understand the different
between âdevice pixels' and âCSS pixels', for which I strongly recommend
PPK's two-part article on the subject [1]. but the short version is:

- A device (computer, mobile phone etc) will have physical âdevice pixels'
that make up the screen, but they vary a great deal in density.
- Each browser has a set size for âCSS pixels' that should be the same size
across devices to your vision, with an assumed viewing distance. In fact,
there is an equation for the size of a CSS pixel so you can work out what
the intended viewing distance is [2].

That is why high-resolution devices like the flagship phones (with more
pixels than an 55" HD TV) can show websites in a readable fashion on a 5"
display. A CSS pixel is often 3 times bigger than the device pixel.

So although text defined in PX will not vary on *one* screen (without
zoom), they will vary across devices, in an appropriate way.

Michelangelo wrote:
"In usability testing I observed users with limited vision who still
enlarge the font without zooming the page, in hopes of minimizing
horizontal scrolling, which is so disorienting."

I've seen this too, and I entirely agree that horizontal scrolling is a big
issue (and I think it should be a fail at WCAG2-AA). However, text-sizing
is not the long term solution, and we are currently in a transition period.

As desktop browsers now default to zoom, and the most popular mobile
browsers *only* have zoom, and responsive techniques allow developers to
cope with zoom effectively, I cannot see any reason for browsers to
continue providing text-sizing. (Other than historical inertia.)

Most new sites are being developed with responsive techniques (although
there are many that haven't changed layout in many years), and Google is
favouring mobile-friendly sites in the search rankings. This is the way
things are going.

The thing to push for is well-done responsive designs. There are some
issues (e.g. images getting blurry when zoomed) but with the recent support
for responsive-images even that has potential solutions.

Whitney wrote:
"It looks like they switch to a mobile template when the zoom level
gets high, so the text (and page overall) wrap well."

Yes, that is what happens when you use responsive design, as Patrick
mentioned, the effective width of the browser reduces, so it triggers the
media queries. You can think of it as the âmobile template', but it is
really the âtemplate' for a certain width.

When you zoom, *something* has to give, and media-queries allow developers
to adapt the layout to different sized browser viewports.

Robert asked:
"So, would it be fair to say that if you created a responsive design
with px units carefully with appropriate breakpoints, it
would be okay?"

Yes [3]. The approach we tend to take is to design the mobile view first,
and as the space (window size) expands adapt the layout to show more. The
breakpoints should be based on the design, rather than particular device
sizes.

1] http://www.quirksmode.org/mobile/viewports.html
2] https://alastairc.ac/2013/02/how-to-hold-your-ipad/
3] https://alastairc.ac/2013/08/browser-zoom-great-for-accessibility/

From: Jonathan Avila
Date: Thu, Jun 25 2015 7:10AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

You don't have to look too far to find responsive sites that fail browser zoom via SC 1.4.4. In my experience simply because a site is responsive with break points doesn't mean that when browser zoomed is applied text won't be truncated. For example absolute and fixed positioned content can be very problematic. Also, pages that snap when you scroll are famous for vertically truncating the text in between break points preventing the user from scrolling to it. So while things may work at a given breakpoint I have concerns with text being truncated at zoom levels that lie between breakpoints. An easy example is a container with a max-height and overflow hidden that is set appropriate at each breakpoint but when zoom is applied between breakpoints, the text is truncated.

Jonathan

--Â
Jonathan AvilaÂ
Chief Accessibility Officer
SSB BART GroupÂ
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957 Â
Follow us:Â FacebookÂ |Â TwitterÂ |Â LinkedInÂ |Â BlogÂ |Â Newsletter

From: Eades, Terri
Date: Thu, Jun 25 2015 8:10AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

How do you deal with this problem between the breakpoints?

Terri

From: Patrick H. Lauke
Date: Thu, Jun 25 2015 9:12AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

However, those sites will fail for all users with devices that have a screen in between breakpoints...so they're just examples of broken sites, full stop. No?

P
--
Patrick H. Lauke

> On 25 Jun 2015, at 15:10, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>
> You don't have to look too far to find responsive sites that fail browser zoom via SC 1.4.4. In my experience simply because a site is responsive with break points doesn't mean that when browser zoomed is applied text won't be truncated. For example absolute and fixed positioned content can be very problematic. Also, pages that snap when you scroll are famous for vertically truncating the text in between break points preventing the user from scrolling to it. So while things may work at a given breakpoint I have concerns with text being truncated at zoom levels that lie between breakpoints. An easy example is a container with a max-height and overflow hidden that is set appropriate at each breakpoint but when zoom is applied between breakpoints, the text is truncated.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> Phone 703.637.8957
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>

From: Patrick H. Lauke
Date: Thu, Jun 25 2015 9:17AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

You build a site properly - not just treating breakpoints as monolithic fixed sizes, but have a design that flexibly reflows and adapts to all possible screen sizes, and treat breakpoints as known sizes at which you more drastically reorder things (e.g. going from a two column layout to a single column layout).

P
--
Patrick H. Lauke

> On 25 Jun 2015, at 16:10, Eades, Terri < = EMAIL ADDRESS REMOVED = > wrote:
>
> How do you deal with this problem between the breakpoints?
>
> Terri
>
>

From: Jonathan Avila
Date: Thu, Jun 25 2015 11:48AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

> However, those sites will fail for all users with devices that have a screen in between breakpoints...so they're just examples of broken sites, full stop. No?

I don't think so. There is another scale factor going on that must be considered with zoom. In my tests on the desktop changing my browser window and using zoom both affect the width and trigger breakpoints, however, zoom scales the page contents while shrinking the window's width does not cause an increase in text size. So, while in theory devices with odd widths could have problems IMO is it not likely because they site would just drop down to the lower breakpoint and the font sizes would remain what they were set for that lower breakpoint. With zoom, the text sizes increase but the lower resolution breakpoint remains causing the issue.

Jonathan

--Â
Jonathan AvilaÂ
Chief Accessibility Officer
SSB BART GroupÂ
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957 Â
Follow us:Â FacebookÂ |Â TwitterÂ |Â LinkedInÂ |Â BlogÂ |Â Newsletter

From: Robert Fentress
Date: Thu, Jun 25 2015 2:45PM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

Thanks for the excellent discussion everyone. This has been very
informative.

I was aware of the device pixel/reference pixel distinction, but sometimes
I forget about its implications. I'm so used to triggering breakpoints by
changing the viewport window, that I didn't fully realize that zooming the
page while keeping the viewport the same is (almost) an inversion of the
same principle. It is definitively more complex than it seems at first,
especially with Jonathan's qualifications. I'm still trying to develop the
right intuitions about it.

On Thu, Jun 25, 2015 at 1:48 PM, Jonathan Avila < = EMAIL ADDRESS REMOVED = >
wrote:

> > However, those sites will fail for all users with devices that have a
> screen in between breakpoints...so they're just examples of broken sites,
> full stop. No?
>
> I don't think so. There is another scale factor going on that must be
> considered with zoom. In my tests on the desktop changing my browser
> window and using zoom both affect the width and trigger breakpoints,
> however, zoom scales the page contents while shrinking the window's width
> does not cause an increase in text size. So, while in theory devices with
> odd widths could have problems IMO is it not likely because they site would
> just drop down to the lower breakpoint and the font sizes would remain what
> they were set for that lower breakpoint. With zoom, the text sizes
> increase but the lower resolution breakpoint remains causing the issue.
>
> Jonathan
>
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> Phone 703.637.8957
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>

From: Patrick H. Lauke
Date: Thu, Jun 25 2015 4:03PM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

> On 25 Jun 2015, at 19:48, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>
> With zoom, the text sizes increase but the lower resolution breakpoint remains causing the issue.

Well yes, text size increases because you're effectively bumping up "how many physical pixels are mapped to a css pixel", which in turn makes your window's css width/height smaller, and so triggers smaller screen breakpoints...or am I missing something?

P

From: Patrick H. Lauke
Date: Thu, Jun 25 2015 4:15PM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

> On 25 Jun 2015, at 19:48, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>
> while in theory devices with odd widths could have problems IMO is it not likely because they site would just drop down to the lower breakpoint and the font sizes would remain what they were set for that lower breakpoint. With zoom, the text sizes increase but the lower resolution breakpoint remains causing the issue.

This seems to be confusing quite a few aspects here, sorry. Let's make it concrete, then: give us an example of a responsive site that you feel has issues like the ones you describe (and said are quite prevalent) when zooming on desktop.

P

From: Jonathan Avila
Date: Mon, Jun 29 2015 8:28AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

> Well yes, text size increases because you're effectively bumping up "how many physical pixels are mapped to a css pixel", which in turn makes your window's css width/height smaller, and so triggers smaller screen breakpoints...or am I missing something?

Yes, as you zoom in the text size becomes larger and the width gets smaller. This can produce problems between breakpoints because the author did not intend the larger text size at a given breakpoint. This is a different experience than someone with an odd width device gets. In their case the lower breakpoint is triggered and the font size remains as the author intended. This explanation was my response to your question of wouldn't this affect all users equally and thus not cause an accessibility issue.

Jonathan

--Â
Jonathan AvilaÂ
Chief Accessibility Officer
SSB BART GroupÂ
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957 Â
Follow us:Â FacebookÂ |Â TwitterÂ |Â LinkedInÂ |Â BlogÂ |Â Newsletter

From: Patrick H. Lauke
Date: Mon, Jun 29 2015 8:31AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

On 29/06/2015 15:28, Jonathan Avila wrote:
> Yes, as you zoom in the text size becomes larger and the width gets
> smaller. This can produce problems between breakpoints because the
> author did not intend the larger text size at a given breakpoint.

But you're not just changing the text size alone, you're changing the
zoom factor which changes the size of the CSS pixel. When zooming up,
you're effectively doing the same as reducing the window width (and then
the browser blows up the size of everything to match). So no, the only
thing that matters here is if the developer considered that particular
width of the screen, NOT whether they expected a particular size at this
particular breakpoint.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Patrick H. Lauke
Date: Mon, Jun 29 2015 8:40AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

On 29/06/2015 15:31, Patrick H. Lauke wrote:
> On 29/06/2015 15:28, Jonathan Avila wrote:
>> Yes, as you zoom in the text size becomes larger and the width gets
>> smaller. This can produce problems between breakpoints because the
>> author did not intend the larger text size at a given breakpoint.
>
> But you're not just changing the text size alone, you're changing the
> zoom factor which changes the size of the CSS pixel. When zooming up,
> you're effectively doing the same as reducing the window width (and then
> the browser blows up the size of everything to match). So no, the only
> thing that matters here is if the developer considered that particular
> width of the screen, NOT whether they expected a particular size at this
> particular breakpoint.

To give this a concrete example, using Chrome in Windows, visiting
www.paciellogroup.com (which uses Bootstrap's default breakpoints). If
you visit with a browser width of 780px at 200%, you see the same as if
you visited at 390px width at 100%. There is no mismatch between what
the browser thinks is the breakpoint, and what the font size is. See
http://i.imgur.com/shGIrJU.png

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Jonathan Avila
Date: Mon, Jun 29 2015 8:41AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

> So no, the only thing that matters here is if the developer considered that particular width of the screen, NOT whether they expected a particular size at this particular breakpoint.

When browser zoom is used there will be all sorts of odd widths. Authors cannot create breakpoints for all of these. What the author should do is allow for variance between breakpoints by designing the content to be fluid and not prevent overflow or wrapping. If a responsive site has truncated text when zoomed up to 200% then it would appear to be a WCAG failure to me. I don't buy the argument that the issue happens to other users and therefore isn't an accessibility issue because it doesn't happen to other users.

Jonathan

--Â
Jonathan AvilaÂ
Chief Accessibility Officer
SSB BART GroupÂ
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957 Â
Follow us:Â FacebookÂ |Â TwitterÂ |Â LinkedInÂ |Â BlogÂ |Â Newsletter

From: Patrick H. Lauke
Date: Mon, Jun 29 2015 8:41AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

From: Jonathan Avila
Date: Mon, Jun 29 2015 8:45AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

> So, to circle back to what I originally said: if the responsive site breaks when zooming in on desktop, it breaks in exactly the same way as if the user came across without zooming, but with a smaller window size. No?

No, that is not the case. If you change the width but don't zoom the font size doesn't change until you reach a breakpoint. When you use browser zoom the font size changes with each increment or decrement.

Jonathan

--Â
Jonathan AvilaÂ
Chief Accessibility Officer
SSB BART GroupÂ
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957 Â
Follow us:Â FacebookÂ |Â TwitterÂ |Â LinkedInÂ |Â BlogÂ |Â Newsletter

From: Patrick H. Lauke
Date: Mon, Jun 29 2015 8:45AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

On 29/06/2015 15:41, Jonathan Avila wrote:
> When browser zoom is used there will be all sorts of odd widths.
> Authors cannot create breakpoints for all of these.

You seem to misunderstand the idea of breakpoints, or rather how
designers/developers use them? It's not a fixed point, but rather a
measure at which a particular design changes.

If authors ONLY design for EXACT known breakpoint sizes, then their
sites will break on devices which don't have those exact screen
measurements either...nothing to do with font sizes, or zooming.

> What the author
> should do is allow for variance between breakpoints by designing the
> content to be fluid and not prevent overflow or wrapping. If a
> responsive site has truncated text when zoomed up to 200% then it
> would appear to be a WCAG failure to me. I don't buy the argument
> that the issue happens to other users and therefore isn't an
> accessibility issue because it doesn't happen to other users.

You may not buy it, but it's the reality...if a designer only made a
design work only if a screen is exactly 320px wide and 768px wide and
higher, and nothing in between, then the design will break for any
device whose pixel size is below 768px and not exactly 320px.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Patrick H. Lauke
Date: Mon, Jun 29 2015 8:49AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

On 29/06/2015 15:45, Jonathan Avila wrote:

> No, that is not the case. If you change the width but don't zoom the
> font size doesn't change until you reach a breakpoint.

No, font sizes don't change across breakpoints at all, UNLESS the author
has set explicit font sizes for different breakpoints.

> When you use
> browser zoom the font size changes with each increment or decrement.

No, it's not the font size that changes, it's the measure of what a CSS
pixel is, so EVERYTHING increases/decreases (including absolute-sized
things in px).

It seems we're talking across purposes here? Am I missing something? Can
you point out - taking the exact example of www.paciellogroup.com - what
you mean? Not trying to be difficult, but your statements really don't
make sense to me based on the reality of what I'm seeing...

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Patrick H. Lauke
Date: Mon, Jun 29 2015 9:00AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

On 29/06/2015 15:40, Patrick H. Lauke wrote:
> To give this a concrete example, using Chrome in Windows, visiting
> www.paciellogroup.com (which uses Bootstrap's default breakpoints). If
> you visit with a browser width of 780px at 200%, you see the same as if
> you visited at 390px width at 100%. There is no mismatch between what
> the browser thinks is the breakpoint, and what the font size is. See
> http://i.imgur.com/shGIrJU.png

For completeness, let me explain a bit more what the image above
actually shows:

- three browser windows side by side (all Google Chrome, all showing
www.paciellogroup.com): at 780px width with 100% default font size, at
780px with 200% zoom, and at 390px width with 100% default font size again
- standard bootstrap has a breakpoint at around 768px, switching from
small-screen view to desktop view
- both the 780px at 200% zoom and the 390px at 100% zoom views are
identical (barring a few tiny differences attributable to number
rounding issues) in what they show - both have triggered the
small-screen view, and in both cases the text has the same proportion
compared to the overall viewport and the other elements within the page
- yes, of course visually the 780px/200% zoom view is "bigger", but
EVERYTHING is bigger, and in exactly the same proportion as the
390px/100% view. there is no mismatch between what the font size is and
what the rest of the page's layout is.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Jonathan Avila
Date: Mon, Jun 29 2015 9:20AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

> If authors ONLY design for EXACT known breakpoint sizes, then their sites will break on devices which don't have those exact screen measurements either...nothing to do with font sizes, or zooming.

Let's take an example, say I have breakpoints at 800px and 480px. I have a media query for 800px and greater and one for less than 800px but greater than or equal to 480px and one for less than 480.

Say I change my window width to 555px -- I will get the media query for < 800 but >H0 and the text size will be whatever the author defined at that point no changes in device pixel ratio. The page will appear as intended for that media query even though I have an odd width.

On the other hand if I zoom using browser zoom my width changes and the device pixel ratio changes. So say I zoom in to approximately 555px. My device pixel ratio may have also changed -- say to 1.5. If the responsive site was not created using fluid techniques and instead was create with techniques that hide overflow and have max heights, etc. text could be truncated for the zoom user.

In this case of Paciello Group's site the site was created with fluid designs and thus appear correctly with the device pixel ratio is increased but other sites do not work like it does. In my experience responsive sites tend to not get horizontal scrollbars with browser zoom like most non-responsive sites do If content is truncated you have to change your zoom level until you reach a breakpoint. This could require the user to zoom to a higher amount that isn't as effective for the user.

Jonathan

--Â
Jonathan AvilaÂ
Chief Accessibility Officer
SSB BART GroupÂ
= EMAIL ADDRESS REMOVED =
Phone 703.637.8957 Â
Follow us:Â FacebookÂ |Â TwitterÂ |Â LinkedInÂ |Â BlogÂ |Â Newsletter

From: Patrick H. Lauke
Date: Mon, Jun 29 2015 10:13AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

On 29/06/2015 16:20, Jonathan Avila wrote:
> Let's take an example, say I have breakpoints at 800px and 480px. I
> have a media query for 800px and greater and one for less than 800px
> but greater than or equal to 480px and one for less than 480.
>
> Say I change my window width to 555px -- I will get the media query
> for < 800 but >H0 and the text size will be whatever the author
> defined at that point no changes in device pixel ratio. The page will
> appear as intended for that media query even though I have an odd
> width.

It will appear as intended IF the design was made properly (fluidly).
Otherwise, you'll see the same issues of truncated content etc.

> On the other hand if I zoom using browser zoom my width changes and
> the device pixel ratio changes. So say I zoom in to approximately
> 555px. My device pixel ratio may have also changed -- say to 1.5.
> If the responsive site was not created using fluid techniques and
> instead was create with techniques that hide overflow and have max
> heights, etc. text could be truncated for the zoom user.

But if the site was not created using fluid techniques, then it will be
broken in exactly the same way in your first example of making the
browser window smaller to about 555px.

> In this case of Paciello Group's site the site was created with fluid
> designs and thus appear correctly with the device pixel ratio is
> increased but other sites do not work like it does.

Examples?

> In my experience
> responsive sites tend to not get horizontal scrollbars with browser
> zoom like most non-responsive sites do If content is truncated you
> have to change your zoom level until you reach a breakpoint.

And again, changing the zoom level to reach a breakpoint is exactly the
same as changing your width without changing zoom level, so to me -
without seeing examples you have in mind - it sounds like those sites
would be broken in exactly the same way to users that do not require
zoom, but just happen to have different screen sizes/browser window widths.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Patrick H. Lauke
Date: Mon, Jun 29 2015 10:31AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

On 29/06/2015 17:13, Patrick H. Lauke wrote:
> And again, changing the zoom level to reach a breakpoint is exactly the
> same as changing your width without changing zoom level, so to me -
> without seeing examples you have in mind - it sounds like those sites
> would be broken in exactly the same way to users that do not require
> zoom, but just happen to have different screen sizes/browser window widths.

To bring this to a point: what is displayed in a browser window of size
w/h at 100% zoom level is effectively identical to what is displayed in
a window of size w*2/h*2 at 200% zoom level (since zoom level in desktop
browsers redefines ALL sizes - both absolute and relative). So any
problems (cut-off or overlapping content etc) that would happen for a
zoom user at a specific size would also happen in exactly the same way
to a non-zoom user with a browser window/device screen size that's set
to the equivalent non-zoomed dimensions.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Patrick H. Lauke
Date: Mon, Jun 29 2015 10:33AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

And to clarify, as I feel bad: not having a go at you here, Jonathan.
Trying to understand if I missed something, but also trying to clarify
exactly what happens in current desktop browsers when zoom is used (as
there seems to still be some misinformation floating around what
actually happens here).

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: _mallory
Date: Mon, Jun 29 2015 10:17PM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | Next message →

On Mon, Jun 29, 2015 at 05:31:03PM +0100, Patrick H. Lauke wrote:
> On 29/06/2015 17:13, Patrick H. Lauke wrote:
> To bring this to a point: what is displayed in a browser window of
> size w/h at 100% zoom level is effectively identical to what is
> displayed in a window of size w*2/h*2 at 200% zoom level (since zoom
> level in desktop browsers redefines ALL sizes - both absolute and
> relative). So any problems (cut-off or overlapping content etc) that
> would happen for a zoom user at a specific size would also happen in
> exactly the same way to a non-zoom user with a browser window/device
> screen size that's set to the equivalent non-zoomed dimensions.

I haven't seen an example of broken-only-on-zoom, but an example of one
would maybe do something like (because I've been forced to do this on
non-responsive sites due to someone not planning for content):

A row of boxes, in order to maintain the same heights, has room for
a text area where some CEO wanted "4 lines of text". While the breakpoints
could be styled to decide how many boxes in a row will fit horizontally,
even if the developer used em's to set the height of the text area,
when browser zooming eventually text starts wrapping and now you've got
5 or 6 lines of text, whereas if you had only shrunk your browser width,
you probably still have 4 lines of text and nothing cut off (we're
assuming another beyond the '4 lines' is overflowed or something).

Though I also lean towards "that's so broken, no way can one claim it
only affects zoom" (and in my experience zoom wraps text 'earlier'
than magnification, which just shows a larger version of what the
browser is already displaying).

This sort of thing is so brittle, there's easily a bazillion non-
zoom places where the last line can be lost, but I'm sure there
are people out there setting heights for content areas and
other such madness (see my mention above).
So this is some specific instance I could think of where maybe
someone with merely a less-wide screen would be able to see a full
set of text and someone who zooms ends up missing the last line or two.

cheers,
_mallory

From: Daniel Tang (dtang)
Date: Tue, Jul 07 2015 11:01AM
Subject: Re: Browser zooming sufficient for WCAG 1.4.4 (resize text)
← Previous message | No next message

Yes.
Continue.
Daniel

Daniel Tang
ENGINEER.HARDWARE ENGINEERING
= EMAIL ADDRESS REMOVED =
Phone: +1 408 526 7814
Cisco Systems Limited
125 West Tasman Dr.
SAN JOSE
CALIFORNIA
95134
US
Cisco.com

Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html