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

Re: Closed non-embedded content???

From: David MacDonald <david100@sympatico.ca>
Date: Mon, 22 Oct 2012 14:06:25 +0200
Message-ID: <BLU0-SMTP6415C41989A0A33E9FE5E4FE7A0@phx.gbl>
CC: Gregg Vanderheiden <gv@trace.wisc.edu>, Peter Korn <peter.korn@oracle.com>, Kiran Kaja <kkaja@adobe.com>, Loïc Martínez Normand <loic@fi.upm.es>, "public-wcag2ict-tf@w3.org" <public-wcag2ict-tf@w3.org>, "stf416@etsi.org" <stf416@etsi.org>
To: Michael Pluke <Mike.Pluke@castle-consult.com>
Hmmm... What about a photo kiosk, in Canada, Kodak has outlets where you bring your disk of photos on USB etc... Plug it in and the internal software selects it, modifies it for cropping etc... And prints it off...?

Cheers
David MacDonald 
From my iPad 

On 2012-10-21, at 11:38 AM, Michael Pluke <Mike.Pluke@castle-consult.com> wrote:

> I fired a question to the list to see if there was an answer to the question – “Is there such a thing as closed non-Web non-embedded content?”. The purpose was really threefold:
>  
> 1)      To be able to give an answer to a question that we received in the last round of commenting on the M376 draft standard.
> 
> 2)      To be sure whether we should include a table of closed functionality exceptions for non-Web non-embedded content in the same way as we are doing for software. 
> 
> If there is no generally accepted examples of closed non-Web non-embedded content, then it can be argued that there is little point in including a table of exceptions for a category of things that don’t exist.
> 
> 3)      In the WCAG2ICT Introduction the currently agreed wording referring to closed functionality says “For closed functionality, where AT cannot be used, ….”.
>  
> This WCAG2ICT wording is fine, but it is of course silent on what causes the closure – software applications, software aspects of hardware, or non-Web non-embedded content. WCAG2ICT does not need to address this awkward question but, because of the way that we have divided our standard into different sections for software and non-Web non-embedded content we cannot avoid it!
>  
> I am not sure that the subsequent debate has really provided a clear answer to the question, accompanied by a clear and universally understood example.
>  
> I hope everyone is OK about me using the list to help to answer what may be seen as a problem that may be unique to M376 (but also maybe for the Access Board). But I think that the issues behind the question may be something that WCAG2ICT may need to think about when adding text to the closed SCs.
>  
> Regarding writing this text, I think that it will need to be stated that, for example, “this SC does not apply if the product is closed to assistive technologies for screen reading” – as it should not be presumed that none of the SCs apply in the case of any type of partial closure. In M376 we also propose the alternative way of meeting the accessibility need, but as was discussed at the last Task Force meeting, this is not the job of WCAG2ICT.
>                                                                                                                                                                                                                 
> Best regards
>  
> Mike
>  
>  
> From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu] 
> Sent: 19 October 2012 22:20
> To: Peter Korn
> Cc: Kiran Kaja; Loïc Martínez Normand; Michael Pluke; public-wcag2ict-tf@w3.org; stf416@etsi.org
> Subject: Re: Closed non-embedded content???
>  
>  
>  
> On Oct 19, 2012, at 3:14 PM, Peter Korn <peter.korn@oracle.com> wrote:
> 
> 
> Kiran,
> 
> What you are really talking about is how a system closed to screen reading AT, but which provides its own self-voicing functionality, deals with certain media.  And how agencies deal with this situation.
> 
> Clearly we need to capture somewhere that a federal agency shall not procure (or produce and provide to the public) eBooks with a "do not speak flag" set on them.  That is the fundamental issue.
>  
> You are talking about M316  -- not WCAG2ICT I presume. 
> 
> 
> 
> Since with eBooks we are talking about non-embedded content, we need to capture this as an issue/property of non-embedded content.  While you could fix this in some sense in the eBook (e.g. "don't purchase eBooks which respect a "do not speak" flag), such a remedy would be inappropriately broad. 
>  
> I presume you meant  "don't purchase ebook READER/PLAYER that respect a 'do not speak' flag" ?    (eBooks don't respect the flag -- they are the ones that SET the flag.)     
>  
> 
> I wonder if this is simply an example of a necessary provision that doesn't come directly out of WCAG A/AA (since you don't have DRM-encoded HTML!).  So perhaps this needs a remedy tailored to DRM situations - a provision noting that no content shall be acquired / disseminated / used where such content expressly disables accessibility features (such as the "no not speak" flag of xyz format eBooks).
> 
> Agree that we should not dig into DRM issues in WCAG2ICT .  
>  
> 
> 
>      Peter
> 
> 
> On 10/19/2012 12:36 PM, Kiran Kaja 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
>  
> -- 
> <Mail Attachment.gif>
> Peter Korn | Accessibility Principal
> Phone: +1 650 5069522 
> 500 Oracle Parkway | Redwood City, CA 94065 
> <Mail Attachment.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
> ---------------------------------------------------------------
>  
> -- 
> <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
>  
Received on Monday, 22 October 2012 12:07:10 UTC

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