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

On Tue, 10 Nov 2015 15:08:40 +0100, Daniel Weck <daniel.weck@gmail.com>  
wrote:

> 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

I'm not sure that details/summary+iframe is best practice, unless you  
assume a world where browsers are fundamentally not interested in meeting  
your use case.

A problem is that as of today, that might not be a stupid assumption. But  
using an iframe means it is hard to distinguish between e.g. advertising  
and an extended description, which is possibly a sub-optimal situation. It  
also means that it is very difficult for a browser to do something helpful  
for the user, providing specific interactions.

As an example of what I mean, Yandex browser has various usful behaviours  
available if you select a word or some text, and it would seem obvious  
that we might extend such behaviours with their specific user interaction  
for cases where extended description is warranted. Instead if we give the  
author all the responsibility, we will be unable to determine what is  
useful to provide, and therefore unable to offer a consistent behaviour  
for users.

Removing the attribute denies browsers the possibility to provide  
consistent experience. Keeping it does not stop authors from making a  
summary/details+iframe solution, with the attribute pointing to the  
details or even to the iframe inside it.

Keeping it also invites arguments in which many participants simply repeat  
positions they have taken before with little regard for evidence or logic.  
In the past I have dealt with those arguments in order to achieve outcomes  
that are clearly superior to those available through the path of least  
resistance, but there is a real cost to doing so.

cheers

Chaals

> 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
>> > >
>> >
>> >
>> >
>> >
>>
>>
>>


-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Tuesday, 10 November 2015 15:29:30 UTC