GNOME Bugzilla – Bug 675341
"Invisible" text is not invisible to ATs like Orca
Last modified: 2012-06-05 16:16:44 UTC
According to the comment found here [1]: /* text is intentionally non-blank otherwise the height is not the same as for * infoMessage and errorMessageLabel - but it is still invisible because * gnome-shell.css sets the color to be transparent */ this._nullMessageLabel = new St.Label({ style_class: 'prompt-dialog-null-label', text: 'abc'}); But Orca is receiving AT-SPI2 events which suggest the text is showing. Here's the output of a simple pyatspi listener script: Widgets claiming STATE_SHOWING [label | Authentication Required] [label | To change time or date settings, you need to authenticate.] [label | Joanmarie Diggs] [label | Password: ] [label | abc] [push button | Cancel] [push button | Authenticate] If it is indeed necessary to have the 'abc' text present but hidden, it would be extremely helpful to prevent it from announcing to AT-SPI2 that it is showing. Alternatively, some means of alerting Orca to the fact that it's functionally hidden would be appreciated. As an aside, Orca doesn't present all of the labels in this dialog *yet*. I was working on that, and couldn't figure out why Orca kept saying 'abc'. ;) [1] http://git.gnome.org/browse/gnome-shell/tree/js/ui/polkitAuthenticationAgent.js#n164
Created attachment 213402 [details] [review] Tentative patch Well, the first solution that I found is just avoiding to expose the text if "prompt-dialog-null-label" style class is used. Taking into account that name, and that comment, it seems to be used to represent text that shouldn't be exposed. Joanmarie was gently enough to test this patch, and works. Having said so ... the problem with this patch is that it is a hack. After all I'm hardcoding a style class name on the patch. Anyway, IMHO, this seems somewhat a collateral effect of the original solution used to ensure the same height of two different labels. Although I didn't take too much time to review all the options, the solution of setting a fake text that shouldn't be showed sound somewhat hacky to me. Final note: take into account that this is not the first time that the accessibility support take literal names to know what it is going on. For the case of selected and checked items, pseudo class "selected" and "checked" are checked, for simplicity sake.
Some related thoughts: some time in the past, when web content was styled so as to not be seen, and ATs looked directly at the DOM, they missed the fact that the content wasn't actually rendered, and presented it by mistake. Sample markup follows: <div style="visibility: hidden;">This text is not rendered</div>. That's because one can't tell by looking only at the DOM whether something is perceivable or not. One also has to take into account the element's computed style. ARIA introduced the aria-hidden attribute to help mitigate this problem. The idea is if an author styles content so it is not rendered, they must also add aria-hidden="true": <div style="visibility: hidden;" aria-hidden="true">This text is not rendered</div>. That way, if an AT looks directly at the DOM, they can check for the aria-hidden attribute and react as appropriate. Also, browsers expose aria-hidden via AT-SPI. With FF, there is an accessible object corresponding to the <div>, but it has an AT-SPI object attribute of 'hidden' set to 'true'. WebKit and IE go further: when they encounter an aria-hidden element, they do not create an accessible in the a11y tree. (Nit: to be complete, no browser provides an accessible for something whose style is 'visibility:hidden' Ditto for the 'display:none' style). But that's all with markup and browsers -- how might this be fixed in the present case? 1. CSS visibility:hidden does not render the content, but does render empty space that is the size that the content would occupy. This is the preferred way of hiding text on the web while still occupying the same space. That is, don't use transparency for this. But, I don't know if the St toolkit's CSS parser/renderer is as sophisticated as gecko or webkit here -- can it use visibility:hidden? 2. Even so, if the intent is to hide the content, then the content should somehow be marked as hidden at the AT-SPI level; either by not exposing any accessible, or by marking its hidden attribute as true. In other words, API's hack is not really that much of a hack after all. The only hack-y bit is how specific the patch is with respect to the 'prompt-dialog-null-label' class. If it could somehow generalize on a rendered style (visibility: hidden and/or display:none), that would be better.
(In reply to comment #2) > 1. CSS visibility:hidden does not render the content, but does render empty > space that is the size that the content would occupy. This is the preferred > way of hiding text on the web while still occupying the same space. That is, > don't use transparency for this. But, I don't know if the St toolkit's CSS > parser/renderer is as sophisticated as gecko or webkit here -- can it use > visibility:hidden? It would be really simple to add.
Joseph, thanks for the explanation. (In reply to comment #2) > 1. CSS visibility:hidden does not render the content, but does render empty > space that is the size that the content would occupy. This is the preferred > way of hiding text on the web while still occupying the same space. That is, > don't use transparency for this. But, I don't know if the St toolkit's CSS > parser/renderer is as sophisticated as gecko or webkit here -- can it use > visibility:hidden? > > 2. Even so, if the intent is to hide the content, then the content should > somehow be marked as hidden at the AT-SPI level; either by not exposing any > accessible, or by marking its hidden attribute as true. In other words, API's > hack is not really that much of a hack after all. The only hack-y bit is how > specific the patch is with respect to the 'prompt-dialog-null-label' class. If > it could somehow generalize on a rendered style (visibility: hidden and/or > display:none), that would be better. Yes, although I didn't explain it really well, the real hacky nature of the patch was how to detect that the element is hidden. I also forgot to mention that the idea of the patch is showing that there is a way to solve it, but it would be good to find a proper general solution. Good that you understood that without me saying. If 1. is implemented, I guess that somehow the StLabel could ask for that CSS property. That would replace my 'prompt-dialog-null-label' check. Then I could do as my patch does, not exposing the text in that case, or setting the state to hidden (right now, not exposing ATK_STATE_SHOWING).
(In reply to comment #3) > (In reply to comment #2) > > 1. CSS visibility:hidden does not render the content, but does render empty > > space that is the size that the content would occupy. This is the preferred > > way of hiding text on the web while still occupying the same space. That is, > > don't use transparency for this. But, I don't know if the St toolkit's CSS > > parser/renderer is as sophisticated as gecko or webkit here -- can it use > > visibility:hidden? > > It would be really simple to add. Ok, then lets maintain my patch on "tentative" status. If finally this CSS visibility:hidden is implemented I could just update my patch. If not we can upgrade my patch status from "tentative" to "best option right now" and apply it. Thanks.
( > Ok, then lets maintain my patch on "tentative" status. If finally this CSS > visibility:hidden is implemented I could just update my patch. > ... Ideally: 1. implement support for the CSS 'visibility' selector and its values { visible | hidden | collapsed } -- see http://www.w3.org/TR/CSS2/visufx.html#visibility 2. implement support for the 'display' selector and its values (too many to list here, but the most important with respect to this bug is 'none') -- see http://www.w3.org/TR/CSS2/visuren.html#propdef-display 3. implement the getComputedStyle() method -- see http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-OverrideAndComputed. This is what the patch would use to get the styling info for the St widget, and from there determine its visibility/display, and what to publish to the a11y layer. That sounds a lot like implementing a browser, and might be overkill. Note the "Ideally" qualifier.
(In reply to comment #6) > That sounds a lot like implementing a browser, and might be overkill. Note the > "Ideally" qualifier. In relation with that, I have been talking with Jasper on IRC. I proposed to use something similar to my previous patch meanwhile all the CSS stuff is implemented. We agreed that check for something called "prompt-dialog-null-label" doesn't seems too formal, so he proposed to add a style class called hidden.
Created attachment 215562 [details] [review] Add "hidden" style class This patch adds a hidden style class, and uses it on polkitAuthenticationAgent. As that label uses both styles, I think that it is useless (and probably error-prone) to keep the invisible color on prompt-dialog-null-label, so I removed that from that style class.
Created attachment 215563 [details] [review] Do not expose label text is hidden style is used On StLabelAccessible is checks the style of the base object. If it includes 'hidden' the text is not exposed.
Review of attachment 215563 [details] [review]: ::: src/st/st-label.c @@ +481,3 @@ +{ + /* See bug BGO#675341: 'hidden' style is used similar way that + hidden tag on html. In that case we don't expose the text */ HTML doesn't have a hidden tag. I don't think this comment is necessary. @@ +504,1 @@ if (actor == NULL) /* State is defunct */ if (actor == NULL || st_widget_has_style_class_name (ST_WIDGET (label), "hidden"))
Created attachment 215612 [details] [review] Add "hidden" style class Removed reference to "hidden" tag on the commit message (sorry, I was talking about the attribute value for input fields)
Created attachment 215613 [details] [review] Do not expose label text if hidden style is used Updated patch after review on comment 10
Review of attachment 215612 [details] [review]: Looks fine.
Review of attachment 215613 [details] [review]: Sure as well.