This repository has been archived by the owner. It is now read-only.

Orientation #70

Closed
kwahlbin opened this Issue Nov 29, 2016 · 49 comments

Comments

Projects
None yet
@kwahlbin
Contributor

kwahlbin commented Nov 29, 2016

Current versions of SC and Definitions

SC Shortname

Orientation

SC Text

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.

Suggestion for Priority Level (A/AA/AAA)

Level AA

Related Glossary additions or changes

Orientation: portrait or landscape mode of the display
See the CSS Device Adaptation Module Level 1, the "orientation" descriptor [css-device-adapt-1].

What Principle and Guideline the SC falls within.

Principle 2: Operable

New Guideline: Make content usable in device orientations.

Description

Some mobile applications automatically set the screen to a particular display orientation (landscape or portrait) and expect that users will respond by rotating the mobile device to match. However, some users have their mobile devices mounted in a fixed orientation (e.g. on the arm of a power wheelchair). Therefore, mobile applications need to support both orientations by making sure content and functionality is available in each orientation. While the order of content and method of functionality may have differences the content and functionality is available. When a particular orientation is essential, the user needs to be advised of the orientation requirements.

Examples of problems

Banking website locked in portrait mode
iOS home screen on the iPhone vs. iPad

Benefits

Users with dexterity impairments, who have a mounted mobile device will be able to use the content in their fixed orientation

Testability

  • Turn the device into portrait orientation.
  • Turn the device into landscape orientation
  • Check all content and functionality is available in both orientations.

In situations where an on-screen keyboard may be used, the on-screen keyobard should be displayed to ensure that content and functionality is not blocked in different orientations.

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.

Techniques

Technique: Using CSS to set the orientation to allow both landscape and portrait.

Technique: Use of show/hide controls to allow access to content in different orientations

Technique: Use of the flexible box model to change the meaningful sequence order of content to match the visual order in different orientations.

Failure: locking the orientation

Failure: Functionality that is only available in one orientation.

@marcjohlic

This comment has been minimized.

Show comment
Hide comment
@marcjohlic

marcjohlic Dec 13, 2016

Member

Signed up as SC Manager

Member

marcjohlic commented Dec 13, 2016

Signed up as SC Manager

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 12, 2017

Contributor

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.

Contributor

mbgower commented Jan 12, 2017

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.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 12, 2017

Contributor

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.

Contributor

mbgower commented Jan 12, 2017

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.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 12, 2017

Contributor

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

Contributor

mbgower commented Jan 12, 2017

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

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 12, 2017

Contributor

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.

Contributor

mbgower commented Jan 12, 2017

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.

@marcjohlic

This comment has been minimized.

Show comment
Hide comment
@marcjohlic

marcjohlic Jan 14, 2017

Member

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.

Member

marcjohlic commented Jan 14, 2017

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.

@marcjohlic

This comment has been minimized.

Show comment
Hide comment
@marcjohlic

marcjohlic Jan 14, 2017

Member

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?

Member

marcjohlic commented Jan 14, 2017

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?

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Jan 17, 2017

Contributor

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

Contributor

mraccess77 commented Jan 17, 2017

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

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Jan 17, 2017

Contributor

@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

Contributor

mraccess77 commented Jan 17, 2017

@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

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jan 17, 2017

Contributor

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.

Contributor

DavidMacDonald commented Jan 17, 2017

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.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 17, 2017

Contributor

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

Contributor

mbgower commented Jan 17, 2017

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

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 17, 2017

Contributor

@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

Contributor

mbgower commented Jan 17, 2017

@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

@jasonjgw

This comment has been minimized.

Show comment
Hide comment
@jasonjgw

jasonjgw Jan 17, 2017

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?

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?

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jan 17, 2017

Contributor

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?

Contributor

alastc commented Jan 17, 2017

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?

@jasonjgw

This comment has been minimized.

Show comment
Hide comment
@jasonjgw

jasonjgw Jan 17, 2017

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Jan 17, 2017

Contributor

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.

Contributor

mraccess77 commented Jan 17, 2017

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.

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jan 17, 2017

Contributor

Fair enough, concern withdrawn.

Contributor

alastc commented Jan 17, 2017

Fair enough, concern withdrawn.

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Jan 17, 2017

Contributor

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

Contributor

mraccess77 commented Jan 17, 2017

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

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Jan 18, 2017

Contributor

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

Contributor

mraccess77 commented Jan 18, 2017

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

@joshueoconnor

This comment has been minimized.

Show comment
Hide comment
@joshueoconnor

joshueoconnor Feb 4, 2017

Contributor

@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?

Contributor

joshueoconnor commented Feb 4, 2017

@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?

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Feb 6, 2017

Contributor

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.

Contributor

mbgower commented Feb 6, 2017

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.

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 6, 2017

Member

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.

Member

patrickhlauke commented Feb 6, 2017

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.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Feb 6, 2017

Contributor

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.

Contributor

mbgower commented Feb 6, 2017

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.

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 6, 2017

Member

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

Member

patrickhlauke commented Feb 6, 2017

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

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 6, 2017

Member

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

Member

patrickhlauke commented Feb 6, 2017

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

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Feb 6, 2017

Contributor

#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

Contributor

mbgower commented Feb 6, 2017

#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

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 6, 2017

Member

@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?

Member

patrickhlauke commented Feb 6, 2017

@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?

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 6, 2017

Member

also, this sort of "notify user if content has changed significantly" is not exclusive to portrait/landscape switching, but can happen just the same way with responsive design and browser windows being resized to different dimensions/aspect ratios. so it would seem strange to me to try to integrate this here, when it happens in other situations too.

