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 <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]
>
>
>
>
> [image: Inactive hide details for Daniel Weck ---11/06/2015 04:32:27
> PM---Thanks Rich, your full email is quoted below, my response her]Daniel
> 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
> <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 <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
> > >
> >
> >
> >
> >
>
>
>