W3C home > Mailing lists > Public > public-wcag2ict-tf@w3.org > October 2012

Re: Closed non-embedded content???

From: Gregg Vanderheiden <gv@trace.wisc.edu>
Date: Fri, 19 Oct 2012 15:55:45 -0500
To: Kiran Kaja <kkaja@adobe.com>
Cc: Loïc Martínez Normand <loic@fi.upm.es>, Peter Korn <peter.korn@oracle.com>, Michael Pluke <Mike.Pluke@castle-consult.com>, "public-wcag2ict-tf@w3.org" <public-wcag2ict-tf@w3.org>, "stf416@etsi.org" <stf416@etsi.org>
Message-id: <942E1B41-1DA0-4531-95F7-238355F0F551@trace.wisc.edu>
On Oct 19, 2012, at 2:36 PM, Kiran Kaja <kkaja@adobe.com> wrote:

> It appears as if we are trying to combine multiple issues.
>  <SNIP>


> Both Adobe Digital Editions on Mac and PC and iBooks on the iOS platform are used to read protected ebooks. If you have the necessary permissions to access the content on these platforms, they let you use your assistive technology to read those books.

> 


I agree



>  <SNIP>

> First, here is a clear and simple definition of closed functionality from the Mandate 376 EN. 
> closed functionality: characteristics that prevent a user from attaching or installing assistive technology


>  <SNIP>

> On the other hand, using Kindle as an example for closed non-embedded content doesn’t make sense as the Kindle platform itself is closed.
>  
> Let us not confuse/combine “attaching or installing assistive technology” and “TTS Flag”. They are two different issues. And as per the definition of closed functionality in the EN, we are only concerned with “attaching or installing assistive technology”.
>  

I may be misunderstanding this -
but I don't think this is an accurate definition of closed functionality 
And unless I'm misunderstanding - this is not how it should apply to non-embedded content.


First - a definition should be substitutable for the original term.    This is an ISO rule and I think it is supposed to apply to ETSI as well 

'Characteristics ' -- is not a substitute for 'functionality'.  

closed functionality definitions should read
   "Functionality (or a synonym)  that ....  etc.....

It should also focus on "USING" AT - not just installing or attaching.    It may be possible to install or attach AT and still not have it work with particular functionality" 



I would suggest something more like

"functionality where the user cannot attach, install or otherwise use assistive technologies to control and/or present information in alternate ways"
OR
"functionality that cannot be used with assistive technologies that control and/or present information in alternate ways"
OR
"functionality that cannot be used with assistive technologies"




Second - Non-embeded content that have DRM enabled, that cannot be accessed by a person with a disability even if that person DOES have permission to use the product, is indeed an accessibility barrier and should be considered to have closed functionality.    In fact, the way this usually works is that DRM content is encoded in a fashion that prevents its contents from being displayed on a player that will work with AT.  And in fact, players are not allowed to decode the DRM unless they also agree to not expose programmatically.  So when the author choses that DRM, they choose to encode their information in a fashion that is not accessible to AT.  

Is it OK for content to use DRM?  YES!   There is no prohibition to having closed functionality.   But it does trigger the need for closed functionality provisions.   So players that have closed functionality (in order to meet DRM rules) must provide the alternate presentation modes specified by the closed functionality provisions.     And content that asks that players treat it contents as closed - must choose encryption formats and DRM that has players that will present in other formats. 

- if the content does not - then it isn't accessible to people who are blind (and others) -- and it should fail the M376/508 provisions that relate to access by these groups.  Simply because it is a fact that it is not accessible to them. 

- if the content chooses a format/DRM that DOES have players that can present the information in different forms -- BUT the CONTENT ALSO sets a flag that says that the players  SHOULD NOT USE those other presentations methods (e.g. should not read the text aloud) then the content should also fail access provisions because it BOTH (a) is not accessible to AT (will not run on players that expose info to AT) AND  (b) it ALSO tells the players to NOT implement or use the alternate access features in the players. 
If both of these are true -- then the content is not accessible -- and again the content should fail 508/M376. 


Gregg
--------------------------------------------------------
Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering University of Wisconsin-Madison
Technical Director - Cloud4all Project - http://Cloud4all.info
Co-Director, Raising the Floor - International - http://Raisingthefloor.org
and the Global Public Inclusive Infrastructure Project -  http://GPII.net

