It can be a bit confusing. Doesn’t WCAG stand for Web (!) Content Accessibility Guidelines? Yes it does, absolutely. But this does not mean that there are separate guidelines for mobile accessibility.
WCAG covers web pages and mobile applications. Mobile web applications and native mobile applications to be precise.
my thesis on the matter.
As a matter of fact, it started with WCAG version 2 and then in June 2018 we even got new success criteria (let’s say requirements) that are actually pretty much mobile oriented. It was a much needed update and there are new updates on it’s way. And with more and more users accessing web on their mobile phones, and of course also installing hundreds of thousands of native mobile applications it is very important to remember – WCAG tries to go beyond the web and even beyond native mobile apps. There are also smart TVs, wearables, internet of things, Virtual and Augmented reality and so on.
WCAG for native mobile applications in practice – orientation
Let’s make a simple test – unlock your iOS or Android smartphone, make sure your orientation settings are not locked and open your favorite application.
Does it adjust and rotate when you physically rotate the phone? Good, then it is respecting the WCAG 1.3.4 (opens in new window). But as I have tested on my phone not every app does do that. My Gmail and Outlook for example worked fine, but MS Teams and actually also any of my multiple online banks did not rotate.
This means that they can not state they conform to WCAG 2.1 on level AA. And that is actually very important. To be precise – the European Web Accessibility Directive (WAD) will require that every public sector native mobile app conforms to WCAG 2.1. on level AA in the summer (23th of June 2021). In some countries that also means some parts of private sector (like for example in Finland – WAD also applies to private banks and insurance companies etc. (Google translation, opens in new page)).
I’ve even asked the Norwegian authorities if they can confirm and they answered yes.
But then, when discussing it with a mobile developer – she was not aware of it at all. So I did a quick overview of whole WCAG and how it can be applied to native mobile apps. It was quite and eye-opener for her, but I did get some additional questions I had to check. After searching on the web – I did not find much more that basics around the WCAG on mobile apps.
I did stumbled upon GitHub comments exactly on the matter of WCAG 1.3.4 – Orientation – and how it is to be applied to native apps (opens in new window).
I have to refer to Patrick – that made a good point in the last comment; both Apple and Android have made it clear how to support automatic and semi automatic adjusting to different orientations and there is no reason not to study and implement it.
Apples human interface guidelines on adaptivity and layout – device screen sizes and orientations (opens in new window) and there are Androids Material Designs Responsive layout grid docs (opens in new window) and Handling Device Orientation Efficiently in Vulkan With Pre-Rotation (opens in new window) can also be of help.
If you are using React Native, then there is also some info in their docs, but I think they should be more clear in the docs about it and advise against locking the screen orientation (opens in new window).
So – again – if accessibility is there from the wireframes it costs less
It is much easier to make an app to work on any device orientation if your wireframes or prototype and designs take it into account. Then the designers and user experience specialist take correct steps and make right decisions and as a developer your task is much easier and at the end – your product more accessible.
Remember – not everybody can or want to use their apps (or webpages for that matter) in a single predefined screen orientation. It should be a matter of preference and choice.
