RE: Proposal: remove aria-describedat from the ARIA 1.1 specification

Deborah Kaplan [mailto:dkaplan@safaribooksonline.com] wrote:
> 
> What the digital publishing industry was requesting in this particular case was a
> single mechanism for extended descriptions which always means extended
> description, and only means extended description.
> 

...which, by my standing-on-the-sideline understanding of this conversation is either @longdesc, or a non-native-html equivalent. 

Deborah and DPUB folks, is the functionality you are looking at close to this:

  * "Content" on screen (it could be an image, or it could be another complex <object>) requires an affordance that allows the end user to either "read more" (aka consume the extended description), or skip over it. (This currently makes describedby a non-starter, as screen readers today automatically provide content referenced by describedby as part of the page flow, and just reads it aloud without user-input)
  * This ability to read more should be on client demand, and not "forced" on the end user. (see above)
  * The end user has a means to either toggle on or off the visual affordance that allows the sighted user to read the extended description.
  * The extended description can be one of either a separate 'page' or content embedded into the same page, and can be rendered in either the same window (using a technique such as iFrame) or opened in a new tab, or opened in the same tab (whereby the end user would have to go "back" to the original referencing content.

(http://w3c.github.io/dpub-accessibility/extended-description-analysis.html#use-cases) 

The fact that <details>/<summary> can provide a similar function (once we get browser support) may be sufficient, although the native visual affordance is that this will provide a "drawer tab" like feature on the screen, where sighted users can "expand or collapse" the extended description. 

And then I understand that a Media Query/JavaScript device will be deployed to hide that "drawer tab" until such time as a user chooses (somehow, some way) to expose that tab?

Am I the only one here who reads this as finding a way to turn <details>/<summary>  into essentially a @longdesc function? 
Hidden from sight until such time as the sighted end-user chooses to be advised that longer descriptions are available?
That you could also use a media query and JavaScript to expose @longdesc content with an "extended description" on-screen trigger for sighted users? (  getAttribute('longdesc')  )

I am all for "many ways of skinning the cat", and if the <details>/<summary>  (or is it <figure> / details>?) solution works (despite the need for scripting to work around the fact that this solution is always exposed on screen, and needs to be hidden via scripting) then sure, I suppose we can live without aria-describedat. 

No matter which way we go, until such time as browsers provide the ability for sighted users to toggle on or off a visual indicator that notifies the user of an extended description as a native setting in the browser, you are going to have to script out this functionality/requirement some way or other. It's not so much question of which element or attribute will do what you want done, it's the user-experience that you are seeking, correct?

JF

Received on Thursday, 5 November 2015 17:51:21 UTC