Closed Bug 972845 Opened 10 years ago Closed 10 years ago

Do not expose elements with aria-hidden="true"

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: jdiggs, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(2 files)

accessible-event listener: hierarchy.py
421 bytes, text/x-python
Details
test case: aria-hidden.html
128 bytes, text/html
Details 
Steps to reproduce:
1. Launch the attached accessible-event listener in a terminal.
2. Load the attached test case in Firefox.

Expected results: The div marked with aria-hidden="true", and its descendant paragraph, would not appear in the accessible tree as per the WAI-ARIA User Agent Implementation Guide which states [1]:

    If not already excluded from the accessibility tree
    per the above rules, user agents SHOULD NOT include
    the following elements in the accessibility tree:

    * Elements, including their descendents, that have
      a WAI-ARIA global attribute of aria-hidden="true".

Actual results: The div marked with aria-hidden="true", and its descendant paragraph appear in the accessible tree:

-> [document frame | file:///home/jd/aria-hidden.html] 
    -> [paragraph | ] This text is not hidden
    -> [section | ] 
        -> [paragraph | ] This text is hidden

Results from performing the same steps using Epiphany/WebKitGtk:

-> [document web | ] 
    -> [paragraph | ] This text is not hidden

I realize that these hidden elements are marked with an object attribute in your implementation. BUT that means that Orca has to check each element for that attribute on the off-chance it is "hidden" and should not be presented to its users. Given that elements that are also properly hidden/not displayed via CSS are not in the accessible tree, that means that Orca has to check each and every element on each and every page on the off-chance it is one of those special cases described here [2]:

    Authors MAY, with caution, use aria-hidden to hide visibly
    rendered content from assistive technologies only if the act
    of hiding this content is intended to improve the experience
    for users of assistive technologies by removing redundant or
    extraneous content. Authors using aria-hidden to hide visible
    content from screen readers MUST ensure that identical or
    equivalent meaning and functionality is exposed to assistive
    technologies.

The W3C says it should not be in the tree. I (the Orca maintainer) want it out of the tree. Please take it out of the tree for ATK/AT-SPI2. Thank you in advance. :)

[1] http://www.w3.org/WAI/PF/aria-implementation/#exclude_elements2
[2] http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden

    
    

    
  
Oh noes! We've been down that road before! :( Look at all of bug 780888, especially Jamie's comments about the possibility that focus could go to an object that is within the stuff not exposed by aria-hidden="true". Therefore, we settled on the compromise that we would, indeed, include aria-hidden="true" trees, but mark them as such so ATs could decide for themselves if they wanted to expose these objects or not, but still make it possible for focusable items to gain focus and be exposed if they were included in the aria-hidden tree.

    
    

    
  
hey, Marco, times are changing, the more scary animal aria-hidden="false" is coming and the taken approach won't work in that case

    
    

    
  
I think I've understood all positions on aria-hidden. In the days when aria-hidden was meant just for AT that didn't use desktop API I felt strongly that we should not prune the tree, sharing concerns like comment 2. However, I think bug 780888 comment 0 is still correct: "It seems the common/modern understanding of aria-hidden is that it prunes the tree. IE and Safari prune the tree. Also I think this will be good for Gaia and AccessFu (Firefox OS a11y)." Dominic (Chrome/Blnk) also makes arguments for pruning in bug 780888.

At least browser-wise we're sort of the odd ones out here and we have Joanie asking us to prune the tree. It is no longer clear to me that resistance is good for accessibility in the long run.

Author error can already wreck accessibility, aria-hidden is just another thing they can muck up -- granted it is a weapon of mass destruction.

    
    

    
  
(In reply to David Bolter [:davidb] from comment #4)

> At least browser-wise we're sort of the odd ones out here and we have Joanie
> asking us to prune the tree. It is no longer clear to me that resistance is
> good for accessibility in the long run.

I don't think it's resistance, it's rather not being active.

> Author error can already wreck accessibility, aria-hidden is just another
> thing they can muck up -- granted it is a weapon of mass destruction.

different requirements of error handling in case aria-hidden and role="presentation" are rather unfortunate since feel inconsistent

    
    

    
  
on implementation note, it'd hard to prune the tree on ATK level only. It's easier to make the change on cross-plaftorm layer.

Before doing this I'd need confirmations that it doesn't break exceptions of windows screen readers. 

Also I would like to have through-out testing, how each browser/AT handles erorrs. I would be surprised if every party follows the spec strictly.

    
    

    
  
I'd say somebody should do testing of existing implementations, clarify aria-hidden behavior and capture that in the spec. I don't feel doing this myself right because of personal antipathy to aria-hidden :) Probably Joanie can pick up the banner as w3c member and somebody who badly wants aria-hidden? :)

    
    

    
  
