Confirmed users
1,396
edits
Accessibility/TextImplementation: Difference between revisions
Jump to navigation
Jump to search
Accessibility/TextImplementation (view source)
Revision as of 05:55, 28 October 2011
, 28 October 2011→Current state
No edit summary |
|||
| Line 5: | Line 5: | ||
Text of the accessible is exposed as a string having embedded object characters which point to nested accessible. Nested accessible may be a text accessibles. In order to get next character or word the AT should crawl the tree until they get a real character or word. While this approach is suboptimal but the main problem is the text received from tree inspection is not necessary consistent with keyboard navigation in general. | Text of the accessible is exposed as a string having embedded object characters which point to nested accessible. Nested accessible may be a text accessibles. In order to get next character or word the AT should crawl the tree until they get a real character or word. While this approach is suboptimal but the main problem is the text received from tree inspection is not necessary consistent with keyboard navigation in general. | ||
Let's consider | Let's consider two examples: | ||
<pre>text<a>link</a>text</pre> | |||
and | |||
<pre>text<a>a link</a>text</pre> | |||
Both are exposed as textXtext where X is embedded object character. Text implementation relying on embedded character approach expose three words. From keyboard navigation point of view these examples have one and two words respectively. If AT doesn't make any assumption what the word can be based on tree inspection then no way to get words in consistent way with keyboard navigation. | |||
=Proposal= | =Proposal= | ||