Screen, Display, Reflow, Adaptive and Responsive

[jake-abma]

Summary from Alastair:
A detailed discussion about the terminology used in the Orientation SC & understanding doc. Could lead to some updates of the understanding doc.

Jake's original post:

---

This is a issue I'm trying to tackle as techniques for "1.3.4: Orientation" and a new SC for "2.2 SC All functionality available in both orientations" just didn't work out fine.

Reflow is also in scope as the new 2.2 is related to Reflow NOT covering the situation for different content / functionality for landscape portrait.

Here are some thoughts as a reference!

New possible SC for 2.2: https://docs.google.com/document/d/1NEDLUWt_VFKtdHhcgm4j-ssWguSGeY8fhdSxm_41WzU/edit?usp=sharing

Suggestion for adjusting 1.3.4: https://docs.google.com/document/d/1HayJaOYZOoiujJFyWP498wWcVmrZtA3UZFZJIgpQuhw/edit?usp=sharing

The DOORSLAM technique with CSS:

https://raw.githack.com/w3c/wcag/tech-failure-doorslam/techniques/css/tech-ask-reorient-device.html

Example: https://raw.githack.com/w3c/wcag/tech-failure-doorslam/working-examples/css-reorient/

[jake-abma]

Some issues with wording:

1.3.4: Orientation

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

• "restrict its view and operation to a single display orientation, such as portrait or landscape"
  • What is "view" here?
  • What is "display" here? device display OR how the content is displayed?
  • The API talks about "Screen Orientation" NOT Display
  • API only works full screen, probably because of width/height / SCREEN proportions
  • Is it "restricts it's view" OR "LOCK it's view" ?
  • Restricting means you can have different content in Landscape / Portrait but still NOT LOCK it.
  • Difference is Width / Height variable
• Screen orientation is something slightly different than device orientation.
• Screen and device orientation (lock) have a relationship and can affect each other.
• Do we need a definition for: "Display"?
• Do we need a definition for: Viewport?
• Do we need a definition for: Screen?
• See also definition for (display...): "CSS Pixel: A CSS pixel is the canonical unit of measure for all lengths and measurements in CSS. This unit is density-independent, and distinct from actual hardware pixels present in a display."
• We have:
  • Hardware Lock
  • CSS Landscape / Portrait
  • CSS Rotate
  • Javascript width / Height
  • The Screen Orientation API

---

• Doorslam is not locking orientation, it's more a change of context
• Tech control orientation #794 is a proper one though

2.2 All functionality available in both orientations

• All functionality must be available in both landscape and portrait display orientations, unless a specific display orientation is essential.

---

• Doorslam is not locking orientation, it's more a change of context
• New name: "On Orientation"???
• But "On input" and "On focus" is AFTER an action, Doorslam already starts at a specific Orientation AND is AFTER an action...

1.4.10: Reflow

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

• Reflow is for responsive websites
  • It's about: "enlarge text and read it in a single column"
• Reflow is for making sure NO double scrolling happens
• Reflow is ALSO for adaptive websites: no loss of information / functionality OR via controls / direct links
• Shouldn't we not have split this?

---

• BUT, as you change viewport / screen you may go from Landscape to Portrait - Width / Height changes, this is not covered specially but may affect orientation.
• It doesn't say anything about "Change of Context"
• Reflow only mentioned starting viewport width of 1280 CSS pixels wide at 400% zoom, nothing about height which might affect the content
• 320 CSS px is measured for Portrait, 1280 CSS + 400% zoom is for Landscape…?!
• The exception doesn't fit with "loss of information or functionality" => "Except for parts of the content which require two-dimensional layout for usage or meaning."

[jake-abma]

And then the first thoughts via mail:

Hi Alastair / Detlev,

So I've been thinking about Orientation and the doorslam technique and what's not really clear is the real purpose of the SC.

The one I have some trouble with is the difference between Screen and Device orientation and the combination of them.
From the text I'm not sure if we mixed them up a bit.

This one suggests "Device orientation":

"restrict its view and operation to a single display orientation, such as portrait or landscape"

And this one mentioned "Screen orientation":

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

Now my best guess is we only mean Device orientation, and should remove all talks about screen orientation (like with CSS, landscape / portrait).

Otherwise we may end up with a weird blend where you can use them both to mix how the view is presented.

I can think of a Device restriction of landscape and still show content with screen orientation the other way around.

