On 17/04/2010 5:28 PM, Rob Gallo wrote: > This issue is a tough one. I would like to suggest yet another approach > where embed characters would have their own ranges, and those ranges should > basically return an empty attribute string, or a string that would amount to > plain text. In principle, I totally agree with you. However, the problem is that this requires clients to make many more calls to IAccessibleText::get_attributes() than they would with the other approach. This isn't such an issue for in-process clients, but it most definitely a performance penalty for out-of-process clients. This will affect NVDA to some extent (we have a sort of hybrid of in-proc and out-proc stuff). However, if I'm not mistaken, this change will also affect ATK clients (all out-of-process), as the cross-platform layer implementation will be the same. Alex, am I correct here?
Having said that, if I understand correctly, Firefox is already exposing these as separate ranges (even descending to get the formatting), so maybe this isn't such an issue. However, on a big block of text with lots of embedded objects, it could get a bit nasty. > Here's why: embed characters aren't, strictly speaking, text. They > represent objects which contain their own text. And the text of the target > objects should have their own attributes. If the object that contains the > embed character and the target object have differing sets of attributes, > that leads to confusion. The idea that Aaron Leventhal proposed was that ATs should just ignore the formatting for the embedded object characters, as it has to descend to get the formatting anyway. It is done for the purpose of optimisation only; as I said, I totally agree with you in principle. This *definitely* needs to be very well documented if it is going to happen. Alex, if this is going to affect ATK as well, we should probably pull Joanie and maybe others into the discussion. Jamie -- James Teh Vice President NV Access Inc, ABN 61773362390 Email: [email protected] Web site: http://www.nvaccess.org/ _______________________________________________ Accessibility-ia2 mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