Member

patrickhlauke commented Feb 6, 2017

also, this sort of "notify user if content has changed significantly" is not exclusive to portrait/landscape switching, but can happen just the same way with responsive design and browser windows being resized to different dimensions/aspect ratios. so it would seem strange to me to try to integrate this here, when it happens in other situations too.

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Feb 6, 2017

Member

#2 is met by the OS, which creates a programmatic notification when landscape alters.

not on desktop, with responsive design and different breakpoints

Member

patrickhlauke commented Feb 6, 2017

#2 is met by the OS, which creates a programmatic notification when landscape alters.

not on desktop, with responsive design and different breakpoints

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Feb 6, 2017

Contributor

not exclusive to portrait/landscape switching, but can happen just the same way with responsive design and browser windows being resized

Anecdotally, I'd suggest that the number of people significantly altering their magnification or browser width on the fly is low. If I increase text size, I do it when I first encounter the page, so any alteration in content occurs before I'm interacting. I suspect the only people who do active resizing of browser windows are those testing their responsive design. It's pretty tough to do accidentally and I'm not aware of a use case.

I don't really see breakpoints as comparable to a change in orientation. Users intentionally or unintentionally change orientation in mid task all the time. (For the record, I did flag concern with alterations in content/context as a result of Resize Content as well).

If you want to strip out the wording I'm concerned about and limit this SC solely to authors not preventing changes in orientation, I'm fine with that. But as soon as we include language stating an author can change the content/context, I think we need additional language about best practices, at the least. I know exactly what would happen to my mom, for instance, if content disappeared from the screen when she changed the orientation. She would be confused and disoriented.

Contributor

mbgower commented Feb 6, 2017

not exclusive to portrait/landscape switching, but can happen just the same way with responsive design and browser windows being resized

Anecdotally, I'd suggest that the number of people significantly altering their magnification or browser width on the fly is low. If I increase text size, I do it when I first encounter the page, so any alteration in content occurs before I'm interacting. I suspect the only people who do active resizing of browser windows are those testing their responsive design. It's pretty tough to do accidentally and I'm not aware of a use case.

I don't really see breakpoints as comparable to a change in orientation. Users intentionally or unintentionally change orientation in mid task all the time. (For the record, I did flag concern with alterations in content/context as a result of Resize Content as well).

If you want to strip out the wording I'm concerned about and limit this SC solely to authors not preventing changes in orientation, I'm fine with that. But as soon as we include language stating an author can change the content/context, I think we need additional language about best practices, at the least. I know exactly what would happen to my mom, for instance, if content disappeared from the screen when she changed the orientation. She would be confused and disoriented.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Feb 16, 2017

Contributor

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.

Contributor

mbgower commented Feb 16, 2017

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.

@marcjohlic

This comment has been minimized.

Show comment
Hide comment
@marcjohlic

marcjohlic Feb 16, 2017

Member

@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

Member

marcjohlic commented Feb 16, 2017

@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

@kwahlbin

This comment has been minimized.

Show comment
Hide comment
@kwahlbin

kwahlbin Feb 16, 2017

Contributor

@marcjohlic I made the edit

Contributor

kwahlbin commented Feb 16, 2017

@marcjohlic I made the edit

@marcjohlic

This comment has been minimized.

Show comment
Hide comment
@marcjohlic

marcjohlic Feb 16, 2017

Member

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

Member

marcjohlic commented Feb 16, 2017

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

@awkawk

This comment has been minimized.

Show comment
Hide comment
@awkawk

awkawk Feb 28, 2017

Member

Updated the issue description to reflect the FPWD text.

Member

awkawk commented Feb 28, 2017

Updated the issue description to reflect the FPWD text.

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Apr 1, 2017

Contributor

Public comments
#265, #235, #193

Contributor

DavidMacDonald commented Apr 1, 2017

Public comments
#265, #235, #193

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald May 4, 2017

Contributor

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.

Contributor

DavidMacDonald commented May 4, 2017

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.

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald May 19, 2017

Contributor

@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

Contributor

DavidMacDonald commented May 19, 2017

@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

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc May 19, 2017

Contributor

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.

Contributor

alastc commented May 19, 2017

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.

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald May 19, 2017

Contributor

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

Contributor

DavidMacDonald commented May 19, 2017

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

@detlevhfischer

This comment has been minimized.

Show comment
Hide comment
@detlevhfischer

detlevhfischer Jul 19, 2017

Contributor

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

Contributor

detlevhfischer commented Jul 19, 2017

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

@kwahlbin

This comment has been minimized.

Show comment
Hide comment
@kwahlbin

kwahlbin Jul 19, 2017

Contributor
Contributor

kwahlbin commented Jul 19, 2017

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Jul 20, 2017

Member

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.

Member

steverep commented Jul 20, 2017

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.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jul 20, 2017

Contributor

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

Contributor

mbgower commented Jul 20, 2017

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

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jul 20, 2017

Contributor

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.

Contributor

mbgower commented Jul 20, 2017

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.

@jasonjgw

This comment has been minimized.

Show comment
Hide comment
@jasonjgw

jasonjgw Jul 20, 2017

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Jul 21, 2017

Member

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

Member

steverep commented Jul 21, 2017

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

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jul 21, 2017

Contributor

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

Contributor

mbgower commented Jul 21, 2017

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

@steverep

This comment has been minimized.

Show comment
Hide comment
@steverep

steverep Sep 11, 2017

Member

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

Member

steverep commented Sep 11, 2017

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.