Re: aria-describedat

On Thu, Mar 22, 2012 at 2:02 PM, Richard Schwerdtfeger
<schwer@us.ibm.com> wrote:
> While that could be done we would have to create one for SVG too and the
> author would have to learn something new.

Why do you think we'd need to create one for SVG? For SVG host
documents, what's wrong with <desc> (potentially with inlined HTML)?
For SVG inlined in HTML, what's wrong with @descriptionurl on the
element that contains the "svg" element?

> This was the problem with HTML4.

Was it?

> We had a longdesc,  a summary on table, an alt on img, a title on

How was that a problem - those attributes have different purposes and
(vaguely) appropriate behaviors and names to match.

Even in ARIA, those functionalities are broken out - we have
@aria-describedat, @aria-describedby, @aria-label, etc.

> Then we go to SVG and start  over again. Let's make accessibility semantics consistent across technologies.

You are proposing to do that by reusing a vocabulary (ARIA), but the
web already has a reusable vocabulary for common document and
application semantics (HTML): it does not need two.

Is there room for a reusable abstraction of the differing platform
accessibility APIs? Probably, but that can be reused as a mapping
rather than imported as a ragtag collection of markup attributes.

Is there room for markup annotations aimed at accessibility APIs?
Probably, but that's not the same as features that are intended to
form the basis of browser UI.

> Besides, HTML5 already is huge.

As HTML5 is a host language, adding features to ARIA makes it huger.
Since the interactions between ARIA features and HTML features are
complex to spec and hard for developers to understand, adding features
to ARIA likely makes more work than adding features to HTML proper.
This work has to be repeated every time another language is made an
ARIA host language.

--
Benjamin Hawkes-Lewis

Received on Thursday, 22 March 2012 15:31:44 UTC