For the record, I tried really hard to make it clear "just ATK". I don't want to change the Windows user experience or impact their ATs. Really. :)

As for this:

(In reply to alexander :surkov from comment #6)
> on implementation note, it'd hard to prune the tree on ATK level only. It's
> easier to make the change on cross-plaftorm layer.

I get that it's easier at the cross-platform layer, but I'm surprised that it is so difficult at the single platform level. In WebKit, each platform is asked by WebCore Accessibility: "Include this in the tree or not?" And WebCore Accessibility builds the tree. It makes it pretty easy for a single platform to include or prune without impacting anyone else.

> Before doing this I'd need confirmations that it doesn't break exceptions of
> windows screen readers. 

Or alternatively, implement a means to make platform-specific trees easier.

    
    

    
  
Feels like divergence.

    
    

    
  
(In reply to Joanmarie Diggs from comment #8)
> For the record, I tried really hard to make it clear "just ATK". I don't
> want to change the Windows user experience or impact their ATs. Really. :)

imo aria-hidden="true" shouldn't be so API specific, in other words either create an accessible or not, the mapping of not existing accessible object must be pretty much same though all APIs. So "just ATK" doesn't make much sense for me.

> As for this:
> 
> (In reply to alexander :surkov from comment #6)
> > on implementation note, it'd hard to prune the tree on ATK level only. It's
> > easier to make the change on cross-plaftorm layer.
> 
> I get that it's easier at the cross-platform layer, but I'm surprised that
> it is so difficult at the single platform level. In WebKit, each platform is
> asked by WebCore Accessibility: "Include this in the tree or not?" And
> WebCore Accessibility builds the tree. It makes it pretty easy for a single
> platform to include or prune without impacting anyone else.

ATK as implemented in Gecko is a very thin layer around crossplatfom logic, so stuff like kids amount are taken from cross-platfrom layer.

> > Before doing this I'd need confirmations that it doesn't break exceptions of
> > windows screen readers. 
> 
> Or alternatively, implement a means to make platform-specific trees easier.

we don't have yet platform-specific trees, we planned to do this but it could take months. anyway, making it ATK-ish only is not I would like to see.

    
    

    
  
> (In reply to alexander :surkov from comment #6)
> > on implementation note, it'd hard to prune the tree on ATK level only. It's
> > easier to make the change on cross-plaftorm layer.
> 
> I get that it's easier at the cross-platform layer, but I'm surprised that
> it is so difficult at the single platform level. In WebKit, each platform is
> asked by WebCore Accessibility: "Include this in the tree or not?" And
> WebCore Accessibility builds the tree. It makes it pretty easy for a single
> platform to include or prune without impacting anyone else.

nothings really needed that before.  There's sort of a mechanizm to do it, but basically anything not cross platform would make multiprocess stuff harder.

> > Before doing this I'd need confirmations that it doesn't break exceptions of
> > windows screen readers. 
> 
> Or alternatively, implement a means to make platform-specific trees easier.

Sure, we *could* do all sorts of things the question is  are they worth doing.

(In reply to David Bolter [:davidb] from comment #4)
> I think I've understood all positions on aria-hidden. In the days when
> aria-hidden was meant just for AT that didn't use desktop API I felt
> strongly that we should not prune the tree, sharing concerns like comment 2.
> However, I think bug 780888 comment 0 is still correct: "It seems the
> common/modern understanding of aria-hidden is that it prunes the tree. IE
> and Safari prune the tree. Also I think this will be good for Gaia and
> AccessFu (Firefox OS a11y)." Dominic (Chrome/Blnk) also makes arguments for
> pruning in bug 780888.
> 
> At least browser-wise we're sort of the odd ones out here and we have Joanie
> asking us to prune the tree. It is no longer clear to me that resistance is
> good for accessibility in the long run.

istr Jamie gave up and started supporting it in nvda too.  So it seems people are going to insist  on implementing this and so we won't gain much other than shooting hostages by refusing. On the other hand I don't really like supporting things I think are bad ideas. So maybe patches will be thoughtfully considered instead of thoughtfully rejected, but I wouldn't put much effort into fixing it.

> Author error can already wreck accessibility, aria-hidden is just another
> thing they can muck up -- granted it is a weapon of mass destruction.

yeah, but my impression is people are about as likely to use it wrong as right, and I'd prefer my footguns to require you say "I do solemly swear I inteed to shoot myself in the foot".

    
    

    
  
(In reply to Trevor Saunders (:tbsaunde) from comment #11)

> On the other hand I don't really like supporting things I think are bad ideas.

I totally understand and sympathize. Believe me. But once something has made it to the point of inclusion in a W3C specification, we have to live with it. Screen readers need to do the RightThing(tm), which in this case is to not present aria-hidden="true" content to end users. The question is, where does the needed logic for that support belong? In the screen reader or in the web engine?

Right now, the burden is on each and every screen reader that provides access to Firefox. And it's not a trivial burden: Each and every element will need to be examined just in case it has aria-hidden="true". What is the likelihood of a match? Given all of the content in the world, I'd bet that:

1. Most pages have no ARIA whatsoever.
2. Most elements with ARIA are not using ARIA to hide things.
3. Elements with aria-hidden="true" are also using CSS as per the W3C instructions to prevent display.

So a displayed element with aria-hidden="true" should be a pretty rare beast. It's a drag for screen readers to have to check each and every element "just in case." I really don't want to have to add that to Orca. But Orca will support aria-hidden:"true" with Firefox one way or the other. Like I said, the "this is a bad idea" ship has already sailed.

    
    

    
  
Throwing another use case into the debate.

There are users with "low" vision who use a screen reader and a magnifier at the same time.  Given Joanie's example as stated, these users will see a magnified view of the aria-hidden text, aka "This text is hidden".  But, if this bug is resolved by removing that text from the a11y tree, the screen reader will not announce it.

It will be odd to have the rest of the page spoken, but not this paragraph even though it is clearly visible to the magnifier/screen-reader user (enhanced even).  Note that similar considerations apply to the case where the text is not rendered on screen, but is marked aria-hidden="false" to force it into the a11y tree.  In that case, it won't be magnified, but it will be spoken by the screen reader.  That would be a very odd user experience -- akin to hearing something that isn't there.

    
    

    
  
Well, my exact test taken as-is is arguably author error (though I prefer bug-filer laziness). ;)

According to http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden, authors are NOT supposed to hide on-screen elements from screen readers, i.e. as I did in my hello-world test case. The exception is the following:

=============
Authors MAY, with caution, use aria-hidden to hide visibly rendered content from assistive technologies only if the act of hiding this content is intended to improve the experience for users of assistive technologies by removing redundant or extraneous content. Authors using aria-hidden to hide visible content from screen readers MUST ensure that identical or equivalent meaning and functionality is exposed to assistive technologies.
=============

If the above special case is true for my web app, and I do everything the W3C states I MUST do as the author, the hidden element is still going to show up in the tree for Firefox. My failure to design a fancy test case that demonstrates this in a more compelling fashion doesn't change the bug.

    
    

    
  
(In reply to Joseph Scheuhammer from comment #13)
> Throwing another use case into the debate.
> 
> There are users with "low" vision who use a screen reader and a magnifier at
> the same time.  Given Joanie's example as stated, these users will see a

I can't think of a case where something is visible and this argument doesn't generalize to it.  That said I think this is one of the standard arguments for why aria-hidden is a bad idea.  So if you want to try to get it out of the w3c spec I think that's great, but that's far too hard a wall for me to consider beating my head against.

(In reply to Joanmarie Diggs from comment #12)
> (In reply to Trevor Saunders (:tbsaunde) from comment #11)
> 
> > On the other hand I don't really like supporting things I think are bad ideas.
> 
> I totally understand and sympathize. Believe me. But once something has made
> it to the point of inclusion in a W3C specification, we have to live with
> it. Screen readers need to do the RightThing(tm), which in this case is to
> not present aria-hidden="true" content to end users. The question is, where

no, we need to live with it only after there's enough stuff out there on the web making it a better user experience to implement it than not, and enough of it we can't just get them to fix their crap.

> does the needed logic for that support belong? In the screen reader or in
> the web engine?

if it should be implemented its probably better done in the browser, but on the other hand its worth considering not absolutely everything using the accessibility API is strictly speaking assistive technology in the traditional sense we've seen password fill things and anti virus stuff etc) and they may have somewhat different desires, and I don't think supporting that is totally unreasonable.

> Right now, the burden is on each and every screen reader that provides
> access to Firefox. And it's not a trivial burden: Each and every element
> will need to be examined just in case it has aria-hidden="true". What is the

you still need to do this in a browser its just much faster.

> So a displayed element with aria-hidden="true" should be a pretty rare
> beast. It's a drag for screen readers to have to check each and every
> element "just in case." I really don't want to have to add that to Orca. But

personally I would say you should just file a bug against orca saying it should work call it blocked on this one and move on with your life, but I'm pretty sure we're not going to agree :/

> Orca will support aria-hidden:"true" with Firefox one way or the other. Like
> I said, the "this is a bad idea" ship has already sailed.

I'm neither a developer nor a really a member of that community at this point so all I can do is go  :"( at you.

    
    

    
  
Given that there seems to be some push back on this issue....

Unless and until this bug is resolved -- and with something other than WONTFIX -- the least y'all could do is try to make it less difficult for screen readers trying to implement support as described by the W3C. In particular, propagate the object attribute so that screen readers do not have to ascend the accessible tree just in case. See newly-filed bug 974238.

    
    

    
  
As you're probably already aware, for the most part, I've resigned myself to the fact that aria-hidden is here to stay. I've even come up with cases where there's currently no other way. <gasp> Since everyone is implementing it anyway, pruning the tree would seem to make sense. However, a few things haven't been answered adequately:
1. Assistive technologies other than magnifiers. Does hiding something from a screen reader user necessarily make sense for a magnifier user, given that a magnifier primarily magnifies what is displayed visually? (This is why I argued there should be multiple attributes, but that argument is out of scope here.) If the tree is pruned, does that break magnifiers? Note that even the spec can't seem to make up its mind whether it's talking about assistive technologies in general or just screen readers:
> Authors MAY, with caution, use aria-hidden to hide visibly rendered content from *assistive technologies* only if the act of hiding this content is intended to improve the experience for users of *assistive technologies* by removing redundant or extraneous content. Authors using aria-hidden to hide visible content from *screen readers* MUST ensure that identical or equivalent meaning and functionality is exposed to *assistive technologies*.
2. How do you handle a focused element covered by aria-hidden? I'm talking in practical terms here, not theory. It might be author error, but the behaviour when it occurs still needs to be defined. Do you just get nothing? Does some placeholder accessible get focus? Does the nearest focusable ancestor (if any) get focus as suggested by Dominic in bug 780888, and if so, what if there's no focusable ancestor?

Barring focus issues, this shouldn't break screen readers in Windows, as they just won't see the accessibles. It might, however, break other types of AT.

    
    

    
  
I agree with Jamie (extra case to consider is caret navigation problem like <div contentEditable="true">hello<span aria-hidden="true">AT hidden but keyboard navigable</span> text</div>).

I'm ok to accept the patch when aria-hidden spec is clarified/browsers agreed to synchronize their implementations (also see my comment #6, comment #7). I'm fine to follow the progress/to help.
Summary: Do not expose elements with aria-hidden="true" via ATK → Do not expose elements with aria-hidden="true"

    
    

    
  
Consensus (at least today at the a11y meetup) is to 'propagate' the hidden attribute to all descendants. Implementation-wise this is just a matter of walking the ancestor chain looking for aria-hidden when object attributes are requested. Interestingly, we could probably stop ascending if we encounter aria-hidden="false"? (Crazy as that case is). Thoughts?

    
    

    
  
Propagation of aria-hidden is covered by bug 786143.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX

    
    

    
  
(In reply to David Bolter [:davidb] from comment #19)
> Consensus (at least today at the a11y meetup) is to 'propagate' the hidden
> attribute to all descendants.

that's a bug 974238. I'm curious though if we ever can make VoiceOver to support that.

> Implementation-wise this is just a matter of
> walking the ancestor chain looking for aria-hidden when object attributes
> are requested. Interestingly, we could probably stop ascending if we
> encounter aria-hidden="false"? (Crazy as that case is). Thoughts?

I would deal with aria-hidden="false" separately. It's even not in the spec yet afaik.

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: