- From: Peter Korn <peter.korn@oracle.com>
- Date: Fri, 24 May 2013 11:05:52 -0700
- To: Gregg Vanderheiden <gv@trace.wisc.edu>
- CC: "public-wcag2ict-tf@w3.org Force" <public-wcag2ict-tf@w3.org>
- Message-ID: <519FAC00.5050901@oracle.com>
Gregg,
I hope we might perhaps wind this discussion down; I'm sorry I've
started such a large tangent...
That said, I have a few comments, in-line below.
On 5/23/2013 9:12 PM, Gregg Vanderheiden wrote:
>
>
> *Hi all,*
> *
> *
> *You can read all the notes and comments below -- but the bottom line
> is quoted here*
> *
> *
> *
> *
> * Good catch Peter. I think we may need to **add a sentence to
> the Closed Functionality Section that reads:*
> *
> *
>
> *NOTE: If the platform has no AT, does not provide the functions
> of AT and does not support the use of AT with its APPS, then the
> APPS will have to function as closed functionality apps and also
> follow the rules established for closed functionality.
> *
>
I just re-read both Chapter 3 Closed Functionality
<http://www.w3.org/TR/wcag2ict/#closed_functionality> and also the
introductory text at the start of Appendix A
<http://www.w3.org/TR/wcag2ict/#closed_functionality_sc>. I think we
have said enough to make the issue clear. I think the sentence you
suggest above goes beyond our charter & scope into proscribing what must
be done ("then the apps WILL HAVE TO...").
>
> *
> *
>
> *Gregg *
>
>
>
>
>
>
> On May 23, 2013, at 1:49 PM, Peter Korn <peter.korn@oracle.com
> <mailto:peter.korn@oracle.com>> wrote:
>
>> 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.
>>>>
>>>
>>> iOS / Voiceover does not meet 1.4.2.
>>
>> I'm not disagreeing with this - hence the "how close" comment. Note
>> also the terminology. Firefox doesn't meet 1.4.4. An app that works
>> with the built-in Firefox zooming feature meets 1.4.4. That's the
>> possible parallel I was exploring.
>
> *GV: why doesn’t firefox meet 1.4.4? Actually I should say -- why
> doesn’t Firefox allow content to meet 1.4.4 ?
> *
No disagreement once you re-word it to "Firefox allow[s] content to meet
1.4.4". Yes it does. And VoiceOver/iOS does much of the work (but not
all of the work today) in enabling native iOS apps to meet 1.4.2.
>
>>
>>>
>>>> 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
>>
>> Again, no disagreement; the functionality is in the right direction,
>> but not sufficient to cover all of 1.4.2 (today).
>
>
>>
>>>> ...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.
>>
>> Ahhh! Now we are getting somewhere interesting. Understanding SC
>> 1.4.2
>> <http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-dis-audio.html>
>> specifies only one disability use case, as set forth in the first
>> sentence: "Individuals who use screen reading software can find it
>> hard to hear the speech output if there is other audio playing at the
>> same time".
>
> *GV: That is an example. but Understanding WCAG 2.0 does not
> override the language of the SC itself.
> *
What is 1.4.2 speaking to if not audio output from AT? And if there is
only 1 AT on the platform, and that AT+platform were to mute
non-AT-generated audio automatically... then why wouldn't 1.4.2 be met
(so long as the non-AT-generated audio from our WCAG complying app was
getting muted)?
>
>> VoiceOver is the only screen reader (I'm aware of) for iOS.
>
> *GV: Right. Since it is a locked system -- it is the only one possible *
> *
> *
>> So long as the audio-generating app is compatible with VoiceOver and
>> any volume lowering (and potential future muting) functionality, the
>> app should be able to rely on that VoiceOver/platform functionality
>> to address that accessibility issue, right? (acknowledging that today
>> that functionality is insufficient to address all of 1.4.2).
>
> *GV: Not necessarily. it only works for screen reading. But this SC
> also applies to self voicing. So lets say we have an app that self
> voices (not using voiceover). It also has audio that plays for
> everyone in the background when you view the page. Those who would
> interfere.
> *
I don't see why it does. Look at the text of the SC: "If /*any */audio
on a [non-Web document or software] plays automatically for more than 3
seconds, either a mechanism is available to pause or stop the audio, or
a mechanism is available to control audio volume independently from the
overall system volume level."
Self-voicing audio (even from a web page) is still audio, no? If
self-voicing audio plays automatically for more than 3 seconds, then...
So a self-voicing web page would need a shut-up key if it were to
automatically read itself, right? Similarly a self-voicing app. There
doesn't seem to be anything in here about whether the audio coming from
the web page / software is "self-voicing" audio or not.
> *
> *
>>
>> Certainly a self-voicing app that is also a self-non-speech
>> audio-playing app would have the responsibility of lowering/muting
>> the non-speech audio when the self-voicing functionality is running.
>> Is that what you were referring to?
>
> *GV: Yep. exactlu*
> *
> *
>> Or something else?
>
>> But, even then, such an app might not meet the letter of WCAG (e.g.
>> if the self-voicing app didn't provide a feature for turning down/off
>> the speech volume it was providing separate from the OS volume, since
>> even the built-in speech of the app ISN'T the speech of VoiceOver and
>> could therefore interfere with VoiceOver speech).
>
> *GV: Right - It would meet WCAG if it met the SC and it wouldn’t
> if it didn’t. *
>>
>>> <snip>
>>>>
>>>> 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?
>>
>> Well, this is where we start approaching the situation of "closed
>> functionality". Certainly at the extreme end is a platform for which
>> there is no AT and no or insufficient built-in accessibility features
>> to enable folks with various disabilities to have access.
>
> *GV: Well clearly it can't meet WCAG if there is no AT and not build
> in accessibility.
> *
Actually, I think it can't meet WCAG if there is no AT. Full stop. This
is because WCAG assumes the existence of AT. And that's why (excerpted
from our Chapter 3): "Because closed functionality, by definition, does
not allow a user to attach assistive technology, WCAG success criteria
that assume the presence of assistive technology will not facilitate
accessibility as WCAG 2.0 intends. Where assistive technologies cannot
be used, other output and input solutions are needed to achieve the
intent of these success criteria."
So whatever regulations incorporate & apply WCAG to non-web have to deal
with this. But it isn't up to us (that is, up to WCAG2ICT or the W3C)
to say how to deal with it. Or to claim that a way to deal with this
and thereby "meet WCAG" is to be self-voicing/self-etc.
Beyond our scope.
>
>> But at the other end...
>>
>> Had AT not developed in the past decades, with analysis techniques
>> for discerning things like columns of text and headings in the
>> command line / text application world of DOS/UNIX/Linux, then I would
>> suggest that those platforms lacked the ability to meet things like
>> 1.3.1 and 1.4.2. They lacked a means to convey structure and
>> relationships. They lacked a way to convey anything that is
>> programmatically determined.
>
> *GV: Not sure what you are saying? Are you saying that if there
> wasn’t any AT then there wouldn’t be any access? Agree. But there
> is. So... ????*
>
>>
>> Certainly an individual application, which has such structure
>> internally, might be able to first define and then convey that
>> information to AT. That is pretty much exactly what we did with the
>> Java platform running on Windows - conveyed structure and
>> relationships and object information via the Java Access Bridge to AT
>> that added support for that bridge (since at the time we started that
>> work, Windows lacked sufficient support in the OS for such things).
>
> *GV: Right.*
> *
> *
>>
>> But we are then going beyond the realm of "telling an app developer
>> how to meet SC x", and into the realm of "developing enabling
>> mechanisms to compensate for a lack in the platform so that in the
>> future app developers will be able to meet SC x". And there is
>> little an app developer may be able to do should someone want to
>> procure an app on such a platform ahead of such development. Except,
>> perhaps, write the self-voicing, self-brailling,
>> self-voice-recognizing, self... etc. etc. app.
>
> *GV: Right. If you write apps for a platform that does not have
> access features then you need to provide them.*
> *
> *
> *Or to put it more properly -- you are responsible for making your app
> accessible. If the platform provides a bunch of access functions --
> then it is MUCH easier for app developers. If not then the app
> developer doesn’t get those head starts. As a result it behooves
> the app developers to ask that these be in the platform (which is
> something that is happening now with Android --and Google is responding. *
> *
> *
> *Note also that every platform is software in itself so it needs to
> provide those capabilities for itself -- and therefore extending it to
> the apps is a logical thing to do.
> *
What I'm saying is that, on a platform without AT (such as but not
limited to a closed environment), an app cannot meet WCAG full stop.
You cannot be "accessibility supported" if that means "works with AT"
and there is no AT. Full stop.
What you may be able to do is meet M376 / 508-refreshed / whatever that
incorporates WCAG /and then further does the "things" that are needed to
address this situation./
>
>>
>> In fact, that becomes another WCAG2ICT question... Exactly what AT
>> features must an non-Web app build into itself in order to satisfy
>> all of the SCs?
>
> *GV: It doesn’t need to build in any specific features. It has to
> meet the SC. And it needs to do whatever it takes to do so. There
> may be different ways to do this. *
>
>> We have our Closed Functionality list, but we have essentially said
>> it is beyond the scope of WCAG2ICT to define this.
>
> *GV: Yes - if the app is going to be self voicing etc - and not rely
> on AT then it would probably follow the closed functionality provisions.*
>
>> So... if the platform lacks, say, a screen reader, then how can an
>> app be "accessibility supported" ever? Seems to me it can't, and it
>> falls to whatever regulatory structure incorporates WCAG for non-Web
>> software to describe that case. Full stop.
>
> *GV: Correct. If there is no AT then you have the equivalent of a
> closed functionality App - since it can't rely on AT if there isn't any. *
> *
> *
> *THis is an interesting point. Essentially -- if there IS NO AT for a
> platform, and it doesn’t provide accessibility support itself (e.g.
> the functions of AT) then it would essentially have to function as a
> closed functionality product. *
> *
> *
> *Do we add a sentence to the Closed Functionality Section that reads:*
> *
> *
>
> *NOTE: If the platform has no AT, does not provide the functions
> of AT and does not support the use of AT with its APPS then the
> APPS will all have to function as closed functionality apps and
> follow the rules established for closed functionality. *
>
> *
> *
> *
> *
>>
>>
>>>> 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.
>>
>>
>> Yes, but... As I noted above, handling such a situation seems to be
>> beyond the scope of WCAG itself. WCAG was written for an environment
>> for which there was AT and user agents and platforms that had
>> accessibility services, etc. etc. When WCAG is applied to native,
>> non-Web apps running on a platform without these things, it seems to
>> me WCAG itself falls silent on some key issues and we have to look to
>> other parts of any regulatory framework that is incorporating and
>> applying WCAG to handle the situation.
>
> *GV: Agree. I think we may need a note like the one above. *
> *
> *
> *Good catch Peter. *
>
>>
>>
>> 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 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
>
Regards,
Peter
--
Oracle <http://www.oracle.com>
Peter Korn | Accessibility Principal
Phone: +1 650 5069522 <tel:+1%20650%205069522>
500 Oracle Parkway | Redwood City, CA 94064
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment
Received on Friday, 24 May 2013 18:06:34 UTC