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

Received on Thursday, 5 November 2015 22:59:39 UTC