AzureStorageExplorer
AzureStorageExplorer copied to clipboard
microsoft
Color contrast of keyboard focus with background color is 1.119 : 1 on list item of download drop down button: A11y_Azure Tools Storage Explorer_Blob container_Download_Non text Contrast
Preflight Checklist
- [x] I have installed the latest version of Storage Explorer.
- [x] I have checked existing resources, including the troubleshooting guide and the release notes.
- [x] I have searched for similar issues.
Storage Explorer Version
1.36.2
Architecture
x64
Platform
Windows
OS Version
Windowns11
GitHub Tags
#A11yMAS; #A11yTCS; #Win32; #DesktopApp; #A11ySev2; #BM_AzureToolsStorageExplorer_Win32_Dec2024; #Azure Tools Storage Explorer; #WCAG1.4.11; #FTP; #A11yWCAG2.1; #External; #External:Chrome; #eDAD:3P:Bug239940; #Third part; #Regressed:04-03-25; #ResolvedByTT;
Environment Details:
Application: Microsoft azure storage explorer Version: 1.36.2 OS: Windows 11 Enterprise 24H2 Build: 26100.2605
Repro Steps
- Launch the Azure Tools Storage Explorer.
- TAB till "Blob container" in tree view and press ENTER key to expand it.
- TAB till any blob container and press ENTER key.
- TAB till "Download" button and press ENTER key.
- Press Down arrow key to list items
- Check the color contrast of keyboard focus
- Observe that Color contrast of keyboard focus with background color is 1.119 : 1 on list item of download dropdown button.
Actual Experience
Color contrast of keyboard focus with background color is 1.119 : 1 on list item of download drop down button.
Expected Experience
Color contrast of keyboard focus with background color should equal or greater than 3:1
User Impact:
Low visibility user will face difficulty to find the keyboard focus because color contrast of keyboard focus with background color is less than 3:1
Attachment
@kapilvaishna You mention a radio button, but we're not entirely sure what you are referring to. Can you provide a screenshot or GIF if the issue?
@craxal sorry for inconvenience now corrected it and added screen shot in bug discerption.
@kapilvaishna This list item in question is a context menu, and it is rendered by the system, not our application. We do not have any control over the colors of the menu.
@craxal Could you please conform the external team service tree id/name and are path to rout this bug to them.
@kapilvaishna I'm not sure. You'd have to redirect it to the Windows team.
Just to be clear, is the #F2F2F2 color in reference to the text or to the hover background? The #F2F2F2 color in Accessibility Insights doesn't seem to match the actual color of the text in the screenshot, and the text color seems to contrast enough to me. Please double-check.
If this is about the hover background color, then I don't think this is an actual violation of any standards. Some statements from WCAG 1.4.11:
Note that this requirement does not apply to inactive user interface components.
This Success Criterion does not require that changes in color that differentiate between states of an individual component meet the 3:1 contrast ratio when they do not appear next to each other. For example, there is not a new requirement that visited links contrast with the default color, or that mouse hover indicators contrast with the default state.
@kapilvaishna Unless you have additional comments or can verify the details I mentioned above, I will be closing this as not a bug.
@craxal i have verified, here color contrast is felling for keyboard focus indicator color with background color, and I am following on this to log external bug to window. As per external bug process once external bug will fix. I will verify and close this bug. Thanks!
@kapilvaishna It looks like it's an issue with Electron, because other apps like Edge and File Explorer don't have this problem. I would still push the Windows end of things in case Electron pushes back saying they're just using Windows native menus.
| Electron | Other Apps |
|---|---|
I have created an issue against Electron: https://github.com/electron/electron/issues/45068. We update Electron regularly, so we'll keep an eye on this to see if an Electron update fixes this.
@kapilvaishna It appears that this is may be underlying issue with Chromium, which Electron depends on.
Since this an external issue, what's the process? Can we close or get an exception?
@craxal I have dropped mail to chromium edge team to log external bug, as per the external bug process, Once the external bug is fixed and closed, we will verify and close this issue.
SL:External to chromium Edge:01-08-25
There is an existing issue that appears to have been open for several years: https://issues.chromium.org/issues/40693702
@craxal The external bug you mentioned is logged against Chrome. Could you please confirm whether the external team is Chrome or Chromium?
There is effectively no difference. Chrome, Edge, Electron, and other projects are all based on Chromium. "Chrome" may be mentioned in the comments, but the bug itself is in Chromium, and fixes are committed to the Chromium code base, which will make their way to Electron.
@kapilvaishna Again, the Chromium bug has been open for several years, so I doubt it will be fixed anytime soon. What is the policy on external issues?
@craxal If any issue is external to first part (Internal to Microsoft) or third party. we follow different processes for each case.
If external team is first party than we will log the bug against them. Once the external bug is resolved and closed, proceed to verify and close the primary bug.
If external team is third party than We will share the sample application with the eDAD team, and they will file a bug against the third party.
I was checking with vendor team of chromium, but they informed me that they don't have that UI in Edge
@kapilvaishna What do you mean by "they don't have that UI in Edge"? Do you mean to say that Edge uses different code for their menus? If that's true, that's fine, but that doesn't change the nature of the bug from our perspective. It's still an external bug that depends on changes in Chromium, which is a third party (linking to the issue again: https://issues.chromium.org/issues/40693702).
@kapilvaishna Can you answer my above questions? External bugs are not something we can resolve within a well-defined timeline, so I don't see much reason for keeping this open.
@craxal as per external but process I will log external bug for this issue and will share but here and till external bug is in active state we can't close this bug as per process.
@kapilvaishna Do you have a link to the external bug that you can post here, please?
Followed up with testers. External bug has been acknowledged. Waiting for links to those external bugs.
@kupatkar99 @kapilvaishna Any updates on the external bugs? I followed the link provided earlier, and I don't appear to have access to see what the current status is.