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

Hello Janina (et. al)
Somewhere in this discussion (<wink>), I raised some concerns about
the use of iframes (inline markup) to embed external (possibly-long)
descriptions. The use of various mailing lists / target audiences
seems to cause confusion here (dpub-ig, dpub-aria, aria, etc.), so
please allow me to link directly to the two most relevant messages:

https://lists.w3.org/Archives/Public/public-digipub-ig/2015Nov/0033.html
https://lists.w3.org/Archives/Public/public-digipub-ig/2015Nov/0055.html

I would love to hear your (and anyone else's) thoughts.
Regards, Daniel




On Tue, Nov 10, 2015 at 4:17 PM, Janina Sajka <janina@rednote.net> wrote:
> But, Rich, Details can be used for all kinds of things, including
> advertising, as Charles points out. We need a way to know that this
> particular Details is a description, as opposed to some other in the
> page.
>
> Janina
>
> Richard Schwerdtfeger writes:
>> I am of the position that aria-describedat should be dropped. It is on the
>> ARIA agenda this Thursday. If others agree then I will be putting out a
>> straw poll. The reality is that aria-describedat does not address all the
>> requirements and because ARIA does not dictate user agent browser behavior
>> depending on it only helps users of assistive technology. What is needed is
>> a solution that helps all users - including those with AT. I think
>> details/summary will do it with the added media query.
>>
>> My position is that we go to details/summary and I have been working with
>> browser vendors to ensure that it is in the remaining platforms.
>>
>> If more is needed beyond details/summary, I agree with Michael this is an
>> APA issue. This is why we have an APA working group.
>>
>> Rich
>>
>>
>> Rich Schwerdtfeger
>>
>>
>>
>> From: Daniel Weck <daniel.weck@gmail.com>
>> To:   "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com>
>> Cc:   Richard Schwerdtfeger/Austin/IBM@IBMUS, Avneesh Singh
>>             <avneesh.sg@gmail.com>, "DPUB mailing list
>>             (public-digipub-ig@w3.org)" <public-digipub-ig@w3.org>, Juan
>>             Corona <juanc@evidentpoint.com>, Zheng Xu <zxu@kobo.com>, Ric
>>             Wright <rkwright@geofx.com>, Charles LaPierre
>>             <charlesl@benetech.org>, "PF (public-pfwg@w3.org)"
>>             <public-pfwg@w3.org>, George Kerscher <kerscher@montana.com>
>> Date: 11/10/2015 08:08 AM
>> Subject:      RE: FW: Proposal: remove aria-describedat from the ARIA 1.1
>>             specification
>>
>>
>>
>> In fairness to Rich, I am the one who originally prompted explanations
>> regarding the recommendation of details+summary+iframe as "best
>> practice" (following Tzvia's initial request for sample content). Let's
>> move this discussion where it belongs. Regards, Daniel
>>
>>
>> On 10 Nov 2015 1:51 p.m., "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com>
>> wrote:
>>   Hi Rich,
>>
>>
>>
>>
>>
>>   I am a little confused about why we are re-hashing this conversation and
>>   why it is happening exclusively on the DPUB list. I’ve copied the PF
>>   list, and I’ve asked Janina to add the review of the extended description
>>   analysis and next steps to the 11 November PF meeting.
>>
>>
>>
>>
>>
>>   At TPAC, we agreed that that DPUB is a stakeholder but will not define
>>   the solution to extended descriptions. I believe Michael and Janina
>>   agreed that this is up to APA. As you know DPUB has been very vocal, but
>>   we are not the only stakeholder. If I understood Michael correctly, the
>>   next step is to review the feasible approaches as pointed to by the
>>   analysis and present them to the stakeholders.
>>
>>
>>
>>
>>
>>   Please see minutes from our joint session at TPAC [1] and the extended
>>   description analysis [2] and feedback [3].
>>
>>
>>
>>
>>
>>   Thanks,
>>
>>
>>   Tzviya
>>
>>
>>
>>
>>
>>   [1] http://www.w3.org/2015/10/29-dpub-minutes.html#item03
>>
>>
>>   [2] http://www.w3.org/2015/08/extended-description-analysis.html
>>
>>
>>   [3]
>>   http://w3c.github.io/dpub-accessibility/extended-description-analysis.html
>>
>>
>>
>>
>>
>>   Tzviya Siegman
>>
>>
>>   Digital Book Standards & Capabilities Lead
>>
>>
>>   Wiley
>>
>>
>>   201-748-6884
>>
>>
>>   tsiegman@wiley.com
>>
>>
>>
>>
>>
>>   From: Daniel Weck [mailto:daniel.weck@gmail.com]
>>   Sent: Monday, November 09, 2015 2:04 PM
>>   To: Richard Schwerdtfeger
>>   Cc: Avneesh Singh; Charles LaPierre; Juan Corona; George Kerscher; DPUB
>>   mailing list (public-digipub-ig@w3.org); Ric Wright; Siegman, Tzviya -
>>   Hoboken; Zheng Xu
>>   Subject: Re: FW: Proposal: remove aria-describedat from the ARIA 1.1
>>   specification
>>
>>
>>
>>
>>
>>   My reply is inline:
>>
>>
>>
>>
>>
>>   On Sun, Nov 8, 2015 at 6:58 PM, Richard Schwerdtfeger <schwer@us.ibm.com>
>>   wrote:
>>
>>
>>
>>
>>
>>   [RICH]
>>
>>
>>   For extended descriptions, why are we concerned about media overlays.
>>   This sounds like yet another use case we were not made aware of.
>>
>>
>>   [DANIEL]
>>
>>
>>   I see. Well, at the DAISY Consortium we have an authoring tool that
>>   generates synchronized text / audio for "external" documents (i.e.
>>   out-of-line long descriptions) as well as for the primary reading flow
>>   from which the ancillary descriptions are referenced. For example, a
>>   "simplified language" description may indeed need to be narrated (using
>>   human recording, or pre-generated synthetic voice), just as much as the
>>   rest of the book.
>>
>>
>>
>>
>>
>>   I realize that this is the DPUB mailing list, and that EPUB3 Media
>>   Overlays (formerly DAISY Digital Talking Books) are not a standard
>>   feature of the Open Web Platform. However, if the W3C recommendation is
>>   to use iframes to embed additional / ancillary content, then MO playback
>>   will not function ; in any of the EPUB3 reading systems I am aware of ;
>>   because of the nested DOM context. I don't foresee a trivial
>>   implementation fix for that either.
>>
>>
>>
>>
>>
>>   [RICH]
>>   I am not convinced yet that an IFrame is a problem.
>>
>>
>>   [DANIEL]
>>
>>
>>   What about support for annotations? The reading systems I know of are
>>   able to handle annotated user selections at the top-document level only,
>>   not within isolated iframe (or object) content islands, which are
>>   typically used as blackboxes for widgets or special-purpose renderers
>>   (e.g. a 3D molecule viewer). I have seen sophisticated long descriptions,
>>   which I am sure would be worth quoting / commenting on (for the same
>>   reason that users like to annotate the primary reading flow). It would be
>>   a shame to hinder this potential use case.
>>
>>
>>
>>
>>
>>   [RICH]
>>   Regarding 5. If you go to a link you are not going to hit an escape to
>>   get back to the exact same point of regard in a web page. It sounds like
>>   you are asking for an entirely new HTML feature.
>>
>>
>>   [DANIEL]
>>
>>
>>   I am not requesting new features. My argument is that embedding ancillary
>>   documents in iframes within the main primary document makes them
>>   second-class citizens vis-a-vis functionality which I think is central in
>>   some digital publications. The problem of linking into a separate
>>   document viewport and returning back into the primary reading flow can
>>   be / is solved in EPUB reading systems (it's implemented in iBooks and
>>   Readium in different ways, but in both cases the originating reading
>>   location gets restored). Pure web browsers address this very problem by
>>   preserving the scrolling offset of the originating page, when
>>   hyperlinking into another document within the _SELF target (_BLANK ;
>>   obviously ; retains the existing context). Sure, some browsers don't
>>   preserve the actual keyboard-focused element, but that's an issue with
>>   tabbed / windowed browsing in general, and screen readers / assistive
>>   technologies.
>>
>>
>>
>>
>>
>>   [RICH]
>>   Regarding repagination, why would you want to repaginate when you are
>>   only looking at an iframe embedded in a <details> element. You are just
>>   asking to temporarily view a piece of information. The pagination should
>>   pertain to the surrounding book content - or perhaps I am missing
>>   something?
>>
>>
>>   [DANIEL]
>>
>>
>>   If I am not mistaken, the detail element is collapsible / expandable. In
>>   an EPUB reading system that paginates reflowable content (most RS do),
>>   any change of content dimensions within a given document triggers a
>>   pagination pass, so that the RS can re-sync the page count / progress
>>   (within the current chapter, and possibly across multiple chapters /
>>   spine items too). That is what I was referring to.
>>
>>
>>
>>
>>
>>   Here's another thought: unlike basic alt / popup text, external
>>   descriptions can consist in rather extensive supplementary material. I
>>   admit rarely seeing descriptions longer than one or two pages of text (as
>>   per a typical e-book paginated renderer), but it still bothers me to
>>   think that ancillary documents would be displayed in fixed-size iframes
>>   (probably within a vertical scrolling pane) whilst the primary
>>   publication documents are rendered as first-class citizens, taking into
>>   account user-chosen presentation settings (e.g. paginated vs. scroll,
>>   margin, font size, line spacing, etc.). I saw some long descriptions that
>>   are not just short temporary snippets of trivial text, I imagine that
>>   they would be hard to read when embedded within the surrounding context
>>   of the main document.
>>
>>
>>
>>   Rich Schwerdtfeger
>>
>>
>>   [DANIEL]
>>
>>
>>   Let me know if I am off-the-mark, I do not want to waste anyone's brain
>>   cycles unnecessarily.
>>
>>
>>   I just want to understand how we went from "use hidden longdesc /
>>   aria-described-at links" (out-of-line model), to "use visible detail
>>   +iframe markup to embed external documents" (inline design). This seems
>>   like a drastic paradigm shift. Beside subjective design preferences,
>>   hopefully I have managed to articulate concrete issues with the current
>>   proposal.
>>
>>
>>   Regards.
>>
>>
>>
>>
>>
>>   [END OF EMAIL]
>>
>>
>>
>>
>>   Inactive hide details for Daniel Weck ---11/06/2015 04:32:27 PM---Thanks
>>   Rich, your full email is quoted below, my response herDaniel Weck
>>   ---11/06/2015 04:32:27 PM---Thanks Rich, your full email is quoted below,
>>   my response here: 1) I couldn't agree more (aria-descr
>>
>>   From: Daniel Weck <daniel.weck@gmail.com>
>>   To: Richard Schwerdtfeger/Austin/IBM@IBMUS
>>   Cc: "DPUB mailing list (public-digipub-ig@w3.org)" <
>>   public-digipub-ig@w3.org>, Zheng Xu <zxu@kobo.com>, Tzviya - Hoboken
>>   Siegman <tsiegman@wiley.com>, Charles LaPierre <charlesl@benetech.org>,
>>   George Kerscher <kerscher@montana.com>, Avneesh Singh <
>>   avneesh.sg@gmail.com>, Ric Wright <rkwright@geofx.com>, Juan Corona <
>>   juanc@evidentpoint.com>
>>   Date: 11/06/2015 04:32 PM
>>
>>
>>
>>   Subject: Re: FW: Proposal: remove aria-describedat from the ARIA 1.1
>>   specification
>>
>>
>>
>>
>>
>>
>>
>>
>>   Thanks Rich, your full email is quoted below, my response here:
>>
>>
>>   1) I couldn't agree more (aria-describedat suffered from that same issue
>>   too).
>>
>>
>>   2) I saw sample HTML "chapters" containing a lot of images and linked
>>   external descriptions. I would venture a guess that many iframe instances
>>   loading simultaneously would be noticeable (even if the embedded
>>   documents are small, each iframe requires the browser / webview to
>>   bootstrap a separate rendering context). Perceived performance
>>   degradation during page/chapter navigation is an ongoing concern,
>>   especially on mobile devices and in web / cloud reading systems (due to
>>   concurrent HTTP requests).
>>
>>
>>   3) Agreed, but based on my experience developing reading systems (not
>>   just Readium), documents embedded in iframe sub-contexts typically cannot
>>   be processed and interacted with on par with the primary reading flow,
>>   when it comes to ; for example ; annotations (user selections + data
>>   attachments), or EPUB3 Media Overlays (synchronised text + audio
>>   playback).
>>
>>
>>   4) Arguably, that's achievable with hyperlinks + ancillary reading
>>   context too, with none of the the aforementioned drawbacks.
>>
>>
>>   5) I don't think context switching is necessarily a drawback, assuming an
>>   "escape" mechanism is provided by the user agent / reading system to
>>   restore the initial reading location (Readium's implementation of
>>   non-linear spine item navigation does just that, by the way). In a pure
>>   web browser with no polyfill to interpret special rel link semantics, a
>>   simple target _BLANK would be a viable fallback (minimum required
>>   functionality). In fact, even the "back" button of modern browsers
>>   (navigation history) does a good job at restoring the location of the
>>   activated originating hyperlink.
>>
>>
>>   Furthermore, I would like to point out that although expand/collapse
>>   areas cause no issues in reflowable content rendered in scrolling
>>   viewports, in paginated contexts it's a different matter, because page
>>   units need to be recalculated, which typically triggers the global
>>   publication paginator to resync the whole "e-book".
>>
>>
>>   Thoughts?
>>
>>
>>   Daniel
>>
>>
>>   On 6 Nov 2015 7:41 p.m., "Richard Schwerdtfeger" <schwer@us.ibm.com>
>>   wrote:
>>   >
>>   > 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
>>   >
>>   > Daniel Weck ---11/06/2015 12:34:24 PM---Thanks Rich. But why an iframe
>>   element, and not a standard a@href hyperlink? In the
>>   >
>>   > 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
>>   >
>>   > 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>
>>   > 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
>>   > >
>>   >
>>   >
>>   >
>>   >
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
>
> Janina Sajka,   Phone:  +1.443.300.2200
>                         sip:janina@asterisk.rednote.net
>                 Email:  janina@rednote.net
>
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup:       http://a11y.org
>
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Chair,  Protocols & Formats     http://www.w3.org/wai/pf
>

Received on Tuesday, 10 November 2015 16:46:10 UTC