Re: Query regarding 1.3.4

Brooks writes:

> it doesn't impact all users equally


This is true for pretty much ALL of the Success Criteria Brooks, and is not
a new problem.

   - Failing to provide captions (SC 1.2.2) will disproportionately impact
   deaf users more-so than blind users.
   - Failing to provide (accessible) widget names and states (SC 4.1.2)
   will disproportionately impact screen reader / AT users over non-screen
   reader / AT users.
   - Failing to provide a mechanism to bypass blocks of content (SC 2.4.1)
   disproportionately impacts users who can only use a keyboard to navigate
   page content.
   - Failing to provide ANY visible tab focus (SC 2.4.7)
   will disproportionately impact sighted keyboard-only users - failing to
   ensure that the visible tab focus ALSO has sufficient foreground/background
   contrast (SC 1.4.6) will also disproportionately impact sighted
   keyboard-only users, but more so for those who are also with low-vision.

This last one tracks closely to the concern you have: a page COULD meet SC
2.4.7 by ensuring visible tab focus, but if the visibility is below the 3:1
color contrast it fails SC 1.4.6 - so it IS possible to meet one SC while
also failing to meet another on the same piece of web-content. Both are
"Fails" against WCAG 2.1, but one is MORE impactful to *some* users than
the other.

However, meeting SC SC 2.4.7 is in no way a blanket "Pass" that forgives or
permits a poor user-experience, it simply means that while the contrast
issue remains, visible tab focus IS present (in other words, if the tab
focus is below 3:1, it fails 1.4.6, but NOT 2.4.7, despite the fact the two
are explicitly linked together). And those 2 SC are not the end of it, as
we are also adding SC 2.4.12 Focus Not Obscured
<https://www.w3.org/TR/WCAG22/#focus-not-obscured-minimum> to WCAG 2.2, to
address an emergent additional barrier *for some users* that can be
addressed by the content author/designer. What we *want* is for all 3 SC to
be met, but if 2 of the 3 are met, it isn't a TOTAL failure, yet it remains
a partial failure.

