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

A11y_AzureToolsStorageExplorer_SASGenerate_Keyboard: Keyboard focus is not in logical order after Close control. #1912

Closed
Suraj1200499 opened this issue Sep 25, 2019 · 7 comments
Assignees
Labels
:accessibility: accessibility Related to keyboard accessibility :accessibility: MAS Required for MAS accessibility compliance ❔ external Root cause of this issue is in another component, product, or service 📦 electron update required Requires updating to a newer version of electron

Comments

@Suraj1200499
Copy link

Suraj1200499 commented Sep 25, 2019

Check out Accessibility Insights! Identify accessibility bugs before check-in and make bug fixing faster and easier.”

GitHubTags: #A11y_AzureToolsStorageExplorer; #A11yMAS; #A11YTCS; #DesktopApp; #MAS2.4.3; #Keyboard; #Win32;

Environment Details:
Application Name: Azure Tools Storage Explorer
Application Version: 1.10.0
Windows10

Repro Steps:

  1. Launch Storage Explorer
  2. Navigate to "Open Connect dialog" pane and Sign in to Azure.
  3. Go to "Manage Accounts" pane and Select the subscriptions you will use. Once selected, click on "Apply" button.
  4. Navigate to "Blob Containers" of the selected subscription, right click and hit enter on "Create Blob container" to Create a new Blob container.
  5. Once completed, Navigate to "Upload" button and Upload a blob/file by using "Upload Files" control.
  6. Blob gets uploaded, right click on blob and select "Get Shared Access Signature" control and hit enter.
  7. Navigate to "Create" button and hit enter.
  8. Start navigating on the screen using Tab key.
  9. Verify Keyboard focus is not in logical order after Close control.

​Actual:​
While navigating on the screen using Tab key, Keyboard focus is not in logical order after Close control.

Expected:
While navigating on the screen using Tab key, Keyboard focus should be in logical order after Close control.
Means after close control when we tab keyboard focus should shift to copy button of "Url" disabled edit box, focus should not shift to "Query string" disabled edit box.
And also keyboard focus should not shift to disabled controls while navigating on the screen using Tab key.

UserImpact:
Keyboard only users face difficulty to navigate on the screen if keyboard focus is not in logical order on the screen.

Recommendation:
https://microsoft.sharepoint.com/teams/msenable/mas/Pages/browse-fixes.aspx

MAS Reference:
https://microsoft.sharepoint.com/:w:/r/teams/msenable/_layouts/15/WopiFrame.aspx?sourcedoc={0de7fbe1-ad7e-48e5-bcbb-8d986691e2b9}

Attachment for Reference:
A11y_AzureToolsStorageExplorer_SASURL_Keyboard.pptx

@MRayermannMSFT MRayermannMSFT added this to the 1.12.0 milestone Sep 30, 2019
@MRayermannMSFT MRayermannMSFT added :accessibility: accessibility Related to keyboard accessibility :accessibility: MAS Required for MAS accessibility compliance labels Sep 30, 2019
@craxal craxal added this to Committed in Storage Explorer via automation Nov 12, 2019
@craxal craxal moved this from Committed to Investigating in Storage Explorer Nov 15, 2019
@craxal craxal changed the title A11y_AzureToolsStorageExplorer_SASURL_Keyboard: Keyboard focus is not in logical order after Close control. A11y_AzureToolsStorageExplorer_SASGenerate_Keyboard: Keyboard focus is not in logical order after Close control. Nov 15, 2019
@craxal
Copy link
Contributor

craxal commented Nov 15, 2019

Verified, but...

@Suraj1200499 You said keyboard focus should shift to the copy button of "Url" after the Close button instead of any disabled text inputs. But none of these inputs are actually disabled. They are read-only, which means the text is selectable, and therefore the input is focusable. This is by design.

Visually, there's only one potentially confusing thing that happens. When focus moves forward from the Close button, the body receives focus. As a result, for some odd reason, the last chunk of text in an input that was selected gets highlighted again. However, the screen reader doesn't announce this, so I don't think there would be any confusion.

@craxal craxal added the ✅ by design Issue is intentional (not a bug) label Nov 18, 2019
@craxal craxal closed this as completed Nov 18, 2019
Storage Explorer automation moved this from Investigating to Done Nov 18, 2019
@Suraj1200499
Copy link
Author

@craxal When tab to move focus from the Close button, keyboard focus shifts to "Query String" read-only control and then to "Container" control which is not logical. Although screen reader not announces this but keyboard only users face in difficulty for understanding the keyboard focus order.

So after Close button if we tab keyboard focus should shift to "Container" control instead of shifting to "Query String" control.

@craxal craxal reopened this Nov 19, 2019
Storage Explorer automation moved this from Done to In Progress Nov 19, 2019
@craxal craxal moved this from In Progress to Under Review in Storage Explorer Nov 19, 2019
@craxal craxal moved this from Under Review to Blocked in Storage Explorer Nov 19, 2019
@craxal
Copy link
Contributor

craxal commented Nov 19, 2019

This bug should automatically resolve when we remove the extra tab stop on the dialog <body>/window, which is resolved as of Electron v5.0.0 (electron/electron#12919). Which means we can't fix this bug until after we update Electron.

A potential workaround is we can re-style the selected text to only show up if the input element has focus. @MRayermannMSFT, however, doesn't think this this workaround is appropriate (I'll let him leave a comment explaining why if he wants).

@craxal craxal added ❔ external Root cause of this issue is in another component, product, or service 📦 electron update required Requires updating to a newer version of electron and removed ✅ by design Issue is intentional (not a bug) labels Nov 19, 2019
@Suraj1200499
Copy link
Author

@craxal
As mentioned "Electron Update Required", We will verify this issue Once "Microsoft Tools Storage Explorer" application is updated to Newer Version(1.12.0).

@craxal
Copy link
Contributor

craxal commented Dec 9, 2019

Verified this is fixed after upgrading to Electron 7.x.

@MRayermannMSFT MRayermannMSFT added this to Needs Exception Process in Accessibility Compliance via automation Jan 27, 2020
@Alexandria-R
Copy link

Approved for exclusion as medium impact.

@MRayermannMSFT MRayermannMSFT moved this from Needs Exception Process to Blocked (Exception Process Complete) in Accessibility Compliance Feb 14, 2020
Storage Explorer automation moved this from Blocked to Done Feb 14, 2020
@mstechie
Copy link

mstechie commented Mar 5, 2023

GitHubTags:#BM-TCS-StorageExplorer-Win32-Sep2019;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:accessibility: accessibility Related to keyboard accessibility :accessibility: MAS Required for MAS accessibility compliance ❔ external Root cause of this issue is in another component, product, or service 📦 electron update required Requires updating to a newer version of electron
Projects
Development

No branches or pull requests

5 participants