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

[TECHNICAL] Changes in accessibility role management #4462

Closed
16 tasks done
JuancaG05 opened this issue Sep 5, 2024 · 0 comments · Fixed by #4466
Closed
16 tasks done

[TECHNICAL] Changes in accessibility role management #4462

JuancaG05 opened this issue Sep 5, 2024 · 0 comments · Fixed by #4466

Comments

@JuancaG05
Copy link
Collaborator

JuancaG05 commented Sep 5, 2024

Regarding this PR #4454, there are several things that can be improved:

  • Include contentDescription as another parameter in the setAccessibilityRole extension function, so that we avoid implementing AccessibilityDelegateCompat again, like in SortOptionsView
  • Check if onCreateOptionsMenu can actually be moved to FileFragment and remove it from its subclasses
  • When setting contentDescription as a concatenation of several Strings, add a space in between so that they form a sentence correctly. Make it in a more Kotlinized way
  • String <string name="content_description_add_new_content_expanded">"Add new content expanded"</string> shouldn't have the "
  • String <string name="content_description_sort_by_name_descending">sort by %1$s descending</string> should start by a capital letter to be consistent with its analogue content_description_sort_by_name_ascending

Other refactor that has to do with accessibility but not with role management, regarding #4455:

  • KeyEvent.KEYCODE_TAB shouldn't be handled like that, since it breaks the navigation model. Tab should be used to move to the next element in the view, not moving to lock_time (which is not always visible)
  • KeyEvent.KEYCODE_DPAD_DOWN should just move the focus from the toolbar to the first element in the view, if possible, not moving it straight to the custom number keyboard shown in the view. That's how the navigation model works in other views
  • Check why introducing the numbers with the keyboard makes the passcode visible

TASKS

  • Research (if needed)
  • Create branch technical/refactor_accessibility_role
  • Development tasks
    • Include contentDescription as parameter in setAccessibilityRole
    • Check onCreateOptionsMenu in FileFragment feasibility
    • Kotlinize Strings concatentation and add missing spaces in between
    • Fix content_description_add_new_content_expanded String
    • Fix content_description_sort_by_name_descending String
    • Check KeyEvent.KEYCODE_TAB handling
    • Check KeyEvent.KEYCODE_DPAD_DOWN handling
    • Check passcode visibility when introducing numbers from the keyboard
    • Implement unit tests (if needed)
  • Code review and apply changes requested
  • Design test plan
  • QA
  • Merge branch technical/refactor_accessibility_role into master
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants