WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: 1.3.4 Orientation

for

From: Sumit Patel
Date: Aug 10, 2020 9:29AM

Thanks for your replies....

I have read that if user looses some content when the orientation
changes such as landscape to portrait, will not come in this SC.
So, Which SC the loss of content in this situation fall into?


Regards,
Sumit.
On 06/08/2020, Patrick H. Lauke < <EMAIL REMOVED> > wrote:
> On 06/08/2020 05:15, Sumit Patel wrote:
>> Hai Accessibility experts,
>>
>> I was going through 1.3.4 Orientation WCAG 2.1 SC. Some soubts have
>> come p in my mind regarding this SC.
>>
>> How to test this SC
>> Is it possible for screen reader users to test this SC?
>
> Depending on the approach developers have taken, you can test on desktop
> by resizing the dimensions/aspect ratio of the browser window/viewport,
> or using some device emulation (e.g. in developer tools) and changing
> the orientation there. And in some cases, you may need to test on an
> actual mobile/tablet device and literally turn it from portrait to
> landscape or vice-versa. In all cases, do that and then observe if the
> page/app is actually still operable or if it stops you from doing
> things. The trickiest part would be to determine if the page has been
> forcibly styled/rotated when in the "wrong" aspect ratio...this one may
> not be straightforward to test for a screen reader user (as the CSS to
> rotate the page should not affect the way SRs navigate through/interact
> with the page).
>
>> What is the technical recommendation, can we give for this the failure
>> of theis SC?
>
> "Stop doing that stuff" *grin*
>
> But in general yes, the recommendation would be for developers not to
> just develop/design for one particular orientation (portrait or
> landscape) and simply showing a "sucks to be you" / "please rotate your
> device" type roadblock message in the other orientation, or to inject
> CSS that forcibly rotates the page content by 90 degrees, and to instead
> make sure that their site/app works in both orientations. As with
> responsive design in general, this doesn't mean that they must
> absolutely have the exact same layout/functionality present in the same
> view/page for both orientations, but more generally that regardless of
> orientation, a user must be able to generally perform the same tasks/get
> the same information (but it's fine if in one orientation, some of the
> stuff is perhaps moves off onto a separate sub-page, or a slide-in
> panel, or similar).
>
>> Technically, how the developers are locking the orientation to one
>> (Landscape or portrait)?
>
> There are a few approaches that developers can take...
>
> * using JavaScript, query the current width/height of the
> viewport/screen, work out if it's portrait (width < height) or landscape
> (width > height), and modify the page content accordingly (e.g. show a
> doorslam "turn your device" screen for the orientation you haven't
> designed for)
>
> * using JavaScript, query the device orientation API
> https://developer.mozilla.org/en-US/docs/Web/API/Detecting_device_orientation
>
> and do the doorslam that way
>
> * using CSS orientation media query
> https://developer.mozilla.org/en-US/docs/Web/CSS/@media/orientation, or
> some other very specific width/height-based set of queries
>
> And there's probably a few more approaches devs can take...
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >