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

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



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
>

Attachments

Received on Friday, 6 November 2015 17:46:35 UTC