-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Any doc to explain why we should be using this viewport value? #481
Comments
We will relax minimal-ui. Other properties guarantee good performance and usability in standalone and viewer scenarios. |
I think we can relax this a bit. This is mostly rooted in https://www.chromium.org/developers/design-documents/chromium-graphics/how-to-get-gpu-rasterization which relaxed without us nothing. |
@cramforce thx for pointing this out, if |
Please, please, please remove the "initial-scale=1, minimum-scale=1" part. Not allowing users to pinch and zoom is awfully disempowering, particular for people with poor vision. dvoytenko wrote "Other properties guarantee good performance and usability in standalone and viewer scenarios." Good performance perhaps, but certainly not usability. |
We will definitely experiment with this a lot. The issue is that apps will be embedded AMP documents directly in their viewers and we need to ensure the portability between those. |
We should definitely find a good compromise here. Totally open to advice! |
Actually, you know what? I think I may have spoken too soon: I thought there was a maximum-scale in there ...there isn't. Having initial-scale and minimum-scale should be fine. I'll see if I can do a bit of research to confirm this. In any case, apologies for jumping the gun there. |
@adactio I'm still seeing I'll echo the existing claims that these should be removed to allow users to scale their content. There's not much point having blazing fast performance if people can't read the page once they get it. The viewport I'd like to see (given <meta name="viewport" content="width=device-width,initial-scale=1,minimum-scale=1"> |
@BPScott Right, the existing documentation does indeed still have maximum-scale=1 and user-scalable=no (and they're currently required for passing amp validation) but on this thread @cramforce said that it could be relaxed a bit and I assumed that @bitinn's suggestion was the option being discussed. I may have misinterpreted. But yeah, maximum-scale=1 and user-scalable=no have got to go!
Exactly! |
Agree with @BPScott. Considering the use case, minimum-scale=1 would actually be a good thing. |
To review: we will definitely do a lot of experimentation and testing with these values on different browsers. The issues that are very important to us:
We will definitely try, but I don't think we are ready to tell how well this would work yet. I do hope however that we can at least make it an author choice. |
I'm happy to see that there will be more experimentation and investigation into this, as a11y is a critical aspect of the web.
Isn't this basically a reason to consider not using |
Adam, yes, that was my point exactly. That's the motivation. And if something will prevent us from doing it now we will definitely take it to the browsers. |
I'd echo (+1) @BPScott's point, we do a lot of work in accessibility and the ability to expand (by at least 200%) is a key requirement for accessibility, and a lot of people who don't necessarily class themselves as needing accessibility help. Having applied it a lot, the only negative that I can see a publisher complaining about is when elements expand outside of the body-width. Typically an ad banner is set at 500px in a body width of 320px, and then you see horizontal scrolling which makes it more likely to accidentally zoom. I think AMP could easily overcome that with things like max-width on images etc. |
Most publishers also do lots of other things, like adding JavaScript to their sites...which doesn't mean AMP needs to include that either, no? As many others, I'll echo that disabling zooming (and mandating this at spec level) is a non-starter for accessibility. |
As suggested by @BPScott and me, if Note that it's To me PS: I am looking at AMP as a future guideline for media/publishers, so getting a11y right means a lot more users will benefit from AMP. It's a tall order but somehow I think we can manage. |
@dvoytenko My recollection from when I worked on Google Image Search UI for tablet/mobile is that you can change the meta element via JavaScript to disable zoom, for example, when a lightbox is activated, then re-enable it later. That may help with issue 4. |
@brlewis thanks! I tested some aspects of this and came away feeling that it was rather flaky on different browsers especially when iframe'd, which is an important case for us. But we'll be definitely testing this more. Thanks for the suggestion! |
Another crazy idea: if publishers do want to use This feels like an anti-pattern: because by default your page should be accessible. But from my observations, almost all publishers eventually violate some a11y rules to achieve the layout they are after. A strict validation rule on this prevent wide-adoption of AMP. In that case, I would say enforce a print-friendly button (and they must be consistent and apparent), so even for ppl on non-iOS devices, a11y is an option. My optimistic endgame for this:
|
My thoughts FWIW, Apps users (80% of mobile users?) aren't used to pinch/zoom, they do that on images and maps eventually, rarely on browsers ... apps don't pinch/zoom. If the font size is the default one, current viewport grants as-good-as-native visualization and if the user has not best eyes out there, the entire system usually will use the bigger font instead of the default small one. Moreover, when it comes to images or maps, pinch/zoom on the whole page as default action becomes misleading instead of improving a11y. Last, but not least, in all these years the DOM never even exposed a single standard way to retrieve the current zoom page ratio, once changed, neither an event capable of intercepting it (resize would be a workaround that might not even trigger) and being unable to actually handle these cases makes dynamic, X,Y handled coordinates, like in maps systems, harder to understand resulting on worst experience for the user. TL;DR since most publishers, somehow first class target for this project, used already current restricted viewport which worked for them and their users, I think the specs should define a minimal set of options, as suggested before, and actually ignore anything else .... letting publishers decide if the user should be able to pinch/zoom/scale. |
OK, I'm the poreson who's severely affected by unability to zoom mobile web content due to "maximum-scale=1" and "user-scalable=no". My eyes are anything but good, but I still use them and I'm not using any screenreader yet, I prefer to zoom content to be able to read it comfortably. And the mobile web pages are often preventing me from it. So please, remove those damned viewport params from your example documents and validation conditions. Or is the mobile web really only for people with eagle-eye sight? |
We've had years of non-reponsive sites that you have to zoom in on, I think users in general are well trained to use zoom. Also, given the JS restrictions, are there going to be maps or similar interactive features in AMP pages to confuse the interactions?
System level text sizing isn't applied in Safari or Chrome. (At least last time I checked. It isn't in Sarafi on iOS 9, I don't have an android/chrome browser to hand.)
The whole point of this project is that publishers sites include many anti-mobile patterns, and AMP is supposed to improve that. Saying that they do something now doesn't seem like a strong argument to continue it. |
@WebReflection If I get this correctly, amphtml is about documents, not app UI. I don't think anyone will use amphtml as an app framework, so pinch-to-zoom shouldn't be prevented, since there is a minority which depneds on this capability. And yes, web standards and browsers should sork differently with parts of web pages displaying actual documents and the rest displaying web app UI |
@alastc I've met many people that never used the browser at all, passing though the app store for anything mentioned but yeah, since the mobile web hasn't been implemented that well so far, old desktop only sites requires pinch/zoom. Here we are talking about new sites that so far worked well with current restrictions: why would have publishers prefer them otherwise? Moreover about maps, I don't see why this project couldn't be thought from scratch future compatible. So far is static content only but tomorrow there could be In any case, I've said that this would be in my opinion the ideal minimum requirement: <meta name="viewport" content="width=device-width,initial-scale=1.0"> but if there's more the AMP validator should just let it go instead of throwing warnings. In this way we can still promote best practice, but not lock specs forever in case there will be games, maps, carousels or who knows which component in the future where the viewport, for whatever reason (games, maps, etc), might need to be fully locked. |
There is an assumption they made a conscious choice about that, but perhaps they followed a default in some templates they were using? I'm doing accessibility training for one of the named launch partners quite soon, and during the process of setting that up I found they didn't know about quite a few accessibility requirements, including the one for allowing zoom. Your minimum requirement is fine, I would just like to see the docs & examples not require or default to disabling zoom. I would also suggest that if disabling zoom is needed for working around bugs/quirks when there are interactive elements, perhaps we should work out what they are and try and fix them? |
Chrome does respect system size and also has a separate text zoom setting The worst offending app here is Facebook. It completely ignores the system The "must express everything in px" mantra of AMP is also annoying. I want
|
I couldn’t agree more with @adactio’s assertion: “…maximum-scale=1 and user-scalable=no have got to go!” |
Kevin: Note, that AMP generally only uses pixels to calculate aspect Would be great to finally get aspect ratio support in CSS, but I find the
|
It'd be interesting to know whether "user-scablable=no" would break WCAG 2.0 1.4.4 - Resize text. My guess it that it would and the requirement to have it on would mean that no AMP HTML website would be able to reach WCAG 2.0 AA standard as a result. I know the EU were concerned earlier this year about people disabling zoom off for mobile devices. If the aim is to make sites that work for people then all people need to be remembered, including those who need to zoom to read text on a page. |
Thanks all for the suggestions! We are going to involve accessibility experts on our side in a short order and experiment with all of the options. It's our goal to do everything possible to enforce a high accessibility standard throughout AMP universe. |
@dvoytenko Glad to hear it! Could you let us know who those accessibility experts are, or ask them to contribute to this issue thread? Cheers. |
Few updates:
|
@dvoytenko Happy to offer a11y advice if you want it :-) BTW - Just echoing the |
Maybe @alice has some thoughts on this... |
Sounds like @dvoytenko has it in largely in hand. Perhaps someone with more experience with zoom than me could respond to his questions (2) and (4) above? |
Regarding gestures, Chrome also has the 'double-tap to zoom text block to current viewport width' gesture that is extremely useful, but easy to trigger accidentally and hard to undo. Pinch to zoom in modal images is also a natural feature; facebook's and twitters apps support zooming in their light boxes; indeed given the infographic plague it is a necessary one to read some things shared as images. |
I'm a bit rusty on the Android side, but:
When we've had people with low-vision in for usability testing they have generally had large Android phones (I haven't run any since the iPhone 6 came out), purely for the extra size of the display. People didn't generally know about the text-size settings, although helpful friends or charities sometimes change things for them. Currently (pinch) zoom on mobile works like magnification, however, a lot more people know about it and use it. Default features are always more used than specific accessibility settings. Also, if you try the three-fingered gestures, it is a lot more fiddly than a simple pinch zoom. |
Rather than http://w3c.github.io/pointerevents/#the-touch-action-css-property |
@kevinmarks we will definitely have pinch to zoom in modals for images (lightbox). We already have double-tap and tap-to-zoom. Somehow pinch-to-zoom itself has fallen through the cracks, but we'll probably add soon. #446. |
Thanks everyone for advise. We are removing restrictions from |
Opened #592 to track implementation. |
Closing the discussion. #592 tracks the implementation of what I believe everyone here is happy with. Thanks for all the input! Truly appreciated!!!! |
@dvoytenko @cramforce Thank you! 💯 |
Many thanks! |
All! Now |
not sure it's relevant ... but maybe it is: WebKit enables fast click only on non-scalable viewports |
It's relevant, but in this case we will leave this up to publisher to decide. Not all documents need fast click. And components that really care about this, such as |
regarding fast click, though webkit's change is welcome, it's about 2 years late compared to other browsers, and less problematic (from an accessibility perspective) solutions - such as removing the ~300ms delay for it's likely that |
https://github.com/ampproject/amphtml/blob/master/spec/amp-html-format.md#required-markup
This probably has something to do with 300ms click delay or rendering issues, but
user-scalable=no
is known to cause accessibility issues, is it worth the compromise?Since
minimal-ui
is also a legacy keyword used by iOS Safari (added then removed), I am not sure why it's recommended neither.Let me know if I should be asking this on StackOverflow.
The text was updated successfully, but these errors were encountered: