We started our accessible text rework in Firefox. It's time to revisit our IAccessible2 text implementation and compare it to ATK text.
Both IAccessible2 and ATK allows you to navigate the text by characters, words and lines. To do so they both provide these three methods:
A difference #1. IAccessible2 getTextAtOffset may return nothing when you asked for a word. This happens when the given offset is between words (see the spec).
ATK always returns a word, no matter where you are because it requires to return the text between two word start or word end offsets (check out the spec).
A difference #2. IAccessible2 getTextAfter/BeforeOffset always return the requested lexem after/before the given offset.
ATK get_text_after/before_offset methods may return a lexem at the offset under certain circumstances. For example here's the case of word end boundary in get_text_after_offset method:
In short ATK and IAccessible2 supply two resembling but different concepts of text traversal. ATK allows you to move through the whole text by any method. For example, text_get_text_at_offset works nice if you pass the end offset you obtained at previous call. In IAccessible2 word you need to use a couple consisting of getTextAtOffset and getTextBefore/AfterOffset to move backward/forward. I'd say IAccessible2 text is simplified (a human friendly) version of ATK text. I won't object if somebody says that ATK looks more powerful. But the same time I'm not sure screen readers need this power.
Anyway IAccessible2 text looked so close to ATK and thus originally we mapped IAccessible2 boundary constants into ATK constants and we ended up with shared logic between these APIs. It was done several years ago and we never revisited this code.
Now we are going to change. IAccessible2 consumers please keep the track of our progress to catch regressions early.
Both IAccessible2 and ATK allows you to navigate the text by characters, words and lines. To do so they both provide these three methods:
- get text *at* offset
- get text *after* offset
- get text *before* offset
A difference #1. IAccessible2 getTextAtOffset may return nothing when you asked for a word. This happens when the given offset is between words (see the spec).
If the index is valid, but no suitable word (or other text type) is found, a NULL pointer is returned.
ATK always returns a word, no matter where you are because it requires to return the text between two word start or word end offsets (check out the spec).
A difference #2. IAccessible2 getTextAfter/BeforeOffset always return the requested lexem after/before the given offset.
Returns the substring of the specified text type that is located after/before the given character and does not include it. The result of this method should be same as a result for IAccessibleText::textAtOffset with a suitably increased/decreased index value.
ATK get_text_after/before_offset methods may return a lexem at the offset under certain circumstances. For example here's the case of word end boundary in get_text_after_offset method:
If the boundary_type is ATK_TEXT_BOUNDARY_WORD_END the returned string is from the word end at or after the offset to the next work end.
In short ATK and IAccessible2 supply two resembling but different concepts of text traversal. ATK allows you to move through the whole text by any method. For example, text_get_text_at_offset works nice if you pass the end offset you obtained at previous call. In IAccessible2 word you need to use a couple consisting of getTextAtOffset and getTextBefore/AfterOffset to move backward/forward. I'd say IAccessible2 text is simplified (a human friendly) version of ATK text. I won't object if somebody says that ATK looks more powerful. But the same time I'm not sure screen readers need this power.
Anyway IAccessible2 text looked so close to ATK and thus originally we mapped IAccessible2 boundary constants into ATK constants and we ended up with shared logic between these APIs. It was done several years ago and we never revisited this code.
Now we are going to change. IAccessible2 consumers please keep the track of our progress to catch regressions early.
No comments:
Post a Comment