Re: Split Issue 30? (was: Chair review of "Keep Longdesc Deprecated" Change Proposal)

On Thu, Feb 9, 2012 at 12:16 AM, John Foliot <john@foliot.ca> wrote:
> Jonas Sicking wrote:
>>
>> I agree we have two somewhat independent issues:
>>
>> 1. Should ARIA attributes be allowed to point to @hidden elements.
>
> ARIA attributes technically can point to hidden elements today - that is not
> the issue

Actually, the change that is in my change proposal, and the change
that Hixie made to the spec which Laura and others have requested to
be reverted, is *exactly* this. It's simply weather it's considered
valid HTML for aria attributes to point to @hidden elements. It
actually doesn't even change the normative requirements for what
browsers should do when a author does this anyway.

Please see the changes detailed in my change proposal as well as the
diff that Laura links to in her revert request.

> (even though, as I have discovered via limited testing, what is
> being pointed to is returned back as null content to in the screen readers I
> tested, which is currently correct behavior) - the point being it is not
> specifically disallowed as far as I can see.
>
> What is at issue is what happens to content not visible on screen: the
> Accessibility APIs flatten the content to string text,

Note that no-where in the HTML spec does it say to treat @hidden, or
otherwise invisible, elements differently. I.e. there are no
difference in the normative requirements for an aria attribute that
points to a @hidden element, from one that points to a non-hidden
element. Hence I would expect them to behave the same. (Similarly, the
spec doesn't say that browsers should behave differently on thursdays,
hence I would expect browsers to behave the same on thursdays as it
does on fridays).

I'm happy to modify my change proposal to make this explicitly clear.
I.e. add a normative requirement that says that browsers MUST expose
the full semantics the description pointed to be aria-describedby,
even when @hidden.

> as none of the APIs
> were designed to support structured (marked-up) content. This point has been
> brought forward numerous times to this Working Group, and no-one has been
> able to show that this is not the case. It's not a browser issue, it's not
> an HTML5 issue, it's an OS/API issue - and an issue out of scope for the
> HTML WG.

If you claim that APIs are designed in a way that doesn't permit the
spec to be correctly implemented, I think the burden of proof is on
you. Especially when two browser implementations are claiming that
they can implement the spec correctly.

Can you please provide a link to the API you are talking about?

> Hidden content, whether referenced by ARIA attributes or not, cannot (should
> not) support focusable content, as this throws of the long-held,
> WAI-required need to maintain visible tab focus for sighted, keyboard-only
> users (not just blind users, but any user unable to use a mouse):

Does this mean that we should not be allowed to put rich content
inside a <canvas> too then? Since such content is hidden by the
<canvas>.

/ Jonas

Received on Friday, 10 February 2012 17:46:53 UTC