Steps to reproduce: 1. Launch the attached accessible-event listener in a terminal 2. Load the attached test case is Epiphany Expected results: The child elements would each be exposed as if they were div elements. Actual results: The list items are removed from the hierarchy with their text folded into the body and without spaces to separate them. The table cells are distinct objects (good) but exposed as ROLE_TEXT (not good): -> [document frame | file:///home/jd/role-presentation.html] text: <[OBJ]item 1item 2[OBJ][OBJ][OBJ][OBJ][OBJ]> -> [paragraph | ] text: <The next element is an unordered list with role presentation.> -> [paragraph | ] text: <The next element is a table with role presentation.> -> [text | ] text: <row 1, col 1> -> [text | ] text: <row 1, col 2> -> [text | ] text: <row 2, col 1> -> [text | ] text: <row 2, col 2>

Ugh. And by "Epiphany" I of course mean "Firefox." Sorry about that. FWIW, WebKitGtk ain't doing it right either. ;)

Alex you've been dealing with strange "tables" lately want to take it?

similar to bug 945435. Why does text role not work here?

(In reply to alexander :surkov from comment #4) > similar to bug 945435. Why does text role not work here? What was your reasoning for not choosing the div role in the first place? Why should a screen reader treat <ul role='presentation'><li>foo</li></ul> as if it were somehow different from <div>foo</div> ? By exposing different roles for the items above to ATs, you are suggesting that there is a relevant difference the ATs should handle and/or present to the user. I don't believe that such a difference exists here. Beyond that, other ATK implementors use ATK_ROLE_TEXT for widgets like textviews. Widgets tend to have roles, names or labels, and states of interest to the user. None of that is true here.

div is a generic container while ATK text is a generic text container. Firefox uses section role for HTML div, section and nav elements, text container role is used for things like HTML:abbr and as fallback role for elements having inline display. For elements with block display Firefox uses paragraph role. HTML li and td are rather text containers than sections but they have block structure so following Firefox logic they should be rather paragraphs. Can you give couple examples of textview widgets?

(In reply to alexander :surkov from comment #6) > HTML li and td are rather text containers than sections but they have block > structure so following Firefox logic they should be rather paragraphs. Problem with making it a paragraph is that Orca has navigation by paragraph and I don't think Orca users would want to find non-paragraphs things like we're discussing in that mix. > Can you give couple examples of textview widgets? In gtk3-demo, the "info" and "source" for each demo are textviews. Also gtk3-demo has a textview demo (under text widget -> multiple views). In gedit (GNOME's Notepad equivalent), the widget containing the entire document is a text view).

Jamie, does NVDA has a preference between paragraph, text_frame or section roles for those elements?

(In reply to Joanmarie Diggs from comment #7) > > Can you give couple examples of textview widgets? > > In gtk3-demo, the "info" and "source" for each demo are textviews. Also > gtk3-demo has a textview demo (under text widget -> multiple views). > > In gedit (GNOME's Notepad equivalent), the widget containing the entire > document is a text view). do you have examples in web?

Of GtkTextViews? No. ;) Of things on the web which I would consider the equivalent, how about this: http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/editor/Editor.html Ironically, Gecko exposes the editor widget as ATK_ROLE_TEXT. Which is awesome both in it being a role I'd expect to see and in it being an illustration of why exposing the presentational children with the very same role is a source of potential confusion for ATs. As a related aside, the text in that demo is something I'd expect to see as the contents of the ATK_ROLE_TEXT object; not as the contents of a child of ATK_ROLE_SECTION. Objects of ATK_ROLE_TEXT don't have children. But that's another bug or two.

I need to better understand ATK_ROLE_TEXT. If it's not supposed to contain any children then the example above shouldn't be a good demo for the role since it's the editor and thus it can contain images.

(In reply to alexander :surkov from comment #11) > I need to better understand ATK_ROLE_TEXT. And the ATK docs don't help there. I've been ranting to my fellow GNOME developers and have just added: "Torch the AtkRole docs, deprecate some old useless roles, and thoroughly document what we keep" to my to-do list. In the meantime, the currently-undocumented expectations include: * Being a multi-line widget (a single-line widget is typically ATK_ROLE_ENTRY) * Can have formatting (font weight, font color, etc.) but doesn't have to. * Cannot have semantic, structural information like headings or tables. Given an (accessible) editor which had support for syntax highlighting, the widget containing the text should be ATK_ROLE_TEXT. (Again, this is the role for Gedit.) Given an (accessible) document viewer or editor in which you could have child objects (widgets, headings, tables, images, etc.), one of the ATK_ROLE_DOCUMENT_* roles would be appropriate. > If it's not supposed to contain > any children then the example above shouldn't be a good demo for the role > since it's the editor and thus it can contain images. My bad. Sorry about that. But I hope it does at least clarify why exposing the presentational children in the opening report as ROLE_TEXT is, at least for ATK/AT-SPI2, less than ideal.

(In reply to alexander :surkov from comment #8) > Jamie, does NVDA has a preference between paragraph, text_frame or section > roles for those elements? For consistency, I'm leaning towards paragraph as explained in comment 6. As i see it, this is similar to: <span style="display: block;">foo</span> Firefox has always treated divs as special. I do agree that the paragraph role is odd as explained in comment 7. "Paragraph" suggests that the author really, semantically meant it to be a *paragraph* of text as opposed to a generic block of text. However, if this is going to be changed, it should be changed across the board (e.g. including the block span example I gave above) and I think that needs to be addressed separately.

I agree we deal here with bunch of bugs 1) li of presentational list should have generic role 2) ATK_ROLE_TEXT is misused, my understanding that Firefox should never use it (except HTML textarea?) as it never knows what is expected underneath. 3) presentational kids role is confusing

What role should be used instead ATK_ROLE_TEXT for text containers (other than text areas)?

(In reply to alexander :surkov from comment #15) > What role should be used instead ATK_ROLE_TEXT for text containers (other > than text areas)? As I stated in the opening report, those presentational block elements should be exposed as if they were div elements which means they should be exposed as ATK_ROLE_SECTION. To be clear, the discussion and newly-added role on https://bugzilla.gnome.org/show_bug.cgi?id=739981 doesn't impact this bug here about block element children which inherit the presentational/none role. New bugs will be filed before too long about spans with onclicks, abbr elements, etc. ;) And as a preview: Those should NOT be exposed as div elements. But one thing at a time.... :)

Comment on attachment 8526197 [details] [diff] [review] patch Review of attachment 8526197 [details] [diff] [review]: ----------------------------------------------------------------- r=me looks good.

Testing a nightly, I found the following mappings: <li> exposed as ROLE_PARAGRAPH. <td> exposed as ROLE_TEXT + AccessibleText interface. For comparison, a <div> is exposed with ROLE_SECTION. Also, I'm wondering about the use case where a <li> contains multiple <p> elements in a list with role="presentation". It's not possible to expose the whole item as ROLE_PARAGRAPH, with children that also have ROLE_PARAGRAPH. Is it?