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

Toolbar - About accessibility #42

Open
zwiastunsw opened this issue Jul 14, 2018 · 3 comments
Open

Toolbar - About accessibility #42

zwiastunsw opened this issue Jul 14, 2018 · 3 comments

Comments

@zwiastunsw
Copy link
Contributor

zwiastunsw commented Jul 14, 2018

The toolbar is a key element of the Joomla Backend user interface. It contains a set of tools that allow you to perform various operations on content items. Therefore, the administrator should:

  • get quick and direct access to the toolbar from anywhere in the workspace
  • after performing the action, return to the place from which the action available in the toolbar was called
  • move between the options of the toolbar with the arrow keys
  • run actions optionally with mouse or default keyboard key (Space - actions, Enter - links).

The accessibility requirements that a good toolbar should meet are precisely defined in WAI-ARIA Authoring Practices 1.1.

Results of current tests

I tested in Windows 10, with NVDA 2018.2.1 and ChromeVox.

  1. The toolbar is fully accessible to mouse users (and sighted users), but not to keyboard and blind users.
  2. There is no way to access the toolbar quickly and directly. To access the toolbar, the keyboard user must use the Tab key to visit all the controls that are located before the current cursor position or after the current cursor position, one by one. To fix this problem, we can
    -- (1) create a new special navigation element on the Backend pages,
    -- (2) use the accesskey attributes.
  3. Moving between buttons requires the use of Tab or Shift+Tab instead of the default arrow keys. The Tab or Shift+Tab keys should move to the next/prev control item. To correct this problem, we must implement correct keyboard support, as described in the WAI-ARIA Authoring Practices 1.1.
  4. After executing the selected action, the user does not return to the place from which the action was called. The reason is the unimplemented keyboard support.

In addition, the screen reader announces the role and label of the toolbar, which sounds the same (toolbar). This is not a good practice. It's best to use a label that describes the purpose of the toolbar, e.g. "Action menu".

@dgrammatiko
Copy link

FWIW, the toolbar will be transformed to mostly few buttons (2-4) one of them being dropdown with all the action (publish, unpublish, etc), so can you please hold this till Rick comes up with the new code?

@zwiastunsw
Copy link
Contributor Author

@dgrammatiko : Of course

@zwiastunsw
Copy link
Contributor Author

zwiastunsw commented Jan 29, 2019

This problem is not solved.
The toolbar is fully accessible to mouse users (and sighted users), but not to keyboard and blind users. There is no way to access the toolbar quickly and directly.
After executing the selected action, the keyboard and blind users does not return to the place from which the action was called. The reason is the unimplemented keyboard support.

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