- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 10 Feb 2012 09:45:56 -0800
- To: John Foliot <john@foliot.ca>
- Cc: Sam Ruby <rubys@intertwingly.net>, public-html@w3.org
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