PROPOSED: 3.4.1 Screen Orientation

Previous version as of 2016-02-18

Expose Orientation: Changes in orientation are programmatically exposed to ensure assistive technology such as screen readers know the changes in layout. [MOBILE]

Proposed 3.4.1

Orientation: Orientation of the content is not locked to landscape or portrait, except where orientation is essential. WCAG definition of essential

[Proposed text for Understanding] Intent of this Success Criterion

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 application developers should try to support both orientations.

Specific Benefits of Success Criterion 3.4.1

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

Examples of problems

banking website locked in portrait mode
iOS home screen on the iPHone vs. iPad

Examples of essential

banking site where a check deposit has to be in a certain orientation
piano app in landscape mode

Related Resources

Resources are for information purposes only, no endorsement implied.

(none currently documented)

Techniques and Failures for Success Criterion 3.4.1

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

Comments

Jon comments

There are applications, like a piano app, that will only work in landscape mode. We need an exemption clause, like the WCAG "essential" clause.

Chris comments

If the user has fixed orientation on a mount, and page comes in upside down with a mechanism to rotate, that mechanism will be also upside down...

David comments

Ideally would like a technique that sniffs user orientation and rotates the mechanism to that orientation.

The term "mechanism is available" also means that the mechanism might be in the browser, user agent, or operating system. This is defined in WCAG and has a precedent in 10 SCs. 1.4.2, 2.2.2, 2.4.1, 2.4.9, 3.1.3, 3.1.4, 3.1.6, 3.2.5, 3.3.4, 3.3.6

Patrick comments

Problem is twofold:

content that expects a certain aspect ratio/orientation to function (e.g. a page which "wants" user to view it in landscape - if user has a portrait aspect ratio, all they get is a "hey, resize your window / tilt your device into landscape mode" message)

content which goes a step further and locks/forces a particular aspect ratio/orientation (possible in native and, with proposals like https://drafts.csswg.org/css-device-adapt/#orientation-desc, also for web content)

While all users are potentially affected by these, certain users groups with disabilities are particularly affected as they can't easily just "turn their device" (thinking of users with a fixed tablet attached to a wheelchair, in landscape mode only).

For web content, desktop browsers don't currently honour any of the device adaptation / viewport directives - this is currently only an issue on "mobile" (phone/tablet) devices. It's possible this distinction may fall away in future (indeed, under certain conditions, even desktop browsers take hints from viewport directives (as is the case with IE/Edge in Windows "metro"/"modern" mode when using split screen view, which picks up on some viewport stuff [don't have the details handy just now])

The more naive "check for aspect ratio width/height and show a 'resize/tilt' message" situations will affect desktop users as much as mobile/tablet users.

In essence, we'd want to say: let users experience your content/use your site/app regardless of their aspect ratio/orientation, as not everybody can easily change window size/orientation.

Simplest way to achieve this: don't fight the browser; using responsive approaches to then make your content look/work great regardless of orientation/aspect ratio is not necessarily tied to this - it's an optional/extra. This should be primarily about NOT locking users out completely. whether the stuff then works well in both portrait and landscape is more of a usability issue.

Another sufficient technique would then be the "mechanism" as in "provide a switch, or setting in an options dialog, or similar".