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

I think you can do that without aria-hidden like

<span id="s" hidden>about foo</span>
<a id="a" href="#" aria-labelledby="a s">More info</a>

Thanks.
Alexander.

On Fri, Mar 20, 2015 at 6:46 PM, James Craig <jcraig@apple.com> wrote:

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