- From: James Craig <jcraig@apple.com>
- Date: Fri, 20 Mar 2015 16:22:17 -0700
- To: Birkir Gunnarsson <birkir.gunnarsson@deque.com>
- Cc: Joseph Scheuhammer <clown@alum.mit.edu>, Joanmarie Diggs <jdiggs@igalia.com>, Alexander Surkov <surkov.alexander@gmail.com>, Dominic Mazzoni <dmazzoni@google.com>, W3C WAI Protocols & Formats <public-pfwg@w3.org>
> 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/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 >> >> >> >>
Received on Friday, 20 March 2015 23:22:47 UTC