1.3.4 Orientation - applicability to native apps

[detlevhfischer]

This probably relates to the discussion we have already had on 1.4.10 Reflow w3c/wcag2ict#3
Native apps that I have recently tested support a change of orientation only on tablets, not smartphones. This seems to be a very common behaviour for native apps.

The Success Criterion 1.3.4 Orientation is included in clause 11 of the EN and would therefore be expected to apply to mobile apps, at least in the European context. Is there any consensus in the WG whether orientation should fully apply to native apps, even at narrow breakpoints / on small screens?
Should the understanding text say anything about it?

[jake-abma]

Hi @detlevhfischer Not sure if this is what you mean but I do have native apps who change / support orientation. The layout will reflow perfectly fine.

Other apps not but it surely is possible.

[detlevhfischer]

I know it is possible. I just note that nearly all apps I checked on my phone (apart from a few utility apps like mail, calendar, maps, calculator, notes) fail 1.3.4 and imagine the massive impact this will have it there is consensus that it is a must also for all native apps.
Would a native app that re-orients at a tablet breakpoint, but not at a phone breakpoint, pass? The SC text and the understanding text say nothing about viewport width, so you can imagine someone saying, "Our app passes (on tablets) so yes, we meet this SC."

[goetsu]

You always can argue that specific display orientation is essential due to the design of the app

[patrickhlauke]

You always can argue that specific display orientation is essential due to the design of the app

You can argue that an orientation is essential as it's intrinsic to the type of content/activity of the app, but not necessarily that it's essential due to the design - that would be quite circular logic ("it's essential that you use this in portrait mode because that's the only mode we designed it for")

[patrickhlauke]

and to answer the main question: i think it makes sense for this to apply to native apps as well, as it would be odd to have web content require it on the same device (and then you have the fun of embedded web content in native apps, where it could be even weirder to make an exception even for the web content just because it happens to be in an embedded view rather than in an all-purpose browser). but yes, this would likely end up failing for a large proportion of existing native apps.

[jake-abma]

This is exactly why I asked this question yesterday at the call (the relationship of native apps Vs. WCAG and the responsibility for the AGWG) and I think we need some thorough discussion about it. Sure in 2008 we focussed on web but in 2019 this should be changed as users don't make the difference, they just want IT products to be accessible. Think @alastc will add it as a topic for the next call as we had a growing cue when the time was up yesterday.

The http protocol as mentioned by David and refuted by Mr. Foliot (we also have smtp and https) is even more an issue when talking about hybrid OR (in my opinion) a native app downloaded by http(s)... just as you can do with a PDF...

To be continued

[patrickhlauke]

i still feel very uncomfortable about the blurring of what Web Content Accessibility Guidelines apply to, and the scope creep of making them apply to things that are not based on web standards under the aegis of W3C (I have had those concerns already back when PDF, Word, Flash, Silverlight etc were also considered "Web Content", to be fair). Native apps are, to me, very clearly not web content at all. It's fine to draw parallels from the overarching principles of WCAG to make them apply to other things that aren't Web Content, but a lot more interpretation is needed in my opinion (from those who try to make it apply), rather than just taking stuff wholesale. Very minor case in point, things like the SC for Link Purpose, which makes little sense in native apps (except for those rare controls that do fire a web browser), or SC Multiple Ways, which pretty much all native apps I can think of would likely insta-fail...

[patrickhlauke]

Noting that even in the current WCAG 2.0/2.1 definition, web content is defined as being something handled by a user agent. In the case of native apps, there's no user agent (unless we now start claiming the OS itself is the user agent)

[detlevhfischer]

