search

w3c / wcag21

Repository used during WCAG 2.1 development. New issues, Technique ideas, and comments should be filed at the WCAG repository at https://github.com/w3c/wcag.
https://w3c.github.io/wcag/21/guidelines/
Other
140 stars 55 forks source link

Orientation #70

Closed kwahlbin closed 7 years ago

kwahlbin commented 7 years ago

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

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 commented 7 years ago

Signed up as SC Manager

mbgower commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

mraccess77 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

If we’re expanding WCAG to cover mobile apps, then that opens up all of the issues surrounding WCAG2ICT, non-Web software, etc. That’s surely an issue to be deferred to Silver.

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.

mraccess77 commented 7 years ago

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 commented 7 years ago

Fair enough, concern withdrawn.

mraccess77 commented 7 years ago

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

mraccess77 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years 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.

mbgower commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 https://github.com/w3c/wcag21/issues/2

mbgower commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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

not on desktop, with responsive design and different breakpoints

mbgower commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@marcjohlic I made the edit

marcjohlic commented 7 years ago

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 commented 7 years ago

Updated the issue description to reflect the FPWD text.

DavidMacDonald commented 7 years ago

Public comments

265, #235, #193

DavidMacDonald commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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

detlevhfischer commented 7 years ago

@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 commented 7 years ago

Thanks Detlev!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/w3c/wcag21/issues/70#issuecomment-316348354, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGQgJphXQ7AnPdBKsQwj7IEE_1uBdiF-ks5sPeA8gaJpZM4K-jPD.

steverep commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

One of the issues that I raised with this proposal remains to be addressed: as currently written, it would prohibit the author from providing a control to lock the orientation, such as a button that calls screen.orientation.lock(). I can’t remember the state of the conversation, other than that Andrew and possibly others acknowledged this as a problem with the proposal, and there was draft wording to address it (e.g., by adding “except at the user’s request”, or similar terms).

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.

Thank you for your compliance.

steverep commented 7 years ago

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

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 commented 7 years ago

@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 commented 7 years ago

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