Re: aria-describedat?

On Wed, Mar 14, 2012 at 12:40 AM, Jason White <[email protected]> wrote:
> I would argue that the HTML and PF WGs should specify either @longdesc or
> @aria-describedat, but not both; we don't want authors to use both attributes
> with URIs that, inadvertently perhaps, refer to different resources.

There are plenty of places where ARIA already duplicates HTML
semantics (e.g. navigation landmark versus <nav>, @aria-label versus
@alt on an <img>, @aria-required versus @required).

Such duplication is justifiable in two ways:

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.)

2. In practice, mainstream user agents implement ARIA as a way to
communicate to accessibility APIs or AT using the DOM. They do not
base user interface on ARIA features. For example, @required triggers
user interface feedback in Firefox, but @aria-required only affects
the accessibility API mapping. I'd expect that if @aria-describedat
were specified, it would follow this pattern of implementation. That
would make it unsuitable for recommendation as a sufficient technique
for long description provision, since all users need to be able to
access long descriptions on  demand, not just AT users. However,
native markup language semantics such as @longdesc could have an
implicit semantic of @aria-describedat. In the case where both are
specified, I'd expect @aria-describedat to win in terms of what is
mapped to the accessibility API.

One can argue that these characteristics (theoretical reusability and
communication to ATs only) are undesirable, but if you do so it's hard
to understand what you think is the point of adding in any new ARIA
features rather than just tidying up what's already there. Gaps in the
semantics of the web platform can be filled directly in the relevant
specs (HTML, SVG, MathML).

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).

> 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>.

Please address deficiencies you see in <canvas> directly, by filing
bugs or providing feedback on the available spec proposals.

See especially:

* Issue 205: Define what author guidance and/or methods should be
provided to those that wish to create accessible text editors using
canvas as a rendering surface.

    http://www.w3.org/html/wg/tracker/issues/205

There are two Change Proposals under consideration:

    http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelectionRevised

    http://www.w3.org/wiki/No_edit_change_proposal_for_canvas_text_editing

* Issue 201: Provide canvas location and hit testing capability to
fallback content

    http://www.w3.org/html/wg/tracker/issues/201

Frank's produced a Change Proposal:

    http://www.w3.org/wiki/Canvas_hit_testing

Ian is working a spec for an addHitRegion method:

    http://wiki.whatwg.org/wiki/Canvas#Regions

--
Benjamin Hawkes-Lewis