Skip to content
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

Open
giacomo-petri opened this issue Nov 9, 2022 · 11 comments

Comments

@giacomo-petri
Copy link
Contributor

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

@awkawk
Copy link
Member

awkawk commented Nov 9, 2022

Not an ideal experience, but not a failure.

@alanfluff
Copy link

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 Refresh (who refreshes if the page is a part filled form?)--continue to provide accessible content; then that webpage passes SC 1.3.4. If a different webpage is poorly coded insomuch as it needs a Refresh or other unexpected/extra step in order to work, then this second webpage should fail SC 1.3.4 since part of its operation (the ability to work in both orientations) has failed.

@johnfoliot
Copy link

johnfoliot commented Nov 9, 2022

@alanfluff sure, except Technique G214 already addresses this:

Applicability
When the orientation of the page is locked, provide a button to allow a user to change the orientation.

Description
The objective of this technique is to allow users to access content in the way the user prefers. A content provider may expect that most users will view content using a specific device orientation or may expect that a user will want to maintain the original view within the device. As a result the provider then prevents the content from rotating. By providing a control to allow the user to rotate the content, someone who needs to use a particular orientation will be able to view the content in a comfortable manner.

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.

@guyhickling
Copy link

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?

@johnfoliot
Copy link

Hi Guy,

How? ScreenOrientation.lock()

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).

@alanfluff
Copy link

@johnfoliot I am undeniably focusing on the SC and not a Technique. But that does not materially change what I noted. While Techniques are part and parcel of WCAG, it seems to me an SC should operate on its own merits. If a page clearly* fails an SC then regardless of Techniques, the page fails.

*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..., meta viewport in head, resulting in the page not reflowing reliably on orientation change. I entirely agree the SC should not be applied when, for example, the device is not operating correctly due to hardware or any level of software from firmware all the way up to browser. If the device, or the browser the user has chosen is at fault, then this SC is not relevant, there are bigger issues to address first : )

@guyhickling
Copy link

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.

@patrickhlauke
Copy link
Member

patrickhlauke commented Nov 10, 2022

Operation, in the context of orientation, reasonably includes either orientation, and that reasonably supposes a user may change orientation.

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...

@alastc
Copy link
Contributor

alastc commented Nov 14, 2022

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.

@alanfluff
Copy link

Thank you @patrickhlauke and @alastc. Those statements bring a lot of clarity.

This leaves me wondering, however, if SC 1.3.4:

…never referred to the act of actually changing orientation...

… exists for scenarios where orientation cannot be switched

…based on the amount of discussion on the WAI mail thread for this, should:

  1. clarifying words be added to the SC 1.3.4 to explain the gist of the above two quotes?
  2. an SC be added to address the issue the originator in the WAI thread referred to - a failure of content to reflow on orientation change, leaving a user having to refresh to return a full useable web page?

I suspect fulfilling these—if it was agreed that was desirable,—would not be quick/simple, but both seem worthy of consideration.

@fstrr
Copy link
Contributor

fstrr commented May 10, 2024

@alastc still want this as "survey ready for"?
@giacomo-petri still need this open or can it be closed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants