Signed up as SC Manager

This seems to be a sentence fragment:

While the order of content and method of functionality may have differences such as exposed by a widget that expands or collapses or discloses content and functionality differently than another view.

I'd like some more verbiage around what constitutes "essential". For instance, would you consider the phone numeric keypad interface to fail on iOS because it cannot rotate to landscape? Or is the fact a design is made to fit a single orientation a sufficient argument? Or is the fact the UI is defined as a standard (ITU E 1.161) that cannot fit in landscape sufficient? Given your chequing example, it seems like conventional designs the only fit one orientation forms at least one argument of essential. What others are there? I'd like some examples of a failure as well, for clarity.

some typos and style issues: "e.g." should be "e.g.," ; " keyobard" should be "keyboard"
Also, not sure what you mean by "check deposit"

Note: the content does not need to be in the same order for different orientation. It does need to meet SC 1.3.2 and SC 2.4.3 and be in a meaningful sequence.

This sentence gave me pause. Shouldn't it be in the same order for focus and for meaningful sequence? Just because the line break alters, doesn't the order get retained?
In situations where it is not possible to maintain focus and meaningful sequence when changing orientation, I think that might constitute an example of essential.
Or is this intended to allow teams to redesign a UI to fit the other orientation? I think a notification that such a thing is going to occur may be necessary, at the least. Interesting...
Finally, I think you will need some provisos (or at least considerations) for Consistent Navigation.

some typos and style issues: "e.g." should be "e.g.," ; " keyobard" should be "keyboard"
Also, not sure what you mean by "check deposit"

I don't seem to have access to edit the text here, but noted - and will check and correct prior to submitting.

"Check deposit" is referring to a function in the banking app that allows the user to deposit a check to their account - typically by taking a picture of the check and adding in amount information.

This seems to be a sentence fragment:

While the order of content and method of functionality may have differences such as exposed by a widget that expands or collapses or discloses content and functionality differently than another view.

@mraccess77 Do you recall what the above sentence was getting at? I looked through the edit history and came up with this correction. Does this work?

"While the order of content and method of functionality may have differences, such as being exposed by a widget that expands or collapses, or disclosing content and functionality differently than another view, the same content and functionality is available."

Also - could it just be pared down simply to:

"While the order of content and method of functionality may have differences the content and functionality is available."

Thoughts?

@marcjohlic "While the order of content and method of functionality may have differences the content and functionality is available." sounds good to me.

@mbgower regarding the bit about differences in content and functionality -- the intention was to allow for hamburger menus and other functionality such as hide and show buttons, etc.
Regarding consistency -- the above would not allow for consistency between orientations -- but I agree consistency within a single orientation is needed. I think that is covered or should be covered by another SC.
Regarding alerting the user of the change I believe that is also covered under another proposed SC. #2

Looks ok for a first draft to solicit public response. When I presented this at Toronto A11y camp, Mike Paciello asked what kind of studies had been conducted. I said objectively a person without arm dexterity with a mounted device on a wheelchair cannot change orientations.

Since this is an authoring guide, maybe it is an understood subtext, but of course on an ipad, the device provides the user the ability to physically lock the orientation of the screen, and an OS may afford the user that ability globally via settings. Do we need any language to support these "exceptions"? Could be as simple as modifying from "Content is not locked to..." to "Authors do not lock content to..."

@DavidMacDonald I understand that authors may choose to condense/expand some content based on orientation, however I'm not convinced that can't be done while maintaining the same reading and navigation sequences. Certainly many, many apps successfully do that right now.
Giving authors a pass on some pretty critical elements of WCAG doesn't seem like the best tactic. A simple message "Altering content to fit screen" etc., could satisfy predictability requirements where a compliant reflow is not possible or optimal. That way I understand as a user that changing the orientation is altering the content.
In regard for this notification being covered by candidate #2 , I would argue that the notification for orientation changes is operating system based, and I suspect provided directly to the AT regardless of the author. In example, on iOS and Android, with VoiceOver and TalkBack operating, the screen reader announces changes in orientation. I don't believe the author should be involved in that process.
What authors can do is pick up on that notification from the OS and choose to display a message about content modifications if they have altered 1.3.2 or 2.4.3

I agree there's a serious problem regarding what "essential" means here. Would it involve similar cases to those in which layout is essential for purposes of the requirement to enable enlargement without horizontal scrolling discussed elsewhere?

Is it possible to lock web-content into a particular orientation? I thought that would be at the browser/OS level? I.e. not an author thing.

Or are we expanding WCAG to cover mobile apps, in which case isn't that quite a big change in scope?

There is some level of support for locking the orientation for web content
https://developer.mozilla.org/en-US/docs/Web/API/CSS_Object_Model/Managing_screen_orientation
So the concern about native apps is moot in my opinion. If it's possible to do in web and also applies to native apps then all the better to have this SC.

Fair enough, concern withdrawn.

An example of essential might be for a billiards game or taking a photo of a check for deposit.

@mbgower wrote " Do we need any language to support these "exceptions"? Could be as simple as modifying from "Content is not locked to..." to "Authors do not lock content to...".

I don't think we need an exception or to add "authors do not...". The issue you bring up would be the same issue for other SC. The content isn't blocking the change the user is in the case of the orientation lock -- so the content passes. Similarly, the user can disable scripting and then a givn page may fail SC 4.1.2 or SC 2.1.1 -- but it's not the content that is failing. Adding the word "author" confuses the situation as some content may be generated and not author created.

@marcjohlic Can you please give me a status update on this one? Are we near a PR for WG review or do you need more time?

I haven't seen anything that addresses my suggestions about notifications when content is modified (not just a reflow) due to Orientation changes, which I posted 20 days ago.

Personally, I thought this SC's scope was limited purely to the "don't lock down content to only operate in a specific orientation", rather than tackling any further aspects such as reading/focus order or notification of change.

While operating systems provide functionality that allows users to stop a device from flipping between portrait/landscape modes, I don't think there's an equivalent opposite - allowing users to force orientation (e.g. somehow force something that is locked down by author to be in portrait to display in landscape)...and this is the aspect where an author needs to account for it, since brute-force "portrait in landscape"/"landscape in portrait" would, without change on the content's side itself, result in letterboxing/black bars.

I thought this SC's scope was limited purely to the "don't lock down content to only operate in a specific orientation", rather than tackling any further aspects such as reading/focus order or notification of change.

@patrickhlauke, there are two statements in the SC that are relevant.
This sentence fragment, which needs to be completed for us to understand what it means...

While the order of content and method of functionality may have differences such as exposed by a widget that expands or collapses or discloses content and functionality differently than another view.

...and this statement, which on the one hand states that meaningful sequence needs to be persistent, but also says order can change.

Note: the content does not need to be in the same order for different orientation. It does need to meet SC 1.3.2 and SC 2.4.3 and be in a meaningful sequence.

I've suggested that if reorienting causes content to be altered, a notification should be displayed by the author when orientation changes, similar to On Input requirement. This warning is for COGA and other considerations; the notification could have an affordance to be dismissed and not reappear after the first time.

Note: the content does not need to be in the same order for different orientation. It does need to meet SC 1.3.2 and SC 2.4.3 and be in a meaningful sequence.

this means that the order of content can differ between the different views (portrait/landscape), but that overall it needs to still be meaningful and the focus order still needs to be logical within the same view.

While the order of content and method of functionality may have differences such as exposed by a widget that expands or collapses or discloses content and functionality differently than another view.

that indeed seems to be a leftover sentence from a previous iteration, left dangling. I believe the intent was to express what I just wrote above, i.e. "While the order ... may have differences, this is irrelevant for this SC (but it still needs to follow 1.3.2 and 2.4.3 for that view)"

This still doesn't make me think that this SC needs to deal with notification (this would be, ideally, done by a separate SC such as #2

#2 is met by the OS, which creates a programmatic notification when landscape alters. But I don't expect a change in orientation to actually change the context on the page by default -- just reflow it.

What I'm saying is that if you as an author alter the material displayed when the orientation changes, you should be notifying the user of that, just like in On Input. If it is just a reflow, that's okay, but if displayed information is suddenly dumped into a menu, or otherwise altered, don't you think a notification should be made?
From the definition of Change of Context

significantly re-arranging the content of a page are examples of changes of context

@mbgower i understand what you're saying, but I contend that that goes beyond the fairly tight scope of this proposed SC "Content is not locked to a specific orientation, and functionality of the content is operable in all orientations, except where orientation is essential for use of the content."

What I'm saying is that if you as an author alter the material displayed when the orientation changes, you should be notifying the user of that, just like in On Input

sure, but that's orthogonal to this SC.

are you proposing expand the intended scope of this SC to cover other things, such as notifications?

