E-mail List Archives

Search E-mail List Archives for

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

From: Justin Leasure
Date: Tue, Oct 27 2020 8:01AM
Subject: Safari Pinch Zoom for 1.4.4
No previous message | Next message →

Hello,

I sent a similar question out about a week ago, but I had a follow up. Does
"pinch zoom" within Safari Mobile meet the requirements of 1.4.4 (resize
text)? The requirement states that zooming must not cause "loss of content
or functionality." Pinch zooming causes full viewport zooming and can cause
excessive horizontal/vertical scrolling, which I think we would all agree
is not ideal. However, if you had a situation where the browser zoom (using
the "Aa" zoom feature within Safari) feature caused a loss of
functionality, would you make the argument that a website still meets 1.4.4
if pinch zoom is enabled? I know that 1.4.11 speaks to the fact that reflow
of content (which should only require one dimensional scrolling) is not
often achievable on mobile devices. So, one could take this to mean that
1.4.4 is still achieved even with two dimensional scrolling. Thanks in
advance for your input.

Thanks,
Justin

From: Patrick H. Lauke
Date: Tue, Oct 27 2020 8:15AM
Subject: Re: Safari Pinch Zoom for 1.4.4
← Previous message | Next message →

On 27/10/2020 14:01, Justin Leasure wrote:
> Hello,
>
> I sent a similar question out about a week ago, but I had a follow up. Does
> "pinch zoom" within Safari Mobile meet the requirements of 1.4.4 (resize
> text)? The requirement states that zooming must not cause "loss of content
> or functionality." Pinch zooming causes full viewport zooming and can cause
> excessive horizontal/vertical scrolling, which I think we would all agree
> is not ideal. However, if you had a situation where the browser zoom (using
> the "Aa" zoom feature within Safari) feature caused a loss of
> functionality, would you make the argument that a website still meets 1.4.4
> if pinch zoom is enabled? I know that 1.4.11 speaks to the fact that reflow
> of content (which should only require one dimensional scrolling) is not
> often achievable on mobile devices. So, one could take this to mean that
> 1.4.4 is still achieved even with two dimensional scrolling. Thanks in
> advance for your input.

1.4.4 and 1.4.11 need to be evaluated separately.

1.4.4 does not disallow bi-directional scrolling from occurring. All it
requires is that users be able somehow (not specified how) resize to
200% without things breaking (controls or content overlapping, being cut
off and unusuable/unreadable, etc). So yes, pinch-zoom is an acceptable
mechanism to pass 1.4.4 if nothing gets cut off/overlapped. Same way
that zooming on desktop, even without reflowing (e.g. if the page has
explicitly-sized containers or elements, and is not doing anything
responsive or elastic), is also a valid way of passing 1.4.4 if nothing
gets overlapped/cut off.

P
--
Patrick H. Lauke

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

From: glen walker
Date: Tue, Oct 27 2020 9:42AM
Subject: Re: Safari Pinch Zoom for 1.4.4
← Previous message | Next message →

I agree with Patrick with regards to testing 1.4.4 separately from 1.4.11
but I don't use pinch/zoom to test 1.4.4. To me, that's not really
resizing the text since it magnifies the entire viewport. Nothing will get
cut off or overlap if the viewport changes so it's kind of useless to prove
1.4.4 passes. I use it all the time, personally, but not in my testing.

I have a bookmarklet on iOS that actually does increase the text size but I
don't really use that for testing either unless I find the website has
trouble with 1.4.4 on the desktop. Then I might use the bookmarklet out of
curiosity to see if it has a problem on iOS too.

It's not perfect and only changes elements that have a fontSize property so
things like images don't change (kind of like the zoom text size only
feature in browsers).

Here's the exact code that you can copy/paste to a bookmarklet. I use '+'
and '-' as the names of my bookmarklets.

javascript:var%20p=document.getElementsByTagName('*');for(i=0;i%3Cp.length;i++)%7Bif(p%5Bi%5D.style.fontSize)%7Bvar%20s=parseInt(p%5Bi%5D.style.fontSize.replace(%22px%22,%22%22));%7Delse%7Bvar%20s=12;%7Ds+=2;p%5Bi%5D.style.fontSize=s+%22px%22%7D

