GNOME Bugzilla – Bug 739981
Need a role for static/generic objects
Last modified: 2014-12-04 18:11:17 UTC
There is currently no AtkRole type that reflects objects which meet all of the following criteria: 1. Contains accessible information directly (i.e. and not in a child object) 2. Has a role that is known by the implementor 3. Lacks a role with any semantic value for the end user 4. Is not something the user can interact with If 1 were not the case, then ATK_ROLE_PANEL would make sense as its documented definition is "A generic container that is often used to group objects." If 2 were not the case, then ATK_ROLE_UNKNOWN would make sense as its documented definition is "The object contains some Accessible information, but its role is not known." As for why we cannot address 3 by changing the documentation of ATK_ROLE_UNKNOWN (which seems like the easiest way to go): Orca tends to not touch objects with ATK_ROLE_UNKNOWN. After all, if the implementor truly has no idea what the thing is, what should the AT do to provide access to it? What interfaces should it check for? What user actions are applicable? Does this accessible object even have a backing widget in the application? All bets are off with "unknown" objects.... If 4 were not the case, odds are that it's a frequently-encountered widget or container for which there is an appropriate AtkRole. As for the use case: See http://lists.w3.org/Archives/Public/public-pfwg/2014Nov/0131.html.
Some additional thoughts: Because the object which meets all of the above criteria is static/generic/plain and non-interactive, the only accessible interface I would expect implemented -- and which Orca will check for -- is the AtkComponent, because the object presumably occupies space. Lastly, implementors should expose the information to be conveyed through the accessible name.
Created attachment 290435 [details] [review] Add ATK_ROLE_STATIC Take 1. Thoughts?
Review of attachment 290435 [details] [review]: lgtm. Somme comments below. ::: atk/atkobject.h @@ +211,3 @@ + expose the displayed information through the accessible name of the object. + For generic containers, see ATK_ROLE_PANEL. For objects whose role is not + known by the implementor, see ATK_ROLE_UNKNOWN. @Since: ATK-2.16. The documentation is good. <rant that can be ignore>I had the feeling that it lacked an example to understand when to use it, but I realized that that can be applied to any role, and more that in this documentation, that example should be put on the mythical ATK implementation guide.</rant> @@ +339,3 @@ ATK_ROLE_DESCRIPTION_TERM, ATK_ROLE_DESCRIPTION_VALUE, + ATK_ROLE_STATIC, Again, I don't like too much the name, but I don't have a better option. So lets go with this name (if you find a better one, that would be welcomed)
Comment on attachment 290435 [details] [review] Add ATK_ROLE_STATIC Thanks for the review! I'm changing the ACN status to Reviewed for a couple of reasons: 1. I am not very good at ignoring rants. ;) And we've been threatening to write the implementation best practices for years now. Adding an example within the current docs sounds like a good idea. 2. The proposed patch excludes static text through implication: You can often interact with static text by giving it focus (example: GtkLabel in a number of our message boxes) and/or selecting its contents. That exclusion was deliberate at the time I created the proposed patch. But that leaves the question of how to expose interactive static text. If that text were exposed as ATK_ROLE_TEXT, Orca would not be able to distinguish it from GtkTextView. And what Orca presents (with respect to automatic reading, role name presentation, presentation of "read only", pausing because it's a separate accessible, etc.) for a GtkTextView is not what Orca should present for inline static text. One option is yet another new role! ;) Another option is to broaden the ATK_ROLE_STATIC to allow for textish interaction. I'm leaning towards the latter, including more docs to explain that as a valid mapping, and the aforementioned examples. New patch later today.
Created attachment 290523 [details] [review] Add ATK_ROLE_STATIC and clarify ATK_ROLE_TEXT Take 2: This version includes examples and additional guidance for authors. It makes it possible for ATK_ROLE_STATIC to be applicable to text. And lastly it tries to steer authors away from trying to use ATK_ROLE_TEXT for static content.
Created attachment 290525 [details] [review] Add ATK_ROLE_STATIC and clarify ATK_ROLE_TEXT Take 3: Be more explicit about "solicits" versus "accepts" input. (Piñeiro gave me feedback on the previous version via IRC. This version addresses that review.)
Alex (Surkov): Any feedback on the latest version? It is meant to address a couple of things: 1) the new ARIA role="text" 2) what ATK_ROLE_TEXT should (and should not) be used for. The latter issue gets back to https://bugzilla.mozilla.org/show_bug.cgi?id=1013584#c4 and the subsequent discussion.
(In reply to comment #7) > Alex (Surkov): Any feedback on the latest version? I have unclear feeling about it since text interface was used to expose the text in ATK. Is this role supposed to implement the text interface or is it supposed to substitute it? > It is meant to address a > couple of things: 1) the new ARIA role="text" I don't have a good idea what ARIA role="text" is, I can see the use case of it but its mapping to a11y API is completely dark matter with me :) > 2) what ATK_ROLE_TEXT should in Gecko we use it for text containers, perhaps it's not ATKish but does proposed role address it some way?
(In reply to comment #8) > (In reply to comment #7) > > Alex (Surkov): Any feedback on the latest version? > > I have unclear feeling about it since text interface was used to expose the > text in ATK. Is this role supposed to implement the text interface or is it > supposed to substitute it? I suppose that depends on what the author is trying to claim is "text" via the new ARIA role. Given: <img src="icon.gif" alt="love" role="text"> I would say that you have: * ATK_ROLE_STATIC * object.name = "love" * does NOT implement the AtkText interface because: - There is no user interactable text - There are no offsets in which to position the cursor - There is no ability to select a subrange of the contents - There are no text attributes * does NOT implement the AtkImage interface because it's an un-image * does implement the AtkComponent interface because it occupies space On the other hand, this next example is probably something that requires feedback from others (best practices, authoring guides, James ....): <span role="text img" aria-label="3 of 5 stars">★★★☆☆︎</span> If the expected user interaction is that a user should be prevented from arrowing character by character amongst the stars, then you should not implement the AtkText interface. If you tell Orca something implements AtkText, it will try to let the user navigate within that element. If that is really NOT something Orca should permit, don't implement AtkText. In contrast, and ignoring ARIA for a second, taking a look at this scenario: <abbr title="Web Hypertext Application Technology Working Group">WHATWG</abbr> In that case, I'd think you'd use ATK_ROLE_STATIC (ATK_ROLE_TEXT is NOT for static text, as the new ATK documentation states). You WOULD implement the AtkText interface because "WHATWG" surely should be user interactive (can set a caret in it, can select it, can copy it, etc.). > I don't have a good idea what ARIA role="text" is, I can see the use case of it > but its mapping to a11y API is completely dark matter with me :) I honestly think this mapping (i.e. to ATK_ROLE_STATIC) makes good sense. What Orca will do when it sees a ROLE_STATIC is what James stated is the desired behavior: * Don't speak any role * Don't pause as if it is separate accessible * Treat it like it's inline text In the case of something with ATK_ROLE_STATIC which implements AtkText (Orca's clue that this generic stuff is real text and likely caret navigable), Orca will also: * Present the text **when using caret navigation** (so "WHATWG") * Present the name when using WhereAmI (so "Web Hypertext Application ....") Related aside: There was some discussion on the Orca list a while back on the topic of: Should Orca present the overridden name for real text content? Or should Orca present the real text content, but alert the user to the presence of additional details and provide a means to optionally obtain those details? The user consensus was the latter. So if Orca knows about real text via AtkText, that is what Orca is going to present (and attempt to navigate within). > > 2) what ATK_ROLE_TEXT should > > in Gecko we use it for text containers, perhaps it's not ATKish Please stop. ;) As I stated in on https://bugzilla.mozilla.org/show_bug.cgi?id=1013584#c12 (and elsewhere within that bug). Gecko's using ATK_ROLE_TEXT in ways that no other ATK implementors are. It would be helpful if ATK_ROLE_TEXT were applied more consistently with the rest of our platform. For this reason, the patch has a much longer definition of ATK_ROLE_TEXT than the docs currently have. > but does > proposed role address it some way? I think it does. For many of things you're probably using ATK_ROLE_TEXT for now, you'll instead use the new ATK_ROLE_STATIC. In addition, any element that has the new ARIA role="text" will also use ATK_ROLE_STATIC. I think this solution will make it possible for ARIA and authors to have this role and ATs to not get screwed up by it. Question is, what other guidance in the form of ATK documentation do you need so that what you as an ATK implementor should do is more clear to you?
So in summary role="text" doesn't define navigable, selectable text for AT, basically it's not a text, it's an inline having accessible name. Taking this into account role="text" sounds rather confusing since it doesn't have anything common with text. I guess role="inline" sounding more techy makes the role propose much clearer. Not sure if static role goes with MSAA terms where static text role is not selectable text like list bullet or CSS generated text, otherwise what you say above looks reasonable.
(In reply to comment #10) > So in summary role="text" doesn't define navigable, selectable text for AT, > basically it's not a text, it's an inline having accessible name. It may or may not be text. But ATs are supposed to treat it as if it were. > Taking this > into account role="text" sounds rather confusing since it doesn't have anything > common with text. I agree about confusing. See my responses on the PFWG public mailing list: * http://lists.w3.org/Archives/Public/public-pfwg/2014Nov/0127.html * http://lists.w3.org/Archives/Public/public-pfwg/2014Nov/0134.html > I guess role="inline" sounding more techy makes the role > propose much clearer. Arguably this new ARIA role isn't necessarily going to be limited to just inline elements. BUT none of that matters wrt this GNOME bug in which we're having this conversation. What this bug here is about is: ATK (and AT-SPI2) is going to get a new role. In addition, the documentation is being updated for ROLE_TEXT. The reasons for making these changes in ATK (and AT-SPI2) are: * Define clearly what ATK_ROLE_TEXT (and ATSPI_ROLE_TEXT) should -- and should not -- be used for. As you yourself said in https://bugzilla.mozilla.org/show_bug.cgi?id=1013584#c11: "I need to better understand ATK_ROLE_TEXT." And as I responded in https://bugzilla.mozilla.org/show_bug.cgi?id=1013584#c12: "And the ATK docs don't help there." I hope the new docs for ATK_ROLE_TEXT help you understand what ATK_ROLE_TEXT shold be used for. * Create a new role which implementors can use for generic/static accessible objects where the role is of no value whatsoever to end users or to ATs trying to figure out how to provide access to it. That new role is ATK_ROLE_STATIC (and ATSPI_ROLE_STATIC). It applies to things which already exist in HTML. These changes are independent of ARIA role="text" / role="inline" / role="please-do-not-pause-or-speak-a-role-here". But assuming that new role sticks around, oh btw, implementors should use ATK_ROLE_STATIC for the mapping. I'm sure that as we move forward implementing this new ATK_ROLE_STATIC, there will be questions. And we can tackle them as they come up -- and update the ATK documentation as needed so that the answers are crystal clear for other and future ATK implementors. Given that I am not seeing any significant concerns from you about this new ATK role, Piñeiro please review when you have a chance. Thanks to both of you!!
(In reply to comment #11) > (In reply to comment #10) > > So in summary role="text" doesn't define navigable, selectable text for AT, > > basically it's not a text, it's an inline having accessible name. > > It may or may not be text. But ATs are supposed to treat it as if it were. I'm confused then. My understand of what text is in terms of AT API is the matter you can have an access to via Text interface, so you can navigate it by lexems, in other words text is something that consists of characters, words, sentences. No lexems -> no text. > > Taking this > > into account role="text" sounds rather confusing since it doesn't have anything > > common with text. > > I agree about confusing. See my responses on the PFWG public mailing list: > * http://lists.w3.org/Archives/Public/public-pfwg/2014Nov/0127.html > * http://lists.w3.org/Archives/Public/public-pfwg/2014Nov/0134.html > > > I guess role="inline" sounding more techy makes the role > > propose much clearer. > > Arguably this new ARIA role isn't necessarily going to be limited to just > inline elements. in that case should no-pauses be applied as well? I've got impression that blocking structure is different for reading and navigation by AT. > What this bug here is about is: ATK (and AT-SPI2) is > going to get a new role. right but the bug is considered in context of new ARIA role="text" which I don't quite understand :) > * Create a new role which implementors can use for generic/static accessible > objects where the role is of no value whatsoever to end users or to ATs trying > to figure out how to provide access to it. That new role is ATK_ROLE_STATIC > (and ATSPI_ROLE_STATIC). that should be fine It applies to things which already exist in HTML. can you give an example of it?
(In reply to comment #12) > I'm confused then. My understand of what text is in terms of AT API is the > matter you can have an access to via Text interface, so you can navigate it by > lexems, in other words text is something that consists of characters, words, > sentences. No lexems -> no text. We have ATK_ROLE_TEXT and we have the AtkText *interface*. These are independent of one another. As you know, we have many AtkRole types that are expected to implement the AtkText interface. ATK_ROLE_PARAGRAPH is one example. ATK_ROLE_LABEL is another. ATK_ROLE_SECTION, ATK_ROLE_HEADING, etc., etc. are other examples of AtkRole types for which an AtkText *interface* implementation is expected. ATK_ROLE_TEXT is the expected role for GtkTextView and widgets like GtkTextView. Clearly GtkTextView and widgets like GtkTextView hold text. Thus an implementation of the AtkText interface is also expected for ATK_ROLE_TEXT. But, again, the role and the interface are independent of one another. > right but the bug is considered in context of new ARIA role="text" which I > don't quite understand :) Forget I even mentioned it. :) > It applies to things which already exist in HTML. > > can you give an example of it? <p>Will there be <span onclick="playDramaticSound()">war</span> between <abbr title="Web Hypertext Application Technology Working Group">WHATWG</abbr> and the W3C?</p> Gecko exposes that as: -> ATK_ROLE_PARAGRAPH -> ATK_ROLE_TEXT <-- wrong, please stop -> ATK_ROLE_TEXT <-- wrong, please stop
Review of attachment 290525 [details] [review]: (In reply to comment #11) > Given that I am not seeing any significant concerns from you about this new ATK > role, Piñeiro please review when you have a chance. Taking into account that we concluded that this is about ATK, and that the concerns about aria roles should go to aria-related sources. LGTM.
Comment on attachment 290525 [details] [review] Add ATK_ROLE_STATIC and clarify ATK_ROLE_TEXT Thanks! https://git.gnome.org/browse/atk/commit/?id=c6e623b
(In reply to comment #13) > > It applies to things which already exist in HTML. > > > > can you give an example of it? > > <p>Will there be <span onclick="playDramaticSound()">war</span> between <abbr > title="Web Hypertext Application Technology Working Group">WHATWG</abbr> and > the W3C?</p> > Gecko exposes that as: > > -> ATK_ROLE_PARAGRAPH > -> ATK_ROLE_TEXT <-- wrong, please stop > -> ATK_ROLE_TEXT <-- wrong, please stop oh, that's interesting, so you want static role for plain text container and section role for rich text containers?
(In reply to comment #16) > oh, that's interesting, so you want static role for plain text container and > section role for rich text containers? Does rich text include styled text? If so, then no, that's not what I want. * <span style="color:red">War</span> - Not a separate accessible * <span style="color:red" onclick="boom()">War</span> - static I think that ~95% of the time a good rule of thumb will be: IF its inline and IF it needs to be exposed as a separate accessible and IF there's no good role for it, THEN it's static. Having said that, what I'm doing slowly but surely is working through Steve Faulker's "ASS" table, looking at what's in WebKitGtk, thinking about the mappings and scenarios, and proposing patches. When I'm done with that, I should have a list in the form of a single (WebKit) Layout test that I can share with you and we can discuss. I was hoping to add that to our Web Engines hackfest agenda, but we can do it remotely.
I think about the rule like this * if accessible node contains single text node then use static role * otherwise use section role Does it look workable?
What what your rule do in this case? <table role="none"> <tr><td>war</td><td>peace</td></tr> </table> Each of those td elements contains a single text node, right? And they cannot be exposed using the table cell role because they are presentational children. But I would NOT want these exposed using the static role; they should be exposed using the section role.
because of block display? So making the static role reserved for inlines? But it looks like you argued that role="text" which is supposed to be mapped into static can be a block (per comment #11), or should it also have the section role?
(In reply to comment #20) > because of block display? So making the static role reserved for inlines? See what I stated in comment 17, namely: I think that ~95% of the time a good rule of thumb will be: IF its inline and IF it needs to be exposed as a separate accessible and IF there's no good role for it, THEN it's static. In other words, mainly, yes: static is reserved for inlines. ~95% of the time. That leaves ~5% of the time when a non-inline element needs role static. A good example of one of these special cases is what you pointed out here: > But > it looks like you argued that role="text" which is supposed to be mapped into > static can be a block (per comment #11), or should it also have the section > role? If role="text" is applied, you should use probably use the static role. Again, the ARIA role "text" is supposed to tell ATs: "Don't pause and don't speak a role." Orca pauses if it's a section. If you want Orca to not pause, do not make it a section; make it static. And if you look at James Craig's spec text for the new ARIA role="text", you'll see examples that include inline spans and images. So ARIA role="text" == static. ============================================ WARNING: EDGE CASE ALERT!! EDGE CASE ALERT!! ============================================ What you do NOT see in James Craig's spec text or examples are: Authors SHOULD only use role="text" for inline elements. As a result, there is nothing preventing authors from doing: <div role="text"> A huge crapload of text, far more text than could be inline. And, oh, by the way, this element is a block element on the screen. Orca probably should not combine it with other elements when presenting it to the user. But role="text" seemed like a good role because, well, all of the stuff in this element IS text after all, right? And adding roles to divs makes the divs more accessible, doesn't it? </div> IF an author does that, THEN I do not think you should use the static role; I think you should use the section role. But, again, as the friendly warning indicates, this is an edge case.
let's see where we end up with role="text" but I would follow 95% rule for the start.