On Oct 19, 2012, at 2:36 PM, Kiran Kaja <kkaja@adobe.com> wrote:

> It appears as if we are trying to combine multiple issues.
>  
> First, here is a clear and simple definition of closed functionality from the Mandate 376 EN. 
> closed functionality: characteristics that prevent a user from attaching or installing assistive technology
>  
> for the purposes of clause 10 in the Mandate 376, we are only concerned with non-web non-embedded content. You wouldn’t attach or install assistive technology directly to a DRM protected content. If you do not have the necessary permissions to access the DRM content, you will not be able to access the content irrespective of you being an assistive technology user or not.
>  
> Now, there is an ebook platform in the market (Kindle) which has a specific flag to disable TTS output. but this TTS flag has nothing to do with assistive technology. The TTS/voice output feature is a feature provided by the platform. You cannot attach assistive technology to either the non-embedded content or the user agent on this platform. So, the user agent is closed functionality. And perhaps one can say that the content on this platform may potentially also be closed. But in this context, the content has no use or application outside the user agent. In other words, no user can do anything with this content outside of the platform.
>  
> Both Adobe Digital Editions on Mac and PC and iBooks on the iOS platform are used to read protected ebooks. If you have the necessary permissions to access the content on these platforms, they let you use your assistive technology to read those books.

> On the other hand, using Kindle as an example for closed non-embedded content doesn’t make sense as the Kindle platform itself is closed.
>  
> Let us not confuse/combine “attaching or installing assistive technology” and “TTS Flag”. They are two different issues. And as per the definition of closed functionality in the EN, we are only concerned with “attaching or installing assistive technology”.
>  
> Regards,
> Kiran Kaja
> Adobe Systems
>  
> From: Loïc Martínez Normand [mailto:loic@fi.upm.es] 
> Sent: 19 October 2012 19:31
> To: Peter Korn
> Cc: Michael Pluke; public-wcag2ict-tf@w3.org
> Subject: Re: Closed non-embedded content???
>  
> Hi,
>  
> Sorry for being late in this thread, but here are my "two cents".
>  
> I agree with Gregg and Peter. The non-web non-embedded content can be closed (by DRM) to accessibility features such as speech output. Of course it is the user agent who will make this "closure" happen. But if the content has the "voice output disabled" bit, then the user agent will be unable to provide non-visual access (of course, if the user agent behaves properly according to DRM). And, as Peter says, this is a "classical" example of "closed by policy".
>  
> To me this is not different to interactivity. Non-web non-embedded content, according to our definition, can be interactive, but the interactivity will only happen when the user agent is presenting the content.
>  
> Best regards,
> Loïc
> 
> On Fri, Oct 19, 2012 at 7:15 PM, Peter Korn <peter.korn@oracle.com> wrote:
> Mike,
> 
> The DRM examples that Gregg raises in this thread arise from a combination of the document & the user agent.  In order for the DRM to work, the document (and any transmission of the document) needs to be encrypted, with the user agent doing the decryption.  And the situations in which the DRM does certain types of decryption depends upon the document.  
> 
> Perhaps this is more "closed by policy" (of the rights holder), but the "closing bit or flag" is within the document.
> 
> 
> Peter
>  
> 
> On 10/19/2012 5:48 AM, Michael Pluke wrote:
> Is there such a thing as non-Web non-embedded content that is closed?
>  
> Can anyone think of any examples? We need to answer this question urgently. In all the cases that we can think of it is the device (i.e. the user agent) that is closed.
>  
> Best regards
>  
> Mike
>  
> -- 
> <image001.gif>
> Peter Korn | Accessibility Principal
> Phone: +1 650 5069522 
> 500 Oracle Parkway | Redwood City, CA 94065 
> <image002.gif>Oracle is committed to developing practices and products that help protect the environment
> 
> 
>  
> -- 
> ---------------------------------------------------------------
> Loïc Martínez-Normand
> DLSIIS. Facultad de Informática
> Universidad Politécnica de Madrid
> Campus de Montegancedo
> 28660 Boadilla del Monte
> Madrid
> ---------------------------------------------------------------
> e-mail: loic@fi.upm.es
> tfno: +34 91 336 74 11
> ---------------------------------------------------------------
Received on Friday, 19 October 2012 20:56:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:17:47 UTC