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

Gregg
--------------------------------------------------------
Gregg Vanderheiden Ph.D. 
On May 23, 2013, at 11:07 AM, Peter Korn <peter.korn@oracle.com> wrote:

> Gregg,
> 
> Just two quick points...
> I was ONLY speaking about whether and how close we were to a situation in which iOS apps (only) might be able to leverage/rely on built-in iOS and VoiceOver behavior to fulfill 1.4.2.

iOS  /  Voiceover does not meet 1.4.2.    

> I'm pretty sure that the volume lowering functionality is an OS/VoiceOver-level function,
Correct.   But it doesn’t meet 1.4.2
> and NOT something that is explicitly built into the podcast/music-playing app.  Given how closely integrated VoiceOver is to the platform, and its privileged status as a special application, this is certainly the way I would implement that functionality.  And perhaps a future version will extend the functionality so that complete muting is an option.
That still wouldn’t necessarily  do it for all iOS apps.  It would only take care of it for the VoiceOver use on the platform.    Other apps that self serve voice. 
> 
> As WCAG is applied more and more to non-Web environments, we may well have platform-specific (and tech-stack specific) characteristics that influence the kind of work that an application needs to do in order to meet various SCs. 
> 
Yes. 
> Therefore an app that is attempting to meet WCAG on a specific platform may be able to leverage such functionality, and techniques describing whether and how this can happen will be of increasing importance.  [Note: I am not here arguing that W3C develop and/or publish such techniques]
> 

Right - this has always been true.   Part of the cascade of accessible services that apps (and content) can rely upon if it is there.   

> One of things I'm most concerned about is actually in the other direction - characteristics of a platform that make it difficult or perhaps even impossible for an application on that platform to meet all of WCAG A/AA. 
> 
Interesting -- what are some things you see that might do this? 
> If an agency decides to deploy such a platform, there may be little to nothing an application vendor can do to offer an application that meets all of WCAG A/AA on that platform.
> 
Well, they can always just build all of the accessibility in.    and for some platforms that is needed   (but that is not a good situation or platform). 
>   And unlike the web (where an agency might install a web user agent from "Jim's Storm Door and browser company" that doesn't magnificent content or expose a DOM or work with any AT), platform-specific binaries don't have the ability to claim "accessibility supported" by noting other platforms that their app is accessible on.  Because "platform-specific" means there is only one platform that can be used to evaluate it...
> 
OK.     Can you give me some examples of this?   There are lots of platforms that don't provide some or many access features.  Apps need to provide them directly on these platforms. (there are 10s of thousands of kiosks that do this).    

this is best thought of as    "the app is responsible to provide all access to the app -- but if the operating system (or browser or other intermediate platform) can be relied up to provide some of the access features for the app -- then then app can use those to meet its requirements.   but otherwise it is responsible. 
> 
> Peter
> On 5/23/2013 6:34 AM, Gregg Vanderheiden wrote:
>> 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
>> 
> 
> -- 
> <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