E-mail List Archives
Thread: SC 1.4.4: browser zoom and responsive design
Number of posts in this thread: 13 (In chronological order)
From: Fernand van Olphen
Date: Sun, Apr 09 2017 3:05PM
Subject: SC 1.4.4: browser zoom and responsive design
No previous message | Next message →
With interest I have followed the discussion about SC 1.4.4, resize text. Conclusion: browser zoom is allowed.
My question is about browser zoom and responsive design.
Suppose I visit a website. It is a garbage-day calender. It gives me the option to browse through the months to check when my garbage is collected. After a few zooms the responsive design kicks in. In this design the calender is replaced by a static list without the option to browse through the months. In other words: the responsive design does not give me the same options as the desktop design does.
https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G142 says under Tests > procedure:
1. Display content in a user agent
2. Zoom content to 200%
3. Check whether all content and functionality is available
The responsive design in my example misses functionality that the desktop design does have.
Is this a violation of SC 1.4.4?
Kind regards,
Fernand van Olphen
Accessibility Advisor
Municipality of The Hague
De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op: http://www.denhaag.nl/disclaimer
From: Srinivasu Chakravarthula
Date: Mon, Apr 10 2017 3:25AM
Subject: Re: SC 1.4.4: browser zoom and responsive design
← Previous message | Next message →
I don't think it would be a violation. When it works well on desktop, it
may work well with device OS zoom settings for smaller screens. Referring
https://www.w3.org/TR/mobile-accessibility-mapping/#zoom-magnification may
be helpful.
Best,
Regards,
Srinivasu Chakravarthula - Twitter: http://twitter.com/CSrinivasu/
Website: http://www.srinivasu.org | http://serveominclusion.com
Let's create an inclusive web!
Lead Accessibility Consultant, Informatica
Hon. Joint Secretary, The National Association for the Blind, Karnataka
Branch
On Mon, Apr 10, 2017 at 2:35 AM, Fernand van Olphen <
= EMAIL ADDRESS REMOVED = > wrote:
> With interest I have followed the discussion about SC 1.4.4, resize text.
> Conclusion: browser zoom is allowed.
>
> My question is about browser zoom and responsive design.
>
> Suppose I visit a website. It is a garbage-day calender. It gives me the
> option to browse through the months to check when my garbage is collected.
> After a few zooms the responsive design kicks in. In this design the
> calender is replaced by a static list without the option to browse through
> the months. In other words: the responsive design does not give me the same
> options as the desktop design does.
>
> https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G142 says under
> Tests > procedure:
>
> 1. Display content in a user agent
>
> 2. Zoom content to 200%
>
> 3. Check whether all content and functionality is available
>
> The responsive design in my example misses functionality that the desktop
> design does have.
>
> Is this a violation of SC 1.4.4?
>
> Kind regards,
> Fernand van Olphen
> Accessibility Advisor
> Municipality of The Hague
>
>
>
>
>
>
>
>
>
> De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u
> op: http://www.denhaag.nl/disclaimer
> > > > >
From: Detlev Fischer
Date: Mon, Apr 10 2017 3:40AM
Subject: Re: SC 1.4.4: browser zoom and responsive design
← Previous message | Next message →
My take would be that essential functionality needed for executing the task that the site supports should also be available in the mobile view. I.e., if it is essential to be able to check the garbage calendar for weeks / months ahead (which is a judgement call), some (possibly different) way of navigating or getting there should be available also in the mobile version. Navigation may be hidden behind a hamburger icon or the next month might come into view only after scrolling. If there is really no way to get there, the site does in my view fail the requirement "without loss of content or functionality".
Best, Detlev
-
Detlev Fischer
testkreis c/o feld.wald.wiese
Thedestr. 2, 22767 Hamburg
Mobil +49 (0)157 57 57 57 45
Fax +49 (0)40 439 10 68-5
http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites
Srinivasu Chakravarthula schrieb am 10.04.2017 11:25:
> I don't think it would be a violation. When it works well on desktop, it
> may work well with device OS zoom settings for smaller screens. Referring
> https://www.w3.org/TR/mobile-accessibility-mapping/#zoom-magnification may
> be helpful.
> Best,
>
> Regards,
>
> Srinivasu Chakravarthula - Twitter: http://twitter.com/CSrinivasu/
> Website: http://www.srinivasu.org | http://serveominclusion.com
>
> Let's create an inclusive web!
>
> Lead Accessibility Consultant, Informatica
> Hon. Joint Secretary, The National Association for the Blind, Karnataka
> Branch
>
> On Mon, Apr 10, 2017 at 2:35 AM, Fernand van Olphen <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> With interest I have followed the discussion about SC 1.4.4, resize text.
>> Conclusion: browser zoom is allowed.
>>
>> My question is about browser zoom and responsive design.
>>
>> Suppose I visit a website. It is a garbage-day calender. It gives me the
>> option to browse through the months to check when my garbage is collected.
>> After a few zooms the responsive design kicks in. In this design the
>> calender is replaced by a static list without the option to browse through
>> the months. In other words: the responsive design does not give me the same
>> options as the desktop design does.
>>
>> https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/G142 says under
>> Tests > procedure:
>>
>> 1. Display content in a user agent
>>
>> 2. Zoom content to 200%
>>
>> 3. Check whether all content and functionality is available
>>
>> The responsive design in my example misses functionality that the desktop
>> design does have.
>>
>> Is this a violation of SC 1.4.4?
>>
>> Kind regards,
>> Fernand van Olphen
>> Accessibility Advisor
>> Municipality of The Hague
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u
>> op: http://www.denhaag.nl/disclaimer
>> >> >> >> >>
> > > > >
From: Jonathan Avila
Date: Mon, Apr 10 2017 12:11PM
Subject: Re: SC 1.4.4: browser zoom and responsive design
← Previous message | Next message →
> The responsive design in my example misses functionality that the desktop design does have.
If there is no way to get to the functionality it seems like an issue to me. In some cases there is a link to a desktop site and that would allow the user to access the content in a none-responsive way and use pinch zoom.
Jonathan
From: Beranek, Nicholas
Date: Mon, Apr 10 2017 12:14PM
Subject: Re: SC 1.4.4: browser zoom and responsive design
← Previous message | Next message →
Yes, and one of the biggest follies that I see are those disabling pinch and zoom through meta viewport declarations a la <meta name="viewport" content="user-scalable=no, maximum-scale=1.0">. This is a bad practice that is unfortunately added to many of the "Bootstrap" libraries.
Nick
From: Patrick H. Lauke
Date: Mon, Apr 10 2017 12:24PM
Subject: Re: SC 1.4.4: browser zoom and responsive design
← Previous message | Next message →
On 10/04/2017 19:14, Beranek, Nicholas wrote:
> Yes, and one of the biggest follies that I see are those disabling
> pinch and zoom through meta viewport declarations a la <meta
> name="viewport" content="user-scalable=no, maximum-scale=1.0">.
Circling back to a previous reply on this thread, modern browsers now
either ignore this or let users override it.
http://webaim.org/discussion/mail_message?id4346
> This
> is a bad practice that is unfortunately added to many of the
> "Bootstrap" libraries.
Tiny point of clarification: that's definitely not something that's in
*the* Bootstrap (as in http://getbootstrap.com/) framework, but I assume
you meant this as a more generic term for ready-made frameworks.
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: Beranek, Nicholas
Date: Mon, Apr 10 2017 1:09PM
Subject: Re: SC 1.4.4: browser zoom and responsive design
← Previous message | Next message →
That was my fault for both capitalizing AND putting it in quotes. I meant the latter: a generic term for ready-made frameworks.
I like how browser manufacturers will adapt to some of the user's needs, but I have a real problem with browsers simply ignoring a declaration within the HTML document. While this statement does not support my case, it introduces a precedent that is only propagated by developers who choose to introduce this behavior, subsequently breaking the ability to see the screen better.
In conclusion, TIL (today I learned) that "Browser settings can ignore this rule (user-scalable, minimum-scale, maximum-scale), and iOS10+ ignores it by default." While I don't agree with ignoring explicit rules, I feel this is a win for users.
Nick
From: Karl Brown
Date: Tue, Apr 11 2017 4:56AM
Subject: Re: SC 1.4.4: browser zoom and responsive design
← Previous message | Next message →
It comes down to whether it's the *functionality* that's important or the
*content*.
The functionality is "the ability to see the collection dates", which the
list on mobile provides.
If the calendar on desktop has additional functionality (quickly skip
through months, etc.) then mobile is missing functionality. Otherwise I'd
argue that the core purpose, the dates, are still available in a readable
format so don't need to be shown the same way where doing so would impair
understanding.
On Mon, Apr 10, 2017 at 7:11 PM, Jonathan Avila < = EMAIL ADDRESS REMOVED = >
wrote:
> > The responsive design in my example misses functionality that the
> desktop design does have.
>
> If there is no way to get to the functionality it seems like an issue to
> me. In some cases there is a link to a desktop site and that would allow
> the user to access the content in a none-responsive way and use pinch zoom.
>
> Jonathan
>
>
>
From: Tim Harshbarger
Date: Tue, Apr 11 2017 7:10AM
Subject: Re: SC 1.4.4: browser zoom and responsive design
← Previous message | Next message →
Another way to look at this might be...
User interfaces are created with the intention of facilitating specific user tasks. If it is still possible to perform those user tasks in an accessible manner, then things are likely ok. If not, there is a problem.
I think that is why it is important to have an understanding of the author's intent when looking at the accessibility of a user interface. I think one of our key goals is to ensure the author's intent is communicated to users in as accessible a manner as possible--whether the "author" intends just to communicate a piece of information or make it possible for a user to buy a widget.
When we don't know the author's intent, then we have to make assumptions.
From: Mallory
Date: Wed, Apr 12 2017 3:21AM
Subject: Re: SC 1.4.4: browser zoom and responsive design
← Previous message | Next message →
In case someone wonders why anyone *would* bother setting
user-scalable to no... anyone who was using Hammer.js
(a library with swipes and things built-in) did not work if users
zoomed, so basically it was a requirement to set zooming off
if your site used Hammer, and Hammer did have some popularity
back when it was out.
cheers,
On Tue, Apr 11, 2017, at 03:10 PM, Tim Harshbarger wrote:
> Another way to look at this might be...
>
> User interfaces are created with the intention of facilitating specific
> user tasks. If it is still possible to perform those user tasks in an
> accessible manner, then things are likely ok. If not, there is a problem.
>
> I think that is why it is important to have an understanding of the
> author's intent when looking at the accessibility of a user interface. I
> think one of our key goals is to ensure the author's intent is
> communicated to users in as accessible a manner as possible--whether the
> "author" intends just to communicate a piece of information or make it
> possible for a user to buy a widget.
>
> When we don't know the author's intent, then we have to make assumptions.
>
>
From: Karl Brown
Date: Wed, Apr 12 2017 3:43AM
Subject: Re: SC 1.4.4: browser zoom and responsive design
← Previous message | Next message →
Another reason zooming got disabled on some sites is because the UX/UI
designers or business insisted on it. I sat in a few meetings where it was
discussed "to keep the design looking as intended."
They didn't like it when I argued (UK based) about reasonable aids and
adaptations under the Equality Act 2010.
On Wed, Apr 12, 2017 at 10:21 AM, Mallory < = EMAIL ADDRESS REMOVED = > wrote:
> In case someone wonders why anyone *would* bother setting
> user-scalable to no... anyone who was using Hammer.js
> (a library with swipes and things built-in) did not work if users
> zoomed, so basically it was a requirement to set zooming off
> if your site used Hammer, and Hammer did have some popularity
> back when it was out.
>
> cheers,
>
> On Tue, Apr 11, 2017, at 03:10 PM, Tim Harshbarger wrote:
> > Another way to look at this might be...
> >
> > User interfaces are created with the intention of facilitating specific
> > user tasks. If it is still possible to perform those user tasks in an
> > accessible manner, then things are likely ok. If not, there is a problem.
> >
> > I think that is why it is important to have an understanding of the
> > author's intent when looking at the accessibility of a user interface. I
> > think one of our key goals is to ensure the author's intent is
> > communicated to users in as accessible a manner as possible--whether the
> > "author" intends just to communicate a piece of information or make it
> > possible for a user to buy a widget.
> >
> > When we don't know the author's intent, then we have to make assumptions.
> >
> >
From: Fernand van Olphen
Date: Wed, Apr 12 2017 5:14AM
Subject: Re: SC 1.4.4: browser zoom and responsive design
← Previous message | Next message →
Thanks everyone for contributing!
Maybe we can reach a sort of conclusion?
Regarding technique G142 (SC 1.4.4) and responsive design:
If I visit a website;
If I browser zoom (ctrl/+ on my keyboard);
If I encounter a responsive design before reaching the 200% zoom level;
Then this design must give me the same CONTENT (however this might be presented to me)
And don't forget to enable pinch zoom ;)
Fernand van Olphen
Accessibility Advisor
Municipality of The Hague
De disclaimer van toepassing op e-mail van de gemeente Den Haag vindt u op: http://www.denhaag.nl/disclaimer
From: Mallory
Date: Wed, Apr 12 2017 12:17PM
Subject: Re: SC 1.4.4: browser zoom and responsive design
← Previous message | No next message
That's just basically "we think it's pretty when broken." I wish all
those
folks were forced to not be able to use a mouse and only get 9px light
grey text on white for all their computing for like a week at work.
cheers
On Wed, Apr 12, 2017, at 11:43 AM, Karl Brown wrote:
> Another reason zooming got disabled on some sites is because the UX/UI
> designers or business insisted on it. I sat in a few meetings where it
> was
> discussed "to keep the design looking as intended."
>
> They didn't like it when I argued (UK based) about reasonable aids and
> adaptations under the Equality Act 2010.
>
> On Wed, Apr 12, 2017 at 10:21 AM, Mallory < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > In case someone wonders why anyone *would* bother setting
> > user-scalable to no... anyone who was using Hammer.js
> > (a library with swipes and things built-in) did not work if users
> > zoomed, so basically it was a requirement to set zooming off
> > if your site used Hammer, and Hammer did have some popularity
> > back when it was out.
> >
> > cheers,
> >
> > On Tue, Apr 11, 2017, at 03:10 PM, Tim Harshbarger wrote:
> > > Another way to look at this might be...
> > >
> > > User interfaces are created with the intention of facilitating specific
> > > user tasks. If it is still possible to perform those user tasks in an
> > > accessible manner, then things are likely ok. If not, there is a problem.
> > >
> > > I think that is why it is important to have an understanding of the
> > > author's intent when looking at the accessibility of a user interface. I
> > > think one of our key goals is to ensure the author's intent is
> > > communicated to users in as accessible a manner as possible--whether the
> > > "author" intends just to communicate a piece of information or make it
> > > possible for a user to buy a widget.
> > >
> > > When we don't know the author's intent, then we have to make assumptions.
> > >
> > >