Re: 4.1.1 depreciation discussion

Denis writes:

> As WCAG gets bigger and bigger, the issue should not be to limit the
number of SC available. The issue should be developing a mechanism to
quickly help designers and developers figure out which ones of those SC
actually applies to the work that they are currently doing (like another
level of filters or something).

This is, as I understand it, one of the goals of Silver - to be a
framework of accessibility requirements that scales to the content/project
as required.

Imagine a filtering mechanism similar to the WCAG Quick Ref guide, where
today you can filter by Priority Level (A, AA, AAA), only the filters would
be by technology (Web, Mobile, XR, etc.). As technology grows, we will
always have a need for 'accessibility requirements' (a.k.a. Success
Criteria) for these emergent technologies, but we must also accept that not
all technologies will require (for example) Heading Structure, which is
very document structure focused, but not really applicable for, say Virtual
Reality.

Worrying about how many requirements we have is, at least to me, a false
concern: we need what we need to ensure that technologies are accessible,
and the number of requirements that takes should not be off-putting in the
least. And while the quantity of requirements for any specific technology
may seem daunting to the content creator at first, our focus is and should
always be primarily on the user-experience for PwD.

My $0.05 Cdn

JF



On Sat, Sep 21, 2019 at 11:34 AM Denis Boudreau <dboudreau01@gmail.com>
wrote:

