RE: Current Problems with Reflow

Hi everyone,

Sorry for the delay, just clearing out some old unread email, but we do have a technique for un-fixing sticky headers:
https://www.w3.org/WAI/WCAG21/Techniques/css/C34.html


It is advisory, but it is something we regularly bring up in a ‘best practices’ section of reports.

-Alastair



From: Wayne Dick <wayneedick@gmail.com>
Sent: 25 September 2020 00:46
To: Mitchell Evan <mtchllvn@gmail.com>
Cc: Patrick H. Lauke <redux@splintered.co.uk>; WAI Interest Group <w3c-wai-ig@w3.org>
Subject: Re: Current Problems with Reflow

Thanks Michell,
The 1.4.10 fail case does. Do we have a technique to support the repositioning of fixed elements that obstruct essential content?

This failure really does not cover headings and footers that take up 50% or more of the viewport.
Actually it is harder than that, because there is a serious judgement call. Maybe we should change the fail case.

Regardless, since I am retired from AG WG, I can only alert the group to problems.

Today, fixed position elements that enlarge too much is the most prevalent condition that makes sites that do reflow, unreadable.

Best, Wayne

Best, Wayne

On Tue, Sep 22, 2020 at 11:33 PM Mitchell Evan <mtchllvn@gmail.com<mailto:mtchllvn@gmail.com>> wrote:
Hi Patrick and Wayne,

You're both right. We already have failure techniques, and these test procedures confirm the failure of the DailyMail.co.uk<http://DailyMail.co.uk> earlier in this thread.

  *   Failure of Success Criterion 1.4.4 when resizing visually rendered text up to 200 percent causes the text, image or controls to be clipped, truncated or obscured<https://www.w3.org/WAI/WCAG21/Techniques/failures/F69>
  *   Failure of Success Criterion 1.4.10 due to content disappearing and not being available when content has reflowed<https://www.w3.org/WAI/WCAG21/Techniques/failures/F102>

>> No new SC or formal fail case is needed.
>
> If not even providing a formal fail case, I find it difficult to say
> that auditors should fail these situations though.

Cheers,
Mitchell

Mitchell Evan, CPWA
linkedin.com/in/mitchellrevan<https://www.linkedin.com/in/mitchellrevan>
Twitter @mitchellrevan<https://twitter.com/mitchellrevan>
+49 1525 8950540
+1 510 375 6104


On Wed, Sep 23, 2020 at 3:19 AM Patrick H. Lauke <redux@splintered.co.uk<mailto:redux@splintered.co.uk>> wrote:
On 22/09/2020 20:29, Wayne Dick wrote:
> Finally, I think accessibility auditors should call this out as a
> failure of 1.4.10. I don't think that this needs to be done in a heavy
> handed way.

There's no "light touch" way of saying something fails. It either passes
or fails. Auditors should really only fail something if it fails the
normative wording of an SC. If this is a case of "we always intended it
to mean this/apply to this/fail this", then that probably needs to be
discussed as a substantive change/errata? Or at the very least needs to
be fully explained in the understanding document?

> No new SC or formal fail case is needed.

If not even providing a formal fail case, I find it difficult to say
that auditors should fail these situations though.

Unless what you mean is that these situations would nominally pass, but
you're suggesting that auditors should nonetheless advise (above and
beyond the normative requirements of WCAG)

> All we need is a
> clear technique that helps developers do the right thing.

Positive techniques are only informative, of course. Good to have, but
NOT adhering to a technique is not grounds for a fail. So if the
intention is indeed to fail things, this needs to be made clear I'd say.

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
--
Inclusive Design 24 (#id24) https://inclusivedesign24.org