User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091125 Minefield/3.7a1pre (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091125 Minefield/3.7a1pre (.NET CLR 3.5.30729) It seems that DL (definition list), DT (definition list term) and DD (definition list definition) get exposed with an IAccessible2 role of paragraph. This means that to an AT using IAccessible2, these nodes can not be identified correctly, and the AT can only tell that they are paragraphs. I propose that: * DL be mapped to ROLE_LIST * DT be mapped to ROLE_LISTITEM * DD be left alone (paragraph is probably most appropriate) Reproducible: Always I don't seem to see an NSAccessible role constant for any of the three node types. So I guess it won't be as simple as changing the MSAA role map.

In the past Aaron has suggested that anything that doesn't map well to IAccessible2 should be mapped to an IAccessible2 role of unknown (0) as accRole exposes the actual tagName as a string (assuming it didn't map well to MSAA either). Then the idea is that if IAcessible2 role is 0, then the accRole string should be used, and some how mapped in the AT however it sees fit. I'm not really bothered in this situation whether these are mapped to list and listItem, or simply to unknown, but I'd like to see a standard rule used. through out all the tagNames. From NVDA's point of view specifically: we already map accRole string of DL to list and DT to listItem. However we only resort to using accRole if IAccessible2 role returns unknown. So either mapping them to list/listItem or unknown both works fine for NVDA. Noting that at the moment IAccessible2 role returns paragraph, so we don't bother checking accRole.

Comment on attachment 415627 [details] [diff] [review] patch1 r=me. I'm curious how this will play out in the actual usability scenario. Meaning, what the talks will be with the paragraph and list items being mixed like this.

The patch looks right but it might be not sufficient. 1) Is it ok to use unchanged list/listitem accessible for dl/dt because they keep the logic of list bullets? 2) It's sort of strange when list contains paragraphs together with list items on the same level. Interesting examples from w3c: <DL> <DT><STRONG>Lower cost</STRONG> <DD>The new version of this product costs significantly less than the previous one! <DT><STRONG>Easier to use</STRONG> <DD>We've changed the product so that it's much easier to use! <DT><STRONG>Safe for kids</STRONG> <DD>You can leave your kids alone in a room with this product and they won't get hurt (not a guarantee). </DL> <DL> <DT>Center <DT>Centre <DD> A point equidistant from all points on the surface of a sphere. <DD> In some field sports, the player who holds the middle position on the field, court, or forward line. </DL>

(In reply to comment #4) > The patch looks right but it might be not sufficient. > > 1) Is it ok to use unchanged list/listitem accessible for dl/dt because they > keep the logic of list bullets? Yeah I considered this. On inspection it looks like the bullet logic is harmless -- did you catch anything? > 2) It's sort of strange when list contains paragraphs together with list items > on the same level. A little, but I think it makes sense to map as much as we can. Did you want the W3C examples included in a mochitest? (Not sure if that's necessary).

(In reply to comment #6) > (In reply to comment #4) > > 2) It's sort of strange when list contains paragraphs together with list items > > on the same level. > > A little, but I think it makes sense to map as much as we can. Yeah, but we should try to expose in more friendly way to AT and ensure we won't confuse any existing AT. Mick, Jamie, it's your turn. How are you going to deal with these lists when the list item content is outside of list item accessible? Probably we need to provide NODE_CHILD_OF relation. > > Did you want the W3C examples included in a mochitest? (Not sure if that's > necessary). Yes, please :) They are funny.

(In reply to comment #7) > Probably we need to > provide NODE_CHILD_OF relation. > Yeah, I think that's we need to do. It's common thing when children are outside of their container and aria-owns is used.

From NVDA's point of view, we don't believe we need nodeChildOf. I think its quite debatable whether a dd (definition list definition) is theoretically a child of the dt (definition list term). I certainly don't see it this way. My belief is also that its usually safest to expose structure that is as close to the DOM as possible, unless its specifically requested by many to make a structure change. Perhaps other ATs may want to comment, but for us this will not cause any problems.

OK my current patch might make Jaws say "List of" instead of "Definition list of"... which is maybe not ideal. Mick's comment 1 might be the way to go after all -- not sure. Waiting to hear back from FS...

I have a "go" from FS for this patch.

(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #4) > > Did you want the W3C examples included in a mochitest? (Not sure if that's > > necessary). > > Yes, please :) They are funny. Really? I liked mine better :P

I tested this with JAWS 11, and it is just fine with and without the patch. No difference.

Comment on attachment 415627 [details] [diff] [review] patch1 >+ else if (tag == nsAccessibilityAtoms::dt || >+ (tag == nsAccessibilityAtoms::li && >+ aFrame->GetType() != nsAccessibilityAtoms::blockFrame)) { Do you need to check whether it's blockFrame or not for dt?

(In reply to comment #14) > (From update of attachment 415627 [details] [diff] [review]) > > >+ else if (tag == nsAccessibilityAtoms::dt || > >+ (tag == nsAccessibilityAtoms::li && > >+ aFrame->GetType() != nsAccessibilityAtoms::blockFrame)) { > > Do you need to check whether it's blockFrame or not for dt? Hmmm maybe we should (see bug 346730). I think I will make that change.

Oh wait no, we don't need this check for dt. The reason we check for it for li if li is block then the accessible for it is already created in /layout/generic/nsBlockFrame.cpp (and not for dt). The reason li has a special CreateHTMLLIAccessible is due to the bullets.

Comment on attachment 415627 [details] [diff] [review] patch1 ok, r=me

Landed 1.9.3: http://hg.mozilla.org/mozilla-central/rev/843fd8228ab8