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

>> The problem in this particular case is exacerbated by the 
>> recommendation that CSS selectors be used on the attribute to control 
>> visual display as it would encourage using aria-hidden="false" rather 
>> than removing the attribute when content is no longer hidden.

> Is this a hypothetical problem, or do you have a real-world example of someone do this?

This is actually something that people have been recommending and implementing for quite a while now.

E.G

ARIA Tab Panel Example
http://accessibility.athena-ict.com/aria/examples/tabpanel2.shtml
" 5.  CSS selectors are used to bind aria-hidden and CSS display:none."

form with aria
http://accessibility.athena-ict.com/aria/examples/form.shtml
" 5. CSS selectors are used to bind aria-hidden and CSS display:none."

AngularJS: Developer Guide: Accessibility
https://docs.angularjs.org/guide/accessibility
"In its default setup, ngAria for ngShow is actually redundant. It toggles aria-hidden on the directive when it is hidden or shown. However, the default CSS of display: none !important, already hides child elements from a screen reader. It becomes more useful when the default CSS is overridden with properties that don't affect assistive technologies, such as opacityor transform. By toggling aria-hidden dynamically with ngAria, we can ensure content visually hidden with this technique will not be read aloud in a screen reader."

Association of Assistive Technology Act Programs Home Page
http://www.ataporg.org/webtips.html
"Sometimes content (such as form error messages) can be hidden or revealed based on the user interaction. With ARIA and CSS, a developer can focus on changing semantic ARIA values while allowing CSS to toggle the visual presentation. CSS of [aria-hidden:true] {display:none} will hide content when aria-hidden has a value of true. By toggling an element's aria-hidden value between true and false, the content will automatically display or hide visually as well."

Web applications and ARIA FAQ - Accessibility | MDN
https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Web_applications_and_ARIA_FAQ
"Though on its own ARIA will not change any styles, as with any HTML attributes, CSS can take advantage of ARIA attributes as element selectors. This may provide a convenient mechanism to style ARIA-enabled widgets."

The above appeared in the top ten list for me on Google when I searched for binding aria-hidden with css display:none...

The reason why so many people do this, is because it has suggested for years that this should be done in the spec at
http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden
" It is recommended that authors key visibility of elements off this attribute, rather than change visibility and separately have to remember to update this"




-----Original Message-----
From: James Craig [mailto:jcraig@apple.com] 
Sent: Friday, March 20, 2015 4:22 PM
To: Birkir Gunnarsson
Cc: Joseph Scheuhammer; Joanmarie Diggs; Alexander Surkov; Dominic Mazzoni; W3C WAI Protocols & Formats
Subject: Re: aria-hidden (updates need to implementation guide or spec)


> On Mar 20, 2015, at 6:29 AM, Birkir Gunnarsson <birkir.gunnarsson@deque.com> wrote:
> 
> +1 to the idea.
> On a related note, I would like to propose a slight alteration to the 
> definition table at the bottom of the aria-hidden entry.
> 
> Currently:
> definition for aria-hidden="false" is the following:
> "The element is exposed to the accessibility API as if it was rendered. "
> 
> Propose to update this to:
> The element *and all its descendants* is exposed to the accessibility 
> API as if it was rendered, .

No. That breaks everything. It's the exact nightmare implementation scenario that Alex and I are trying to avoid.

If an really author wants that, they should explicitly add it to every node in the tree. 

> (I know the meaning is essentially the same, I would just like to 
> emphasize this point(.
> I have noticed confusion in situations where aria-hidden="false"
> overrides visible rendering of content.
> <div aria-hidden="false" role="tabpanel" class="active"> <input 
> type="hidden" value="3"> <label for="inp1">Please enter the number of 
> meals you would like to purchase</label> <input id="inp1" 
> type="number"> </div> is not the same as:
> <div role="tabpanel" class="active">
> <input type="hidden" value="3">
> <label for="inp1">Please enter the number of meals you would like to 
> purchase</label> <input id="inp1" type="number"> </div> The former 
> exposes two inputs to assistive technologies, whereas the latter only 
> exposes one.

I think you're probably seeing this in WebKit or Blink (Am I right? It's fixed in WebKit now, by the way.) and that is not the intended behavior. It is one of the problems we're trying to solve. aria-hidden=false should not "unhide" anything except the current node and its text node children. The "do what I mean" behavior you are expecting is nearly impossible to implement. 

The issue was that the spec was previously ambiguous about inheritance of aria-hidden, so edge cases like this arose.

> The problem in this particular case is exacerbated by the 
> recommendation that CSS selectors be used on the attribute to control 
> visual display as it would encourage using aria-hidden="false" rather 
> than removing the attribute when content is no longer hidden.

Is this a hypothetical problem, or do you have a real-world example of someone do this?

> Maybe the solution to this is to update the html to accessibility api 
> mapping so that <input type="hidden"> is automatically mapped to 
> aria-hidden="true" in the browser accessibility API (after all input 
> elements are not allowed to have children, so this should not cause 
> confusion).

It already is[1], and should be. We're just trying to keep it that way.

James


[1] input[type=hidden] is not mapped to [aria-hidden=true] per se, but it is not rendered, which is more-or-less the same thing.



> Thanks
> -B
> 
> 
> 
> 
> 
> On 3/19/15, 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/91346abccb1a6a0210c60e10ccb5ef5689
>> 16ae8b
>> 
>> 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
>> 
>> 
>> 
>>

Received on Saturday, 21 March 2015 00:24:07 UTC