Working with WCAG 2.1 — 1.3.4

In 2020 my team designed a website that contained, as a primary feature, an interactive video.

This experience leveraged the magic of PixiJS to draw the user through a narrative, giving them control over key interactions.

The experience also had a voice over, which we supported with closed captions both in the interactive video and within any accompanying non-interactive YouTube versions.

However when it came to screen orientation on mobile devices, we had to think carefully about WCAG 1.3.4 (Screen orientation guidelines) when designing for mobile interaction as one of our requirements was to meet AA accessibility standards wherever possible.

This is one of the challenges of working in a creative environment that wants to make the internet do New And Exciting Things — the UX team have to remind them that they also have to make things that are accessible. And there can be a tension between the two that requires some careful thought and discussion.

Note: images used here are for illustrative purposes and are not final UI or creative. Photo used in phone images is by @baileyzindel on Unsplash.

The challenge

The interactive video’s controls for navigation, closed captions, sound etc were best experienced in landscape orientation on mobile devices, to provide maximum screen real estate, however my understanding of WCAG 1.3.4 is that forced screen rotation is not acceptable. Nevertheless, due to the nature of the content, a portrait mode version would limit both the interactivity of the experience, and (unfortunately) also limit access to in-video accessibility features.

This required further investigation and an assessment of the options available.

The assessment

In order to make a decision to proceed with build, we had to explore a number of options and their implications for users, the message that the client business was trying to communicate, the creative intent of the team and of course technical feasibility.

To achieve this we had discussions as a team, I reviewed WCAG guidelines and I consulted with external accessibility experts from my own professional network.

Scenario 1 — in-screen message on portrait view, i.e. “please rotate device to view”

Assessment — This (I believe) is a definite no. Presenting road blocks to users is against the intent of 1.3.4 and is generally considered poor practice. The author/system should rotate the content (if it is required) rather than the user. Also, as someone once said:

UX is like a joke — if you have to explain it, it’s not very good. — Martin LeBlanc

I remember a screen from a previous version of the Starbucks app, where the store finder map blocked you and forced rotate. I remember thinking how dreadful that was. So that’s a no.

Scenario 2 — Create full screen portrait version of the experience, that flexes on rotate

Assessment — This approach would incur significant additional dev and design time to adapt a portrait experience, and although technically it would reduce the need for screen rotation, it would also have the potential to reduce the interactivity, content and accessibility features significantly.

If we had had more time and infinite budget, we could have produced video that played in portrait orientation with device movement and gyroscope, but that’s a large investment for functionality that research showed is often turned off on device, and in fact requires more user mobility.

Scenario 3 — Play video as-is (landscape) but scaled down for portrait, with b/w above and below.

Assessment — this is the approach seen on many mobile video players, essentially running a full screen modal in portrait, however it would significantly reduce visibility of content, and may fail to fully communicate to the user the breadth of accessibility features available to them.

Scenario 4 — Play video as-is (landscape) but scaled down for portrait, with b/w above and below — but add in CC and other features

Assessment — In this version, the accessibility features are communicated in portrait mode, however the visibility of CC is still limited in portrait. Also, adding additional signifiers to portrait could reduce chances of users rotating device, and thereby discovering the full options.

Scenario 5 — Play as full screen landscape modal

Assessment — This delivers the best format for communicating content and general accessibility options. It does rely on user being able to rotate device OR tilt head, however this means that all accessibility options become immediately available including any CC/sound and screen reader narration.

Conclusion

Although not entirely optimal, Scenario 5 allows us to immediately expose all accessibility options to the user, without introducing explicit barriers or roadblocks (such as “please rotate device”).

This is the pattern currently used by Netflix and some BBC experiences, and ensures that those who need in-video accessibility tools are prioritised, given that video content is also the priority of the experience.

WCAG 1.3.4’s orientation recommendations are to be followed “unless a specific display orientation is essential.” and that essential means “if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform”

In this case, persisting in portrait play would limit the perception, understanding and operability of our content and its accessibility features, and so we concluded that landscape orientation to be essential to the experience — but kept a specific requirement in place that the user must not be blocked from playing content.

Note: We continue to monitor alternative methods of content display and best practice, and try to assess each challenge against individual project requirements.