W3C home > Mailing lists > Public > public-digipub-ig@w3.org > November 2015

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

From: Daniel Weck <daniel.weck@gmail.com>
Date: Thu, 5 Nov 2015 22:58:50 +0000
Message-ID: <CA+FkZ9EhUs_BXiUjp9vTqjOnYYWRyHPP_gE0WHh0OfngMa695g@mail.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>
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? :)

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×240</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
>> 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
Received on Thursday, 5 November 2015 22:59:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 25 April 2017 10:44:35 UTC