Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Difficulty to know which plural form is selected #863

Open
CyrilleB79 opened this issue Sep 13, 2024 · 9 comments
Open

Difficulty to know which plural form is selected #863

CyrilleB79 opened this issue Sep 13, 2024 · 9 comments

Comments

@CyrilleB79
Copy link

CyrilleB79 commented Sep 13, 2024

I am a blind translator of NVDA screen reader.

As a blind user, when translating plural forms it's difficult to know from the GUI which form is being translated.

Steps to reproduce with NVDA

  1. Open a .po file containing a string to translate with a plural form, for a language with 2 forms (1 singular and 1 plural).
  2. Select this string in the list
  3. Press tab until you reach the "Singular" button (i.e. at least 5 times)
  4. Press tab once again to go to the "plural" button
  5. Press "enter" to press the "plural button
  6. Press "space" to press the "plural button. Then the focus jumps to the translation edit field.
  7. Listen to the name of the edit field

Actual result

  • Steps 3. and 4. one of the two buttons should be active (and actually it is visually underlined), but this information is not conveyed by any mean to the accessibility APIs.
  • Step 5: nothing happens
  • Step 7: the accessible name of the edit field is named "singular"; I am unsure if this name is provided by poedit to accessibility APIs or if it's derived from something else by the APIs themselves or by the screen reader NVDA.

Expected result

  • Steps 3. and 4. one of the two buttons should report a state indicating to accessibility APIs that it is selected (e.g. pressed for a button, checked for a checkbox, selected for a tab, etc.). Alternatively, if it's difficult to provide a state to accessibility APIs, the name of the button should include its state.
  • Step 5: the button should have been activated (but this issue is quite minor since we may use space).
  • Step 7: the accessible name of the edit field should match the name of the selected (underlined) button, i.e. "plural" here

Notes

By the way, thanks to @LeonarddeR and you for the recent accessibility improvement in poedit.

@vslavik
Copy link
Owner

vslavik commented Sep 19, 2024

Poedit uses a "fake" notebook control here, assembled from some panels and buttons. This is actually broken in multiple interesting ways:

  1. For screen readers, there's no notebook. I think it would be desirable to just use a standard notebook in the presence of screen reader, appearance be damned, no? (This is already done e.g. for other visual flair like menus or title-less windows.)
  2. TAB navigation is thoroughly broken and while 1 would fix it, this needs to be fixed in the "visual" version too: TAB needs to move into the tab, not among the buttons, and left/right arrows need to be supported.
  3. A11y names for text controls are missing (and may be hard to read).

I'm not sure where does "singular" come from; I don't see that in Accessibility Insights.

Regarding the last point, I also wonder about the usability of the tab names. For Roman languages, they are just plural/singular, but for many other languages, there are more than 2 forms and Poedit shows descriptive labels, e.g. for Czech it shows "One", "n → 2,3,4" and "n → 0,5,6,7" as the tabs. Many other systems use CLDR nomenclature ("One", "Few", "Many") that is easier to pronounce, but I, as a translator, never know what they apply to w/o checking, so I tried to do better for Poedit. Now I wonder if NVDA chokes on that or not and if a different phrasing (e.g. "2,3,4 etc.)" would be more helpful...?

@CyrilleB79
Copy link
Author

Yes, a standard notebook controller should probably be more usable. If the focus stops once on the tabs list and if we can change the selected tab with left/arrow, that would be nice and completely usable.

Re the name of the buttons/tabs for Slavic languages:
I am not a translator of these languages. But I have worked on pluralization support in NVDA and thus have conducted tests with some of these languages. For someone who do not know the specificity of each langauge, I'd say than having the examples numbers (as today) is much more helpful than "some", "few", etc.

vslavik added a commit that referenced this issue Oct 30, 2024
@CyrilleB79
Copy link
Author

A standard notebook controller has been implemented in b6f7be8. Many thanks, the experience is now totally correct.

Thus points 3, 4 and 5 are now solved or not applicable anymore.

Point 7 (text field name) still remains, but it's an NVDA problem (see in NVDA's poedit app module, class PoeditRichEdit, method _get_name)

@vslavik
Copy link
Owner

vslavik commented Dec 3, 2024

Please don't close issues yourself. This is still not fully fixed.

@vslavik vslavik reopened this Dec 3, 2024
@CyrilleB79
Copy link
Author

OK. I'll submit a fix in NVDA and let you know if/when it is merged.

@vslavik
Copy link
Owner

vslavik commented Dec 3, 2024

@CyrilleB79 No, sorry, I meant that there still are a11y things like keyboard navigation to fix...

@CyrilleB79
Copy link
Author

What are the remaining keyboard navigation issues? From my experience, keyboard navigation is now quite correct.

@vslavik
Copy link
Owner

vslavik commented Dec 3, 2024

See the comments above. It definitely is not without a screenreader (which is still an a11y issue - unusable keyboard navigation).

@CyrilleB79
Copy link
Author

Regarding TAB navigation, I do not understand your point: when "Needs work" is focused and if I press TAB, the focus jumps on the selected tab of the tab control, and pressing left/right arrow here allows me to focus (and thus select) another tab as I would expect.

Regarding missing A11y names for text controls, that's true. It's worth noting that NVDA uses a dedicated retrieval of the name based on the position of the controls in the GUI, namely looking at the name of the control above the text control. This strategy is not very robust and is actually not completely working today, probably due to slight layout changes in newer poedit versions. So NVDA (2024.4.1) should not be used as is to check text control naming.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants