Re: Query regarding 1.3.4

Hi Marc,

I appreciate your thoughtful response.  This will be my last post on this
topic.  I do think it is worth considering a few more points before I log
off on this thread.

What if a user can't "see" at a glance that the page didn't load
correctly?  Being able to take in the totality of a web page at the outset
of interaction is a privilege that not everyone has.  Whether it is
blindness, low-vision, a cognitive disability that impairs one's capacity
to consider the whole page at once, it is not safe to assume at all that
folks with certain disabilities are going to be able to understand that
things are amiss on the page and that a quick refresh is in order to reset
the content/functionality.

Also, if "Refresh" gets a pass on SC 1.3.4 - Orientation, how motivated are
content owners to dig into the task of determining whether or not a tweak
or two to their content will fix the problem so that browsers will
consistently render the page correction upon orientation change?

If we've got a built-in technique in WCAG that gives an accessibility pass
on re-rendering the page correctly, how much incentive is there for browser
manufacturers to fix bugs that are at the root of this problem?

There's a lot of minimization here of the impact to people with
disabilities in this scenario of failure to render the page correctly on
re-orientation.  I put forth a number of questions to ask ouselves about
this impact in my email on November 9 at 2:24 pm CST on this thread.
Surprisingly, I don't see much response to this line inquiry - and frankly,
that's disappointing to me.

Over and Out,

Brooks Newton

On Fri, Nov 11, 2022 at 12:18 AM Marc Haunschild
<marc.haunschild@accessibility.consulting> wrote:

> Hello Brooks,
>
> I don’t think that is an easy pass. Responsive, beautiful, userfriendly
> and accessible frontends are rare. There are no easy passes or shortcuts.
>
> In my opinion it’s quite normal that if something looks strange, a refresh
> can help. It#s a daily routine - when the page does not load completely,
> does not load at all, shows strange errors and so on.
>
> Especially after changes made by users quite often things look strange
> (using the page zoom, changing text spacing and or other things that are
> covered by SCs).
>
> In my opinion that is not perfect, but yet completely acceptable.
>
> My 2 Cents…
>
> Everybody enjoy the day!
>
> Marc
>
>
>
> Am 10.11.2022 um 00:50 schrieb Brooks Newton <brooksallennewton@gmail.com
> >:
>
> 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://www.w3.org/WAI/WCAG21/Understanding/orientation.html>  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://www.w3.org/WAI/WCAG21/Techniques/general/G214> "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://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>
>>> 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
>>>>
>>>>>
>>
>> --
>> *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"
>>
>
>