nvaccess / nvda

NVDA, the free and open source Screen Reader for Microsoft Windows
https://www.nvaccess.org/
Other
2.11k stars 637 forks source link

major problems with Arabic text and Thunderbird's composition area #5677

Open mohdshara opened 8 years ago

mohdshara commented 8 years ago

Hi.

In Mozilla's rich text areas, like In Thunderbird's composition area, a rich textarea on Firefox like this body area of a ticket, , entering and editing Arabic text has major problems:

  1. open a new message and in the body area write a word like قفز "jumped" to make it easy, here's the word in a line alone: قفز
  2. press home to move to the begining of the line. you correctly hear the first letter ق however, move right you will hear the letters in reverse as expected, as Arabic is an RTL language: ز ف ق however, why do I hear the first letter when I press home when the cursor isn't on the first letter in reality? I expect to hear the letters in correct order if I move using the left arrow key, but I don't.

3 the situation becomes messier if I write 2 words on 2 lines like this: قفز القط in the first line, I hear the 2 words together, although each is on a separate line.

there are probably more problems, but this is the simplest description that I could come up with.

windows 10 64 bit, Nvda 2015.4, Firefox v43.0.4, any version of thunderbird, and Arabic keyboard is of course added.

jcsteh commented 8 years ago

All of these issues are almost certainly problems that need to be fixed in Mozilla, since NVDA relies completely on the application for cursor navigation. However, let's try to establish the problems.

  1. press home to move to the begining of the line. you correctly hear the first letter ق however, move right you will hear the letters in reverse as expected, as Arabic is an RTL language: ز ف ق however, why do I hear the first letter when I press home when the cursor isn't on the first letter in reality?

I'm not sure I understand this. You say the behaviour when you use the right arrow key is expected, but I think that might not be what you meant. In Thunderbird's message composer, if I type the word you provided and press home, I land on "ق". If I press left arrow, I land on "ف". As I understand it, that is expected, since Arabic is RTL.

Note that in browse mode, we don't switch direction for RTL languages. Right arrow always moves to the next character (regardless of direction) and left arrow always moves to the previous character. However, you seem to be referring only to the composition area here. Are you perhaps getting these mixed up?

3 the situation becomes messier if I write 2 words on 2 lines like this: قفز القط in the first line, I hear the 2 words together, although each is on a separate line.

This is definitely a Mozilla bug. Interestingly, it doesn't occur if you add another line (blank or English) after the two lines.

ehollig commented 6 years ago

CC @jcsteh, do you know if this has been fixed in Mozilla, or an issue has been created?

jcsteh commented 6 years ago

Not as far as I know. However:

  1. I asked questions about this which haven't yet been answered by the reporter; see https://github.com/nvaccess/nvda/issues/5677#issuecomment-171472364.
  2. While Mozilla still have some involvement with Thunderbird, Mozilla itself isn't actively developing it any more. This means this is unfortunately unlikely to get fixed because the Thunderbird project probably doesn't have anyone with the required accessibility expertise.
  3. Thunderbird is (for now) still based on Mozilla Gecko, but the future of that seems unclear. We might be able to make a case for getting this bug fixed in Firefox (and thus Gecko) if it can be reproduced there, but whether Thunderbird actually ends up including that fix is an open question.
mohdshara commented 6 years ago

I may have indeed confused something. let me attempt to explain this better: In a rich text area like this one, and using focus mode, if I type the word: قفز and then press home, I hear, ق. that's fine. now if I move using the right errow I hear ز. that's not expected because ف is the expected next letter. if I press home and then press the left errow I hear blank. the second issue still stands as I explained if you typed 2 words on 2 seprate lines. I am fine to file this bug aggainst Firefox and with changing the tile of the issue to reflect this fact. Firefox v58 beta NVDA 2017.4

Adriani90 commented 5 years ago

@mohdshara I guess you mean thunderbird 58. Right? Or is this a firefox issue?

jcsteh commented 5 years ago

@mohdshara's mention of Firefox was intentional. If the issue is reproduceable in Firefox, there's a much better chance of getting it fixed, since Mozilla Corporation has staff who can fix issues with editor and accessibility. That fix would then be rolled into Thunderbird, since it uses the core Mozilla code. In contrast, if it's Thunderbird specific, the chances of getting it fixed are much lower, since Thunderbird is no longer developed by Mozilla Corporation and the team that develops Thunderbird probably doesn't have any staff who work on editor and certainly not accessibility.

Adriani90 commented 4 years ago

@mohdshara can you still reproduce this issue in NVDA 2019.2.1 in Thunderbird 68.3.0 or in Firefox 70.0.1?

mohdshara commented 4 years ago

alright, Firefox V71.0 and NVDA 2019.2, and using the body of this very ticket: If I type the 2 words in separate lines without trying to right align them قفز القط

  1. I hear each word in the correct order as I arrow up or down.

  2. pressing home on either of them makes NVDA speak the correct first letter.

  3. Arrowing left when my cursor is placed on the first letter I hear blank as expected.

  4. Arrowing right doesn't make NVDA speak the expected second ord third letter. However, if I type them and right align them by first selecting them and then pressing ctrl + right shift: قفز القط

  5. I hear each word in the correct order as I arrow up or down as long as I make sure to leave a blank third line.

  6. pressing home on either of them makes NVDA speak the correct first letter.

  7. Arrowing right when my cursor is placed on the first letter I hear blank as expected.

  8. pressing the left cursor key spells them correctly.

  9. focus on the first letter of the first word and press shift + down arrow to select that line you hear both lines at the same time. you have to disregard this and press the down arrow again to really select both lines.

  10. all sorts of weird problems I can't explain start happening after any text selection.

it's worth noting that this is specific to Firefox. I no longer use Thunderbird to be able to comment on the status of that.

I hope the description above is clearer?

Adriani90 commented 1 year ago

This seems still reproducible also in Thunderbird 115.1.0 with NVDA 2023.2 Beta 3. @emitche if you might have some ressources, could you have a look at this old issue as well? I think this could contribute alot to more accessibility in the arabic context in general.

emitche commented 1 year ago

This seems still reproducible also in Thunderbird 115.1.0 with NVDA 2023.2 Beta 3. @emitche if you might have some ressources, could you have a look at this old issue as well? I think this could contribute alot to more accessibility in the arabic context in general.

Thank you. I won't get to this immediately, but I can make sure we are tracking this bug at Thunderbird.

Thank you for this report.

Adriani90 commented 2 months ago

The navigation seems still broken in Firefox and Thunderbird when blank lines or other lines of non arabic text are added. This is also valid for arrow key navigation, not only home and end.

I guess it is hard to develop an algorythm to perform the correct actions when two types of reading are combined. Technically, I think blank lines are always computerized as left to right and not right to left, if I am not mistaken. So adding a blank line will directly impact the flow of the system caret when reading arabic text.

A solution could be to have a second system caret appearing when arabic text appears but this is something that should be handled by the OS and not by the screen reader.