Clarification of exemptions for 1.3.4 Orientation

[patrickhlauke]

A refocused/disambiguated version of a point that emerged from the discussion over on #3217

In general, there are two ways a site can fail 1.3.4 Orientation:

• doing an "orientation lock" that forcibly keeps the display of content to a particular orientation - for instance, designing a page specifically for portrait aspect, and if the user has their device/viewport in landscape aspect, display the content but at a 90 degree angle (so that a user would have to tilt their head sideways to read it)
• doing a "doorslam" message that tells the user to rotate their device - the content is not visible/usable, and is blocked from use completely

Now, for the exceptions where "a specific display orientation is essential" ... the current wording of the SC means that in those essential cases, both approaches (keeping it locked to an orientation, and doing a doorslam) are allowed. Is that the intention?

if yes, I would suggest having a best practice piece of advice that clarifies that for essential exceptions, the "orientation lock" approach is preferable to the "doorslam" approach - at least then, users can still read/use the content (with difficulty, as they need to tilt their head)

if no, then we need to specify that the exception is only for orientation lock, and that "doorslam" approaches are never allowed even when it's an essential exception.

[patrickhlauke]

for avoidance of doubt, my preference here would be to say that the "doorslam" is never acceptable, even for essential content, as it completely stops users with a device fixed to a particular orientation (e.g. tablet mounted to a wheelchair) to access the content altogether.

while fundamentally bad, i'd nonetheless settle for at least calling out the practice as rubbish and strongly suggesting a best practice of never using "doorslams" even for essential exemptions.

[alastc]

My paraphrase of the SC would be: "content can be used in either orientation unless an orientation is essential, in which case it can restrict it's view to a single orientation."

That's how I read the 'unless' in the SC text.

However, even if the content is restricted, it should pass other SCs, and the lock-out mechanim could fail on things like consistent navigation. In web-content you should still have a back button, which is not good, but enables recovery to the previous view.

both approaches (keeping it locked to an orientation, and doing a doorslam) are allowed. Is that the intention?

During the development it was difficult to create text that differentiated the methods, so the intent was to prevent these where it was not necessary.

[patrickhlauke]

@alastc

My paraphrase of the SC would be: "content can be used in either orientation unless an orientation is essential, in which case it can restrict it's view to a single orientation."

However, the latter part doesn't quite gel with the normative wording, which doesn't just talk about view, but also operation

"…does not restrict its view and operation…"

(if it just said "view", absolutely with you...but sadly it's not saying just that).

so in practice, what do we want to do? The understanding currently doesn't address this explicitly. The term "restrict" doesn't give many more clues either.

"the intent was to prevent these where it was not necessary"

that's not helpful though, since if they're not necessary (read: essential), then neither orientation lock nor doorslam are allowed anyway. so when it IS necessary to "restrict" the orientation, both approaches are still valid then.

I think since the normative wording does include both "view" and "operation" (and a doorslam is in effect a way to restrict "operation" altogether), we may need to go down the best practice advice route

if yes, I would suggest having a best practice piece of advice that clarifies that for essential exceptions, the "orientation lock" approach is preferable to the "doorslam" approach - at least then, users can still read/use the content (with difficulty, as they need to tilt their head)

[patrickhlauke]

and the lock-out mechanim could fail on things like consistent navigation. In web-content you should still have a back button, which is not good, but enables recovery to the previous view

that seems a tad...stretched as a rationale, i'll admit. goes into those weird discussions of "by virtue of not having the consistent navigation (and effectively being an error page), does this not make the page NOT part of a set of web pages?"

the bit about "should have a back button" seems a bit opinionated (and not documented anywhere)

[alastc]

That was just part of the discussions, the main thing was to have a straightforward (as possible) SC that prevented a reliance on orientation when it wasn't needed. Straightforward often means less granular...

[alastc]

I think since the normative wording does include both "view" and "operation" (and a doorslam is in effect a way to restrict "operation" altogether), we may need to go down the best practice advice route

I think so. I don't think it makes any difference trying to separate view and operation as they are both part of the SC.

[avkuo]

Issue #3217 was closed, this issue seems close-able but @patrickhlauke is this still an issue? Please close if no longer an issue.

[patrickhlauke]

the ambiguity is still there, and would need some clarification in understanding i'd say. i'll have a think about it...

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