@patrickhlauke 2.4.5 Multiple ways has never been part of clause 11 Software of the EN 301549 (which I see as my point of reference for evaluating apps).
Regarding 2.4.4 Link purpose, I tend to apply that also to controls that call up other views inside the app (admittedly the line gets blurry as most are implemented as buttons), certainly to those controls in webviews that are (or act like) links.
I think 1.4.10 Reflow (which has been included in clause 11) is odd and I would mark that N.A. with the annotation that reflow is not generally supported in mobile UAs. I also wonder what I am to make of 1.4.12 Text spacing which has been deemed applicable in clause 11 without any way for authors to implement that now sauf some app-internal setting to increase spacing - is that the honest intention to push that to app authors rather than locate it at the UA level?
1.4.13 Content on Hover or Focus seems equally odd as there is little of that in mobile apps that I can recall, though it is not impossible (and the requirement would be valid say, for Android used with a keyboard or mouse).
Regarding 1.3.4 Orientation, you may be right that it should be an applicable requirement for native apps, but I would like to see more views on that.
I still don't get why 3.2.3 Consistent Navigation and 3.2.4 Consistent Identification have been deemed inapplicable to mobile apps since I find them generally applicable. Interestingly 4.1.3 Status Messages has now been added in the latest draft fo the EN (V3.1.1) to see the light of day some time in August, I believe.
Quite a messy picture.

[patrickhlauke]

Ah, you're right, 2.4.5 is excluded from 508 Refresh / VPAT 2.x as well.

For 1.4.13, the "with a paired keyboard or mouse" scenario is the one I have in mind as well. Likely authors won't rely on hover/focus as touch is deemed to be the primary mode of interaction on mobile/tablet devices, but still...

Another SC that does feel odd (or at least needs more reinterpretation) for native apps is 2.4.2 Page Titled... sigh

[detlevhfischer]

2.4.2 Page titled is also one of those that are void in the EN... (adds) I mean in clause 11 Software - thanks for pointing that out, @awkawk

[awkawk]

2.4.2 is used in the EN for Web Content and Non-web Documents, but not non-web Software.

[patrickhlauke]

2.4.2 is not, to my knowledge at least, excluded for 508 Refresh though, unless I missed that exclusion for non-web Software

[awkawk]

Section 508: 2. Non-Web software shall not be required to conform to the following four Success Criteria in WCAG 2.0: 2.4.1 Bypass Blocks; 2.4.5 Multiple Ways; 3.2.3 Consistent Navigation; and 3.2.4 Consistent Identification.

[patrickhlauke]

Section 508: 2. Non-Web software shall not be required to conform to the following four Success Criteria in WCAG 2.0: 2.4.1 Bypass Blocks; 2.4.5 Multiple Ways; 3.2.3 Consistent Navigation; and 3.2.4 Consistent Identification.

So, as said, 2.4.2 Page Titled is NOT excluded

[awkawk]

Official WG response (February 19 2019):
Thank you for the question. While the discussion seems to suggest that Orientation is applicable beyond web content, the official response for this question will be answered with the update to WCAG2ICT.

[alastc]

The proposed response was accepted, but labelled with WCAG2ICT / WCAG.next, so we can find the can we kicked down the road....

[mraccess77]

I know this issue is closed -- but this topic on orientation and mobile native apps is a huge issue for apps including most Apple and Google apps that fail the criteria and require a redesign of mobile apps to support landscape. Many apps are portrait based and have tab bars at the bottom of the display. A change to landscape would require changing the orientation of the tab bar to vertical and appearance on the left or right. For most websites orientation changes aren't really such a big issue -- for mobile apps -- they are generally design for a particular orientation and don't offer the same fluid responsive mechanisms and thus most were not designed at all to address this. This means that most mobile apps cannot meet WCAG 2.1 without a re-design. It would be helpful to prioritize work on WCAG 2.1 to non-web ICT and to collect or create some samples that might help organizations re-design their app to meet the requirements.

[patrickhlauke]

starter for ten: Apple's HIC guidelines for "Adaptivity and Layout", which includes information about auto-layout features (which can indeed allow for some automatic/semi-automatic readjusting to different orientations) https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/adaptivity-and-layout/

for Android native, see the "Responsive Layout Grid" section of the developer documentation https://material.io/design/layout/responsive-layout-grid.html

(so yes, it's quite feasible to develop/design native apps that adapt, in a very similar way to responsive web design ... it's just that it's not that common for native devs just yet)

[Rasubra8]

Whether 1.3.4 is applicable for non-web documents like PDF/Excel/Word that can be viewed in Desktop/mobile as well?