Does 1.3.4 Orientation apply to parts of a page or screen?

[mitchellevan]

Understanding 1.3.4 currently says:

The intent of this Success Criterion is to ensure that content displays in the orientation (portrait or landscape) preferred by the user.

Does this only apply to whole pages and screens, or can some content in a page pass while other content in the same page fails?

F100 only gives the example of a whole screen or page failing, and I don't see any other examples or prose that would answer this question clearly.

Example of some content passing and some content potentially failing 1.3.4: The iOS calculator app provides its scientific functions in landscape view only. Video of the iPhone calculator in portrait and landscape views (YouTube)

Unlike the essential exception example of a piano keyboard, it would be quite feasible for the app to offer users a third calculator layout on request, like the physical button layout of most hardware scientific calculators (Google Image Search).

[JAWS-test]

I think the SC is not only about the whole page, but also about individual page sections. Reduced functionality in the one orientation would also be a violation of the SC

[alastc]

The SC text start with " Content does not restrict its view", so applies to all content within a page.

Given that WCAG 2.x conformance is pass/failed at the page level, it doesn't make any difference. However, if you wish to build on that and report on instances within a page, that's entirely up to you.

[jake-abma]

Hi @mitchellevan the example given for the iPhone is about a whole view / screen, not only a part.

The example given in the Understanding, F97 basically / possibly has a same structure (for HTML...)
==corrected link== https://www.w3.org/WAI/WCAG21/Techniques/failures/F100

There are two 'containers' and only one is shown at a time depending on the orientation.

