Re: Query regarding 1.3.4

My two cents:
all points mentioned are interesting and it seems there is no consensus in
this thread. Might be a good idea (and I'll do that) to open an issue for
clarification into the WCAG GitHub, maybe asking to add some words in the
SC understanding to clarify this controversial aspect.

At the same time, as also mentioned by Kevin, in my opinion this issue
affects everybody and, even if of course it should be fixed, it doesn't
reflect in a 1.3.4 SC failure.
Content is not locked and users are able to access the specific page in
both portrait and landscape by refreshing the page. This is a AA level
criterion; if the intent of the SC is the one described by Kevin - with
which I agree - might be worth thinking about adding a AAA level criteria
that requires content to adapt dynamically after switching orientation (not
sure if this will cause problems with adaptive websites).

Last, but not least, G214
<https://www.w3.org/WAI/WCAG21/Techniques/general/G214> sufficient
techniques says "Using a control to allow access to content in different
orientations which is otherwise restricted". Trying to abstract the concept
(we know that sufficient techniques are *specific* guidance for particular
scenarios and cannot cover all the possibilities), even if of course there
might be different interpretation, the refresh button provided by the
technology (browser in this case), in combination with the author code,
might be considered a control that allow users to display the website on a
different orientation. I agree that this will cause a "loss of focus/loss
of entered contents" which might affect more or less multiple users, but
again, as stated by Kevin, this is valid for everyone.

Giacomo Petri

Il giorno mer 9 nov 2022 alle ore 02:40 Kevin Prince <
kevin.prince@fostermoore.com> ha scritto:

> With respect – it’s not locked into either orientation  (it doesn’t
> restrict its view) but there is a bug for everyone when it changes between
> orientations. That affects everybody. Different countries define the
> failure vs best practice vs bug.
>
>
>
> In both failure criterion there is an explicit step to open the content in
> landscape, and one to open it in portrait. If the criteria were supposed to
> include the scenario we have here then it would say move between portrait
> and landscape. (PS, I don’t like it but if that’s how your regulator
> defines compliance then that’s the literal reading you have to take)
>
>
>
> Either way fix the bug.
>
>
>
> *Kevin Prince *
> Product Accessibility & Usability Consultant
>
> *Foster Moore*
> A Teranet Company
>
> *E* kevin.prince@fostermoore.com
> Christchurch
> *fostermoore.com <http://www.fostermoore.com/>*
>
> *From:* John Foliot <john@foliot.ca>
> *Sent:* Wednesday, 9 November 2022 11:06 am
> *To:* Kevin Prince <kevin.prince@fostermoore.com>
> *Cc:* Ramakrishnan Subramanian <ram.eict2013@gmail.com>; w3c-wai-ig@w3.org
> *Subject:* Re: Query regarding 1.3.4
>
>
>
> Hi Kevin,
>
>
>
> > It doesn't fail the failure criteria of 1.3.4 because it allows changes
> in orientation
>
>
>
> Respectfully, it *IS* a failure of SC 1.3.4, because according to
> Ramakrishnan, there *IS* "... *loss of content or functionality*" (their
> actual words). The SC does not speak to *how *that may happen (opening
> the page in either view, or when the view changes due to device rotation),
> only that the content MUST render and function correctly in both views.
> Again, the normative text clearly states:
>
>
>
> "*Content does not restrict its view and operation to a single display
> orientation*, such as portrait or landscape, unless a specific display
> orientation is essential."
> https://www.w3.org/TR/WCAG21/#orientation
>
>
>
> SC 1.3.4 is NOT about change of orientation, it is about ensuring content
> works in both views.
>
>
>
> As others have noted, a tablet could be physically locked into landscape
> mode (because it is mounted on a motorized scooter for example), but if
> page content is 'locked' into only rendering in Portrait mode, it fails.
>
> JF
>
>
>
> On Tue, Nov 8, 2022 at 4:28 PM Kevin Prince <kevin.prince@fostermoore.com>
> wrote:
>
> Strictly speaking it's a bug that needs fixing for all. It doesn't fail
> the failure criteria of 1.3.4 because it allows changes in orientation - it
> just handles them badly.
>
> Kevin
>
> *Kevin Prince *
>
> Product Accessibility & Usability Consultant
>
>
>
> *Foster Moore*
>
> A Teranet Company
>
>
>
> *E* kevin.prince@fostermoore.com
>
> Christchurch
>
> *fostermoore.com <http://www.fostermoore.com/>*
>
>
> -----Original Message-----
> From: Ramakrishnan Subramanian <ram.eict2013@gmail.com>
> Sent: Wednesday, 9 November 2022 5:06 am
> To: w3c-wai-ig@w3.org
> Subject: Query regarding 1.3.4
>
> CAUTION: This email originated from outside of the organization.
>
>
> Dear Members,
> I would like to know whether loss of content or functionality that happens
> when the device orientation is changed would be A Failure of Success
> criteria 1.3.4? or is it a best practice?
> Some Examples of loss of content /functionality that I refer during the
> change of orientation may include content truncation / overlapping / unable
> to scroll etc.
>
>
> --
>
> Thanks and Regards
> Ramakrishnan
>
>
>
>
> --
>
> *John Foliot* |
> Senior Industry Specialist, Digital Accessibility |
> W3C Accessibility Standards Contributor |
>
> "I made this so long because I did not have time to make it shorter." -
> Pascal "links go places, buttons do things"
>