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

Re: Closed non-embedded content???

From: Peter Korn <peter.korn@oracle.com>
Date: Sat, 27 Oct 2012 21:43:49 -0700
Message-ID: <508CB805.4070207@oracle.com>
To: Gregg Vanderheiden <gv@trace.wisc.edu>
CC: "Bailey, Bruce" <Bailey@Access-Board.gov>, Michael Pluke <Mike.Pluke@castle-consult.com>, "public-wcag2ict-tf@w3.org" <public-wcag2ict-tf@w3.org>
Gregg,

I doubt there are many e-book readers that allow an override of a "do 
not read aloud" or "do not expose to AT" flag (though they wouldn't call 
it by the latter name!).  Publishers wouldn't like to publish /*any 
*/books for such an e-book, if they ever wanted to sometimes publish a 
"do not read aloud" book for that platform.

I suspect the best answer will be for gov'ts to strongly favor DRM-free 
formats and e-book readers that don't use any DRM.  In other words, to 
favor things for which explicitly inaccessible content cannot be made.

And where there are business/mission-important reasons to use an e-book 
reader that supports DRM (and for which "do not read aloud" flags are 
implemented), to expressly not acquire any such e-book/media.


Peter

On 10/27/2012 9:01 AM, Gregg Vanderheiden wrote:
> I agree.
>
> Hmmmm
>
> so maybe the answer to the questions is
>
> 1) If given the choice of a reader that ALWAYS honors the "do not read 
> aloud"  or "do not expose to AT" flag  (no accessible mode)  and one 
> that allows the user to override it (accessible mode) the gov should 
> choose the latter.
>
> Of course that wont help if the book vendor will not allow any books 
> to be sold that would play on a reader that allows the flag to be 
> overridden -- or wont allow any reader to use their decryption if it 
> does  allow flay override.
>
> i can understand not wanting to allow screen reader access because it 
> allow easy capture of text.  But arent we so close to having software 
> that can visually read text off the screen that anyone who really want 
> to steal text can just steal it that way?
>
>
> /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 27, 2012, at 7:59 AM, "Bailey, Bruce" <Bailey@Access-Board.gov 
> <mailto:Bailey@Access-Board.gov>> wrote:
>
>> Gregg, I concur with your analysis, and want to respond question you 
>> raise.
>>
>>> The question is:
>>> can players meet access regs if they honor the" do not provide 
>>> access" flag?
>>
>> A parallel situation comes up pretty often in the Federal sphere. 
>>  Really it is *any* software that *might* be used in a way that is 
>> inaccessible.  Agencies have responsibility to (1) procure software 
>> that is as accessible as possible, but then (2) develop and promote 
>> policies and practices that ensure accessibility using that software.
>>
>> I am reminded of a review I was involved with recently for a webinar 
>> package which had two modes for mutual web surfing.  The default 
>> mode, screen sharing, let participants see the presenter's mouse 
>> cursor and made sure everyone was scrolled to the same place on a web 
>> page.  There was another mode though that used the participants 
>> browser for this, and had the strong advantage of being compatible 
>> with screen reading software.  It made things more complicated, but 
>> it would be a mistake to ban this webinar software because it allowed 
>> an inaccessible mode.
>>
>

-- 
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 Sunday, 28 October 2012 04:44:49 UTC

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