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 19:00:56 UTC