I'm gong to take a final bash to describe my concern with this.
We currently have an SC that captures changes in content, On Input.

3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)

My first thought was that On Input could capture the issue of a user having content change due to a reorientation. However, it is specific to "changing the setting of any user interface component". Clearly, turning your phone sideways does not apply.

Due to some of the language I've previously pointed out, this SC, which tells authors they cannot force an orientation (good!), is also giving them license to alter the content without notifying the user (bad!). I think that is a problem and is guaranteed to increase cognitive load. It either needs to be addressed by removing the text saying 'it's okay to change content' or it needs to add in a warning tell them not to alter content without notifying the user.

Issue #2 does not address this because of its restrictions.

Another option is to write a new SC that captures alteration based on other inputs than 3.2.2 specifies. I think until that surfaces this SC must tackle it, or at the very least the FPWD should flag that this issue is unresolved and invite comment.

@kwahlbin can you please edit the original "Description" of this SC and replace:

While the order of content and method of functionality may have differences such as exposed by a widget that expands or collapses or discloses content and functionality differently than another view.

with

While the order of content and method of functionality may have differences the content and functionality is available.

for easier reading. This change was approved on Jan 16th in the comments above.
Thanks

@marcjohlic I made the edit

PR #140 has been created for this proposed SC.

It is noted that there is an ongoing discussion in the comments above about whether a Note should be appended to this SC stating that authors must notify users when a change in orientation would cause a change in content (for example a navbar in portrait mode may be changed to a hamburger menu in landscape mode). Decision was that this SC could go to survey as submitted and the discussion on the Note could continue in survey or FPWD comments.

@kwahlbin @joshueoconnor @awkawk

Updated the issue description to reflect the FPWD text.

Public comments
#265, #235, #193

Suggest rewording to tight it up, so it doesn't require it to work when orientation is changed AFTER page load. Addressing comment #235

The content is operable in the device orientation that is used to load the web page, except where orientation is essential for use of the content.

@nschonni asked a great question at the accessibility Summit Ottawa where I presented possible new SCs ... Is this not covered in the Resize Content SC. #77

I don't think so. Certainly being able to resize content means that content will work at different sizes, which helps it to work in both landscape/portrait. However, that isn't the same as locking orientation to one or the other.

Hey @nschonni would you like to comment on Alastair's response?

@marcjohlic @kwahlbin @patrickhlauke
Just for reference - use case of content forcing a particular orientation (here, landscape):
https://www.e-visio.de/
Call up site, then reduce viewport width to the point where it is smaller than viewport height, and see what happens.

There was fairly detailed discussion on the mailing list where I tried to address several issues with the current version of this SC. Rather than repeat all that here, I just wanted to reference it to be discussed later, and paste in my proposed wording:

A mechanism is available to view content in all display orientations without loss of essential content or functionality, except where the display orientation is fixed by the user agent or is essential for usage or meaning.

@steverep Not happy with the resulting wording you're proposing. To me it has lost the essential point trying to be addressed here, which is "Don't force the user into a orientation unless there is a requirement to do so"

The existing wording seems fine to me, except it could use a removal of a comma to make the exception apply to both factors:

Content is not locked to a specific orientation and functionality of the content is operable in all orientations, except where orientation is essential for use of the content.

I think Alex's concerns about VR headsets are clearly captured by the exception, and can be spelled out in the Understanding doc. As can be the notion that this is targetted primarily at mobile form factors where sensors in the device can call on the OS to rotate the content based on user orientation. Also very easy to spell out in the Understanding doc that this is not intended to prevent Personalization settings at the hardware or software level that allow a user to lock presentation to a specific orientation. it is entirely meant to ensure authors do not unilaterally impose an orientation on the user.

BTW, I'm okay if folks want to reword to capture David's point that we make this an on-load provision.
i think not responding to user orientation of the device is not a great design chocie, but in the scenarios I'm aware of, the big accessibility issue is the app not starting in the same orientation as the user.

@mbgower wrote:

To me it has lost the essential point trying to be addressed here, which is "Don't force the user into a orientation unless there is a requirement to do so"

Flipping your statement around from negative to positive results in just saying "let the user pick their desired orientation", which is exactly what my version says so I don't see how it misses the essential point.

Locking is not the user problem; it is the primary technique that causes the user's problem of not being able to use the orientation they want. In fact, it's ironic because these users might benefit from locking as long as it's in that desired orientation. I've explained it extensively on the mailing list.

