Re: aria-describedat?

Benjamin Hawkes-Lewis <[email protected]> wrote:
 
> 1. ARIA is intended to be used with markup languages other than HTML,
> therefore it should cover all semantics required to make documents and
> applications accessible. (It doesn't actually do this, but then ARIA
> has always been in identity crisis.)

My recollection is that it was also designed as an interim solution, until
such time as the necessary features were added to the underlying markup
languages. Trends in recent years suggest that the interim is going to be a
very long one indeed, however.
 
> I'm ambivalent about whether we should specify @aria-describedat; my
> key point is to stress that I don't think it's a @longdesc replacement
> since I don't think implementors will create browser UI for it (but
> this thread is an opportunity to be proved wrong).

I don't think there's a consensus, or anything close to it, about which
accessibility requirements should be supported by a browser UI, and which
should be handled by browser extensions or other AT tools that, among other
capabilities, respond to Aria attributes. Without clarity on this point, it
will be harder to reach agreement about whether an Aria attribute can serve as
a sufficient @longdesc substitute, and this surely isn't the only such issue.
> 
> > My broader attitude to this entire issue is in line with Charles
> > McCathieNevile's position, but I also worry that the attention and debate whic
> > it is generating are disproportionate to the importance of the problem. I
> > think this focus on @longdesc risks deflecting resources away from larger
> > concerns affecting HTML 5, such as the discussion about the proper use and
> > accessibility implications of CANVAS.
> 
> This sort of FUD harms @longdesc and does not help <canvas>.

It isn't fud. It's a claim about prioritization of limited resources within a
constrained time-frame and the impact of such priority decisions on
accessibility over-all. The emergence of user interfaces written in Canvas
(e.g., GTK 3, LibreOffice, pdf.js, just to mention examples that have come to
my attention as under development) raises serious concerns about how canvas
will be used and whether inaccessible applications will be deployed before the
accessibility-related problems associated with Canvas are resolved.

Of course, such examples might not be the start of the trend; one could well
argue that entire UIs aren't supposed to be written in Canvas; but we know
also that trying to constrain how the Web application development community
uses a new feature is not always a successful strategy.
> 
> Please address deficiencies you see in <canvas> directly, by filing
> bugs or providing feedback on the available spec proposals.

I'll be monitoring the Canvas discussion and contributing if I think I have
something worthwhile to say on the matter.