Re: Should we drop any WCAG 2 SCs in 2.1?

>
​>​
I am not that concerned about “bloat” – the requirements are the
requirements are the requirements. The web as a platform has grown
significantly more complex and sophisticated over the 8+ years since the
original WCAG 2.0, and overall the developer’s toolbox has also grown
exponentially. I don’t think it is unreasonable to then expect that
accessibility requirements have also expanded in direct relationship to the
level of complexity introduced by today’s modern web development
practices...I’d suggest that filtering could be performed on web sites
and/or within tools, as already demonstrated in the WCAG Quickref – I don’t
think we need to worry about quantity as much as we need to ensure we have
the right number: not too many, but not too few.

That is actually my feeling also...  We may at some point want to think
about establishing filtering criteria that would show a list of SCs without
WCAG 2 stuff that we (almost) never fail people on anymore.

We can take this back to the mobile task force as another opinion in
response to the concern about SC bloat.  I don't want to combine new
proposed SCs and old WCAG2 SC (e.g. 2.1.1 and 2.5.1) to make fewer SCs,
UNLESS all the requirements of the new SC can be understood fairly easily
and we don't loose anything from the old SC after they are combined.


Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

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>

On Thu, Jul 14, 2016 at 5:27 PM, John Foliot <john.foliot@deque.com> wrote:

> Hi David,
>
>
>
> > 1.4.2 audio control, because user agents are implementing a way to mute
> a tab without muting system audio.
>
>
>
> I still would suggest that even if **most** ‘user agents’ provided this
> ability as a native control function, we can never guarantee that **all**
> user agents can do so. Additionally, just because this has been simplified
> in the majority of user-agents/browsers today in no way removes the
> requirement, it only suggests that for users today with modern browsers
> this is less difficult to achieve. Besides, “user agents” today also
> includes “native app” builds on mobile devices (etc.), and so the reliance
> on “browsers” alone is limiting.
>
>
>
> > On Firefox Control+M mutes any sound coming from the page and allows the
> screen reader to read the page.
>
>
>
> How does one activate Ctrl+M on a tablet or mobile device? I think this is
> a bad example.
>
>
>
> Additionally, I am not that concerned about “bloat” – the requirements are
> the requirements are the requirements. The web as a platform has grown
> significantly more complex and sophisticated over the 8+ years since the
> original WCAG 2.0, and overall the developer’s toolbox has also grown
> exponentially. I don’t think it is unreasonable to then expect that
> accessibility requirements have also expanded in direct relationship to the
> level of complexity introduced by today’s modern web development practices.
>
>
>
> > …but are folded away somewhere so 2.1 is not bloated with SCs that
> developers don't need to worry about.
>
>
>
> First, I think that is a false premise – the requirement will still exist
> (will **always** exist), and suggesting in a blanket statement that this
> is no longer a concern for developers is not categorically true. It may be *
> *less** of a concern in certain circumstances, but it is still a concern
> if a user-agent does not support this feature.
>
>
>
> If the concern is over ‘presentment’ of the requirements, I’d suggest
> (again) that filtering could be performed on web sites and/or within tools,
> as already demonstrated in the WCAG Quickref – I don’t think we need to
> worry about quantity as much as we need to ensure we have the right number:
> not too many, but not too few.
>
>
>
> I think you’ve hit the nail on the head: “…it would be difficult to drop
> anything and make 2.1 backward compatible”. I think I would stop there, and
> exit the thought experiment with, “No, we should not drop any SC in WCAG
> 2.1”. Put to a vote, that is how I would respond.
>
>
>
> Cheers!
>
>
>
> JF
>
>
>
> *From:* David MacDonald [mailto:david100@sympatico.ca]
> *Sent:* Thursday, July 14, 2016 3:58 PM
> *To:* John Foliot <john.foliot@deque.com>
> *Cc:* WCAG <w3c-wai-gl@w3.org>; Jeanne Spellman <jeanne@w3.org>; James
> Nurthen <james.nurthen@oracle.com>
> *Subject:* Re: Should we drop any WCAG 2 SCs in 2.1?
>
>
>
> I agree it would be difficult to drop anything and make make 2.1 backward
> compatible, unless an SC has been overcome by events, and is automatically
> met.
>
>
>
> A candidate might be...
>
>
>
> 1.4.2 audio control, because user agents are implementing a way to mute a
> tab without muting system audio. On Firefox Control+M mutes any sound
> coming from the page and allows the screen reader to read the page. The SC
> says "a mechanism is available" so now its available in a major browser...
> and will soon be in all browsers (hopefully). But for WCAG one stack is
> enough.
>
>
>
> I don't see how I can ever fail someone on 1.4.2 anymore, thanks to James
> pointing this out.  If we are looking to not cause SC bloat with the new
> SCs, perhaps we can make a new category for SCs which have been largely
> overcome by advances in User Agents etc... which still apply to 2.1 but are
> folded away somewhere so 2.1 is not bloated with SCs that developers don't
> need to worry about.
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902
>
> 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>
>
>
>
> On Thu, Jul 14, 2016 at 2:05 PM, John Foliot <john.foliot@deque.com>
> wrote:
>
> Hi David,
>
>
>
> I don't think I'm understanding the question - I can't see how we could
> remove a SC from a WCAG 2.1 and preserve a backwards-compatible path to
> 2.0.
>
>
>
> Again, WCAG is about content requirements AFAIK, and while techniques and
> patterns can come and go, the principles and Success Criteria remain, and I
> would be concerned about dropping a Success Criteria simply on the basis
> that newer technologies seemingly make it easier to achieve any individual
> Success Criteria. That, in and of itself, would not justify removing a
> requirement in my mind (only make it simpler for content authors to meet
> the Success Criteria).
>
>
>
> Can you elaborate more please?  Thanks.
>
>
>
> JF
>
>
>
> On Thu, Jul 14, 2016 at 12:00 PM, David MacDonald <david100@sympatico.ca>
> wrote:
>
> On today's mobile call Jeanne brought up an important consideration as we
> make the WCAG 2.1. If 2.1 seems much longer than 2.0 we may be facing
> resistance to the new version. It came up in the context of the question
> about whether we should try to roll new SCs into the existing SCs where
> possible, or introduce new SCs.
>
>
>
> But I think the issue raises another question.
>
>
>
> Are there any SCs that have been overcome sufficiently by the environment,
> OS, User Agents etc. that we can remove them without breaking the
> acceptance requirement of WCAG 2.1 that meeting it also meets 2.0?
>
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902
>
> 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>
>
>
>
>
>
> --
>
> John Foliot
>
> Principal Accessibility Strategist
>
> Deque Systems Inc.
>
> john.foliot@deque.com
>
>
>
> Advancing the mission of digital accessibility and inclusion
>
>
>