Re: Seeking thoughts on real world application of SC 1.4.2 Audio Control on iOS

Yep, 
I did get that.

--  In the first part of your email you talked about a new development where  1.4.4. was fulfilled by zoom on all browsers.   I mentioned that this  wasn’t new and it was true two years before WCAG came out -- and in fact -- it was BECAUSE it was true that that SC (1.4.4) was at Level AA.   So that wasn’t anything new that should change the way WCAG or that SC 1.4.4 was looked at.  That was how it was intended to work, and the situation when we drafted  WCAG 2.0.


-- THen you said you thought 1.4.2 might fall in same category.   You cited using the iPhone to listen to a podcast etc.   So the iPhone was using an app as a player or user agent for power points.   
---- I pointed out that what one browser did, did not change what was true for content (unless of course, the content could ONLY be listened to on that one platform.   Now if it was AUDIO ONLY podcast -- then we just have the ability for the APP to allow the difference in audio level.   So this can become an app only issue.   And an app can address this.  But again the need for the success criterion exists until every app automatically meets it -- and then it is needed to ensure that the next app doesn’t drop the feature.    The guidelines are not a "not done" list but a "needs to be there' list.   If at some time in the future something happens so that the need is met automatically for reasons that have nothing to do with there being access guidelines - and there is no chance that it would ever not be true -- then it might be dropped from future versions.   But having a success criterion that is easy to meet or automatically met (but there are things beyond the success criterion that should also be done) is always good.

In this case, the iOS app does not provide the required audio difference specified by the success criterion  -- so the issue hasn’t even been addressed on this one platform.  THe quieting of the audio for voiceover is good enough for people with good hearing but not sufficient for some of those with hearing loss - and not sufficient for the success criterion. 


THE MOST IMPORTANT part of all this however is
The success criteria are specifically designed so that they say what SHOULD BE TRUE -- not what an author should do.   So when user agents or software automatically and always provide the capability, then authors no longer need to  (and this is noted in the "sufficient techniques" section of Understanding WCAG 2.0 ). 

Even when automatically met - it is important for the NEED/requirement to stay in the list of success criteria so that:
 the need is not forgotten (and disappears as tech advances)  and
there is a place to attach all the other recommendations (advisory) that are not requirements but that are good to do whenever they can.


Gregg
--------------------------------------------------------
Gregg Vanderheiden Ph.D.


On May 23, 2013, at 2:32 AM, Peter Korn <peter.korn@oracle.com> wrote:

> Gregg,
> 
> You may have missed a key point I was making - that I'm looking at the WCAG SCs as applied to a native iOS application, and not to a web app running on iOS.
> 
> That is something we'll need to do a lot more of, thanks to our work and more significantly thanks to the EU & US application of WCAG to non-Web applications.
> 
> 
> Peter
> 
> On 5/22/2013 9:59 PM, Gregg Vanderheiden wrote:
>> 
>> Gregg
>> --------------------------------------------------------
>> Gregg Vanderheiden Ph.D.
>> 
>> 
>> On May 22, 2013, at 8:16 PM, Peter Korn <peter.korn@oracle.com> wrote:
>> 
>>> Hi gang,
>>> 
>>> For a (growing?) number of our success criteria, the underlying environment/platform provides support such that it is (no longer) necessary for the application to do anything special.  For example, it is no longer necessary for an application to be self-enlarging to meet SC 1.4.4 Resize Text, since virtually every current version of every browser will do this.  It is only necessary to not be incompatible with that browser feature.
>> 
>> 
>> GV2: Actually, this is not a recent development.   This was true before WCAG even went to last call the first time  (two years before it was adopted) -- and in fact was a condition for accepting that SC at level AA.   So this isn't a recent thing that changed since WCAG was released. 
>>  
>>> 
>>> Thinking now about SC 1.4.2 Audio Control, specifically on iOS, I wonder if we may be in a similar situation.  When I am listening to audio on my iPhone (e.g. listening to a podcast or music), and I use VoiceOver to interact with the phone, while VoiceOver is speaking, it lowers the volume of whatever is playing so that VoiceOver's speech is clearly intelligible.  I haven't measured, but the volume difference may be as great as the 20 dB difference specified by the AAA SC 1.4.7 Low or No Background Audio.
>> 
>> GV2:  Correct.   And back when WCAG was done this was true of a few applications.  But then and now, the success criterion was needed because it is not always true.   And it is important that, when it is not true, there is another away to achieve this.   At some point in the future when all popular platforms allow this  then it will be something that authors will no longer need to do.   The success criteria were carefully worded so that this would happen.
>> 
>> 
>> 
>> Now the question arises as to why the SC 1.4.4 (Large Text) was included in WCAG 2.0 back in 2006 if ZOOM would satisfy this success criterion.     The answer is twofold.
>> 1) because it would prevent someone from doing something (intentional or unintentional) to defeat the ZOOM.
>> 2) but most importantly - because it would bring to peoples attention (at level AA) that this was an important issue --- and to provide a place to attach advisory techniques that went much further than the success criterion in providing guidance on this important topic. 
>>  
>>> 
>>> So it seems VoiceOver/iOS is addressing the user need behind this SC; though perhaps not addressing it fully...?  I note that, at least in iOS v6.1.4 there doesn't seem to be an option to set the volume level that the "background" audio is lowered to, so the platform doesn't expose the full capability described in Understanding SC 1.4.2.  
>>> 
>>> Anyway, I'm curious about the TF's thoughts on this.  Specifically:
>>> Are we at least close to an analogous situation to SC 1.4.4, where an (iOS) app can rely on the underlying OS to handle the SC?  (of course you would test to ensure compatibility with the feature)
>> 
>> GV2:  we are getting close (but not there) -- for that one platform.  But since web pages are not written to only be viewed on that platform -- and since it isn't on other platforms  -- I don't see that it has any effect on our guidelines. 
>> 
>> Also note that when it was true across platforms for 1.4.4 with zoom -- the group still thought it important to include it.
>>> Whatever the specific requirements of the SC, have we fundamentally met the user need?  Or does anyone know of specific users for whom the built-in volume-lowering functionality of VoiceOver on iOS is insufficient
>> GV2:  since the guidelines are about content across platforms -- what one platform does is not relevant.   We had that issue too back then when Opera had many access features built in but it was only on that platform. 
>> 
>> Regards
>> 
>> Gregg
>> 
>> (we should find a way to capture some of these -- perhaps in a Q&A  or FAQ page on WCAG.   Or put it in Understanding somehow?   
>> 
>> What do people think? 
>> 
>> 
>> 
>>> Regards,
>>> 
>>> Peter
>>> 
>>> -- 
>>> <oracle_sig_logo.gif>
>>> Peter Korn | Accessibility Principal
>>> Phone: +1 650 5069522 
>>> 500 Oracle Parkway | Redwood City, CA 94064 
>>> <green-for-email-sig_0.gif> Oracle is committed to developing practices and products that help protect the environment
>> 
> 
> -- 
> <oracle_sig_logo.gif>
> Peter Korn | Accessibility Principal
> Phone: +1 650 5069522 
> 500 Oracle Parkway | Redwood City, CA 94065 
> <green-for-email-sig_0.gif> Oracle is committed to developing practices and products that help protect the environment