javascript:var%20p=document.getElementsByTagName('*');for(i=0;i%3Cp.length;i++)%7Bif(p%5Bi%5D.style.fontSize)%7Bvar%20s=parseInt(p%5Bi%5D.style.fontSize.replace(%22px%22,%22%22));%7Delse%7Bvar%20s=12;%7Ds-=2;p%5Bi%5D.style.fontSize=s+%22px%22%7D

The only difference between the two is "s+=2" vs "s-=2".

Here's the '+' bookmarklet again but urldecoded and pretty printed (yes,
there are superfluous '{'):

javascript:
var p=document.getElementsByTagName('*');
for(i=0;i<p.length;i++)
{
if(p[i].style.fontSize)
{
var s=parseInt(p[i].style.fontSize.replace("px",""));
}
else
{
var s=12;
}
s+=2;
p[i].style.fontSize=s+"px"
}

Pretty basic. Get all the elements on the page. If it has a fontsize, use
it. If it doesn't, default to 12. Increase or decrease the font size by
2. Set the font size back on the element.

For *native* iOS app testing, I use the "Text Size" feature in settings.
Some might consider the "Text Size" feature an assistive technology and
thus not be applicable to 1.4.4 since it says "without assistive
technology" but I'll leave that up to you to decide. I think it's great if
an app honors the Text Size setting but if it doesn't, it's questionable
whether that technically fails 1.4.4. But if you want to use it, you have
to enable the "Larger Accessibility Sizes" (which seems to hint that it's
assistive technology) and then move the slider so that it's four ticks from
the right end. That gives you a fontsize that is just below 200% from the
original, but it's close enough to play with 1.4.4.

If you want to confirm the sizes of Text Size, see the "typography" section
(
https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/typography)
of Apple's Human Interface Guidelines page from Apple. The "Dynamic Type
Sizes" section (
https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/typography#dynamic-type-sizes)
of that doc shows 7 font sizes (xsmall to xxxlarge) that correspond to the
7 tickmarks on the "larger text" accessibility option.

