Re: Moving forward with Issue-204

Edward O'Connor, Fri, 08 Jun 2012 11:25:34 -0700:
  ...
> == Analysis of the relationship between the two proposals ==
  ...
> 6. AllowAriaReferHidden broadly allows authors to refer to hidden=""
>    elements for non-hyperlinking purposes, including scripting. It
>    provides several examples, including a use of aria-describedby="".

The problem is when aria-describedby points to a hidden hyperlink. See 
below.
 
>    The v3 proposal more narrowly allows authors to refer to hidden=""
>    elements for descriptive purposes, and does not (explicitly) allow
>    the other cases allowed (such as scripting) allowed in the
>    AllowAriaReferHidden proposal.
> 
>    The AllowAriaReferHidden proposal (or rather, an example added to the
>    spec by the revert proposed by AllowAriaReferHidden) provides a use
>    case for non-hyperlinking, non-descriptive referring to hidden=""
>    content:
> 
>      "Similarly, a canvas element with the hidden attribute could be
>      used by a scripted graphics engine as an off-screen buffer, and a
>      form control could refer to a hidden form element using its form
>      attribute."
> 
>    Given this use case, I believe the v3 proposal overly restricts
>    author behavior.

Sure, it is seems odd to restrict the "technical" use cases.

> 7. The v3 proposal explicitly disallows authors from using structured
>    content in hidden="" elements; the AllowAriaReferHidden imposes no
>    such restriction.

I think, once more, that the problem is the permission to refer to 
hyperlink - with the expectation that AT users will be able to activate 
it. For much other content, e.g. hidden headings, they are potentially 
useful even when "flattened". Whereas to make a hyperlink useful also 
when it does not act as a link, requires more brain waves. 

But it might be possible. See below.

>    This was (one of the) main issues debated in the F2F discussion of
>    ISSUE-204. Neither proposal captures the compromise reached at the
>    F2F.
> 
>    The author conformance change on which there was broad agreement (or
>    at least broad "can live with") at the F2F is require authors not
>    write content that, when flattened, loses essential meaning. But the
>    restriction in the v3 proposal goes far beyond that.

Again: The requirement that it should not loose meaning when 
"flattened" would put authoring restrictions - or at least reluctance - 
on including links in the hidden content, not? See below.

>    In mailing list discussion after the F2F Jonas suggested an alternate
>    restriction, not on authors but instead on UAs, that structured
>    hidden="" content not be flattened when exposed to AT. It has become
>    clear that such a requirement would be unacceptable to Microsoft.

It seems like an important point that the F2F consensus was to put 
restriction on *authors*.

Here is an example where I believe that AT users for whom the text is 
flattened, would receive all the text inside the #hidden fragment, 
whereas those AT users for whom the #hidden fragment was not flattened, 
would get the choice to not read the info inside the #more fragment 
until they explicitly ask for it:

<img src=i aria-describedby="hidden">
<div hidden id=hidden>
Image of a cat. <a href=#more>More data about the cat:</a>
<span id="more" class="made-visible-via-CSS-when-targeted" >
The cat is tiger colored, and very young.
</span>
</div>

The example makes the assumption that CSS will still be active for the 
content inside the #hidden fragment. Thus, one should see the entire 
#hidden fragment as an invisible section where - a hidden room, where 
the light is on inside.

>    I think there could be compromise language on this issue, which
>    simultaneously encourages (but does not require) UAs to expose the
>    full semantics of hidden="" content to AT, and that requires authors
>    to only use aria-describedby="" to refer to hidden="" content that,
>    when flattened, does not lose essential meaning.

I agree.

>    I encourage everyone
>    who has contributed text to both CPs to try to come up with such
>    compromise language on this point.
-- 
Leif Halvard Silli

Received on Friday, 8 June 2012 20:49:00 UTC