Re: Query regarding 1.3.4

Hi Brooks,

I don't think anyone is saying (at least I hope they're not) that the situation you outline is a 'good' experience, or a 'bug' that has an equitable impact across all users.

However, the normative text of the SC does not say that the page has to allow transitioning from one orientation to another, only that a page can't restrict its view to one orientation and that everything has to function in both orientations.

Jon, who was involved in working on the specification and was likely privy to what the intent of the SC is/was, has said clearly that it does not scope to pages being required to functionally transition from one orientation to another. As one of my responsibilities for a previous role I was in the same WCAG WG, though that role also didn't allow me the time to actually do anything other than attend. I remember Jon, his strong opinions, but also the fact that I frequently heard from him "This is not a hill I would want to die on" and variations of "Well, I don't like it, but that's the consensus, and though I disagree - strongly - lets go with the consensus and not hold up the process." I have no reason to think that Jon is inserting his own personal opinion about the SC into these discussions, or that his reporting of the WCAG WG intention for this SC is anything other than accurate.

Your questions about the failures present on a page that has changed orientation after page load is a good one, but also pretty well addressed by the issue I linked to [https://github.com/w3c/wcag/issues/391] previously. This issue is primarily a discussion about how, when, and if WCAG SC compound. After much discussion it was settled that the text in the Conformance Claims section of the document said exactly what they intended it to say. Particularly relevant is this note:

"NOTE
New A full page includes each variation of the page that is automatically presented by the page for various screen sizes (e.g. variations in a responsive Web page). Each of these variations needs to conform (or needs to have a conforming alternate version) in order for the entire page to conform."

This note does not say that each variation of the page that can be triggered by the user, or each variation of the page after user interaction, needs to conform.

All of that is to say that I don't believe WCAG currently covers issues related to orientation changes after page load. I believe it should cover situations like that, as well as issues related to sites that have wonky displays after zooming, but will display nicely after you refresh at that zoom level.

Thank you to the person who submitted an issue related to this discussion.

Best regards,
Juliette

On 11/9/2022 12:31:08 PM, Brooks Newton <brooksallennewton@gmail.com> wrote:
OK, so let me get this straight.  Is anyone in this thread saying that abandoning the user task and refreshing the page is a viable reason for passing SC 1.3.4 - Orientation [https://www.w3.org/WAI/WCAG21/Understanding/orientation.html]  in the half-finished business license application scenario I presented?  If so, really? 


How many success criteria do we have in WCAG 2.x that exist primarily to prevent users with disabilities from abandoning tasks that may be technically possible, but not probable due to user disabilities?   I know I'm asking a lot of questions.  This interpretation of SC 1.3.4  having an abandon/refresh exception doesn't seem in keeping with the spirit of many other success criteria in WCAG 2.x.

Maybe what's missing here is the recognition that multiple other success criteria will be failed in this scenario, so we don't have to pin the failure on SC 1.3.4?  Like Alan, I'm having a difficult time justifying why the user scenario I wrote earlier in the thread wouldn't be a hard fail of SC 1.3.4, even if a refresh of the page fixed the content or functionality in the given display orientation. 


Are instructions provided to the user to simply abandon their task and refresh that page to get the page working right?  If they aren't provided, is that a failure of SC 3.3.2 - Labels or Instructions [https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html]?  Is it reasonable to expect that a user will just intuitively know that refreshing the page is the fix to the problem?  Can you expect the user to make that destructive choice when they've put a lot of time and energy into what they've already input or interacted with on the page?


Isn't the disproportionate time and energy  required to complete tasks for people with certain disabilities the reason for supporting successful outcomes that are probable, not just theoretically possible? How long should it take for the user to reach that conclusion to throw away page progress by refreshing if they are never explicitly directed to do so by the content author?


Would this orientation scenario also be a failure of SC 3.3.9 - Redundant Entry (WCAG 2.2) [https://www.w3.org/TR/WCAG22/#redundant-entry], in the case of a half-filled out application that must be erased and filled out again after refresh?

I'm not saying I have all of the answers here - I'm just trying to ask the right questions to get closer to consensus.

Brooks Newton


On Wed, Nov 9, 2022 at 12:49 PM Bristow, Alan <Alan.Bristow@elections.ca [mailto:Alan.Bristow@elections.ca]> wrote:

Thank you Giacomo​.


Regards,

Alan
. . . . -   . . - - -
Alan Bristow ( he / him / il )
Web Developer / Développeur Web
Elections Canada / Élections Canada
alan.bristow@elections.ca [mailto:alan.bristow@elections.ca]
From: Giacomo Petri <giacomopetri89@gmail.com [mailto:giacomopetri89@gmail.com]>
Sent: Wednesday, November 9, 2022 1:07 PM
To: Marc Haunschild (Accessibility Consulting)
Cc: John Foliot; Kevin Prince; Ramakrishnan Subramanian; w3c-wai-ig@w3.org [mailto:w3c-wai-ig@w3.org]
Subject: Re: Query regarding 1.3.4
 
Ce message a été envoyé par un expéditeur externe. Veuillez faire preuve de prudence et ne pas cliquer sur les liens ou ouvrir les pièces jointes à moins de reconnaître l'expéditeur et de savoir que le contenu est sûr.

This message was sent from an external sender. Please exercise caution and do not click links or open attachments unless you recognize the sender and know the content is safe.


I assumed per 1.3.4 that both orientations work on page load but not while switching from portrait to landscape and vice versa.
Especially after reading 

While the content may work perfectly in both and only fail when transitioning from one to the other, I see nothing that indicates working in the initial orientation is all that is needed. By definition orientation is subject to change, and so it seems pretty clear the intention is content works in either orientation, including after a change in orientation.


from Alan. 

This case happens more frequently than expected, especially for animated elements such as sliders or carousels.

That's the reason of my feedback and why I've opened https://github.com/w3c/wcag/issues/2771 [https://github.com/w3c/wcag/issues/2771]