These elements allows to point URL at the revision and date of the change. Currently Firefox doesn't expose accessibles for them at all. Perhaps we need to expose text container accessibles for these elements and expose an accessible action to open the URL like we do in case of img@longdesc. Probably the browser needs to have UI. Thoughts are welcome. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/del https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ins

Jamie suggestion: object attributes: revision:ins/del, cite and datetime per twit

Has any work been done on this? We need <del> and <ins> to be communicated to screen readers through the accessibility API so that blind users can know which text has been deleted and which text has been inserted. According to one of the NVDA lead developers (already copied on the bug here), this information is not being appropriately conveyed by Firefox to the accessibility API. This shortcoming in Firefox makes it difficult to understand things like legal documents on the web which frequently use del and ins syntax to convey old versus new versions.

There is a lengthy discussion of this issue on the NVDA bug tracker: http://community.nvda-project.org/ticket/4920 The short version that's relevant here is that NVDA needs the del and ins elements exposed to the API or else it won't be able to present the semantic meaning to users. Sometimes that meaning is quite important. Besides legal documents, I've seen del and ins used to convey old prices versus new prices on e-commerce sites, or to convey humor by saying an inappropriate word first with <del> then a more appropriate word with <ins>. There are other ways in which it is used too. The meaning is lost on screen reader users without having this information available in the API.

Discussion on how to expose this in IA2 here: https://github.com/LinuxA11y/IAccessible2/issues/4 We need this for Google Docs.

New IA2_ROLE_CONTENT_INSERTION/DELETION roles were added: https://github.com/LinuxA11y/IAccessible2/pull/5 Chrome already exposes these. I'm inclined to not worry about the cite and datetime attributes for now. We can always address this later if there is a need for them. I don't think it makes sense to block the role implementation on this. There's also an ARIA issue for role parity for ins/del: https://github.com/w3c/aria/issues/526 Joanie, how should we map this for Linux? I don't think there are insertion/deletion roles there (yet?) from what I could find.

P2 because this is needed by Docs and it shouldn't be too hard to implement (I think?).

(In reply to James Teh [:Jamie] from comment #6) > P2 because this is needed by Docs and it shouldn't be too hard to implement > (I think?). agreed, just a couple of entries in the markup map, plus internal roles and their platform mappings.

Comment on attachment 8995433 [details] Bug 903187: Map HTML ins/del to accessible roles. https://reviewboard.mozilla.org/r/259888/#review266912 r=me with these fixed/answered. ::: accessible/base/RoleMap.h:1427 (Diff revision 1) > ROLE(BLOCKQUOTE, > "blockquote", > ATK_ROLE_BLOCK_QUOTE, > NSAccessibilityGroupRole, > ROLE_SYSTEM_GROUPING, > IA2_ROLE_SECTION, You need to rebase the patch on top of bug 1478568. ::: accessible/tests/mochitest/elm/test_HTMLSpec.html (Diff revision 1) > > obj = { > role: ROLE_PARAGRAPH, > - textAttrs: { > - 0: { }, > - 6: { "text-line-through-style": "solid" } Why do you remove these checks for style? Aren't we still interested in checking that something sensible is exposed through text attributes here? ::: accessible/tests/mochitest/elm/test_HTMLSpec.html (Diff revision 1) > > obj = { > role: ROLE_PARAGRAPH, > - textAttrs: { > - 0: { }, > - 6: { "text-underline-style": "solid" } Same.

I'll see about adding these roles to ATK and AT-SPI2.

Comment on attachment 8995433 [details] Bug 903187: Map HTML ins/del to accessible roles. https://reviewboard.mozilla.org/r/259888/#review266912 > You need to rebase the patch on top of bug 1478568. Oops. Done. > Why do you remove these checks for style? Aren't we still interested in checking that something sensible is exposed through text attributes here? I actually tried, but I couldn't get this to work. I moved the attribute check to offset 0 inside the ins/del element, but it kept complaining that it couldn't find the expected attribute. I think this test function is designed to test for attribute changes, not attributes which span the entire object. I don't quite understand what "default" attributes are, but the function disables checking for these and I assume that's what this is about. I'm choosing not to worry about this because we only test text attributes for other elements where the element doesn't get an accessible created for it; e.g. <b>, <i>, <u>, etc. Now that ins and del do get an accessible, the semantic is more important, just like it is for <a href>, <address>, etc.

Pushed by jteh@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b6c8ed7e23e3 Map HTML ins/del to accessible roles. r=MarcoZ

Joanie, I've mapped these to ATK_ROLE_SECTION for now. We can open a new bug if/when the ATK roles land.