9 ms·

I'll post this here since people interested in accessibility will be reading this thread. I have terrible vision. One of my pet peeves is when I go to a websi

I'll post this here since people interested in accessibility will be reading this thread. I have terrible vision. One of my pet peeves is when I go to a website on my phone through safari that doesn't allow me to zoom the text. For those occasions, I came across a JavaScript bookmark that I created on my phone that runs to undo whatever is preventing me from zooming in. I'm not a web developer (I do desktop/server software development), so I have no idea how or why certain pages implement this policy/style. It just seems a little arbitrary to choose a font size for your site and not allow visitors to zoom-in in case they have trouble reading the text.

davidbarker 11y ago
I agree — disabling zooming is frustrating. Have you tried the "Reader" option in Safari? It works well for a lot of websites.
- cycomachead 11y ago
  The reader option is awesome when it exists, but there's currently no way to set a site to always enable it. Safari itself makes the determination on a page by page basis. Or at least that used to be the case.
Rifu 11y ago
I believe one of the reasons for preventing zoom-in is because it plays havoc with any element that is "fixed" in your browser (ie pretty much every nav bar/fixed header you'll ever encounter).
- jameshart 11y ago
  Also screws with ad layout and visibility. For sites that are primarily beholden to ad revenue, that can be a dealbreaker.
- locokoko 11y ago
  I just ran into this very problem. My workaround includes checking the window width with JQuery and changing the fixed status box (originally on the right side of the page) to floating at the top should the width be below a certain margin. Is this an acceptable solution? (I am just beginning web dev in lisp)
  - JoshTriplett 11y ago
    I think you can get the right result with a media query, assuming those are recomputed on zoom, which they should be.
    - locokoko 11y ago
      Thanks, works perfectly. Now I can delete some unnecessary JS :)
- JoshTriplett 11y ago
  That's a reason to set appropriate scale factors, not to prevent zooming entirely.
- JoelSutherland 11y ago
  If zooming is disabled, the browser can respond to clicks without a 300ms delay since it doesn't have to wait for a double-click zoom. It seems like the best solution to this problem would be to make a global toggle in settings.
  - amyjess 11y ago
    Alternately, you can just require multitouch zoom and get rid of the antiquated notion that you can double-click to zoom.
    - agos 11y ago
      Double tap to zoom is a standard gesture for mobile Safari, hardly antiquated.
      - SerpentJoe 11y ago
        That's true, but given that pinch to zoom is nearly ubiquitous, and given that the double tap gesture requires a 300ms lag before responding to single taps, the Web would arguably be better without it.
        socceroos 11y ago
        I can confirm that working around this issue is horrible. That dastardly 300ms makes quick operation of a mobile app a complete pain in the arse. Constantly having to wait for iOS to catch up with you. It really makes the experience horrible. But that's how iOS want it. If they made webapps that performant then they'd have trouble imprisoning everyone in the App Store.
    - deleted 11y ago
      [deleted]
- pjc50 11y ago
  How? It should just zoom the viewport, there's no reason for any of the DOM elements to even be aware that it's happening. Or has this been implemented in a really stupid way?
  - Rifu 11y ago
    I'm not too familiar with it myself, but if I had to hazard a guess it's because setting an element to display:fixed breaks it out into its own root stacking context[0], and browser zoom affects every stacking context[1]. Would love to hear from someone who's actually familiar with what's going on though. [0] http://updates.html5rocks.com/2012/09/Stacking-Changes-Coming-to-position-fixed-elements http://updates.html5rocks.com/2012/09/Stacking-Changes-Comin... [1] https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Understanding_z_index/The_stacking_context https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Under...
- jakobegger 11y ago
  While we're at it, please also get rid of fixed elements, especially on mobile devices. They obscure parts of the page for limited value, and they often break in horrible ways.
  - leppr 11y ago
    But with more and more mobile web browsers hiding the address bar, how is that person reading over your shoulder going to know what's the name of that awesome site you are viewing?
  - cycomachead 11y ago
    This is the solution... Even 'zoom' on fixed elements as dastardly as it looks is easier to read than text that is too small.