Let's take an example that addresses both @jasonjgw's valid scenario, and demonstrates why my proposal is actually a stronger criterion for the user. Say I create a game that needs to be played in locked orientation, because of the option of movement as input or played with 2 players with the device laid flat.

• With the current version, the exception would have to be loosely invoked resulting in zero benefit to the user. So, the author could just lock it to landscape and pass, so someone with a portrait mount would have a lot of difficulty.
• In my proposal, we could say that the only way that the orientation is "essential" is if that game would simply not make sense if rotated or has some physical restriction like using the compass, a much stronger criterion. Then, the author could do the following to pass with full accessibility to both portrait or landscape users:
  1. Query the current device orientation on load, and display the content in that orientation, but lock it.
  2. Provide a setting during play that allows the user to click a button and rotate the view, but always remaining locked via the screen orientation API.

Finally, the criterion has no provision for when the device or OS does not support both orientations, or only supports it manually (e.g. no sensor). It's left up to the reader to understand we're only talking about when the content has code to lock it, and not when the locking is controlled by the user agent, which is unlike other criteria which do consider that possibility.

@steverep, first I'm failing to understand a real difference between

is essential for usage or meaning

and

is essential for use of the content

Both are pretty much the same exception, are they not? I don't see any big benefit to including "meaning", but I also can't offhand think of any big issue, so for the sake of argument, let's assume "is essential for usage or meaning" is used in both proposals and focus on the other, more problematic part.

I think there is a clear history (even within the 2.1 issue threads) that the whole "mechanism" language has created as much confusion as it has benefit. If Average Programmer is writing an app and comes across this provision about providing a mechanism for orientation, is there a strong possibility s/he reads this as a need to author an affordance to allow the user to switch orientation?

That's a very different message from saying to the author 'don't lock the orientation just because you can't be bothered to design a malleable app', which I'm 90% sure is what the Mobile task force was keen on saying.

Finally, the criterion has no provision for when the device or OS does not support both orientations, or only supports it manually (e.g. no sensor). It's left up to the reader to understand we're only talking about when the content has code to lock it, and not when the locking is controlled by the user agent, which is unlike other criteria which do consider that possibility.

I admit to being unsure which wording you're critiquing. This paragraph seems to be a good argument for the original language. What the hardware supports is irrelevant to this SC. If the hardware only supports one orientation and the author has not locked the orientation, there is no problem, right?

BTW, I don't understand why orientation of a compass would matter in regard to landscape/portrait. It obviously wouldn't be very useful to tilt a compass perpendicular to the north pole but that is not the "orientation" being addressed here.

In fact, it's ironic because these users might benefit from locking as long as it's in that desired orientation.

This is part and parcel of @jasonjgw 's concern about personalization. I think if we're going to start trying to cover personalization scenarios in the SCs themselves, a whole lot of them are going to have to be overhauled. I'm not adverse to including an exception for user request, but I really think there should be a better global way of acknowledging that providing an affordance to support user preferences is a good thing (and that the results may be antithetical to any stated SC goal) without cluttering the SC language with it.
In example, " Audio description is provided for all prerecorded video content in synchronized media" doesn't specify that a user can turn the descriptions off, but that's obviously a desirable feature for many users.

@mbgower, a very late reply...

first I'm failing to understand a real difference between "is essential for usage or meaning" and "is essential for use of the content". Both are pretty much the same exception, are they not?

Yes, they are. I was not drawing a distinction between that language, but rather what is being exempted. Currently the exemption is for lacking the content, whereas my proposal exempts being able to view in either orientation. There are many less reasons for the latter since you'd have to make a case that the content would not make sense if simply rotated and shrunk to fit the opposite aspect ratio.

BTW, I don't understand why orientation of a compass would matter in regard to landscape/portrait. It obviously wouldn't be very useful to tilt a compass perpendicular to the north pole but that is not the "orientation" being addressed here.

Where is it dictated that the portrait or landscape display orientations need to be aligned somehow with the direction of gravity? Portrait or landscape are only distinguished by the difference in aspect ratio as aligned with my line of sight. A compass app matters because rotating the same content doesn't make sense unless the needle rotates back to north.

I think there is a clear history (even within the 2.1 issue threads) that the whole "mechanism" language has created as much confusion as it has benefit.

Maybe so, but that's a generic WCAG issue not related to why I'm proposing a change, and we've got multiple other new SC using it too.