Do you have a clear view on this and must we adjust the Understanding doc to reflect the purpose more clear?

Cheers,
Jake

[jake-abma]

to give a bit more perspective:
​we only focus on device orientation if that is locked (by detecting device orientation)
screen orientation must always follow device orientation
OR
​we only focus on device orientation if that is locked (by detecting device orientation​)
screen orientation can still be in portrait OR landscape and may not be the same as the device orientation (content may still be in wrong orientation although no device locking takes place)

[jake-abma]

Does the SC cover both and so:

Do we need one using the device orientation​ (DeviceOrientationEvent)

AND

One using screen orientation (CSS/Javascript - Width/Height)

[jake-abma]

hereby already a Codepen, will this just be enough for a doorslam technique? (simple CSS work, but pretty stable.)

https://codepen.io/JakeAbma/pen/OYKjYM​

Not used the "The Screen Orientation API" but also not sure how stable it is yet...​

[jake-abma]

Hi Jake,

The SC text doesn’t mention either screen or device, just content.

I’m not really clear what the problem is, where you say:

I can think of a Device restriction of landscape and still show content with screen orientation the other way around.

Maybe that’s what I’m missing, when would display & device orientation differ?

Surely if a device is locked in landscape, the screen will be as well?

Do we need one using the device orientation​ (DeviceOrientationEvent)
AND
One using screen orientation (CSS/Javascript - Width/Height)

Unless the test procedure is markedly different, I think one technique could cover both.

Code examples are good, but in this case it could include two examples:

•      one could use be the code example you did (using CSS/JS calc),
  

•      another example (without code example) that just says “Using a specific scripting event such as DeviceOrientationEvent”
  

If the concept is clear and the testing method is the same, it is just another example of the same thing.

Cheers,

-Alastair

[jake-abma]

Hi Alastair,

If you read the ​SC and Understanding from the perspective of a mobile device, OR laptop / desktop you get results not always compatible.

Take my example and make your viewport width/height different by adjusting your browser.
I can rotate my desktop but that doesn't fix the doorslam.
The text is written for mobile devices, not "fixed" devices. The text is not correct in these cases.

Also I can use DeviceOrientationEvent and CSS styling to the opposite and have not desired results.

So what I'm saying is we can do stuff with DeviceOrientationEvent and by width/height possibilities (CSS), can mix them and have grey area not covered. Also DeviceOrientationEvent​ is not covered greatly yet on all OS/UA levels.

Cheers,
Jake

[jake-abma]

(I do of course understand the SC and intent, but according to the text...:)

"...to a single display orientation, such as portrait or landscape..."

Is this physical display? If yes, my Codepen passes on laptop, because it can be operated, just make your UA narrow enough.

"...Some websites and applications automatically set and restrict the screen to a particular display orientation..."

Is it about the display now, or the screen? And is screen your viewport or your device screen?

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

Clear, so it's about DeviceOrientationEvent AND not screwing with CSS/JavaScript to still get unwanted results.

"...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, thus ensuring that it always match the device display orientation..."​

So, only "hardware-level ability to dynamically adjust default display orientation" fixes / locks are part of this SC? If so, we should remove ALL CSS/Javascript based width/height issues.

[jake-abma]

"The SC text doesn’t mention either screen or device, just content."

Yes, and "to a single display orientation​" => is that the orientation of a display? or the orientation "displayed"?

[jake-abma]

Ok, I didn’t understand that you were talking about non-mobile usage.

In that case, I think the interpretation should be based on the SC text, so it should apply to non-mobile usage (as it’s about the content not the device).

Given that the SC doesn’t require the same content/functionality, I don’t think it’s a reach to ask for no door-slams on any device.

i.e. “a single display orientation” is about how the content is displayed, no necessarily the orientation of the device.

Is it about the display now, or the screen? And is screen your viewport or your device screen?

It is the display of the content, which may or may not be aligned with the device.

So, only "hardware-level ability to dynamically adjust default display orientation" fixes / locks are part of this SC?

No, but that is a sub-set of the methods for preventing usage in other orientations.

If you’ve time to put together a PR to update the understanding doc, it would be appreciated…

If not that’s ready to become an issue.

Cheers,

-Alastair

[jake-abma]

ok, thanks, we will need to be clear on this indeed.

An update to the Understanding is on the list