> Thanks Wilco, this makes a lot of sense to me. I think I’m slowly leaning
> towards the “let’s deprecate 4.1.1” camp.
>
> However, I still feel like WCAG getting too big is a non-issue. We’re
> adding SC based on users needs and new technologies.
>
> Some of these (including AR/VR) are specific to particular use cases and
> will be ignored when not relevant, much like SC 1.2.x is ignored  when no
> audio or video content is present in an interface.
>
> As WCAG gets bigger and bigger, the issue should not be to limit the
> number of SC available. The issue should be developing a mechanism to
> quickly help designers and developers figure out which ones of those SC
> actually applies to the work that they are currently doing (like another
> level of filters or something).
>
>
> /Denis
>
>
>
>
> On Sat, Sep 21, 2019 at 11:50 Wilco Fiers <wilco.fiers@deque.com> wrote:
>
>> Hey all,
>>
>> I took on this task for WCAG 2.2, because I feel strongly that removing
>> 4.1.1 is the right way to go. I have not completed all the research I
>> wanted to complete. ACT has taken up more time in the past few months than
>> it usually does, so I've asked the chairs if this could be handed over.
>>
>> I think this conversation should not be based on Twitter polls, but on
>> facts. Since I'm handing this work over, or perhaps it will be dropped. I
>> did want to share what I've learned about SC 4.1.1:
>>
>>
>> 1. Outside of testing for duplicate IDs, none of the free automated
>> testing tools I've looked at test SC 4.1.1. That includes: AInspector, ARC
>> toolkit, Axe, JSX-A11y, Siteimprove, Vue-a11y and WAVE. (If you know any
>> freely available ones I've missed, please let me know)
>>
>> Additionally Trusted Tester (v5) does not test SC 4.1.1 at all. (See
>> https://section508coordinators.github.io/TrustedTester/parsing.html)
>>
>>
>> 2. I've only found 2 scenarios frequently reported under 4.1.1 that seem
>> to have an impact on PwD. Both of which can be reported under a different
>> success criterion. That's not to say there aren't any other issues, but if
>> there are it's so uncommon no expert I've asked could recall any.
>>
>> Scenario 1 is where the duplicate ID is involved in computing the
>> accessible name of some form field / button / image / whatever. Having an
>> incorrect accessible name is addressed by other success criteria as well.
>>
>> Scenario 2 has to do with an issue in Dragon. An interactive element with
>> a duplicate ID can be misidentified by Dragon, and can cause the wrong
>> thing to get activated. Since Dragon is a keyboard interface, this is a
>> failure of 2.1.1. (Definition: interface used by software to obtain
>> keystroke input).
>>
>>
>> I'll have to leave it up to the wisdom of other folks in the group how to
>> interpret this. But if David's poll is at all representative, I think
>> that's strong evidence that 4.1.1 needs to be either be dropped or
>> replaced. Think of it this way, if SC 4.1.1 was proposed today (rather than
>> already being in WCAG), does anyone think it would get accepted for WCAG
>> 2.2 with that much of opposition? I don't think we should be so concerned
>> about removing things that have (largely) outlived their usefulness.
>> Especially since a frequent concern is that WCAG is getting too big.
>>
>> Kind regards,
>>
>>
>> W
>>
>> On Sat, Sep 21, 2019 at 12:34 AM Andrew Kirkpatrick <akirkpat@adobe.com>
>> wrote:
>>
>>> David,
>>>
>>> Thanks for keeping this on your radar, but I don’t think that we can
>>> make decisions based on twitter polls. We don’t need to ignore that either,
>>> but I don’t think that your twitter poll question really captures any
>>> criteria for why it would be removed and asking people whether they agree
>>> with that, it just asks “what do you think?”.
>>>
>>>
>>>
>>> I don’t know if we will remove it or not, the group needs to discuss it.
>>> The core of the argument is that if 4.1.1 doesn’t do anything that isn’t
>>> covered by other SC, we can get rid of it. The WG needs to have a
>>> discussion regarding if 4.1.1 identifies any issues that impact users that
>>> aren’t caught elsewhere and then discuss what to do with that.
>>>
>>>
>>>
>>> So, from my perspective, the proposal to discuss 4.1.1 in the group
>>> should remain, but until the working group does so it is still just a
>>> proposal.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> AWK
>>>
>>>
>>>
>>> Andrew Kirkpatrick
>>>
>>> Head of Accessibility
>>>
>>> Adobe
>>>
>>>
>>>
>>> akirkpat@adobe.com
>>>
>>> http://twitter.com/awkawk
>>>
>>>
>>>
>>> *From: *David MacDonald <david100@sympatico.ca>
>>> *Date: *Saturday, September 21, 2019 at 1:51 AM
>>> *To: *WCAG <w3c-wai-gl@w3.org>, WCAG Editors <team-wcag-editors@w3.org>
>>> *Subject: *4.1.1 depreciation discussion
>>> *Resent-From: *WCAG <w3c-wai-gl@w3.org>
>>> *Resent-Date: *Saturday, September 21, 2019 at 1:50 AM
>>>
>>>
>>>
>>> Hi All
>>>
>>>
>>>
>>> Congratulations to all who made the long trip to Japan and those who
>>> stayed up to attend online... I  hope that everyone from North America gets
>>> a quick restoration of their circadian rhythms.
>>>
>>>
>>>
>>> I had proposed to remove 4.1.1 and point to 1.3.1 and 4.1.2 to cover the
>>> same issues.  Wilco researched it and it got a good airing on Github.
>>>
>>> https://github.com/w3c/wcag/issues/770
>>>
>>>
>>>
>>> I also tweeted out a survey.
>>> https://twitter.com/davidmacd/status/1172603177654530054
>>>
>>>
>>>
>>> It appears form both the Github thread and the survey, that support to
>>> remove it is around 48% on 33 votes, and 52% for keeping it.
>>>
>>>
>>>
>>> I think based on the Github discussion, this survey,and emails, that I
>>> should withdraw the proposal, because historically, new actions on the
>>> standard should have broad support, not moderate support.
>>>
>>>
>>>
>>> Cheers,
>>> David MacDonald
>>>
>>>
>>>
>>> *Can**Adapt* *Solutions Inc.*
>>>
>>> Tel:  613-806-9005
>>>
>>> LinkedIn
>>> <http://www.linkedin.com/in/davidmacdonald100>
>>>
>>> twitter.com/davidmacd
>>>
>>> GitHub <https://github.com/DavidMacDonald>
>>>
>>> www.Can-Adapt.com <http://www.can-adapt.com/>
>>>
>>>
>>>
>>> *  Adapting the web to all users*
>>>
>>> *            Including those with disabilities*
>>>
>>>
>>>
>>> If you are not the intended recipient, please review our privacy policy
>>> <http://www.davidmacd.com/disclaimer.html>
>>>
>>
>>
>> --
>> *Wilco Fiers*
>> Axe for Web product owner - Co-facilitator WCAG-ACT - Chair ACT-R
>>
>> --
> /Denis
>
>
> --
> Denis Boudreau
> 514-730-9168
>
>

-- 
*​John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com