-
Bug
-
Resolution: Fixed
-
Highest
-
7.19.1
-
Severity 2 - Major
-
Issue Summary
The DOM order is incorrect when the user tries navigating back to the toolbar section.
Steps to Reproduce
- In the Confluence, dashboard select a Space.
- Select Create in the header section.
- On the available page, navigate to the toolbar section and select any tool such as "Bold", "bullet", etc.
- The focus will go on the text field.
- Try to traverse back using "Shift+tab".
Screenshot
Screen recording
Screen Recording 2022-08-25 at 3.10.45 PM.mov
Actual Results
After selecting any tools link from the toolbar section such as bold, italic, underline, heading or any other option from the formatting elements, the focus is directly redirecting to the page text area. And the user is unable to select other options and needs to traverse all the way to the top menu elements again. In order to select the toolbar elements, the user needs to traverse the whole page to select these elements, which is difficult for keyboard-only and assistive technology users.
Also currently when user presses shift + tab key from "page title" input to go back to toolbar the focus goes to "skip to main link inappropriately.
Also the toolbar is disabled when main editor is not focused. This might cause problems for keyboard-only and assistive technology users.
Expected Results
When user actives any option from the toolbar, the focus should not move to the editor. Instead it should stay on the same element. Also screen reader should announce the state of the element whether it is active or not. For that provide aria-pressed attribute with default value as "false" when it is inactive & set to "true" when user activates it.
When user presses shift + tab keys from "page title" input focus should move logically as per visual order of elements.
The toolbar should not be disabled & users should be able to navigate to toolbar as per their choice.
Also we should be able to use roving tabindex mechanism for toolbar elements so that user can tab once & use arrow keys to navigate through all options.
Refer to this Example from W3C => https://www.w3.org/WAI/ARIA/apg/example-index/toolbar/toolbar.html
Note: We should give a try to make some design changes in order to place the elements in more logical order. Following is the new suggested order of elements so that editor is more accessible for all users.
- Main navigation
- Breadcrumbs & invite people
- Toolbar
- Page title
- Main editor.
To summarise, the toolbar & editor should be ideally near to each other on the page so that navigation becomes easier.
Workaround
Currently, there is no known workaround for this behavior. A workaround will be added here when available
- resolves
-
CONFSERVER-90503 Comments: Tabindex attribute defined inappropriately.
-
- Closed
-
Blank page: Incorrect DOM order while editing the page
-
Bug
-
Resolution: Fixed
-
Highest
-
7.19.1
-
Severity 2 - Major
-
Issue Summary
The DOM order is incorrect when the user tries navigating back to the toolbar section.
Steps to Reproduce
- In the Confluence, dashboard select a Space.
- Select Create in the header section.
- On the available page, navigate to the toolbar section and select any tool such as "Bold", "bullet", etc.
- The focus will go on the text field.
- Try to traverse back using "Shift+tab".
Screenshot
Screen recording
Screen Recording 2022-08-25 at 3.10.45 PM.mov
Actual Results
After selecting any tools link from the toolbar section such as bold, italic, underline, heading or any other option from the formatting elements, the focus is directly redirecting to the page text area. And the user is unable to select other options and needs to traverse all the way to the top menu elements again. In order to select the toolbar elements, the user needs to traverse the whole page to select these elements, which is difficult for keyboard-only and assistive technology users.
Also currently when user presses shift + tab key from "page title" input to go back to toolbar the focus goes to "skip to main link inappropriately.
Also the toolbar is disabled when main editor is not focused. This might cause problems for keyboard-only and assistive technology users.
Expected Results
When user actives any option from the toolbar, the focus should not move to the editor. Instead it should stay on the same element. Also screen reader should announce the state of the element whether it is active or not. For that provide aria-pressed attribute with default value as "false" when it is inactive & set to "true" when user activates it.
When user presses shift + tab keys from "page title" input focus should move logically as per visual order of elements.
The toolbar should not be disabled & users should be able to navigate to toolbar as per their choice.
Also we should be able to use roving tabindex mechanism for toolbar elements so that user can tab once & use arrow keys to navigate through all options.
Refer to this Example from W3C => https://www.w3.org/WAI/ARIA/apg/example-index/toolbar/toolbar.html
Note: We should give a try to make some design changes in order to place the elements in more logical order. Following is the new suggested order of elements so that editor is more accessible for all users.
- Main navigation
- Breadcrumbs & invite people
- Toolbar
- Page title
- Main editor.
To summarise, the toolbar & editor should be ideally near to each other on the page so that navigation becomes easier.
Workaround
Currently, there is no known workaround for this behavior. A workaround will be added here when available
- resolves
-
CONFSERVER-90503 Comments: Tabindex attribute defined inappropriately.
-
- Closed
-