In the example given (https://www.w3.org/WAI/WCAG21/working-examples/failure-orientation-message/) the only difference is that in one container sits the content, in the other only a text with "Please rotate your device!"

It is surely possible to add the calculator in one 'container' and the calculator on steroids in the 'other container'.

[awkawk]

@jake-abma I agree that it applies to the whole page, but if 50% of a whole page is not rotating and 50% is then the user does not have access to 100% of the content anymore, so I think that this would trigger a failure.

@mitchellevan are you asking about a situation where a portion of the content doesn't rotate or when the landscape view offers different or additional functionality from the portrait view?

[jake-abma]

@awkawk wrote:

but if 50% of a whole page is not rotating and 50% is then the user does not have access to 100% of the content anymore, so I think that this would trigger a failure.

Yes, surely fails

[mitchellevan]

@awkawk:

are you asking about a situation where a portion of the content doesn't rotate or when the landscape view offers different or additional functionality from the portrait view?

The latter. I'm asking about the case where landscape offers content or functionality that's not available in portrait.

Equally we could talk about content in portrait not available in landscape. The distinction should be trivial, unless one considers "already covered in 1.4.10 Reflow" to be a factor in 1.3.4 conformance. (I don't, but some might.)

[patrickhlauke]

I seem to remember that the main concern of 1.3.4 Orientation was, initially, to avoid those "please turn your phone to portrait" type door-slam screens. Aspects of "what if there is no door-slam, but content is different/incomplete" were only raised later on, as it was tacitly assumed originally that a page would not omit content from one orientation to the other.

(to be clear, i completely agree that it's pointless saying "ok, this passes because it doesn't door-slam the user, but ... unless they re-orient their device/screen, they simply won't get to the same content/functionality")

1.4.4 Resize text, 1.4.10 Reflow, 1.4.12 Text spacing explicitly contain "without loss of information or functionality" / "without loss of contnet or functionality" in their normative wording. Wondering if this should also be crowbarred into 1.3.4 Orientation normative wording (or, at the very least, explained in a note or in understanding, that this is implied)

(and to be clear, as with 1.4.4, 1.4.10, 1.4.12 it's not necessarily that a page can't have slightly different ordering of content/functionality, or even do things like shuffle content/functionality onto separate pages/sub-pages/disclosure widgets/etc in different viewport sizes/metrics/etc, but that overall users must still be able to somehow get to the same content/functionality even if not on that same page ... at least that's my understanding of it)

additionally, while to an extent I can see the argument of "1.4.10 Reflow covers this", that's not quite accurate because a site can potentially use cues other than viewport dimensions (such as the experimental screen orientation API, deviceorientation events, or some JS/CSS based orientation check) to decide whether or not to door-slam or omit content - so a page can potentially pass 1.4.10 while also still omitting content/functionality on an actual orientation change/when the device is in the "wrong" orientation

[mraccess77]

Patrick is correct the requirement was written to address situations where the view was restricted and not to ensure equivalent content or functionality. The idea is that future criteria would be written to address functional equivalents but I am not aware of that being addressed at this time.

[jake-abma]

if functionality is the question, we probably talk about another variation, which is covered with reflow (?!)

[goodwitch]

I thought that if important info/functionality (that does not meet the 1.3.4 Orientation exception) disappears (is not available) in portrait or landscape, that it would still need to be available somewhere...or it would fail 5. Conformance - https://www.w3.org/TR/WCAG21/#conformance Imagine if a closed caption button is only available in landscape but not portrait. Would y'all seriously say that passes WCAG? G *glenda sims* ***@***.***>, cpwa <https://www.accessibilityassociation.org/certification> | team a11y lead | 512.963.3773 deque systems <http://www.deque.com> accessibility for good Build more accessible experiences. Start your axe DevTools Pro trial today. <https://axe.deque.com/plans?utm_source=signature&utm_medium=email>

…

On Wed, Apr 14, 2021 at 9:57 AM Jake Abma ***@***.***> wrote: if functionality is the question, we probably talk about another variation, which is covered with reflow (?!) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1725 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6S4WWHYTTZ3Z6CAYXHPYLTIWUPBANCNFSM42QPH3YA> .

[patrickhlauke]

that was my immediate thought as well, however if you're thinking of the new note that was added for 5.2.2 Full pages

New A full page includes each variation of the page that is automatically presented by the page for various screen sizes (e.g. variations in a responsive Web page). Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform.

this doesn't actually say anything specific about each variation having the same content/functionality somehow. just that it needs to be conformant/accessible.

[patrickhlauke]

if functionality is the question, we probably talk about another variation, which is covered with reflow (?!)

reflow and orientation can be different though (depending on the technology used to detect/lock the orientation), so can't rely on one to cover the gap in the other

[mitchellevan]

This healthy discussion demonstrates that currently the supporting docs don't clearly answer my original question:

Does this only apply to whole pages and screens, or can some content in a page pass while other content in the same page fails?

So based on the discussion here and the normative text of 1.3.4, I propose the following edits to Understanding Success Criterion 1.3.4: Orientation.

The intent of this Success Criterion is to ensure that content displays in the orientation (portrait or landscape) preferred by the user. Some websites and applications automatically set and restrict the screen to a particular display orientation and expect that users will respond by rotating their device to match, but this can create problems. Some users have their devices mounted in a fixed orientation (e.g. on the arm of a power wheelchair). Therefore, websites and applications need to support both orientations by not restricting the orientation. Changes in content or functionality due to the size of display are not covered by this criterion which is focused on restrictions of orientation.[moved below]

Historically, devices tended to have a fixed-orientation display, and all content was created to match that display orientation. Today, most handhelds and many other devices (e.g., monitors) have a hardware-level ability to dynamically adjust default display orientation based on sensor information. The goal of this Success Criterion is that authors should never restrict content's orientation, limit the user's ability to view and operate content to only one of the available thus ensuring that it always match the device display orientations.

For example, this Success Criterion fails if an author suppresses the rotation of content when the display is rotated. Another example of a failure of this Success Criterion is omitting all or part of a page when the display is rotated. However, changes in content or functionality due to the size of display are not covered by this criterion, which is focused on restrictions of changes due to the display orientation.

Initially I was going to add just the failure examples. Then I noticed that the supporting text had subtly diverged from the normative text. The normative text does not only require correct orientation of content; it actually says that content must be viewable and operable regardless of device orientation.

I'm aware that this edit will cause some content to fail which some auditors have previously passed, but the change is slight. Door slams and failures to rotate have always clearly failed this criterion. Most missing or inoperable content is already caught by 1.4.4 Resize Text and 1.4.10 Reflow. Now following the letter and spirit of 1.3.4 more closely, we're adding the rather rare case of missing or inoperable content caused solely by display orientation (and not falling under the essential exception).

[patrickhlauke]

If this change is made, I do think that a much larger explanation needs to be provided somewhere that also clearly explains it's fine if content, at certain screen sizes/orientations/etc is refactored into separate pages, as long as overall a user can still get to the same content/functionality (just that where space is tight, this may have been moved to what would nominally count as a completely different URI / sample). otherwise, I can see overzealous auditors failing a lot of very sensible and common patterns

[patrickhlauke]

oh, but for clarity, i do agree that a strict reading of the normative text of the SC does indeed track with @mitchellevan 's reading that it also covers content/functionality being dropped/only being available at a particular orientation

[fstrr]

This issue is labelled as a discussion, so we’re moving this to Discussions. There doesn’t seem to be an update to make to the documentation, but if that changes, we can move it back to the issues list.

[mitchellevan]

There doesn’t seem to be an update to make to the documentation, but if that changes, we can move it back to the issues list.

In my 2021-04-22 comment I proposed a specific change to documentation. I request that the Working Group please review this proposed change, thanks!