E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 5 (In chronological order)

From: Sumit Patel
Date: Wed, Aug 05 2020 10:15PM
Subject: 1.3.4 Orientation
No previous message | Next message →

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?
What is the technical recommendation, can we give for this the failure
of theis SC?
Technically, how the developers are locking the orientation to one
(Landscape or portrait)?

Waiting for the answers

Regards,
Sumit

From: Patrick H. Lauke
Date: Thu, Aug 06 2020 2:42AM
Subject: Re: 1.3.4 Orientation
← Previous message | Next message →

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

From: Mallory
Date: Thu, Aug 06 2020 5:37AM
Subject: Re: 1.3.4 Orientation
← Previous message | Next message →

There's another doorslam that I think a screenreader-using tester would have trouble detecting, which is one I personally ran into 2 years ago: the client used CSS media queries to detect viewport width to expose a "mobile" view, then checked height vs width and added an overlay with their "your orientation is bad" message.

That overlay wasn't marked up as a dialog or anything, so if you miss the text inside it, you may think the page below is still available (for keyboard it was!), but visually it's blocked. I triggered it simply viewing the page on a desktop (since that's "landscape") with my 200% zoom level.

So keep an eye out for any text mentioning rotating your device: it might just be visually positioned over the whole viewport without actually blocking content like a full modal dialog will.

cheers,
_mallory

On Thu, Aug 6, 2020, at 10:42 AM, Patrick H. Lauke 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
> > > > >

From: Sumit Patel
Date: Mon, Aug 10 2020 9:29AM
Subject: Re: 1.3.4 Orientation
← Previous message | Next message →

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 ADDRESS 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
> > > > >

From: Mallory
Date: Tue, Aug 11 2020 6:53AM
Subject: Re: 1.3.4 Orientation
← Previous message | No next message

Yes, if one orientation misses some content due to poor layout/not being responsive, that often falls under Reflow 1.4.10.

**But**
that SC is very limited, specifically to either a 320px viewport width, or a 1280px viewport width at 400% zoom. Technically, Reflow does not refer to other viewport widths (except for reference to vertical text pages).

The two listed Failures on the Orientation page mention
- locking orientation (after you rotate your device, the content remains 90 degrees off/does not rotate)
- showing a doorslam (https://www.w3.org/WAI/WCAG21/Techniques/failures/F100)

If you are sticking to WCAG SC failures only, then in theory a page which
- correctly shows all content on 320px width viewports and 1280px viewports at 400% zoom,
- and rotates the screen to adjust for device orientation,
- but one orientation blocks some of the content because they did not make it fully responsive to different viewport widths,

then I suppose technically the page passes WCAG, while in practicality failing some users. This is similar to: a page which makes content inaccessible at 300% zoom on a 1280px-width viewport would technically pass the Reflow SC but fail in practicality.

Awful, huh?

cheers,
_mallory

On Mon, Aug 10, 2020, at 5:29 PM, Sumit Patel wrote:
> 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 ADDRESS 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
> > > > > > > > > >
> > > > >