Closed Bug 345321 Opened 18 years ago Closed 13 years ago

Make sure nsHyperTextAccessible handles bidi text correctly

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: uriber, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: access)

We should make sure nsHyperTextAccessible navigates bidi text in a way which makes sense.
Specifically, we should consider whether to use visual movement (as it is currently) or logical movement - perhaps depending on bidi.edit.caret_movement_style.

<aaronlev>	uri: it's used mostly by screen readers implementing something called "Review mode"
<aaronlev>	where the screen reader provides the users with a set of commands to navigate content, and either speaks the text aloud or renders it on a braille display
<aaronlev>	the user can navigate by char, word, line, sentence, para, heading, etc.
<aaronlev>	uri: it should probably do whatever hitting arrow keys would do in the bidi case
<aaronlev>	i thought about it some but not a lot
<Uri>	At least if we're talking about speaking out text, visual movement doesn't make much sense
<Uri>	aaronlev: Text should always be read in logical order
<aaronlev>	uri: that's true, but the problem is this, let's say you start navigating in review mode to the right, reading 1 char at a time
<Uri>	OK
<aaronlev>	then you exit review mode and start arrowing to the right using the natural firefox commands (i'm talking midas or nvu here)
<aaronlev>	you will now get different results
<aaronlev>	basically i think it's an area where we probably don't do the right thing, but i don't have much time to think about that issue quite yet
<Uri>	aaronlev: So, i suspect that as a first guess, mVisual=FALSE is better
<Uri>	also, for caret movement, we currently have a pref controlling it
<aaronlev>	uri, ok, i think we should file a bug on that
<aaronlev>	but more a general bug, to make it work with bidi text
<aaronlev>	which mentions that issue
<Uri>	aaronlev: OK, do you want me to do that?
<aaronlev>	uri: cool maybe the pref should notice if we're using a screen reader
<aaronlev>	uri: that'd be great
Assignee: aaronleventhal → nobody
Blocks: keya11y
Keywords: access
Blocks: texta11y
No longer blocks: keya11y
I thought screen reader cares about bidi text. Jamie, can I hear you on this?
I don't really understand what this is about. A screen reader "reads"in logical order and offsets should be in logical order. As I understand it, from an API perspective, moving by word/char should be thought of as moving forward or backward (logical), not right or left (visual). If an AT provides its own caret navigation, the AT should be responsible for handling correct caret movement direction. This does require that the app exposes the correct caret direction via accessibility APIs. One other consideration might be to provide a way to move by visual order (up/down/left/right) in APIs.

Note that NVDA doesn't currently change the caret movement direction for its own virtual cursor navigation. We haven't considered how to do this yet either. :(
worksforme per comment #2 (in other words nsHyperTextAccessible handles bidi text correctly).

perhaps it's nice to have additional API to move by visual order to help AT.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.