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
>
> [image: Inactive hide details for Daniel Weck ---11/05/2015 05:00:48
> PM---Thank you, but this is an *inline* description. How would det]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
> <javascript:_e(%7B%7D,'cvml','daniel.weck@gmail.com');>>
> To: Zheng Xu <zxu@kobo.com <javascript:_e(%7B%7D,'cvml','zxu@kobo.com');>>
> Cc: "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com
> <javascript:_e(%7B%7D,'cvml','tsiegman@wiley.com');>>, Avneesh Singh <
> avneesh.sg@gmail.com
> <javascript:_e(%7B%7D,'cvml','avneesh.sg@gmail.com');>>, Charles LaPierre
> <charlesl@benetech.org
> <javascript:_e(%7B%7D,'cvml','charlesl@benetech.org');>>, George Kerscher
> <kerscher@montana.com
> <javascript:_e(%7B%7D,'cvml','kerscher@montana.com');>>, "DPUB mailing
> list (public-digipub-ig@w3.org
> <javascript:_e(%7B%7D,'cvml','public-digipub-ig@w3.org');>)" <
> public-digipub-ig@w3.org
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','tsiegman@wiley.com');>
> >>
> >>
> >>
> >> From: Richard Schwerdtfeger [mailto:schwer@us.ibm.com
> <javascript:_e(%7B%7D,'cvml','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
> >
>
>
>
>

Attachments

Received on Friday, 6 November 2015 18:34:46 UTC