If you enable "Larger Accessibility Sizes" option in a11y settings, that
adds an additional 5 font sizes (AX1 to AX5) (
https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/typography#larger-accessibility-type-sizes)
or 5 tickmarks to the slider.

If you look at the "Large (Default)" table under "Dynamic Type Sizes", it
says "body" text is 17pts. If we want 200% zoom, that would be 34pt. If
you look in the second table, under AX2, "body" size is 33 pt. Not quite
34pt but close enough. AX2 is 4 tickmarks from the right end of the
AX1-AX5 line, corresponding to 4 tickmarks from the right end of the text
slider, which is what I use for 200% zoom.

Probably way more than you wanted to know and definitely way more than I
intended to type.


On Tue, Oct 27, 2020 at 8:15 AM Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

> On 27/10/2020 14:01, Justin Leasure wrote:
> > Hello,
> >
> > I sent a similar question out about a week ago, but I had a follow up.
> Does
> > "pinch zoom" within Safari Mobile meet the requirements of 1.4.4 (resize
> > text)? The requirement states that zooming must not cause "loss of
> content
> > or functionality." Pinch zooming causes full viewport zooming and can
> cause
> > excessive horizontal/vertical scrolling, which I think we would all agree
> > is not ideal. However, if you had a situation where the browser zoom
> (using
> > the "Aa" zoom feature within Safari) feature caused a loss of
> > functionality, would you make the argument that a website still meets
> 1.4.4
> > if pinch zoom is enabled? I know that 1.4.11 speaks to the fact that
> reflow
> > of content (which should only require one dimensional scrolling) is not
> > often achievable on mobile devices. So, one could take this to mean that
> > 1.4.4 is still achieved even with two dimensional scrolling. Thanks in
> > advance for your input.
>
> 1.4.4 and 1.4.11 need to be evaluated separately.
>
> 1.4.4 does not disallow bi-directional scrolling from occurring. All it
> requires is that users be able somehow (not specified how) resize to
> 200% without things breaking (controls or content overlapping, being cut
> off and unusuable/unreadable, etc). So yes, pinch-zoom is an acceptable
> mechanism to pass 1.4.4 if nothing gets cut off/overlapped. Same way
> that zooming on desktop, even without reflowing (e.g. if the page has
> explicitly-sized containers or elements, and is not doing anything
> responsive or elastic), is also a valid way of passing 1.4.4 if nothing
> gets overlapped/cut off.
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >

From: Patrick H. Lauke
Date: Tue, Oct 27 2020 10:05AM
Subject: Re: Safari Pinch Zoom for 1.4.4
← Previous message | Next message →

On 27/10/2020 15:42, glen walker wrote:
> I agree with Patrick with regards to testing 1.4.4 separately from 1.4.11
> but I don't use pinch/zoom to test 1.4.4. To me, that's not really
> resizing the text since it magnifies the entire viewport.

It still satisfies the ask of 1.4.4 - that the user is able to resize
the text. It doesn't normatively say that it's ONLY the text that the
user needs to be able to resize, in isolation.

> Nothing will get
> cut off or overlap if the viewport changes so it's kind of useless to prove
> 1.4.4 passes. I use it all the time, personally, but not in my testing.

But that's the thing - normatively, you're passing this pretty much
always, because the user is always able to resize to 200%. Authors would
have to do something really wild to break it (can't recall now if that's
the case, but I seem to remember some combinations of absolute
positioning and viewport size (vh/vw) measures may end up causing
issues, but it seems unlikely).

P
--
Patrick H. Lauke

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

From: glen walker
Date: Tue, Oct 27 2020 4:55PM
Subject: Re: Safari Pinch Zoom for 1.4.4
← Previous message | Next message →

On Tue, Oct 27, 2020 at 10:05 AM Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

> On 27/10/2020 15:42, glen walker wrote:
> > I agree with Patrick with regards to testing 1.4.4 separately from 1.4.11
> > but I don't use pinch/zoom to test 1.4.4. To me, that's not really
> > resizing the text since it magnifies the entire viewport.
>
> It still satisfies the ask of 1.4.4 - that the user is able to resize
> the text. It doesn't normatively say that it's ONLY the text that the
> user needs to be able to resize, in isolation.
>

No, I get that. I'm familiar with normative vs not. All I'm saying is
that my personal opinion is that pinch zoom isn't really a text resize. I
don't think the browser is notified of a pinch/zoom so there's no chance
for the page to behave badly and overlap or clip elements. Does it make
the text bigger? Absolutely. Is it considered "resize text"? Perhaps my
pedantic definition of "resize" is flawed but I don't think so. But I'm
happy with my definition and will continue to use it. It doesn't bother me
if others don't agree.

From: Jonathan Avila
Date: Tue, Oct 27 2020 6:46PM
Subject: Re: Safari Pinch Zoom for 1.4.4
← Previous message | Next message →

> the browser is notified of a pinch/zoom so there's no chance for the page to behave badly and overlap or clip elements. Does it make the text bigger? Absolutely.

I run into areas of pages on mobile Safari that prevent pinch zooming from working. Most likely these areas are intercepting touch events and then do something different or what not - but I have seen this. Most of the time it's only on a area of the page and I can scroll up or down and pinch zoom and then back to the area I want to. This is probably not unlike the scroll jacking I'm seeing a lot now where the mouse scroll is taken over by content and might zoom in instead of scroll or simply scroll a region and then and only when I'm at the bottom of the region does it then allow me to scroll past the region to the rest of the page.

Jonathan

From: glen walker
Date: Tue, Oct 27 2020 8:37PM
Subject: Re: Safari Pinch Zoom for 1.4.4
← Previous message | No next message

>
> >I run into areas of pages on mobile Safari that prevent pinch zooming
> from working.
>

Yes, I've seen this too but is the opposite of what I was talking about.
If pinch/zoom is not interfered with, the page is not notified that it was
zoomed. But the page can certainly interfere with the zoom, as mentioned
in your example.