Context Navigation

Changes between Version 1 and Version 4 of Ticket #11700

Ticket #11700
- Property Status changed from new to confirmed
- Property Cc IRINAURU@… giorgio satya_minnekanti@… chrisgui@… added

-                      v1
+                      v4
 We should think about providing good a11y for widget.
 Currently screen readers treats every widget as an end of the element. We need to be far better than that.
+Currently screen readers treats every widget as the end of an element. We need to do far better than that.
 The most important requirements i see at the moment are:
 …
 Here i have no clear conception as of yet, because you're only able to access editable using the tab key, but it iterates from the very beginning of the document, rather than current caret position.
 ways comes to my mind, easier:
+Currently 2 solutions come to my mind:
 Solution 1
 …
 * Allow only to enter into editable (with {{{tab}}} key) only when widget is focused
 * We don't need to inform our end-user what widget he's in (that reduces extra time spent on listening). The only one information he will need is the name of editable itself
 * Important implementatino detail would be to allow focus cycling inside widget
+* Important implementation detail would be to allow focus cycling inside widget