81–90 of 93 posts
Earlier quoted context omitted.
Alternately, you can just require multitouch zoom and get rid of the antiquated notion that you can double-click to zoom.
Double tap to zoom is a standard gesture for mobile Safari, hardly antiquated.
Earlier quoted context omitted.
Definitely not in the minority. Bookmarklet was a little easier to get out the door, and I haven't found a great way to maintain extensions for several browsers. Will definitely up its priority. Userscript is an awesome idea, thanks for taking the time to build this out. Is this something that will work in all browsers? What's the installation process like? Perhaps we can build one of those into the project page as w…
Although userscripts themselves are cross-browser compatible, I don't know of any browser that offers native support for them. However, there are extensions that manages them (Greasemonkey for Firefox, Tampermonkey for Chrome, etc.) Once the user has a userscript manager installed, the installation process is a matter of a one click job.
https://www.chromium.org/developers/design-documents/user-sc...
Earlier quoted context omitted.
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-magn...
That seems to focus on font size adjustments, which would be unaffected by a meta viewport, no?
That is exactly what is disabled when authors disable zoom via the meta property.
Earlier quoted context omitted.
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).
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.
Earlier quoted context omitted.
That seems to focus on font size adjustments, which would be unaffected by a meta viewport, no?
"Magnify browser's viewport (typically "pinch-zoom")" That is exactly what is disabled when authors disable zoom via the meta property.
Earlier quoted context omitted.
Double tap to zoom is a standard gesture for mobile Safari, hardly antiquated.
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.
But that's how iOS want it. If they made webapps that performant then they'd have trouble imprisoning everyone in the App Store.
Earlier quoted context omitted.
I read that. I still don't understand how an h4 directly under an h2 impairs accessibility.
Perhaps screen readers can be set to read out the major headings to help people figure out what part of the document they want to read. This would have a level of detail or verbosity control. First you read h1, find the right header. Then h2 with 2 levels of detail, which hits h2 and h3. You miss the sub-section you wanted because it was marked h4 instead of h3. It's a broken tree structure... that'll cause problems…
As others have mentioned, it's likely flagged as an accessibility issue since having an h4 follow an h2 indicates a broken document structure.
It's also probably included in the tool because things like that usually (though not always) mean that the developer is just using the h4 tag based on how it looks as opposed to actual semantic meaning, and the tool is designed to get you to put more thought into what you're actually building.