Re: FW: Proposal: remove aria-describedat from the ARIA 1.1 specification from Richard Schwerdtfeger on 2015-11-06 (public-digipub-ig@w3.org from November 2015)

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Fri, 6 Nov 2015 13:41:14 -0600
To: Daniel Weck <daniel.weck@gmail.com>
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>
Message-ID: <OF4E0B5CAE.3F1315A0-ON86257EF5.006B50F6-86257EF5.006C2515@us.ibm.com>


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



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

  Inactive hide details for Daniel Weck ---11/05/2015 05:00:48 PM---Thank
  you, but this is an *inline* description. How would detDaniel 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


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

image/gif attachment: graycol.gif
Received on Friday, 6 November 2015 19:41:52 UTC