- From: Daniel Weck <daniel.weck@gmail.com>
- Date: Tue, 10 Nov 2015 16:45:21 +0000
- To: Janina Sajka <janina@rednote.net>
- Cc: Richard Schwerdtfeger <schwer@us.ibm.com>, Avneesh Singh <avneesh.sg@gmail.com>, Charles LaPierre <charlesl@benetech.org>, Juan Corona <juanc@evidentpoint.com>, George Kerscher <kerscher@montana.com>, "DPUB mailing list (public-digipub-ig@w3.org)" <public-digipub-ig@w3.org>, "PF (public-pfwg@w3.org)" <public-pfwg@w3.org>, Ric Wright <rkwright@geofx.com>, "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com>, Zheng Xu <zxu@kobo.com>
Hello Janina (et. al) Somewhere in this discussion (<wink>), I raised some concerns about the use of iframes (inline markup) to embed external (possibly-long) descriptions. The use of various mailing lists / target audiences seems to cause confusion here (dpub-ig, dpub-aria, aria, etc.), so please allow me to link directly to the two most relevant messages: https://lists.w3.org/Archives/Public/public-digipub-ig/2015Nov/0033.html https://lists.w3.org/Archives/Public/public-digipub-ig/2015Nov/0055.html I would love to hear your (and anyone else's) thoughts. Regards, Daniel On Tue, Nov 10, 2015 at 4:17 PM, Janina Sajka <janina@rednote.net> wrote: > But, Rich, Details can be used for all kinds of things, including > advertising, as Charles points out. We need a way to know that this > particular Details is a description, as opposed to some other in the > page. > > Janina > > Richard Schwerdtfeger writes: >> I am of the position that aria-describedat should be dropped. It is on the >> ARIA agenda this Thursday. If others agree then I will be putting out a >> straw poll. The reality is that aria-describedat does not address all the >> requirements and because ARIA does not dictate user agent browser behavior >> depending on it only helps users of assistive technology. What is needed is >> a solution that helps all users - including those with AT. I think >> details/summary will do it with the added media query. >> >> My position is that we go to details/summary and I have been working with >> browser vendors to ensure that it is in the remaining platforms. >> >> If more is needed beyond details/summary, I agree with Michael this is an >> APA issue. This is why we have an APA working group. >> >> Rich >> >> >> Rich Schwerdtfeger >> >> >> >> From: Daniel Weck <daniel.weck@gmail.com> >> To: "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com> >> Cc: Richard Schwerdtfeger/Austin/IBM@IBMUS, Avneesh Singh >> <avneesh.sg@gmail.com>, "DPUB mailing list >> (public-digipub-ig@w3.org)" <public-digipub-ig@w3.org>, Juan >> Corona <juanc@evidentpoint.com>, Zheng Xu <zxu@kobo.com>, Ric >> Wright <rkwright@geofx.com>, Charles LaPierre >> <charlesl@benetech.org>, "PF (public-pfwg@w3.org)" >> <public-pfwg@w3.org>, George Kerscher <kerscher@montana.com> >> Date: 11/10/2015 08:08 AM >> Subject: RE: FW: Proposal: remove aria-describedat from the ARIA 1.1 >> specification >> >> >> >> In fairness to Rich, I am the one who originally prompted explanations >> regarding the recommendation of details+summary+iframe as "best >> practice" (following Tzvia's initial request for sample content). Let's >> move this discussion where it belongs. Regards, Daniel >> >> >> On 10 Nov 2015 1:51 p.m., "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com> >> wrote: >> Hi Rich, >> >> >> >> >> >> I am a little confused about why we are re-hashing this conversation and >> why it is happening exclusively on the DPUB list. I’ve copied the PF >> list, and I’ve asked Janina to add the review of the extended description >> analysis and next steps to the 11 November PF meeting. >> >> >> >> >> >> At TPAC, we agreed that that DPUB is a stakeholder but will not define >> the solution to extended descriptions. I believe Michael and Janina >> agreed that this is up to APA. As you know DPUB has been very vocal, but >> we are not the only stakeholder. If I understood Michael correctly, the >> next step is to review the feasible approaches as pointed to by the >> analysis and present them to the stakeholders. >> >> >> >> >> >> Please see minutes from our joint session at TPAC [1] and the extended >> description analysis [2] and feedback [3]. >> >> >> >> >> >> Thanks, >> >> >> Tzviya >> >> >> >> >> >> [1] http://www.w3.org/2015/10/29-dpub-minutes.html#item03 >> >> >> [2] http://www.w3.org/2015/08/extended-description-analysis.html >> >> >> [3] >> http://w3c.github.io/dpub-accessibility/extended-description-analysis.html >> >> >> >> >> >> Tzviya Siegman >> >> >> Digital Book Standards & Capabilities Lead >> >> >> Wiley >> >> >> 201-748-6884 >> >> >> tsiegman@wiley.com >> >> >> >> >> >> From: Daniel Weck [mailto:daniel.weck@gmail.com] >> Sent: Monday, November 09, 2015 2:04 PM >> To: Richard Schwerdtfeger >> Cc: Avneesh Singh; Charles LaPierre; Juan Corona; George Kerscher; DPUB >> mailing list (public-digipub-ig@w3.org); Ric Wright; Siegman, Tzviya - >> Hoboken; Zheng Xu >> Subject: Re: FW: Proposal: remove aria-describedat from the ARIA 1.1 >> specification >> >> >> >> >> >> My reply is inline: >> >> >> >> >> >> On Sun, Nov 8, 2015 at 6:58 PM, Richard Schwerdtfeger <schwer@us.ibm.com> >> wrote: >> >> >> >> >> >> [RICH] >> >> >> For extended descriptions, why are we concerned about media overlays. >> This sounds like yet another use case we were not made aware of. >> >> >> [DANIEL] >> >> >> I see. Well, at the DAISY Consortium we have an authoring tool that >> generates synchronized text / audio for "external" documents (i.e. >> out-of-line long descriptions) as well as for the primary reading flow >> from which the ancillary descriptions are referenced. For example, a >> "simplified language" description may indeed need to be narrated (using >> human recording, or pre-generated synthetic voice), just as much as the >> rest of the book. >> >> >> >> >> >> I realize that this is the DPUB mailing list, and that EPUB3 Media >> Overlays (formerly DAISY Digital Talking Books) are not a standard >> feature of the Open Web Platform. However, if the W3C recommendation is >> to use iframes to embed additional / ancillary content, then MO playback >> will not function ; in any of the EPUB3 reading systems I am aware of ; >> because of the nested DOM context. I don't foresee a trivial >> implementation fix for that either. >> >> >> >> >> >> [RICH] >> I am not convinced yet that an IFrame is a problem. >> >> >> [DANIEL] >> >> >> What about support for annotations? The reading systems I know of are >> able to handle annotated user selections at the top-document level only, >> not within isolated iframe (or object) content islands, which are >> typically used as blackboxes for widgets or special-purpose renderers >> (e.g. a 3D molecule viewer). I have seen sophisticated long descriptions, >> which I am sure would be worth quoting / commenting on (for the same >> reason that users like to annotate the primary reading flow). It would be >> a shame to hinder this potential use case. >> >> >> >> >> >> [RICH] >> Regarding 5. If you go to a link you are not going to hit an escape to >> get back to the exact same point of regard in a web page. It sounds like >> you are asking for an entirely new HTML feature. >> >> >> [DANIEL] >> >> >> I am not requesting new features. My argument is that embedding ancillary >> documents in iframes within the main primary document makes them >> second-class citizens vis-a-vis functionality which I think is central in >> some digital publications. The problem of linking into a separate >> document viewport and returning back into the primary reading flow can >> be / is solved in EPUB reading systems (it's implemented in iBooks and >> Readium in different ways, but in both cases the originating reading >> location gets restored). Pure web browsers address this very problem by >> preserving the scrolling offset of the originating page, when >> hyperlinking into another document within the _SELF target (_BLANK ; >> obviously ; retains the existing context). Sure, some browsers don't >> preserve the actual keyboard-focused element, but that's an issue with >> tabbed / windowed browsing in general, and screen readers / assistive >> technologies. >> >> >> >> >> >> [RICH] >> Regarding repagination, why would you want to repaginate when you are >> only looking at an iframe embedded in a <details> element. You are just >> asking to temporarily view a piece of information. The pagination should >> pertain to the surrounding book content - or perhaps I am missing >> something? >> >> >> [DANIEL] >> >> >> If I am not mistaken, the detail element is collapsible / expandable. In >> an EPUB reading system that paginates reflowable content (most RS do), >> any change of content dimensions within a given document triggers a >> pagination pass, so that the RS can re-sync the page count / progress >> (within the current chapter, and possibly across multiple chapters / >> spine items too). That is what I was referring to. >> >> >> >> >> >> Here's another thought: unlike basic alt / popup text, external >> descriptions can consist in rather extensive supplementary material. I >> admit rarely seeing descriptions longer than one or two pages of text (as >> per a typical e-book paginated renderer), but it still bothers me to >> think that ancillary documents would be displayed in fixed-size iframes >> (probably within a vertical scrolling pane) whilst the primary >> publication documents are rendered as first-class citizens, taking into >> account user-chosen presentation settings (e.g. paginated vs. scroll, >> margin, font size, line spacing, etc.). I saw some long descriptions that >> are not just short temporary snippets of trivial text, I imagine that >> they would be hard to read when embedded within the surrounding context >> of the main document. >> >> >> >> Rich Schwerdtfeger >> >> >> [DANIEL] >> >> >> Let me know if I am off-the-mark, I do not want to waste anyone's brain >> cycles unnecessarily. >> >> >> I just want to understand how we went from "use hidden longdesc / >> aria-described-at links" (out-of-line model), to "use visible detail >> +iframe markup to embed external documents" (inline design). This seems >> like a drastic paradigm shift. Beside subjective design preferences, >> hopefully I have managed to articulate concrete issues with the current >> proposal. >> >> >> Regards. >> >> >> >> >> >> [END OF EMAIL] >> >> >> >> >> Inactive hide details for Daniel Weck ---11/06/2015 04:32:27 PM---Thanks >> Rich, your full email is quoted below, my response herDaniel Weck >> ---11/06/2015 04:32:27 PM---Thanks Rich, your full email is quoted below, >> my response here: 1) I couldn't agree more (aria-descr >> >> From: Daniel Weck <daniel.weck@gmail.com> >> To: Richard Schwerdtfeger/Austin/IBM@IBMUS >> Cc: "DPUB mailing list (public-digipub-ig@w3.org)" < >> public-digipub-ig@w3.org>, Zheng Xu <zxu@kobo.com>, Tzviya - Hoboken >> Siegman <tsiegman@wiley.com>, Charles LaPierre <charlesl@benetech.org>, >> George Kerscher <kerscher@montana.com>, Avneesh Singh < >> avneesh.sg@gmail.com>, Ric Wright <rkwright@geofx.com>, Juan Corona < >> juanc@evidentpoint.com> >> Date: 11/06/2015 04:32 PM >> >> >> >> Subject: Re: FW: Proposal: remove aria-describedat from the ARIA 1.1 >> specification >> >> >> >> >> >> >> >> >> Thanks Rich, your full email is quoted below, my response here: >> >> >> 1) I couldn't agree more (aria-describedat suffered from that same issue >> too). >> >> >> 2) I saw sample HTML "chapters" containing a lot of images and linked >> external descriptions. I would venture a guess that many iframe instances >> loading simultaneously would be noticeable (even if the embedded >> documents are small, each iframe requires the browser / webview to >> bootstrap a separate rendering context). Perceived performance >> degradation during page/chapter navigation is an ongoing concern, >> especially on mobile devices and in web / cloud reading systems (due to >> concurrent HTTP requests). >> >> >> 3) Agreed, but based on my experience developing reading systems (not >> just Readium), documents embedded in iframe sub-contexts typically cannot >> be processed and interacted with on par with the primary reading flow, >> when it comes to ; for example ; annotations (user selections + data >> attachments), or EPUB3 Media Overlays (synchronised text + audio >> playback). >> >> >> 4) Arguably, that's achievable with hyperlinks + ancillary reading >> context too, with none of the the aforementioned drawbacks. >> >> >> 5) I don't think context switching is necessarily a drawback, assuming an >> "escape" mechanism is provided by the user agent / reading system to >> restore the initial reading location (Readium's implementation of >> non-linear spine item navigation does just that, by the way). In a pure >> web browser with no polyfill to interpret special rel link semantics, a >> simple target _BLANK would be a viable fallback (minimum required >> functionality). In fact, even the "back" button of modern browsers >> (navigation history) does a good job at restoring the location of the >> activated originating hyperlink. >> >> >> Furthermore, I would like to point out that although expand/collapse >> areas cause no issues in reflowable content rendered in scrolling >> viewports, in paginated contexts it's a different matter, because page >> units need to be recalculated, which typically triggers the global >> publication paginator to resync the whole "e-book". >> >> >> Thoughts? >> >> >> Daniel >> >> >> On 6 Nov 2015 7:41 p.m., "Richard Schwerdtfeger" <schwer@us.ibm.com> >> wrote: >> > >> > 1. The details and summary approach allows all users to benefit in >> accessing the external description. aria-describedby and hidden iframes >> don't do that >> > 2. I don't think that a hidden iframe is going to take that much >> overhead if all that we are doing is bringing in an external description >> > 3. An IFrame can be accessed by all users and not just screen reader >> users. >> > 4. The IFrame would address the requirement of the digital publishing >> people to allow for crowd sourced descriptions as well as alternative >> content >> > 5. A hypertext link would require you to go to an entirely separate >> document and cause a context switch. Context switches would result in >> going to an entirely different document and then you would need to go >> back and land where you left off prior to clicking the link. Iframes are >> expanded inside the details and appear like a div to assistive >> technologies and the tabbing order would follow straight through to the >> contents of the IFrame. >> > >> > I hope this enlightens. >> > >> > >> > Rich Schwerdtfeger >> > >> > Daniel Weck ---11/06/2015 12:34:24 PM---Thanks Rich. But why an iframe >> element, and not a standard a@href hyperlink? In the >> > >> > From: Daniel Weck <daniel.weck@gmail.com> >> > To: Richard Schwerdtfeger/Austin/IBM@IBMUS >> > Cc: Avneesh Singh <avneesh.sg@gmail.com>, Charles LaPierre < >> charlesl@benetech.org>, George Kerscher <kerscher@montana.com>, "DPUB >> mailing list (public-digipub-ig@w3.org)" <public-digipub-ig@w3.org>, >> "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com>, Zheng Xu <zxu@kobo.com> >> > Date: 11/06/2015 12:34 PM >> > >> > Subject: Re: FW: Proposal: remove aria-describedat from the ARIA 1.1 >> specification >> > ________________________________ >> > >> > >> > >> > Thanks Rich. >> > But why an iframe element, and not a standard a@href hyperlink? In the >> "other" aria-describedBy proposal, a *hidden* iframe is used to host the >> external document, but this was very much a hack to work around the fact >> that the described-by attribute ; unlike described-at ; cannot reference >> an external resource directly (thus the proposed iframe level of >> indirection). >> > With detail+summary, the original content document / primary reading >> flow is interfered with anyway (structually and visually), so I do not >> understand the rationale for embedding an additional iframe (which ; by >> the way ; is likely to hinder page loading performance in cases where >> there are many descriptions). >> > Surely, now that the battle is lost for a "hidden" attribute, we might >> as well promote a regular HTML hyperlink? This would address the >> objections raised by a number of browser vendors, when it comes to >> agreeing on best practice regarding the access mechanism for >> general-purpose out-of-line descriptions. >> > Could you please enlighten me? (or provide a reference to a document >> that outlines the pros/cons) >> > Many thanks! >> > Kind regards, Daniel >> > >> > On Friday, 6 November 2015, Richard Schwerdtfeger <schwer@us.ibm.com> >> wrote: >> > Daniel, >> > You would do that through the use of an iFrame inside of <details> as >> seen below (modifying ZHeng Xu's example): >> > >> > Here you go: >> > <section class="progress window"> >> > <h1>Copying "Really Achieving Your Childhood Dreams"</h1> >> > <details> >> > <summary>Copying... <progress max="375505392" >> value="97543282"></progress> 25%</summary> >> > <iframe src="xxx"</iframe> >> > </details> >> > >> > >> > at the url xxx: >> > >> > <html> >> > ... >> > <body> >> > <dl> >> > <dt>Transfer rate:</dt> <dd>452KB/s</dd> >> > <dt>Local filename:</dt> <dd>/home/rpausch/raycd.m4v</dd> >> > <dt>Remote filename:</dt> <dd>/var/www/lectures/raycd.m4v</dd> >> > <dt>Duration:</dt> <dd>01:16:27</dd> >> > <dt>Colour profile:</dt> <dd>SD (6-1-6)</dd> >> > <dt>Dimensions:</dt> <dd>320㈴0</dd> >> > </dl> >> > </dl> >> > </body> >> > </html> >> > >> > Best, >> > Rich >> > >> > Rich Schwerdtfeger >> > >> > Daniel Weck ---11/05/2015 05:00:48 PM---Thank you, but this is an >> *inline* description. How would detail+summary be used for *external* >> long >> > >> > From: Daniel Weck <daniel.weck@gmail.com> >> > To: Zheng Xu <zxu@kobo.com> >> > Cc: "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com>, Avneesh Singh < >> avneesh.sg@gmail.com>, Charles LaPierre <charlesl@benetech.org>, George >> Kerscher <kerscher@montana.com>, "DPUB mailing list ( >> public-digipub-ig@w3.org)" <public-digipub-ig@w3.org> >> > Date: 11/05/2015 05:00 PM >> > Subject: Re: FW: Proposal: remove aria-describedat from the ARIA 1.1 >> specification >> > ________________________________ >> > >> > >> > >> > Thank you, but this is an *inline* description. How would >> > detail+summary be used for *external* long descriptions? (as per >> > Rich's email, it looks like ARIA's describedat will be removed) >> > If the plan is to use a regular a@href HTML hyperlink within the >> > detail element markup, then my previous comments apply. If not, what >> > is the plan? :) >> > Daniel >> > >> > >> > >> > On Thu, Nov 5, 2015 at 10:34 PM, Zheng Xu <zxu@kobo.com> wrote: >> > > Found details/summary example in html5 >> http://www.w3.org/html/wg/drafts/html/master/semantics.html#the-details-element >> >> > > >> > > And here is a code snippet: >> > > ======================================= >> > > <section class="progress window"> >> > > <h1>Copying "Really Achieving Your Childhood Dreams"</h1> >> > > <details> >> > > <summary>Copying... <progress max="375505392" >> value="97543282"></progress> 25%</summary> >> > > <dl> >> > > <dt>Transfer rate:</dt> <dd>452KB/s</dd> >> > > <dt>Local filename:</dt> <dd>/home/rpausch/raycd.m4v</dd> >> > > <dt>Remote filename:</dt> <dd>/var/www/lectures/raycd.m4v</dd> >> > > <dt>Duration:</dt> <dd>01:16:27</dd> >> > > <dt>Colour profile:</dt> <dd>SD (6-1-6)</dd> >> > > <dt>Dimensions:</dt> <dd>320㈴0</dd> >> > > </dl> >> > > </details> >> > > </section> >> > > ======================================= >> > > >> > > Cheers, >> > > Jeff >> > > >> > > ________________________________________ >> > > From: Daniel Weck <daniel.weck@gmail.com> >> > > Sent: November 5, 2015 2:00 PM >> > > To: Siegman, Tzviya - Hoboken; Avneesh Singh; Charles LaPierre; >> George Kerscher >> > > Cc: DPUB mailing list (public-digipub-ig@w3.org) >> > > Subject: Re: FW: Proposal: remove aria-describedat from the ARIA 1.1 >> specification >> > > >> > > Hello, I would like to see an example too. >> > > I must admit, at the moment I fail to see how detail+summary falls >> > > into the same category as aria-describedAt / longdesc. Aren't these >> > > two competing / mutually-exclusive design approaches? If I remember >> > > correctly, the latter was considered in the first place because a >> > > simple URL attribute has minimal interference with the structure and >> > > visuals of the "primary" reading flow (which is what I thought >> > > publishers requested). Conversely, detail+summary requires the >> > > insertion of additional markup in the vicinity of the described >> > > element. >> > > >> > > Don't get me wrong, I like the fact that detail+summary is more >> > > semantically expressive, and that it can contain rich markup. But for >> > > detail+summary to qualify as a container or accessor for "extended / >> > > external" description, there needs to be additional metadata >> > > associated with the element (e.g. role value, or ; sigh ; a CSS class >> > > name convention), in order for supporting reading systems to >> interpret >> > > and render content selectively (Media Query would definitely help >> here >> > > to). So, this can in fact already be implemented *today* using >> > > existing HTML markup, even though detail+summary is arguably a >> cleaner >> > > solution (declarative, with built-in collapse/expand behaviour). >> > > >> > > I should point out that I have a personal preference for >> > > non-obfuscated/hidden features supported by mainstream user agents >> > > (standard user interface affordance), that is to say not just >> > > specialised assistive technology (which was one of the big criticism >> > > of longdesc etc. leading up to the objection of some browser >> vendors). >> > > So in principle, my vote would go for detail+summary, but given that >> > > this appears to be a totally different design approach compared to >> > > aria-describedAt, I wonder whether this paradigm shift is (1) purely >> > > pragmatic (i.e. the battle for longdesc and aria-describedAt adoption >> > > is pretty much lost), or (2) if a consensus has in fact emerged >> > > amongst stakeholders (disability community, browser vendors, etc.) >> > > such that traditional hyperlinking is now considered best practice. >> > > >> > > Sorry if I am off-the-mark, I may have missed some of the discussions >> > > resulting in the promotion of detail/summary as an alternative to >> > > aria-describedAt. Also, I haven't seen concrete examples so I may be >> > > misunderstanding the proposal. >> > > >> > > Kind regards, Daniel >> > > >> > > On Thu, Nov 5, 2015 at 3:52 PM, Siegman, Tzviya - Hoboken >> > > <tsiegman@wiley.com> wrote: >> > >> FYI >> > >> >> > >> >> > >> >> > >> If anyone has samples of <details>/<summary> in use for extended >> > >> description, please pass them along so that we can help out with >> > >> documentation of best practices. >> > >> >> > >> >> > >> >> > >> Tzviya >> > >> >> > >> >> > >> >> > >> Tzviya Siegman >> > >> >> > >> Digital Book Standards & Capabilities Lead >> > >> >> > >> Wiley >> > >> >> > >> 201-748-6884 >> > >> >> > >> tsiegman@wiley.com >> > >> >> > >> >> > >> >> > >> From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com] >> > >> Sent: Thursday, November 05, 2015 10:42 AM >> > >> To: WAI Protocols & Formats >> > >> Cc: DPUB-ARIA >> > >> Subject: Proposal: remove aria-describedat from the ARIA 1.1 >> specification >> > >> >> > >> >> > >> >> > >> After discussions with Microsoft and following the bug tracker for >> Firefox >> > >> it appears that <details>/<summary> is going to be implemented at >> some point >> > >> in both Edge and Firefox. This addresses the gaps in browser >> support. A >> > >> media query will need to be created at some point to handle the >> > >> showing/hiding of this element, and I see those discussions are >> happening, >> > >> but I believe this addresses the requirements of the digital >> publishing >> > >> industry. >> > >> >> > >> Since this requirement is being met I would like to propose the >> removal of >> > >> aria-describedat from the ARIA 1.1 specification at the next ARIA >> Working >> > >> Group meeting. Are there any objections? Do you agree? >> > >> >> > >> We can vote on the next ARIA WG call but I wanted to give people a >> heads up. >> > >> >> > >> Rich >> > >> >> > >> >> > >> Rich Schwerdtfeger >> > > >> > >> > >> > >> > >> >> >> >> >> >> >> > > > > -- > > Janina Sajka, Phone: +1.443.300.2200 > sip:janina@asterisk.rednote.net > Email: janina@rednote.net > > Linux Foundation Fellow > Executive Chair, Accessibility Workgroup: http://a11y.org > > The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) > Chair, Protocols & Formats http://www.w3.org/wai/pf >
Received on Tuesday, 10 November 2015 16:46:12 UTC