Re: FW: Proposal: remove aria-describedat from the ARIA 1.1 specification

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:18:18 UTC