Closed Bug 405810 Opened 13 years ago Closed 13 years ago

Screen readers incorrectly report line position

Categories

(Core :: Disability Access APIs, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: aaronlev, Assigned: aaronlev)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Attachments

(1 file, 4 obsolete files)

We need to support the following text attributes on any root accessible editable text object that has focus.

These attributes report the current position of the caret in user-centric terms. Like groupPosition() the screen reader can use these more efficiently than calculating the info itself.

Most important:
line-number:[unsigned int]
column-number:[unsigned int]

Would be useful:
total-columns:[unsigned int] -- only expose for plain text editors, because it does not make sense for a proportional font.
total-lines:[unsigned int]

Future:
In the future if we ever get any kind of page breaks in our editor we would also want to expose:
page-name
page-number
total-pages
It turns out the column stuff is for newspaper columns. We don't need to support that yet.

So, let's just focus on line-number. They'll fix their code to compute the char position.
Summary: Screen readers incorrectly report line and column position → Screen readers incorrectly report line and char position
(In reply to comment #1)
> It turns out the column stuff is for newspaper columns. We don't need to
> support that yet.

Why not?
Go ahead if it's easy, but CSS columns are almost never used yet. So it's just not critical for Firefox 3.
Surkov, just do line-number only.
Summary: Screen readers incorrectly report line and char position → Screen readers incorrectly report line position
Attached patch WIP (obsolete) — Splinter Review
Assignee: surkov.alexander → aaronleventhal
Status: NEW → ASSIGNED
For heading following by regular text, the regular text line #s don't work. Vice versa it does work.
Attachment #291768 - Attachment is obsolete: true
This is correctly reporting line-number for input, textarea, designMode and contentEditable
Attachment #291771 - Attachment is obsolete: true
Attachment #291813 - Flags: review?(ginn.chen)
I thought it should be text attribute.

Isn't the simple version of line-number from patch of bug 345759 suitable for us? Do we need to accumulate line numbers in accessible?
Surkov, no it shouldn't be a text attribute:
1) We need to mimic what Lotus Notes ODF support has, which is already supported in some screen readers
2) Doing it as a text attribute would inconveniently break up other text attribute runs.
Surkov, I'm sorry, when I wrote up the bug I said text-attributes. My fault.

I just verified with Pete Brunet that it needs to be an object attribute.

So, the current patch would appear to be correct.
I think "line number" is not a good word to describe the attribute.
maybe we should use "caret in line" or something else.

And, frameSelection->GetFrameForNodeOffset can't be called from libaccessibility.so.
So we have a problem if not enable-static.
Ginn, I forgot to include nsFrameSelection.h in patch for review-- this should remove concerns about building successfully

We can't change the name line-number. It's already used in shipping products (Lotus Symphony and some Windows screen readers).
Attachment #292049 - Flags: review?(ginn.chen)
Attachment #291813 - Attachment is obsolete: true
Attachment #291813 - Flags: review?(ginn.chen)
Attachment #292049 - Flags: review?(ginn.chen) → review+
Attachment #292049 - Flags: superreview?(roc)
Attachment #292049 - Flags: superreview?(roc) → superreview+
Attachment #292049 - Flags: approval1.9?
Does making GetFrameForNodeOffset virtual have any performance impact?
Robert, can you answer Mike's question in comment 14? I'm not sure.
Attachment #292049 - Flags: approval1.9? → approval1.9+
Checked in line-number object attribute support. Will be in 12/12 builds.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.