- From: James Craig <jcraig@apple.com>
- Date: Fri, 20 Mar 2015 15:46:44 -0700
- To: Alexander Surkov <surkov.alexander@gmail.com>
- Cc: Joseph Scheuhammer <clown@alum.mit.edu>, Joanmarie Diggs <jdiggs@igalia.com>, Dominic Mazzoni <dmazzoni@google.com>, W3C WAI Protocols & Formats <public-pfwg@w3.org>
- Message-Id: <AEF3EE48-67F5-4686-8013-E3121D4154E6@apple.com>
The flip-side is that we've had thousands of web developers request non-hacky ways to provide clarifying text for accessibility. This is a case I want to support, particularly for labeling. <a href="#"> More info <span hidden aria-hidden="false"> about foo </span> </a> The confusion was related to how aria-hidden inherits and how that plays with the UA renderer. <a href="#"> More info <span hidden aria-hidden="false"> about foo <p> Some sub-level node that is not rendered and not "unhidden", so should not be exposed to Accessibility APIs. </p> </span> </a> > On Mar 20, 2015, at 11:20 AM, Alexander Surkov <surkov.alexander@gmail.com> wrote: > > In general I don't support the idea to show hidden elements. We discussed this topic in the past but just in case here's some summary why I don't like it. > * These elements don't have any geometry, thus their usage is quite restricted for certain AT like zooming software. > * It encourages the web developers to provide special AT versions of web site. > > On the another hand I don't recall if we have good any use cases for aria-hidden="false", and it's not easy to implement it in Firefox. It all repels me from supporting aria-hidden="false". > > Thanks. > Alexander. > > > On Thu, Mar 19, 2015 at 8:39 PM, James Craig <jcraig@apple.com <mailto:jcraig@apple.com>> wrote: > We made some modifications to aria-hidden a few months ago to clarify implementation. > Diff: https://github.com/w3c/aria/commit/91346abccb1a6a0210c60e10ccb5ef568916ae8b <https://github.com/w3c/aria/commit/91346abccb1a6a0210c60e10ccb5ef568916ae8b> > > Summary: It was an spec artifact that the default value for aria-hidden was false. In spirit there had alway been and assumption a undefined value meant "undefined" not false, but the property was boolean, which led to implementation confusion. We clarified this a while ago by adding a new, default "undefined" value: > > > false: The element is exposed to the accessibility API as if it was rendered. > > true: The element is hidden from the accessibility API. > > undefined (default): The element's hidden state is determined by the user agent based on whether it is rendered. > > and some clarifying text: > > > User agents determine an element's hidden status based on whether it is rendered, and the rendering is usually controlled by CSS. For example, an element whose display property is set to none is not rendered. An element is considered hidden if it, or any of its ancestors are not rendered or have their aria-hidden attribute value set to true. > > > Current editor's draft: > http://rawgit.com/w3c/aria/master/aria/aria.html#aria-hidden <http://rawgit.com/w3c/aria/master/aria/aria.html#aria-hidden> > > I have been asked by some WebKit engineers to explain this a bit more. From an implementation perspective, I think it can be summarized as this loosely worded pseudo code. Indentation implies blocks, but I tried to phrase it as a sentence so that it'd be understandable by screen readers that are not verbalizing white space. > > 1. If element is rendered > and aria-hidden is not true on current element > and aria-hidden is not true on any ancestor: > -> element is not hidden. Expose to accessibility API. > > 2. If original element is not rendered > and aria-hidden is false on original element: > for each ancestor element: > if current ancestor element is rendered > or current ancestor element is explicitly set as aria-hidden=false: > continue > else: > -> original element is hidden. Do not expose to accessibility API > end loop > -> original element is not hidden. Expose to accessibility API. > > 3. If node type is text node > and parent element is not "hidden" (as defined above) > -> text node is not hidden. Expose to accessibility API. > > Thoughts? I'm trying to decide if this should go in the spec or in the implementation guide. > > Thanks, > James Craig > > >
Received on Friday, 20 March 2015 22:47:14 UTC