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