Re: Closed non-embedded content???

Gregg,
     The definition M376 is using for closed functionality is the same as
used by the December 2011 508 ANPRM. Interestingly, the definition was
rewritten from what the TIETAC committee had proposed  for 'closed product
functionality'. It was made more concise and to remove some of the examples
which are not necessarily good examples of closed products, but some of the
meaning seems to have been lost in the process.

Snipped from Section 508 ANPRM:
Closed Functionality.  Characteristics that prevent a user from attaching
or installing assistive technology.  Examples of ICT with closed
functionality are self-service machines, information kiosks, set-top boxes,
and devices like printers, copiers, fax machines, and calculators.

From TIETAC report
Closed Product Functionality:  Functionality of a product where ASSISTIVE
TECHNOLOGY can not be used to achieve some or all of the functionality of
the electronic user interface components for any reason including hardware,
software, platform, license, or policy limitation.

Snipped from Current Section 508 instead defined Self-contained, closed
products:
Self Contained, Closed Products. Products that generally have embedded
software and are commonly designed in such a fashion that a user cannot
easily attach or install assistive technology. These products include, but
are not limited to, information kiosks and information transaction
machines, copiers, printers, calculators, fax machines, and other similar
types of products.

Proposal for a more precise definition: Characteristics that prevent a user
from attaching or installing assistive technology to access the
functionality of a product.


Best regards,


Mary Jo Mueller
IBM Research â–º Human Ability & Accessibility Center
11501 Burnet Road, Bldg. 904 Office 5D017, Austin, Texas 78758
512-286-9698 T/L 363-9698
maryjom@us.ibm.com


www.ibm.com/able and w3.ibm.com/able
IBM Accessibility on Facebook â–¼ IBMAccess on Twitter â–¼ IBM Accessibility on
LinkedIn
“If your actions inspire others to dream more, learn more, do more and
become more, you are a leader.”  ~ John Quincy Adams



From: Gregg Vanderheiden <gv@trace.wisc.edu>
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>
Date: 10/19/2012 03:56 PM
Subject: Re: Closed non-embedded content???



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
      ---------------------------------------------------------------