W3C home > Mailing lists > Public > public-html@w3.org > March 2012

(unknown charset) [public-html] <none>

From: (unknown charset) Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Sat, 17 Mar 2012 14:38:23 +0100
To: (unknown charset) Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>, Paul Cotton <Paul.Cotton@microsoft.com>
Cc: (unknown charset) HTML Accessibility Task Force <public-html-a11y@w3.org>, public-html@w3.org
Message-ID: <20120317143823620276.ca074bc0@xn--mlform-iua.no>
Chairs, please see my reasoning in the quote from 14th of March, below, 
and answer the following question:

QUESTION: Can you give us a hint about how it would be evaluated if 
Lauras - or another - proposal promotes @longdesc for *any* element 
that have role=img, versus Laura's current proposal - which - though it 
also contains language which says that one could expand its use - 
allows it on the img element alone?

In particular: Would it necessarily become any simpler to expand 
@longdesc to other elements if HTML5 first allows it on img? Would it 
be *expected* that it then gets expanded? In earlier Decisions, ideas 
that were presented but not presented as The Change Proposal, have been 
dismissed.

In your original Decision, you mentioned that @longdesc in HTML4 is 
permitted on both iframes and img. Also, in the Decision and later, you 
have asked for justification for why only <img> should have @longdesc - 
which is what the proposals to make @longdesc conforming, have argued. 

Currently, there seems to be agreement amongst the @longdesc supporters 
that a long description link feature for more situations than <img> 
elements with the ARIA role of an 'img', is needed. And one way to 
justify the focus on img alone, could be the possibility of 
@aria-describedAT - in which case @longdesc on img alone, becomes more 
defendable. It could also be argued that <img> is a unique element that 
deserves some special casing.

The absolutely lowest fruit would be a CP that extends support to 
iframe: It ought to already be implemented and working, and iframe does 
sometimes act as an image. A little bit higher up, hangs the fruit 
called 'any element that has - or is given - role=img'. And close to 
that is <video> and poster image. Plus allowing it to describe any 
embedded content. The highest fruit is to allow it to describe 
'anything', regardless of the role of the element.

Leif Halvard Silli, Wed, 14 Mar 2012 13:19:38 +0100:
> Looking squarely at Laura's Change Proposal: Is there any reason not to 
> expand it - before we go to a poll/survey - to cover any element where 
> the author has given it role='img'?
> 
> I mean: If we want to put the horse *before* the cart?
> 
> It would be futile to ask the chairs to consider @longdesc a second 
> time, for other use cases, if we are not able to the the single, most 
> logical step.
> 
> An element with role=img is - from an AT user's point of view - 
> entirely closed. It is only the info that the author has placed there - 
> in @title, @aria-label, @alt etc - specifically for that purpose, that 
> makes a role=img element perceivable to that user group.
-- 
Leif H Silli
Received on Saturday, 17 March 2012 13:38:56 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:31 UTC