I really would like to see (as well as many, many others) a "what it is / isn't" as mentioned in https://github.com/w3c/wcag/issues/744​

This would really help many people understand the details better

Cheers!

[jake-abma]

just one more thing:

"i.e. “a single display orientation” is about how the content is displayed, no necessarily the orientation of the device.""

The intent starts with:

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

So I says the orientation of the device AND how the content is displayed matters.

Or do we allow the loophole of "Showing content in portrait when in landscape and vice versa"? (doesn't restrict single... :-) )

[jake-abma]

"i.e. “a single display orientation” is about how the content is displayed, no necessarily the orientation of the device.""

The intent starts with:
"The intent of this Success Criterion is to ensure that content displays in the orientation (portrait or landscape) preferred by the user.""
So I says the orientation of the device AND how the content is displayed matters.

The ‘orientation preferred by the user’ could apply to a device, the devices screen, or a browser window.

“Displays” as a verb does not require a “display” (as a noun), if that’s where the confusion comes from?

-Alastair

[mraccess77]

If a device is in landscape but the content appears the correct direction but in a portrait width and can be operated I'd say the SC passed but the content is not restricting display of content in that orientation -- it'st just not maximizing the available space.

[alastc]

Hi Jake,

Overall, I wonder if you have been coding so much that certain words have taken the programming meaning rather than the standard English meaning??

What is "view" here?

I read that as ability to see the ability to view it, to access the content. (Not "view" in the sense of programming, where a view is a set of features available at one time.)

What is "display" here? device display OR how the content is displayed?

The phrase is "a single display orientation", is qualified by "such as portrait or landscape", and the whole thing starts with "Content does not...". Therefore, the object is the content and display-orientation means portrait/landscape(/other).

The API talks about…

What API? Apart from the technique, we shouldn’t be using API/technology specific language in the SC.

Is it "restricts it's view" OR "LOCK it's view" ?

Using “restrict” means that it covers both lock (i.e. going sideways when you rotate the device) AND hiding the content behind a door slam. But it does not cover (as you point out) changing content based on orientation.

Difference is Width / Height variable

I see that as one mechanism for working out orientation, but the normative SC shouldn’t try to differentiate mechanisms directly.

Do we need a definition for: Display / viewport / screen?

Only ‘display’ is referenced in the SC text, and we intended the standard English meaning of to present something so it can be seen. It is modified by “orientation”, so I think it’s specific enough.

We have: Hardware Lock, CSS Landscape / Portrait, CSS Rotate, Javascript width / Height, The Screen Orientation API

Indeed, these are all mechanisms, but not things we should refer to directly in the SC, they are technology specific.

Doorslam is not locking orientation, it's more a change of context (content?)

That is an interesting nuance, I have to admit I hadn’t consider the message “please turn your device” to be content, but we didn’t draw a line as such.

I think we could tackle that in the understanding. As there are no controls, and the content is hidden, I think that qualifies as ‘restricted’. Whereas changing the content / features whilst allowing people to use it does not count as restricted.

Reflow is for responsive websites

I’m not sure where you were going with that section, there are a lot of statements but I’m not sure what the issue is. I can’t work out what you thought should be split.

BUT, as you change viewport / screen you may go from Landscape to Portrait - Width / Height changes, this is not covered specially but may affect orientation.

Again, I can’t tell what you are aiming it. If you zoom-in (only) that doesn’t affect orientation, even with width/height ratio calculations, the ratio is maintained.

Now my best guess is we only mean Device orientation, and should remove all talks about screen orientation (like with CSS, landscape / portrait).

I think we mean “display orientation”, as the least technology-specific version.

Does the SC cover both and so:
Do we need one using the device orientation (DeviceOrientationEvent)
AND
One using screen orientation (CSS/Javascript - Width/Height)

I think those are both good techniques, one CSS (primarily) and one JS. Two mechanisms, one effect. They could be two examples within one technique as well, although I’m not sure where we’d put that!?

The text is written for mobile devices, not "fixed" devices. The text is not correct in these cases.

The SC text is written for the content, that is the object in the SC. Therefore you can get different results on different devices, but what matters is what the content is trying to do.

E.g. you might never find the doorslam on a laptop if the JS uses the API to detect portrait usage. However, that would still be a failure, the content does try to doorslam.
(And thinking about it, we should update the Understanding doc if it doesn’t mention that aspect!)

[jake-abma]

@alastc , will be back on all questions/answers, but would like to pick up some parts already as I'm working on the Dutch translation.

Right now I see the first draft is translating "display" as a "physical screen position".
It seems more people interpret this as the "device display" (not content) and this was the basis for my question:

What is "display" here? device display OR how the content is displayed?

The phrase is "a single display orientation", is qualified by "such as portrait or landscape", and the whole thing starts with "Content does not...". Therefore, the object is the content and display-orientation means portrait/landscape(/other).

Now according to your reaction I read it's only about the "display of the content"and has nothing to do with the physical device position (of the screen).

Please affirm this so we can add this to the translation in the proper way.

Cheers!

[jake-abma]

Interestingly your explanation of display ("present something so it can be seen") is not the way also other people read it and causes confusion. Clear definitions and how we use them might still be good to consider. referring to:

Do we need a definition for: Display / viewport / screen?

Only ‘display’ is referenced in the SC text, and we intended the standard English meaning of to present something so it can be seen. It is modified by “orientation”, so I think it’s specific enough.

See how the sentence is translated (loosely) with emphasis on display as physical, not "something so it can be seen".

ORIGINAL:

Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.

TRANSLATION:

De weergave en bediening van content is niet beperkt tot een enkele schermstand, zoals staand of liggend, tenzij een specifieke schermstand essentieel is.

TRANSLATE BACK TO ENGLISH (Previous / Loose):

The display and operation of content is not limited to a single screen position, such as portrait or landscape, unless a specific screen position is essential.

UPDATED LOOSE TRANSLATION (BY ME):

The content does not restrict the display and operation to a single presentation orientation, such as portrait or landscape, unless a specific orientation presentation is essential.

[jake-abma]

I'm not sure if we shouldn't make a difference between a hardware sensor and a software check for width/height. They can be contradictory to each other on the same device and thus are not equal in the results.

Difference is Width / Height variable

I see that as one mechanism for working out orientation, but the normative SC shouldn’t try to differentiate mechanisms directly.

[jake-abma]

When thinking this one through you might end up with a different perspective on making a case for the difference between restrict and lock:

Doorslam is not locking orientation, it's more a change of context (content?)

That is an interesting nuance, I have to admit I hadn’t consider the message “please turn your device” to be content, but we didn’t draw a line as such.

---

Is it "restricts it's view" OR "LOCK it's view" ?

Using “restrict” means that it covers both lock (i.e. going sideways when you rotate the device) AND hiding the content behind a door slam. But it does not cover (as you point out) changing content based on orientation.

[jake-abma]

Last comments from Survey:

Still not sure Doorslam belongs at orientation, lots of questions, specially when looking at first paragraph at intent.

Need more time to summarise my issues again, but here already a short reaction:

---

"Some websites and applications automatically set and restrict the screen to a particular display orientation..."

At the Doorslam the screen is NOT set to a particular display orientation and restricted, both are shown in landscape or portrait according to the device orientation OR width / height ratio variable. So the content is not shown in landscape on portrait device orientation.

---

"Therefore, websites and applications need to support both orientations by not restricting the orientation."

The Doorslam supports both orientations, only not for each content block, the restriction is not orientation but the content is restricted for a specific device orientation OR width / height ratio variable.

---

"Changes in content or functionality due to the size of display are not covered by this criteria which is focused on restrictions of orientation."

What is the "size of display" here? because the Doorslam does exactly that, change the content (and thus restrict one of the content blocks to show)

---

"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, thus ensuring that it always match the device display orientation.""

Now we start with "hardware-level ability / sensor information" and NOT width/height ratio (may conflict). But "ensuring that it always match the device display orientation" is exactly what we NOT want.

---

"Alternatively, where a device-level orientation lock is not in place, the user agent should display the page according to the orientation of the device (either its default, or the current orientation determined by any device sensors).""

This is not true for a device in landscape where the UA size is portrait (as can be seen / tested on your desktop with a small browser window).

[patrickhlauke]

At the Doorslam the screen is NOT set to a particular display orientation and restricted

the page is "restricted" in the sense that the actualy page content is simply hidden/removed from the user, and a "sucks to be you / rotate your screen" message is shown

because the Doorslam does exactly that, change the content (and thus restrict one of the content blocks to show)

yes, i guess there's a certain nuance here. it might need further language about changing content simply to a non-functional, non-interactive warning message...