-
Notifications
You must be signed in to change notification settings - Fork 256
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
Success Criterion 1.3.4: Orientation - Content breaks while switching from one orientation to the other #2771
Comments
Not an ideal experience, but not a failure. |
With respect, this should be a fail of SC 1.3.4. While content may work perfectly in both orientations and only fail when transitioning from one to the other, I see nothing that indicates working in the initial orientation is all that is needed. By definition orientation is subject to change, and so it seems pretty clear the intention is content that works in either orientation, including after a change in orientation. WCAG says: 'Content does not restrict its view and operation to a single display orientation'. Operation, in the context of orientation, reasonably includes either orientation, and that reasonably supposes a user may change orientation. Changing orientation is the raison d'être of devices that offer two orientations. No device sold today is designed to need a refresh or power cycle between orientation changes. No one would expect that. If a webpage can provide accessible content in either orientation and after a change in orientation--without any additional steps for the user such as |
@alanfluff sure, except Technique G214 already addresses this: Applicability Description While this technique assumes an author supplied 'button'*, it does not forbid a user-agent function filling the need, and pretty much every user-agent I've ever encountered allows for a page reload/refresh, so as long as the page refresh results in the content being viewable and operational after the refresh, you've met the intent of the SC. (* The Technique is a wee vague here, as it states "Check for a control within the user interface to change the orientation of the content. This is subtly different than saying "Check for a control within the page to change the orientation of the content." because the browser chrome is also part of the user interface. I agree that a bit more clarity here would be beneficial however.) Given this has been a Suitable Technique since the publishing of WCAG 2.1 4 years ago, trying to further constrict or constrain this SC would potentially break backward compatibility if an org was reliant today on Technique G214. |
The question in my mind is, when the content fails to redisplay properly after the user changes the orientation of their device, is that due to failure of the device manufacturer to redisplay properly? - in which case it is down to them and not a failure of the web developer (i.e. the dev isn't failing the WCAG in their work). And it wouldn't even be a hardware bug - the manufacturer might see reasons for not altering the responsive reflow of the page which would probably entail a page refresh and loss of any data? Or is the developer doing something to lock the orientation after page load? - I can't see many developers doing that (or even knowing how to do that - I would certainly have to find out first how to do it, supposing I wanted to use that). Occasionally a developer might do that deliberately for some purpose, but I would think it is very rare. So maybe this is down to the device manufacturers and/or their operating systems? |
Hi Guy, This is less of an issue today than it was back in the early days of mobile interfaces, where web devs were quite fond of locking their view on those devices. But the overall lack of usability (for ALL users) saw this fall from favor a few years back. There are still the odd instance of this, but like Success Criterion 2.3.1 Three Flashes or Below Threshold I think that the message has gotten through: devs today, for the most part, are NOT locking down their content (at least by my experience - your milage may vary). |
@johnfoliot I am undeniably focusing on the *Please forgive my use of the word 'clearly' here, since this is an SC that seems to be somewhat less clear than others o_O @guyhickling I am only imagining a case where, for example, a web team has incorrectly used, say..., |
John, I'm not sure that is what is happening, however. Both these threads have been talking about screens that happily load correctly in either orientation, portrait or landscape, but then subsequently re-display wrong after the user changes the orientation. The original complaint that started all this was not that the page was locked (it wasn't) but that redisplay wasn't occurring correctly - content being truncated, overwritten, etc. So there appears to be something else going on here, I think. It looks to me like a hardware fault. |
in the context of "Content..." (which is the subject of the normative wording), not limiting operation means, in simple terms, that controls still work (buttons/links/form controls/etc can still be activated). Operation, at least in my understanding, never referred to the act of actually changing orientation... |
Suggested response for group review: A bug which is triggered when a user changes the orientation of their device not an ideal experience, but not a failure. The subject of the SC is the content, and if refreshing the page enables the view and operation, that would pass. The scope is fairly narrow, a failure would mean the content (e.g. scripts on the page) are preventing content from working in an orientation. The original intent (from the understanding doc) is when "Some users have their devices mounted in a fixed orientation (e.g. on the arm of a power wheelchair)". The SC exists for scenarios where orientation cannot be switched. |
Thank you @patrickhlauke and @alastc. Those statements bring a lot of clarity. This leaves me wondering, however, if SC 1.3.4:
…based on the amount of discussion on the WAI mail thread for this, should:
I suspect fulfilling these—if it was agreed that was desirable,—would not be quick/simple, but both seem worthy of consideration. |
@alastc still want this as "survey ready for"? |
There is an interesting topic which comes from w3c-wai-ig mailing list about Success Criterion 1.3.4: Orientation.
Assuming we have a website that is both working in portrait and in landscape, but for some reason, while switching from one orientation to the other one, its carousels break, resulting not available to anyone (loss of content).
Now, refreshing the page with this new orientation, content is now properly presented to the user.
Is it a WCAG failure or not?
Is the intent of the SC to evaluate the status of the page based on how the device was oriented on page load (both portrait and landscape) or it assumes that dynamic change of orientation while navigating the website must be always supported too?
Might be worth to clarify this point somewhere?
Last, but not least, G214 sufficient techniques says "Using a control to allow access to content in different orientations which is otherwise restricted".
Trying to abstract the concept (we know that sufficient techniques are specific guidance for particular scenarios and cannot cover all the possibilities), even if of course there might be different interpretation, the refresh button provided by the technology (browser in this case), in combination with the author code, can be considered a control that allow users to display the content (carousels in my previous example) on a different orientation?
I agree that this will cause a "loss of focus/loss of entered contents" which might affect more or less multiple users, but users are not prevented to access the website with a specific orientation (and this will affect everyone).
If the intent was to evaluate the orientation on load might be worth to thinking about adding a AAA level criteria that requires content to adapt dynamically after switching orientation (not sure if this will cause problems with adaptive websites).
Thanks,
Giacomo
The text was updated successfully, but these errors were encountered: