Re: Split Issue 30?

My opinion: It makes sense to not mix the issue of whether 
aria-describedby can point to content with the @hidden attribute, 
together with the issue of whether @longdesc should be conforming. 
Because:

1 @longdesc is only proposed for <img> elements:
  We could end up with a situation where  @aria-describedby can point 
to content with the @hidden attribute set, except when used together 
with <img> elements. [In that regard, with HTML5 and ARIA, many other 
elements than <img> can be given role='img' - but they don't have the 
@longdesc attribute.]

2 The @hidden issue needs clarification:
  There are other features than @hidden that hide an element. E.g. some 
elements are hidden by default. And if an element is given role='img', 
then its children are hidden by default - and there is nothing that 
hinders aria attributes from pointing to these children.

3 'full semantics' needs clarification:
  The - narrow - focus is on @hidden. But as told, <div role=img> turns 
its children to an ARIA state that for most purposes is equal to 
hidden. So would it only be when @hidden attribute is explicitly set 
that the 'full semantics' are enabled, or would it also happen for 
children of an element with role=img. 

The @hidden attribute has its own 'nature', and the question of whether 
it is right to point to @hidden sections, could be answered based on 
whether it is consistent with the idea behind @hidden to do point to 
it. Or it could be answered from the angle of whether it is accessible 
to do so. In the latter case, then we must also consider that, as told, 
there are many other ways to hide an element than with @hidden. 

From an authoring point of view: Whether I use @aria-hidden='true' or 
@hidden, my problem is that, as soon as I try to *link* to such 
sections - with an anchor element - then the attribute has to change 
status or be removed, in order to become accessible to AT. One could 
then just skip these attributes, perhaps ... But, actually, ARIA says 
that @aria-hidden='true' in some cases *must* be used: 'If an element 
is only visible after some user action, authors MUST set the 
aria-hidden attribute to true.' 
<http://www.w3.org/TR/wai-aria/complete#aria-hidden> 

What I am also aiming at is that even in Jonas' proposal, I don't see 
that he need to include permission to use @hidden, as such, because - 
as told - there are many other ways to hide an element than using 
@hidden.

Leif H Silli


Sam Ruby, Fri, 10 Feb 2012 09:23:04 -0500:
> On 02/10/2012 08:34 AM, Laura Carlson wrote:
>> On Wed, Feb 8, 2012, Jonas Sicking wrote:
>> 
>>>> 1. Should ARIA attributes be allowed to point to @hidden elements.
>>>> 2. Should @longdesc be marked as obsolete.
>>>> 
>>>> However it seems like issue 2 depends on issue 1. I.e. the case for
>>>> marking longdesc as obsolete is stronger if ARIA is allowed to point
>>>> to hidden elements.
>>>> 
>>>> Would it be possible to ensure that we decide on 1 before we poll on
>>>> 2?
>> 
>> The more I think about this, the more it just doesn't seem right.
>> 
>> It seems that splitting off and then re-ordering issues as proposed
>> above is to be used as a scheme to strengthen the effort to kill off
>> longdesc.
>> 
>> Therefore, I object and ask to have the poll run concurrently on all 
>> proposals.
>> 
>> All of my cards are on the table. No tricks are up my sleeve. I hope
>> the same it true of others.
>> 
>> Let's have the poll fair and square and decide this thing without 
>> further delay.
> 
> I dislike this characterization and the innuendo that people may be 
> playing tricks.
> 
> You indicate (correctly) that this discussion has been going on for 
> several years.  Less than two years ago, a decision was rendered 
> based on the proposals that were provided.
> 
> We subsequently reopened the discussion based on use cases that could 
> have been provided during that time, but for whatever reason was not.
> 
> One way to proceed would be to split the issues and proceed as you 
> previously stated: namely to re-decide the deprecation issue without 
> considering the proposed change to how certain aria attributes are 
> interpreted.
> 
> One possible outcome of that would be that we would need to once 
> again reopen the deprecation decision once that data has been 
> gathered and presented.  I don't believe anybody wants that.
> 
> Deciding multiple issues concurrently is not without its 
> complications.  If there are found to be strong objections to leaving 
> the interpretation of these aria attributes as the currently are 
> spec'ed (based on the revert request) and the proposal that attracts 
> the weakest objections also happens to deprecate longdesc, some 
> (including perhaps yourself) might not consider the selection of that 
> proposal to be fair.
> 
> (The converse is also possible: we could find that there are strong 
> objections to deprecating longdesc, and not give due consideration to 
> the merits of the proposed change to how area attributes should be 
> interpreted)
> 
> This is not a game where the objective is to win independent of the 
> merits of the arguments.  This is all about the merits of the 
> arguments.
> 
>> On Wed, Feb 9, 2012, I wrote:
>> 
>>> People have had seven years
>> 
>> Sorry. Typo. Should have been "several years"
>> 
>> Best Regards,
>> Laura
>> --
>> Laura L. Carlson
> 
> - Sam Ruby
>

Received on Friday, 10 February 2012 15:47:34 UTC