JoshTriplett 11y ago
The only legitimate reason I know of: if your site is interpreting touch events directly, and you use pinch-to-zoom yourself; for instance, full-page maps. In that case, it's your responsibility to make all your non-zooming elements (such as the fixed UI overlay on the map) appropriately sized for the device.
mkozlows 11y ago
For what it's worth, using the viewport meta element to disable zoom is a WCAG AA accessibility violation: http://www.w3.org/TR/mobile-accessibility-mapping/#zoom-magnification http://www.w3.org/TR/mobile-accessibility-mapping/#zoom-magn...
- yellowapple 11y ago
  That seems to focus on font size adjustments, which would be unaffected by a meta viewport, no?
  - steveax 11y ago
    "Magnify browser's viewport (typically "pinch-zoom")" That is exactly what is disabled when authors disable zoom via the meta property.
    - yellowapple 11y ago
      Right, but it's not what the relevant accessibility standard focuses on. It's the difference between zooming the whole page and making just the text bigger (i.e. through a browser's minimum font size setting), and it's only the former that's affected by meta viewport tags, no?
      - cycomachead 11y ago
        As some who also has terrible vision -- dedicated text sizing is awesome, but being able to just pinch-zoom makes ALL the difference for me. So many aspects of a web page are hard to use other than just text as well. (Those "X" close icons can get pretty damn hard to decipher at times.) No solution is perfect, but allowing zooming is simple and a huge win for me. (Even if the site still has a sticky header that wont get out of the way...)
Someone1234 11y ago
This is a little off topic, but if you use Chrome on Android you can disable site's ability to disable zoom. - Open Chrome (or Chrome Beta) on Android. - Settings -> Accessibility - Force enable zoom (check). Sites may need to be reloaded after applying this setting.
- tracker1 11y ago
  For that matter, you can also set a default text-scaling level as well (mine is at 130%), which I tend to do in addition to force enable zoom. Many sites have fonts that are too small on a phone imho... they really should be at least 12pt for most text assuming that proper scaling meta is set... Too many sites use 9-10pt fonts which are just really hard to read. I'm far sighted, so my phone is literally the hardest thing for me to use much of the time. One of the worst offenders was the Facebook app, which didn't seem to even follow Android's setting for using larger fonts. I've since stopped using the FB app (way too much battery usage), and just use the mobile site, which isn't much better in terms of usability.

davidbarker 11y ago

I agree — disabling zooming is frustrating. Have you tried the "Reader" option in Safari? It works well for a lot of websites.

cycomachead 11y ago
The reader option is awesome when it exists, but there's currently no way to set a site to always enable it. Safari itself makes the determination on a page by page basis. Or at least that used to be the case.

Rifu 11y ago

I believe one of the reasons for preventing zoom-in is because it plays havoc with any element that is "fixed" in your browser (ie pretty much every nav bar/fixed header you'll ever encounter).

jameshart 11y ago
Also screws with ad layout and visibility. For sites that are primarily beholden to ad revenue, that can be a dealbreaker.
locokoko 11y ago
I just ran into this very problem. My workaround includes checking the window width with JQuery and changing the fixed status box (originally on the right side of the page) to floating at the top should the width be below a certain margin. Is this an acceptable solution? (I am just beginning web dev in lisp)
- JoshTriplett 11y ago
  I think you can get the right result with a media query, assuming those are recomputed on zoom, which they should be.
  - locokoko 11y ago
    Thanks, works perfectly. Now I can delete some unnecessary JS :)
JoshTriplett 11y ago
That's a reason to set appropriate scale factors, not to prevent zooming entirely.
JoelSutherland 11y ago
If zooming is disabled, the browser can respond to clicks without a 300ms delay since it doesn't have to wait for a double-click zoom. It seems like the best solution to this problem would be to make a global toggle in settings.
- amyjess 11y ago
  Alternately, you can just require multitouch zoom and get rid of the antiquated notion that you can double-click to zoom.
  - agos 11y ago
    Double tap to zoom is a standard gesture for mobile Safari, hardly antiquated.
    - SerpentJoe 11y ago
      That's true, but given that pinch to zoom is nearly ubiquitous, and given that the double tap gesture requires a 300ms lag before responding to single taps, the Web would arguably be better without it.
      - socceroos 11y ago
        I can confirm that working around this issue is horrible. That dastardly 300ms makes quick operation of a mobile app a complete pain in the arse. Constantly having to wait for iOS to catch up with you. It really makes the experience horrible. But that's how iOS want it. If they made webapps that performant then they'd have trouble imprisoning everyone in the App Store.
  - deleted 11y ago
    [deleted]
pjc50 11y ago
How? It should just zoom the viewport, there's no reason for any of the DOM elements to even be aware that it's happening. Or has this been implemented in a really stupid way?
- Rifu 11y ago
  I'm not too familiar with it myself, but if I had to hazard a guess it's because setting an element to display:fixed breaks it out into its own root stacking context[0], and browser zoom affects every stacking context[1]. Would love to hear from someone who's actually familiar with what's going on though. [0] http://updates.html5rocks.com/2012/09/Stacking-Changes-Coming-to-position-fixed-elements http://updates.html5rocks.com/2012/09/Stacking-Changes-Comin... [1] https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Understanding_z_index/The_stacking_context https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Under...
jakobegger 11y ago
While we're at it, please also get rid of fixed elements, especially on mobile devices. They obscure parts of the page for limited value, and they often break in horrible ways.
- leppr 11y ago
  But with more and more mobile web browsers hiding the address bar, how is that person reading over your shoulder going to know what's the name of that awesome site you are viewing?
- cycomachead 11y ago
  This is the solution... Even 'zoom' on fixed elements as dastardly as it looks is easier to read than text that is too small.

JoshTriplett 11y ago

The only legitimate reason I know of: if your site is interpreting touch events directly, and you use pinch-to-zoom yourself; for instance, full-page maps. In that case, it's your responsibility to make all your non-zooming elements (such as the fixed UI overlay on the map) appropriately sized for the device.

mkozlows 11y ago

For what it's worth, using the viewport meta element to disable zoom is a WCAG AA accessibility violation: http://www.w3.org/TR/mobile-accessibility-mapping/#zoom-magnification http://www.w3.org/TR/mobile-accessibility-mapping/#zoom-magn...

yellowapple 11y ago
That seems to focus on font size adjustments, which would be unaffected by a meta viewport, no?
- steveax 11y ago
  "Magnify browser's viewport (typically "pinch-zoom")" That is exactly what is disabled when authors disable zoom via the meta property.
  - yellowapple 11y ago
    Right, but it's not what the relevant accessibility standard focuses on. It's the difference between zooming the whole page and making just the text bigger (i.e. through a browser's minimum font size setting), and it's only the former that's affected by meta viewport tags, no?
    - cycomachead 11y ago
      As some who also has terrible vision -- dedicated text sizing is awesome, but being able to just pinch-zoom makes ALL the difference for me. So many aspects of a web page are hard to use other than just text as well. (Those "X" close icons can get pretty damn hard to decipher at times.) No solution is perfect, but allowing zooming is simple and a huge win for me. (Even if the site still has a sticky header that wont get out of the way...)

Someone1234 11y ago

This is a little off topic, but if you use Chrome on Android you can disable site's ability to disable zoom. - Open Chrome (or Chrome Beta) on Android. - Settings -> Accessibility - Force enable zoom (check). Sites may need to be reloaded after applying this setting.

tracker1 11y ago
For that matter, you can also set a default text-scaling level as well (mine is at 130%), which I tend to do in addition to force enable zoom. Many sites have fonts that are too small on a phone imho... they really should be at least 12pt for most text assuming that proper scaling meta is set... Too many sites use 9-10pt fonts which are just really hard to read. I'm far sighted, so my phone is literally the hardest thing for me to use much of the time. One of the worst offenders was the Facebook app, which didn't seem to even follow Android's setting for using larger fonts. I've since stopped using the FB app (way too much battery usage), and just use the mobile site, which isn't much better in terms of usability.