This is a known issue, and is why page conformance today is based on
successfully meeting ALL of the SC, and not cherry-picking the ones that
are most dear to you. Heck, to be Section 508 compliant, you don't even
need to meet this WCAG 2.1 SC, as Section 508 is based on WCAG 2.0 and SC
1.3.4 emerged during the 2.1 work effort. That's wrong too, but also
outside of the scope of what the W3C can do (the US Congress is not going
to jump to our demands just because we're demanding it).

> we were always having to change rules to exempt accessibility errors that
would be caused by known issues with browsers

...BECAUSE there was nothing that a content owner could do to change the
issue.

The Web *Content *Accessibility Guidelines, rightly or wrongly, are
centered on author-supplied content: the charter for the Accessibility
Guidelines WG <https://www.w3.org/2019/12/ag-charter#scope> specifically
notes that the working group can only also provide *non-normative
information* about the ways web technologies need to work with authoring
tools, user agents, and assistive technologies.

But neither the working group nor the W3C itself can FORCE browser vendors
and other user-agent vendors to build their products the way we would hope,
or demand how they must support our goals. That's primarily the role of
legislative bodies, and in that regard the EU is far ahead of the US (North
America) in that type of effort, with both the GDPR (General Data
Protection Regulation) and NIS Directive (digital security) driving changes
in those types of tools (user agents). (see:
https://venturebeat.com/security/while-everyone-was-focused-on-gdpr-the-nis-directive-snuck-in-through-the-back-door/
for some background).

JF

On Thu, Nov 10, 2022 at 11:33 AM Brooks Newton <brooksallennewton@gmail.com>
wrote:

> Except that it doesn't impact all users equally, Andrew,  as I pointed out
> in my example with a user with partial paralysis. Any user who takes a long
> time and/or incurs a significant cognitive load in completing work on a
> poorly rendered page after orientation change will be disproportionately
> impacted.
>
> It seemed in the WCAG 2.1 and in the WCAG 2.2 process in which I
> participated, we were always having to change rules to exempt accessibility
> errors that would be caused by known issues with browsers.  I think it
> hurts the resulting Success Criteria to make these exceptions.  This SC is
> a prime example of what I call Accessibility Dark Patterns.  I'm adding
> "use Refresh button to abandon the task to fix accessibility problems" as
> the latest entry to my growing list.
>
> Brooks
>
> On Thu, Nov 10, 2022 at 9:59 AM Andrew Kirkpatrick <akirkpat@adobe.com>
> wrote:
>
>> Alan,
>>
>> I would say that this sounds like an issue that would impact all users,
>> not just those with disabilities, and even though WCAG isn’t providing a
>> failure to take to the web team hopefully incorrect functioning for users
>> would be sufficient to get the team to fix it.
>>
>>
>>
>> Thanks,
>>
>> AWK
>>
>>
>>
>> Andrew Kirkpatrick
>>
>> Director, Accessibility
>>
>> Adobe
>>
>>
>>
>> akirkpat@adobe.com
>>
>> http://twitter.com/awkawk
>>
>>
>>
>>
>>
>> *From: *"Bristow, Alan" <Alan.Bristow@elections.ca>
>> *Date: *Thursday, November 10, 2022 at 10:52 AM
>> *To: *Andrew Kirkpatrick <akirkpat@adobe.com>, John Foliot <
>> john@foliot.ca>, Brooks Newton <brooksallennewton@gmail.com>
>> *Cc: *WAI-IG <w3c-wai-ig@w3.org>
>> *Subject: *Re: Query regarding 1.3.4
>>
>>
>>
>> *EXTERNAL: Use caution when clicking on links or opening attachments.*
>>
>>
>>
>> Apologies for chiming in here, I replied way down at the bottom of the
>> thread and I am no doubt not as qualified to cover detail and history here
>> as others are, but, I am surprised that in these two scenarios..:
>>
>>
>>
>> WEB TEAM 1 codes a page poorly, with a strange META VIEWPORT setting, or
>> a JavaScript issue, or odd CSS, take your pick -- a webpage form works in
>> either orientation, but change orientation and content is visually
>> unuseable as it is obscured in some way, due to a bug with META, JS, or CSS.
>>
>>
>>
>> WEB TEAM 2 does the same, but with no errors. Change orientation and the
>> page reflows correctly.
>>
>>
>>
>> ..SC 1.3.4 does not [apparently] allow accessibility auditors to fail the
>> first page. If it does not allow then, then SC 1.3.4 seems incomplete or
>> even "wrong".
>>
>>
>>
>> I understand I am not in a position to understand the history or nuance
>> of how SC 1.3.4 came into being, but I do understand that I would want to
>> have a WCAG SC to hand to point to when the manager of WEB TEAM 1 asks why
>> they need to spend resources fixing this.
>>
>>
>>
>> PS: Requiring a refresh when transitioning from one orientation to
>> another in order for content to be visually useable seems
>> simply unacceptable; Were I the user and part-way through filling a form,
>> even if the page did not lose what I had entered (many would I suspect),
>> the cognitive load from needing to read an explaination at the top of the
>> page that this is necessary and/or the anxiety that "maybe I will loose my
>> place" or "maybe I will lose what I have entered" are points that melt
>> away, if, SC 1.3.4 does not allow a refresh to be a get out of jail free
>> card (I am not even sure it currently does, I just note that if it does, it
>> shouldn't).
>>
>>
>>
>> Regards,
>>
>>
>>
>> Alan
>>
>> . . . . -   . . - - -
>>
>> Alan Bristow ( he / him / il )
>>
>> Web Developer / Développeur Web
>>
>> Elections Canada / Élections Canada
>>
>> alan.bristow@elections.ca
>> ------------------------------
>>
>> *From:* Andrew Kirkpatrick <akirkpat@adobe.com>
>> *Sent:* Thursday, November 10, 2022 9:36 AM
>> *To:* John Foliot; Brooks Newton
>> *Cc:* 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.
>>
>>
>>
>>
>>
>> OK, chiming in here. There was discussion in the WG on this topic back in
>> November 2017 at TPAC in Burlingame, CA.
>>
>>
>>
>> Here’s some discussion: https://www.w3.org/2017/11/17-ag-minutes#item04
>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2017%2F11%2F17-ag-minutes%23item04&data=05%7C01%7Cakirkpat%40adobe.com%7Cf8aa45fb258041494ad608dac33397cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638036923622806417%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0uBRgQViVq6Is1rahDa17il8e4%2Fa6wT5jSdx5Hs0NAM%3D&reserved=0>
>>
>>
>>
>> As a result of this discussion and a survey and Call for Consensus (
>> https://lists.w3.org/Archives/Public/w3c-wai-gl/2017OctDec/0655.html
>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.w3.org%2FArchives%2FPublic%2Fw3c-wai-gl%2F2017OctDec%2F0655.html&data=05%7C01%7Cakirkpat%40adobe.com%7Cf8aa45fb258041494ad608dac33397cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638036923622806417%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yNWOAM39zqIieDwvDkZ1eG%2FtJBCn3dhDrKbCZibGlHE%3D&reserved=0>)
>> I implemented this change:
>>
>>
>> https://github.com/w3c/wcag21/commit/3a2a7b9b87ebc22586f09c8864a6659840dd3694
>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fcommit%2F3a2a7b9b87ebc22586f09c8864a6659840dd3694&data=05%7C01%7Cakirkpat%40adobe.com%7Cf8aa45fb258041494ad608dac33397cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638036923622806417%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tbA0ImpUTHz7hQqt0Ig9%2F9GZjcPKSkULLuOURsuC1Xk%3D&reserved=0>
>>
>>
>>
>> This change adjusted the language from an earlier version where it was:
>>
>> Content is not locked to a specific <a>display orientation</a>, and
>> functionality of the content is operable in all display orientations,
>> except where display orientation
>>
>>       is <a>essential</a> for use of the content.
>>
>>
>>
>> To:
>>
>> Content does not restrict its view and operation to a single <a>display
>> orientation</a>, such as portrait or landscape, unless a specific display
>> orientation is <a>essential</a>.
>>
>>
>>
>> Following the minutes is hard (typing the minutes is hard – try capturing
>> all that is said by a group of 15-20 people in a room for 3 days in text!)
>> but it is clear that the discussion led to this change as a result of
>> concerns raised in the WG, and that the Call for Consensus (the way that
>> the WG approves changes, giving people a chance to think and catch up on
>> the minutes and proposed changes if they weren’t present for those) passed
>> with only positive feedback.
>>
>>
>>
>> When we create criteria, the process doesn’t always create wording that
>> everyone thinks is ideal. Sometimes there are SC that don’t get into WCAG
>> at all because there isn’t a compromise position. In this case, there was,
>> and while it may make people think that it should mean that content should
>> adapt when a screen is changed from portrait to landscape and back, that
>> wasn’t the way it was approved. Of course, in most cases this is what is
>> done and I believe that the WG knew that would be the case and that most
>> sites would exceed the basic orientation requirement.
>>
>>
>>
>> I hope this helps clarify this.
>>
>>
>>
>> Thanks,
>>
>> AWK
>>
>>
>>
>> Andrew Kirkpatrick
>>
>> Director, Accessibility
>>
>> Adobe
>>
>>
>>
>> akirkpat@adobe.com
>>
>> http://twitter.com/awkawk
>> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fawkawk&data=05%7C01%7Cakirkpat%40adobe.com%7Cf8aa45fb258041494ad608dac33397cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638036923622806417%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=i4FX%2BEyFWS%2FekAM1OIYxIdItFAsEtXuMhFaDYJ0e804%3D&reserved=0>
>>
>>
>>
>>
>>
>> *From: *John Foliot <john@foliot.ca>
>> *Date: *Thursday, November 10, 2022 at 9:10 AM
>> *To: *Brooks Newton <brooksallennewton@gmail.com>
>> *Cc: *WAI-IG <w3c-wai-ig@w3.org>
>> *Subject: *Re: Query regarding 1.3.4
>> *Resent-From: *WAI-IG <w3c-wai-ig@w3.org>
>> *Resent-Date: *Thursday, November 10, 2022 at 9:03 AM
>>
>>
>>
>> *EXTERNAL: Use caution when clicking on links or opening attachments.*
>>
>>
>>
>> Brooks,
>>
>>
>>
>> I was going to let this run its course, but I must take exception to some
>> of the assertions you are making:
>>
>>
>>
>> > I completely disagree with the notion that accepting a refresh press in
>> the browser (also known as abandoning the process) is a fix-all for
>> non-compliant content.
>>
>>
>>
>> *It's not*, It is a single Technique for meeting the *requirements of a
>> single Success Criteria. *
>>
>>
>>
>> Accessibility and accessibility conformance is subtle, it's not a brute
>> force hammer. And as you and others have noted, an
>> accessible user-experience is not a single SC, it's the sum of all of them
>> put together. When you read the Understanding Document associated to SC
>> 1.3.4, you will note that it states, "*The goal of this Success
>> Criterion is that authors should never restrict content's orientation, thus
>> ensuring that it always match the device display orientation.*" That's
>> it, just as the goal of SC 2.4.2 (Page Titled) is "*...to help users
>> find content and orient themselves within it by ensuring that each Web page
>> has a descriptive title.*"
>>
>> But, (I hear some ask), what does that have to do with page orientation?
>> Nothing - but that's the point. You could pass SC 1.3.4 in all of the
>> permutations you envision, but if you fail to provide a page <title> you've
>> STILL got an "inaccessible experience" for some users. And a page refresh
>> in that use-case is not a fix-all for that problem.
>>
>>
>>
>> > I think it is unreasonable to allow a page refresh to serve as a pass
>> for orientation content/functionality failures without clear instructions
>> at the beginning of the page to do so.
>>
>>
>>
>> That is not an unreasonable opinion, however individual opinion does not
>> a Success Criteria make. I think that in principle what you are stating is
>> indeed a Best Practice, but I also have to wonder aloud if this isn't a
>> tempest in a teapot - do you have any real evidence of users, who, *midway
>> through filling out a form*, decide to change orientation of that form?
>> I'm not suggesting that it would NEVER happen, but the law of averages and
>> logic & reason strikes me that your strawman scenario is quite the edge
>> case: that most users will have "oriented" their view long before they dive
>> into a form.
>>
>>
>>
>> > Seems like a lot of excuse making to give an inaccessible experience an
>> easy pass.
>>
>>
>>
>> Again, I believe you are conflating this into far more than it is. NOBODY
>> has said that the technique of invoking a page refresh in this scenario was
>> an awesome user experience - it isn't. Nor is anyone saying that it is a
>> "Pass" on an "inaccessible experience" - because it isn't - but it IS a
>> successful meeting of the mandated outcome of SC 1.3.4.
>>
>>
>>
>> The goal here (going all the way back to Ramakrishnan's original
>> question) is to *evaluate a single Success Criteria*, one of many that
>> add up to creating a MORE accessible experience for MOST users. And the
>> hard reality is, to meet the single goal of rendering content in a viewport
>> that has experienced a physical change in orientation is that, under some
>> conditions, some content may need to be refreshed to render properly -
>> although some quick testing here confirms to me that most forms, even when
>> you change orientation mid-way through completing them, will a) adapt to
>> the new screen parameters, and b) retain all of the content previously
>> entered.
>>
>> So to arrive at the scenario where a hard page-refresh is required to
>> ensure a partially completed form is fully visible and "actionable" after a
>> change of orientation means that there is likely a lot more funkyness on
>> that page - there will also likely be other SC failures (I cannot for one
>> second believe that a web page would pass all of the other 49 A & AA SC in
>> WCAG 2.1 and ONLY experience this one failure - I just can't).
>>
>>
>>
>> For me, Accessibility has always been about removing barriers for users,
>> and/but when the barrier cannot be fully removed, can it be minimized? (I
>> learned this the hard way back when I worked at Chase Bank - where US
>> banking regulations and serious and legitimate security concerns over DOS
>> attacks - based on actual evidence - trumped eliminating *ALL* CAPTCHAS
>> from their sites. We got rid of a lot of them, but had to accept some water
>> with our wine in some instances, our objections notwithstanding. Nobody on
>> the Accessibility team back then was happy about that, but we had no choice
>> but to accept the trade-off: a major bank site taken offline by a DOS
>> attack is inaccessible to everyone!)
>>
>> And so personally I've landed at understanding that an all-or-nothing
>> stance may feel righteous, but at the end of the day getting perfect is (by
>> my experience) unachievable - there are always trade offs. Accessibility
>> is, and always will be, a long-tail problem in part because we have
>> 'solutions' and articulated needs authored 'at scale' - based on the
>> understood needs of 'groups of users': blind/low vision, mobility impaired,
>> cognitively impaired, etc. Yet because each person is unique, so too will
>> be their needs (this is also why meeting the needs of ALL users with
>> cognition impairments is so complex - the different types of issues along
>> with the multiple degrees of severity and impact).
>>
>>
>>
>> The sad reality today is that even if a website successfully met all 50 A
>> and AA SC in WCAG 2.1, that the content may still be inaccessible to some
>> users, based on that user's individual needs. Perfection is an ideal, not
>> an outcome.
>>
>>
>>
>> With respect,
>>
>>
>>
>> JF
>>
>>
>>
>> On Wed, Nov 9, 2022 at 6:50 PM Brooks Newton <brooksallennewton@gmail.com>
>> wrote:
>>
>> Hi,
>>
>>
>>
>> All fair points, although I completely disagree with the notion that
>> accepting a refresh press in the browser (also known as abandoning the
>> process) is a fix-all for non-compliant content.  I do appreciate the clear
>> explanation from both of you, Juliette and John, as to your perspectives.
>> I was on all of those calls when this was discussed, and likely scribed for
>> a session or two during meetings on this very topic. That's the good thing
>> about being in the room when something happens - you've have first-hand
>> knowledge of what could never be believed second-hand.
>>
>>
>>
>> I never had any expectation that this normative definition would exclude
>> the scenario that I've laid out and that others have said happens more
>> often than you'd expect.
>>
>>
>>
>> Long story short from me: I think it is unreasonable to allow a page
>> refresh to serve as a pass for orientation content/functionality failures
>> without clear instructions at the beginning of the page to do so.  If it's
>> a known issue, content authors have an obligation to inform users to
>> perform a refresh before beginning to fill out the form.
>>
>>
>>
>> Seems like a lot of excuse making to give an inaccessible experience an
>> easy pass.  That happens a lot, especially with browser bugs or innately
>> inaccessible practices that are controlled by software.
>>
>>
>>
>> Brooks
>>
>>
>>
>> On Wed, Nov 9, 2022 at 3:56 PM John Foliot <john@foliot.ca> wrote:
>>
>> Hi Brooks,
>>
>> >  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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FWAI%2FWCAG21%2FUnderstanding%2Forientation.html&data=05%7C01%7Cakirkpat%40adobe.com%7Cf8aa45fb258041494ad608dac33397cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638036923622962628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=N%2B%2BDDm4hrXQ%2BJ%2Fe6d7doHp4glemCvfgActOTMFw%2BeX8%3D&reserved=0>
>> in the half-finished business license application scenario I presented?  If
>> so, really?
>>
>>
>> Viable reason? I don't understand that - what do you mean by "reason"?
>>
>>
>>
>> Are you asking, does the current technique -  G214
>> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FWAI%2FWCAG21%2FTechniques%2Fgeneral%2FG214&data=05%7C01%7Cakirkpat%40adobe.com%7Cf8aa45fb258041494ad608dac33397cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638036923622962628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GclcgrjNY%2FlQCiVoaJFFGlFr7qTtta5KALiSKYlJ%2FSw%3D&reserved=0> "Using
>> a control to allow access to content in different orientations which is
>> otherwise restricted" suffice in meeting this single Success Criteria? Yes
>> - really. It may not solve ALL problems (and may potentially introduce
>> others), but it DOES address this problem.
>>
>>
>>
>> Does it absolve content authors from also having to ensure other aspects
>> of their content is accessible?
>>
>>
>>
>> No. But we cannot try and stretch a SC to meet all possible scenarios,
>> especially when there is a confluence of multiple potential issues. As AWK
>> noted, it is less than ideal, but IF the content needs to be refreshed, BUT
>> (and?) the content author is also supporting Success Criterion 3.3.9, then
>> why would you fail this? And if using that technique DID erase previous
>> user entered data, well, that's a failure of SC 3.3.9, and NOT of SC 1.3.4.
>>
>>
>>
>> > 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?
>>
>>
>>
>> Precisely!
>>
>> WCAG is like a jigsaw puzzle, all of the SC are required to complete the
>> puzzle, and there is often an inter-dependency of multiple SC contributing
>> to the accessible experience. For example, to make a video truly accessible
>> usually requires Captions (SC 1.2.2) AND Audio Description (SC 1.2.3 and/or
>> SC 1.2.5), and I often argue that for some users (deaf/blind) a full
>> transcript should also be provided (SC 1.2.3 OR SC 1.2.8 AAA).
>>
>>
>> A page's content could easily Pass SC 1.2.2 while also failing SC 1.2.5,
>> and we see this frequently, and yet this rarely comes up as "confusing".
>> Yet intuitively, we all know that the video isn't "fully" accessible, but
>> it is partially so. How is that any different than your use-case?
>>
>> I personally think that a large part of the problem here is that too many
>> folks dive into Techniques, without stopping and truly thinking about the
>> normative text of the SC, which for 1.3.4 is pretty simple: content has to
>> "work" (render, interact, etc.) in either view format, as decided upon by
>> the end user.
>>
>>
>>
>> If content authors deliberately lock content into a fixed view, then the
>> requirement is for the end-user to be able to override that - the old W3C
>> axiom "author proposes, user disposes". Depending on *how *the author
>> "locked down" the view however, it may be as simple as invoking a
>> page-refresh, or it may be more complicated, with a dedicated "unlock"
>> button/control also furnished by the content author... it all depends on
>> how the locking is achieved.
>>
>> I'll also question your use-case (half-finished business license
>> application) as being fairly niche - I'm not saying that some users might
>> re-orient their web form after completing half of a form, but that does
>> strike me as odd... I mean, I could also change the font-face or color or
>> size midway through a form as well, but (to use your expression), Really?
>>
>>
>> Nonetheless, if the user does that, and is obligated to do a screen
>> refresh to get it to render correctly, then it is passing this single SC -
>> nothing more, nothing less. Nobody is suggesting that this is optimal, but
>> a strict reading of the SC confirms that at least this one specific SC has
>> been met. Bravo, 1 down, another 49 to go...
>>
>>
>>
>> Peace out friend
>>
>>
>>
>> JF
>>
>>
>>
>> On Wed, Nov 9, 2022 at 3:24 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FWAI%2FWCAG21%2FUnderstanding%2Forientation.html&data=05%7C01%7Cakirkpat%40adobe.com%7Cf8aa45fb258041494ad608dac33397cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638036923622962628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=N%2B%2BDDm4hrXQ%2BJ%2Fe6d7doHp4glemCvfgActOTMFw%2BeX8%3D&reserved=0>
>> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FWAI%2FWCAG21%2FUnderstanding%2Flabels-or-instructions.html&data=05%7C01%7Cakirkpat%40adobe.com%7Cf8aa45fb258041494ad608dac33397cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638036923622962628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pePDeGA57NT6QBxVRrGFT3Z60Jz9c9Ch4RsEkzdHIXQ%3D&reserved=0>?
>> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2FWCAG22%2F%23redundant-entry&data=05%7C01%7Cakirkpat%40adobe.com%7Cf8aa45fb258041494ad608dac33397cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638036923622962628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dPnMN97LqastM91sIX17S4ALxQwRdozaFkup9lCRjDM%3D&reserved=0>,
>> 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>
>> wrote:
>>
>> Thank you Giacomo​.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Alan
>>
>> . . . . -   . . - - -
>>
>> Alan Bristow ( he / him / il )
>>
>> Web Developer / Développeur Web
>>
>> Elections Canada / Élections Canada
>>
>> alan.bristow@elections.ca
>> ------------------------------
>>
>> *From:* Giacomo Petri <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
>> *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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag%2Fissues%2F2771&data=05%7C01%7Cakirkpat%40adobe.com%7Cf8aa45fb258041494ad608dac33397cf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C638036923622962628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Evr6llE2zz2naIfp5RhfYQBmVWFAchUKlnT7SPLGYtA%3D&reserved=0>
>>
>>
>>
>>
>> --
>>
>> *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"
>>
>>
>>
>>
>> --
>>
>> *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"
>>
>

-- 
*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"