Re: Drop longdesc, get aria-describedat?

Hi Janina,

you wrote:

"My druthers would be to accept longdesc right away and call it obsolete
but conforming. That clearly signals that a replacement is expected
while providing needed functionality right away--the same it has been
available since html 4. As I said, this is my
preference. Others may have other views."

I  find that to be an acceptable compromise.

regards
stevef

On 7 March 2012 22:28, Janina Sajka <janina@rednote.net> wrote:

> Leif Halvard Silli writes:
> >
> > I subsequently proposed that we write a separate specification for
> > @aria-describedAT/@longdesc. So rather than drop it, I suggest to run
> > with it.
> >
> > Could we do that? We would have to make a change proposal which
> > includes - or eventually promises [I'm not sure what the chairs woudl
> > want] - a specification of '@aria-describedAT/@longdesc'.
> >
> > I see 2-3 options of such a mini-spec - but there could be more:
> >
> > * Either the spec describes aria-describedAT - and obsoletes @longdesc
> >
> > * Or the spec describes aria-describedAT - and says that @longdesc can
> > be used, whenever aria-describedAT is used as well.
> >
> > * Or we write a spec which defines @longdesc as an ARIA attribute - to
> > be used as you have envisioned @aria-descrbedAT. [Thus, we would drop
> > aria-descrbedat and only have @longdesc.]
> > --
> ARIA will do DescribedAT. When we do we will consider ramifications
> across multiple markup environments, as we have always done, e.g. in a
> separate response to Silvia Pfeiffer I noted that we're considering use
> cases and requirements from Epub. Another example, we're interested in
> ARIA over SVG.
>
>
> So, writing an ARIA-DescribedAT should be considered an option to submit
> to PF. That's certainly acceptable.
>
> However, this wouldn't produce a solution today, or even next month, and
> a11y has been waiting a long time.
>
> My druthers would be to accept longdesc right away and call it obsolete
> but conforming. That clearly signals that a replacement is expected
> while providing needed functionality right away--the same it has been
> available since html 4. As I said, this is my
> preference. Others may have other views.
>
> Lastly, I would agree that HTML could also craft a mechanism to serve
> the need in a superior fashion. There's nothing wrong in doing that, but
> that would take some time, certainly. Too bad so much time has been
> wasted trying to make describedby fit where it just wasn't going to fit.
> And, every day that passes with longdesc shoved aside is another day
> when this core requirement is unmet in the spec. As previously noted, it
> hasn't been met for half a decade. That's a long time especially for a
> "living" specification that supposedly so responsive to needs.
>
> I know you're trying to find a solution, Leif. I'm doing my best to be
> as helpful as I can.
>
> Janina
>
>
> > Leif Halvard Silli
>
> --
>
> Janina Sajka,   Phone:  +1.443.300.2200
>                sip:janina@asterisk.rednote.net
>
> Chair, Open Accessibility       janina@a11y.org
> Linux Foundation                http://a11y.org
>
> Chair, Protocols & Formats
> Web Accessibility Initiative    http://www.w3.org/wai/pf
> World Wide Web Consortium (W3C)
>
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html