- From: Peter Korn <peter.korn@oracle.com>
- Date: Thu, 23 May 2013 08:07:17 -0700
- To: Gregg Vanderheiden <gv@trace.wisc.edu>
- CC: "public-wcag2ict-tf@w3.org Force" <public-wcag2ict-tf@w3.org>
- Message-ID: <519E30A5.9010007@oracle.com>
Gregg,
Just two quick points...
1. 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.
2. I'm pretty sure that the volume lowering functionality is an
OS/VoiceOver-level function, 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.
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. 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]
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. 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. 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...
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
>
> 1. 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 ).
>
> 2. Even when automatically met - it is important for the
> NEED/requirement to stay in the list of success criteria so that:
> 1. the need is not forgotten (and disappears as tech advances) and
> 2. 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
> <mailto: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
>>> <mailto: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
>>>> <http://www.w3.org/TR/WCAG/#visual-audio-contrast-scale>, 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
>>>> <http://www.w3.org/TR/WCAG/#visual-audio-contrast-dis-audio>,
>>>> 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 <http://www.w3.org/TR/WCAG/#visual-audio-contrast-noaudio>.
>>>> *
>>> *
>>> *
>>> *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
>>>> <http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-dis-audio.html>.
>>>>
>>>>
>>>> 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> <http://www.oracle.com/>
>>>> Peter Korn | Accessibility Principal
>>>> Phone: +1 650 5069522 <tel:+1%20650%205069522>
>>>> 500 Oracle Parkway | Redwood City, CA 94064
>>>> <green-for-email-sig_0.gif> <http://www.oracle.com/commitment>
>>>> Oracle is committed to developing practices and products that help
>>>> protect the environment *
>>>
>>
>> --
>> <oracle_sig_logo.gif> <http://www.oracle.com/>
>> Peter Korn | Accessibility Principal
>> Phone: +1 650 5069522 <tel:+1%20650%205069522>
>> 500 Oracle Parkway | Redwood City, CA 94065
>> <green-for-email-sig_0.gif> <http://www.oracle.com/commitment> Oracle
>> is committed to developing practices and products that help protect
>> the environment
>
--
Oracle <http://www.oracle.com>
Peter Korn | Accessibility Principal
Phone: +1 650 5069522 <tel:+1%20650%205069522>
500 Oracle Parkway | Redwood City, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment
Received on Thursday, 23 May 2013 15:08:07 UTC