RE: aria-describedat - Elsevier

It sounds like we are all coming to the same conclusion. Media queries should be a comfortable solution for everyone.

Tzviya Siegman
Digital Book Standards & Capabilities Lead
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Monday, August 24, 2015 5:44 PM
To: Paul Topping
Cc: White, Jason J; DPUB mailing list (public-digipub-ig@w3.org); PF; Gies, Edward M. (ELS-DAY); Siegman, Tzviya - Hoboken
Subject: RE: aria-describedat - Elsevier


That makes total sense.

I think tying visualization of the details/summary view based on media queries exposed through CSS in the browser should do it. Exposure of the possible additional information could be done using style sheets as well. JavaScript is out of the picture. I would like to do all this without a plugin but potentially the reading system could be modified to trigger the media query on platform that don't have a system property for that setting. e.g. exposelongdescriptions or exposeextendedcontent.

Rich


Rich Schwerdtfeger

[Inactive hide details for Paul Topping ---08/24/2015 04:07:01 PM---[Although I am not really part of this thread and may have g]Paul Topping ---08/24/2015 04:07:01 PM---[Although I am not really part of this thread and may have gotten things wrong, I will offer this fo

From: Paul Topping <pault@dessci.com<mailto:pault@dessci.com>>
To: Richard Schwerdtfeger/Austin/IBM@IBMUS, "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com<mailto:tsiegman@wiley.com>>
Cc: "White, Jason J" <jjwhite@ets.org<mailto:jjwhite@ets.org>>, "DPUB mailing list (public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>)" <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>, PF <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>, "Gies, Edward M. (ELS-DAY)" <Ted.Gies@elsevier.com<mailto:Ted.Gies@elsevier.com>>
Date: 08/24/2015 04:07 PM
Subject: RE: aria-describedat - Elsevier

________________________________



[Although I am not really part of this thread and may have gotten things wrong, I will offer this for what it’s worth.]

There is a big difference in using JavaScript in reading system implementations and requiring a reading system accept arbitrary JavaScript in the documents it processes. Since reading systems are overwhelmingly based on HTML engines, using JavaScript in their implementation is routine. It would impossible to implement one without it. On the other hand, JavaScript in the document is a big problem from many perspectives. It is a potential security hole since a malicious document could attempt to get the reading system to run its malicious code. It is also difficult for the reading system to ensure that the document’s JavaScript code does reasonable things, even when nothing malicious is intended.

Paul Topping

Design Science, Inc.
"How Science Communicates"
Makers of MathType, MathFlow, MathPlayer, Equation Editor
http://www.dessci.com



From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com]
Sent: Monday, August 24, 2015 1:53 PM
To: Siegman, Tzviya - Hoboken <tsiegman@wiley.com<mailto:tsiegman@wiley.com>>
Cc: White, Jason J <jjwhite@ets.org<mailto:jjwhite@ets.org>>; DPUB mailing list (public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>) <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>; PF <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>; Gies, Edward M. (ELS-DAY) <Ted.Gies@elsevier.com<mailto:Ted.Gies@elsevier.com>>
Subject: RE: aria-describedat - Elsevier


Use CSS driven styling from media queries. I guess I am not yet seeing the need for javascript here.

WRT aria-describedat, how were you expecting to render the alternative content without javascript for all users? Browsers, will not render it automatically. Were you going to modify the e-readers to render "more information" type renderings with the epub readers?

Rich

Rich Schwerdtfeger

[Inactive hide details for "Siegman, Tzviya - Hoboken" ---08/19/2015 08:31:32 AM---I've added the DPUB IG to this discussion so]"Siegman, Tzviya - Hoboken" ---08/19/2015 08:31:32 AM---I've added the DPUB IG to this discussion so the group can chime in. In last week's meeting we discu

From: "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com<mailto:tsiegman@wiley.com>>
To: "White, Jason J" <jjwhite@ets.org<mailto:jjwhite@ets.org>>, Richard Schwerdtfeger/Austin/IBM@IBMUS
Cc: "Gies, Edward M. (ELS-DAY)" <Ted.Gies@elsevier.com<mailto:Ted.Gies@elsevier.com>>, PF <public-pfwg@w3.org<mailto:public-pfwg@w3.org>>, "DPUB mailing list (public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>)" <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Date: 08/19/2015 08:31 AM
Subject: RE: aria-describedat - Elsevier

________________________________




I've added the DPUB IG to this discussion so the group can chime in.

In last week's meeting we discussed a strong preference for avoiding reliance on scripting. This is because many reading systems will not accept files that contain scripts. See point 8 in requirements document [1].

[1] http://www.w3.org/dpub/IG/wiki/Publisher_requirements_for_extended_descriptions


Tzviya Siegman
Digital Book Standards & Capabilities Lead
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>


-----Original Message-----
From: White, Jason J [mailto:jjwhite@ets.org]
Sent: Wednesday, August 19, 2015 9:20 AM
To: Richard Schwerdtfeger
Cc: Gies, Edward M. (ELS-DAY); PF
Subject: Re: aria-describedat - Elsevier


> On Aug 18, 2015, at 17:37, Richard Schwerdtfeger <schwer@us.ibm.com<mailto:schwer@us.ibm.com>> wrote:
>
>  we have talked about using CSS media quiries to hide the content
> unless the user turns on a feature in the host OS platform that would
> trigger a media query attribute which would turn on the visibility of
> the details element in the book.

I would strongly support further development of the media query proposal, which would continue the good work accomplished by the IndieUI working group in this area.

The capability hinted at in section 10.1 of the Media Queries Level 4 editors’ draft, if specified and implemented, would enable organizations such as the DAISY Consortium or the IMS Global Learning Consortium to design more elaborate media features than those which might be provided for in a W3C specification.

See “Scripted custom media queries”: https://drafts.csswg.org/mediaqueries-4/

and note discussion of tis topic earlier in the year by the IndieUI working group.

In the EPUB context, a reading system implemented as a Web application could define custom media features in JavaScript according to conventions developed for example by one of the organizations noted above. These features could then be used in media queries within book content to select from among the available alternatives to an image, table or other construct. The user interface for specifying the user’s needs could be provided by the reading system or externally.

This is entirely compatible with the existence of system or user agent-level preferences reflected in media features; the idea is that custom media queries would enable more elaborate user needs/preferences to be defined and used in specific contexts.


________________________________

This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.


Thank you for your compliance.

________________________________



______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com

______________________________________________________________________