Re: aria-hidden (updates need to implementation guide or spec)

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> wrote:

> We made some modifications to aria-hidden a few months ago to clarify
> implementation.
> Diff:
> 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
>
> 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
>
>
>