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

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

 

CanAdapt Solutions Inc.

Tel:  613.235.4902

LinkedIn <http://www.linkedin.com/in/davidmacdonald100>  


twitter.com/davidmacd <http://twitter.com/davidmacd> 

 <https://github.com/DavidMacDonald> GitHub

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

 

CanAdapt Solutions Inc.

Tel:  613.235.4902 <tel:613.235.4902> 

LinkedIn <http://www.linkedin.com/in/davidmacdonald100>  


twitter.com/davidmacd <http://twitter.com/davidmacd> 

 <https://github.com/DavidMacDonald> GitHub

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.

 <mailto:john.foliot@deque.com> john.foliot@deque.com

 

Advancing the mission of digital accessibility and inclusion