Re: Query regarding 1.3.4

Hi Kevin,

Accuracy and precision is important here!

There is no such thing as a normative failure criterion, it is a failure
*technique* - one of potentially many. The failure techniques in WCAG are
illustrative, and provide solid guidance on how to test (or conversely,
build), *but the list of failure techniques in WCAG is not definitive*, and
WCAG recognizes and allows for other ways of both meeting or
failing-to-meet the outcomes mandated in the normative text.

WCAG is quite clear about Techniques, when it states:

*Techniques are informative—that means they are not required. The basis for
determining conformance to WCAG 2.1 is the success criteria from the WCAG
2.1 standard—not the techniques.*
https://www.w3.org/WAI/WCAG21/Understanding/understanding-techniques#techniques-are-informative




>   ...it’s not locked into either orientation  (it doesn’t restrict its
view)

Hmmm... When Ramakrishnan asks "*I would like to know whether loss of
content or functionality that happens when the device orientation is
changed would be A Failure of Success criteria 1.3.4?*" he didn't indicate
that it didn't rotate (in fact he notes that the content changes when
rotated), he asked if, WHEN rotated, AND there is a loss of content or
functionality, THEN is it still a failure of SC 1.3.4.(?)

The answer, based on the NORMATIVE requirement, is absolutely yes:


"Content does not restrict its view *and operation* to a single display
orientation, such as portrait or landscape..."



> If the criteria were supposed to include the scenario we have here then
it would say move between portrait and landscape.

Again, I assert you are misunderstanding the Techniques and their role both
in the relationship to the normative Criteria, as well as the
different Techniques that may be used in both development and testing.

None of the WCAG Success Criteria have normative techniques, they
articulate normative OUTCOMES. WCAG goes to great lengths to underscore
this idea, and yet still today many people think that testing against the
Failure Techniques is all that is required. That is a gross
misunderstanding of the Failure Techniques.

The main content of WCAG 2.1 is normative
<https://www.w3.org/TR/WCAG21/#dfn-normative> and defines requirements that
impact conformance claims. Introductory material, appendices, sections
marked as "non-normative", diagrams, examples, and notes are informative
<https://www.w3.org/TR/WCAG21/#dfn-informative> (non-normative). *Non-normative
material provides advisory information to help interpret the guidelines but
does not create requirements *that impact a conformance claim.
https://www.w3.org/TR/WCAG21/#interpreting-normative-requirements



Just because there is no Technique for testing today that simplistically
states "*Rotate the device and ensure that there is no loss of view or
function*" does not mean that it isn't the expectation of the SC, because
the SC mandates the outcome that content both render and function in either
mode - it cares less how you got to the view mode, only that the content
works and renders properly in both modes. (* In fact, due to
future-proofing, the SC even leaves open room for the possibility of a 3rd
- or more - views, when it says "...*such as* portrait or landscape..." -
i.e. it anticipates that other modes *may* emerge in the future - 3D? -,
and so does not restrict itself to ONLY portrait or landscape modes. As an
active member of the Working Group both now and then, *we spent* *a lot* *of
time* word-smithing the new WCAG 2.1 additions.)

*W3C recommends that the only thing that is required is meeting the WCAG 2
success criteria.* The basis for determining conformance to WCAG 2 is the
success criteria from the WCAG 2 standard — not the techniques. W3C’s
*Techniques
for WCAG 2* document is informative (that is, not required, non-normative).
https://www.w3.org/WAI/standards-guidelines/wcag/faq/#techsnot



Ramakrishnan's use-case then is an unqualified failure of SC 1.3.4 - no
debate.

JF

On Tue, Nov 8, 2022 at 8:34 PM Kevin Prince <kevin.prince@fostermoore.com>
wrote:

> With respect – it’s not locked into either orientation  (it doesn’t
> restrict its view) but there is a bug for everyone when it changes between
> orientations. That affects everybody. Different countries define the
> failure vs best practice vs bug.
>
>
>
> In both failure criterion there is an explicit step to open the content in
> landscape, and one to open it in portrait. If the criteria were supposed to
> include the scenario we have here then it would say move between portrait
> and landscape. (PS, I don’t like it but if that’s how your regulator
> defines compliance then that’s the literal reading you have to take)
>
>
>
> Either way fix the bug.
>
>
>
> *Kevin Prince *
> Product Accessibility & Usability Consultant
>
> *Foster Moore*
> A Teranet Company
>
> *E* kevin.prince@fostermoore.com
> Christchurch
> *fostermoore.com <http://www.fostermoore.com/>*
>
> *From:* John Foliot <john@foliot.ca>
> *Sent:* Wednesday, 9 November 2022 11:06 am
> *To:* Kevin Prince <kevin.prince@fostermoore.com>
> *Cc:* Ramakrishnan Subramanian <ram.eict2013@gmail.com>; w3c-wai-ig@w3.org
> *Subject:* Re: Query regarding 1.3.4
>
>
>
> Hi Kevin,
>
>
>
> > It doesn't fail the failure criteria of 1.3.4 because it allows changes
> in orientation
>
>
>
> Respectfully, it *IS* a failure of SC 1.3.4, because according to
> Ramakrishnan, there *IS* "... *loss of content or functionality*" (their
> actual words). The SC does not speak to *how *that may happen (opening
> the page in either view, or when the view changes due to device rotation),
> only that the content MUST render and function correctly in both views.
> Again, the normative text clearly states:
>
>
>
> "*Content does not restrict its view and operation to a single display
> orientation*, such as portrait or landscape, unless a specific display
> orientation is essential."
> https://www.w3.org/TR/WCAG21/#orientation
>
>
>
> SC 1.3.4 is NOT about change of orientation, it is about ensuring content
> works in both views.
>
>
>
> As others have noted, a tablet could be physically locked into landscape
> mode (because it is mounted on a motorized scooter for example), but if
> page content is 'locked' into only rendering in Portrait mode, it fails.
>
> JF
>
>
>
> On Tue, Nov 8, 2022 at 4:28 PM Kevin Prince <kevin.prince@fostermoore.com>
> wrote:
>
> Strictly speaking it's a bug that needs fixing for all. It doesn't fail
> the failure criteria of 1.3.4 because it allows changes in orientation - it
> just handles them badly.
>
> Kevin
>
> *Kevin Prince *
>
> Product Accessibility & Usability Consultant
>
>
>
> *Foster Moore*
>
> A Teranet Company
>
>
>
> *E* kevin.prince@fostermoore.com
>
> Christchurch
>
> *fostermoore.com <http://www.fostermoore.com/>*
>
>
> -----Original Message-----
> From: Ramakrishnan Subramanian <ram.eict2013@gmail.com>
> Sent: Wednesday, 9 November 2022 5:06 am
> To: w3c-wai-ig@w3.org
> Subject: Query regarding 1.3.4
>
> CAUTION: This email originated from outside of the organization.
>
>
> Dear Members,
> I would like to know whether loss of content or functionality that happens
> when the device orientation is changed would be A Failure of Success
> criteria 1.3.4? or is it a best practice?
> Some Examples of loss of content /functionality that I refer during the
> change of orientation may include content truncation / overlapping / unable
> to scroll etc.
>
>
> --
>
> Thanks and Regards
> Ramakrishnan
>
>
>
>
> --
>
> *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"